OpenMakeWhat OpenMake is
Open-weight AI infrastructure for organizations that need control over their data, models, and agents. An organization picks its own model, connects its own data, lets employees use AI, gives agents real work, and governs permissions, external communication, cost, execution, and audit itself.
On-premise is not the product. It is one deployment option among customer VPC, private cloud, an in-house GPU cluster, and a closed network. The product is the platform that stays identical across all of them, which is why the pitch is not “we will build you a server” but “we will stand up your own AI platform inside your security boundary.”
- Open-weight: Qwen, EXAONE, Llama, Mistral, and any OpenAI-compatible endpoint stay interchangeable, so no commercial provider owns the organization's AI
- Private: whichever environment it runs in, the organization owns the data boundary
- Agentic: work does not stop at question and answer — retrieve, analyze, query internal systems, research, write files, verify, get approval, store the result
- Open source: the runtime ships under the MIT License, so an operator can audit what executes, change it, and run a private fork without asking anyone
Where OpenMake sits
The self-hosted enterprise market already exists and is already being paid for. Dify Enterprise sells VPC, on-premise, and closed-network deployment with SSO, RBAC, audit logs, and data sovereignty. Open WebUI presents self-hosted, on-premise, and air-gapped operation with SSO, LDAP, RBAC, audit, and data residency as its enterprise value. OpenHands redefined its 2026 enterprise product as an agent control plane. Value has moved from making AI answer well to letting an organization operate AI safely.
That is a good signal, but copying any of them is not the plan. A private ChatGPT competes with Open WebUI, an agent workflow builder competes with Dify, and a coding agent collides head-on with OpenHands, Claude Code, and Codex. OpenMake takes a different axis: general knowledge work in a normal company, on open-weight models the organization owns.
Open WebUI
Self-hosted AI interface.
Dify
AI app and workflow builder.
OpenHands
Software agent control plane, focused on software development.
Ollama / vLLM
Model runtime.
OpenMake
Open-weight private AI plus a general agent runtime, for the knowledge work an ordinary organization actually does.
Five operating layers
If these layers are missing, the product is closer to a multi-agent framework than a platform an organization can operate. The roadmap is therefore organized by operating responsibility, not by the number of expert personas in the catalog.
Agent Runtime
Run, pause, resume, cancel, retry, and recover agent tasks as durable state machines.
Control Plane
Identity, RBAC, policy, approval, budgets, secrets, organization settings, and audit rules.
Execution Plane
Actual model, tool, browser, code, file, API, MCP, and sandbox execution.
State & Memory
Task state, checkpoints, sessions, artifacts, RAG, and scoped long-term memory.
Observability
Execution timeline, logs, traces, cost, failure reasons, evaluation scores, and audit reports.
Why this is the right direction
The direction is correct because it strengthens what OpenMake already is: open source, local, operator-owned, open-weight friendly, tool-capable, and transparent about execution. Competing on the number of agents would be easy to copy. Competing on reliable, governed execution inside someone else's boundary is harder and more valuable.
It also makes new models an opportunity rather than a threat. An organization does not pay for Qwen; it pays for the management and execution layer that turns Qwen into a company system. When a better open-weight model ships, that layer gains value instead of losing it.
It protects the local advantage
OpenMake can own the trust boundary: local model route, local workspace bridge, Docker sandbox, and operator-controlled external providers.
It fixes the real bottleneck
The hard part is no longer calling a model. The hard part is preserving state, enforcing permissions, retrying safely, and proving what happened.
It makes Skills the ecosystem unit
External contributors can package workflows, tools, prompts, policies, evaluators, schemas, and tests without turning every feature into core code. The MIT License is what makes that contribution loop possible in the first place.
It gives A2A a sharper role
Multi-agent debate becomes a verifier and reviewer layer for high-risk work, instead of a default tax on every simple request.
How far openmake_llm has come
Measured as a chat and local LLM platform, OpenMake is already substantial. Measured as a governed agent runtime, the durable execution core is no longer the missing piece: as of 1.52.1, agent tasks are persisted rows on a seven-state machine, checkpoint at the end of every turn, pause for approval, auto-resume after a process restart, and record their own token total.
Two qualifications belong with that claim. Most of this runtime ships behind flags that default to off — the task sandbox, the concurrency queue, the local executor, and auto-dispatch are all opt-in, so a fresh install is not the same deployment as the one we run. And the durability is turn-granular: a crash in the middle of a turn replays that turn, tool side effects included, because there is no per-tool-call journal yet.
The remaining gaps are narrower and more specific — sub-turn durability, a real execution graph, scoped memory, and the organization control plane.
Model gateway and local routing: high
The local-first gateway, role-based model routing, external provider adapters, token accounting, and fallback behavior are already close to the model-runtime layer the platform needs. Per-user quota fails open, so today it is accounting rather than an enforcement point.
Durable task runtime: high
Persisted task rows, a seven-state machine with queued and paused, end-of-turn checkpoints, boot recovery that auto-resumes tasks with a valid checkpoint, step-level event logs, schedules, and sandbox or local executor selection are all running. The concurrency queue is opt-in and lives in process memory on a single API instance, with only the queued status persisted.
Local execution surface: high
The bridge that runs tools on a user's own machine is now a single implementation — packages/local-bridge-core — behind three clients: the desktop companion, the openmake-code CLI, and a SwiftUI menu bar app. Path scoping, the execution denylist, non-bypassable confirmation, and the OS sandbox profile live in that core, and creating a local task is written to the audit log.
Tool, sandbox, approval: medium
MCP tools, Docker-isolated external servers, task sandbox tools, file and browser execution, human approval gates, and a network-level egress allowlist for browser containers exist, but they are not yet a full policy-enforced Tool Runtime. An approval wait is an in-memory promise; only the paused status survives a restart.
Execution graph: early
The stored plan is a flat list of steps with a status and a note, and each execution step is attributed back to it by index. It is not yet a durable DAG where each node owns dependencies, permissions, cost caps, retry policy, outputs, and completion criteria.
Memory: partly built
Procedural memory is real: a successful task's browser or script procedure is saved as a procedural skill and replayed on a similar goal without asking the model again. Episodic recall is derived rather than stored — past similar tasks are reconstructed from task and step rows and injected as a compressed block. Semantic memory is the genuine gap: there is no vector store, and user memory is searched by trigram match.
Observability: medium
OpenTelemetry tracing, step-level event logs, audit logs, metrics, and a weekly gate report that renders the evidence behind each measure-first gate. Golden-dataset routing and response evaluations run as CI gates, and one routing gate has already been retired because the measurement did not support it. What is still missing is a first-class audit report an organization can hand to a reviewer.
Enterprise control plane: early
JWT, three roles, API keys carrying bridge and chat scopes, usage, admin screens, and operator settings are present. Multi-tenancy has not started — no tenant, project, or workspace column exists in the schema — and budget policy, data egress control, and deployment approval remain future work.
Where the development effort goes
About seventy percent of development capacity belongs to the enterprise foundation. The gap between the software project and a sellable product is not a missing feature; it is the control plane the last section calls early. These four bands are the order that gap gets closed in.
P0 — required
Organization and tenant, RBAC, project, model policy, data egress policy, audit, secret management, usage and budget.
P1
Execution graph, agent policy, sandbox policy, approval workflow, observability, scoped memory.
P2
SSO with OIDC and SAML, LDAP, SIEM integration, backup and restore, HA, Kubernetes deployment.
P3
Air-gapped installation, offline model registry, offline skill registry, an enterprise update channel.
Community and Enterprise, from one codebase
OpenMake follows an open-core model, because a strong community edition is what makes the enterprise business possible rather than what competes with it. Skills are the ecosystem unit: a contributor should be able to package one workflow without understanding the whole runtime.
OpenMake Community — MIT, free
Single organization, local models, agent runtime, MCP, skills, basic RAG, and a basic sandbox. Strong enough that people install it and keep using it.
OpenMake Enterprise — paid
Organizations, advanced RBAC, SSO and LDAP, policy engine, model governance, data egress control, audit, budget, enterprise deployment, HA, air-gap, and support. None of it is built yet: the schema has no tenant or project column, and every installation today is a single organization.
OpenMake Code as an execution node
Rather than a separate project, the desktop and local tooling becomes the execution node that runs local files, source, terminal, and internal network work under the same control plane. That consolidation has started: the Electron shell was retired once its bridge moved into a shared core, and the execution node is now a native companion, a CLI, and the web that drives them.
What carries forward
OpenMake 1.52.1 already has useful pieces: local-first model routing, role-based orchestration, agent tasks, skills, 22 built-in MCP tools, Deep Research with evidence, NotebookLM grounding, artifacts, operator controls, and one local-work bridge now shared by the desktop companion, the openmake-code CLI, and the native menu bar app. These should be repositioned instead of discarded.
- LLM Gateway stays a gateway: provider auth, streaming, token accounting, timeout, fallback, and parameter normalization
- The message pipeline keeps request processing, while planning separates into a stored planner that emits reusable execution graphs, required permissions, approval points, cost estimates, and completion criteria
- A2A discussion moves out of the default path and into high-risk planning, code review, fact cross-checking, result verification, and complex decisions
- RAG remains the knowledge retrieval layer, while working, episodic, semantic, procedural, and artifact memory become separate runtime concerns
What must be built as core
The missing foundation is not another agent profile. Durable execution — tasks that survive process restarts, checkpoint at the end of each turn, wait for approval, and resume from known state — is now in the product. What is still missing sits above it: a graph the runtime can execute, a policy layer that does not live in prompts, and memory with a scope.
Durable Task Runtime — built
Task model, state machine, worker, event log, checkpoint, cancellation, pause, resume, and retry. This is the layer everything below now stands on. Two pieces stay open: idempotent replay, since a turn that crashes mid-flight re-runs its tool calls, and a queue that outlives the process, since today's is opt-in and in-process.
Execution Graph — planned
DAG nodes with input, output, agent, model, tool, permission, timeout, retry policy, success criteria, cost cap, and approval requirement. Today the stored plan is a flat list of steps.
Policy and Approval — partly built
Server-enforced permission levels from read-only work to external impact, deployment, payment, security, legal, and finance actions. The approval gate covers part of this today; the declarative policy engine behind it does not exist yet.
Tool Runtime — partly built
A registry with schemas, permission metadata, execution mode, timeout, retry policy, telemetry, and standardized result envelopes. The tools themselves run, 22 built-ins plus external MCP, but not behind a registry like this.
Workspace Sandbox — built
Per-task workspace, mounted folders only, process or container isolation, resource limits, network allowlist, and preserved outputs. This one is already running; it is listed here because the layer above still reaches it through ad hoc calls rather than policy.
Memory and Audit — partly built
Scoped memory with source, confidence, sensitivity, expiry, plus traces for plan, model choice, tool calls, cost, approval, failure, retry, and artifacts. Procedural memory and the traces exist; the scope metadata and a semantic store do not.
Build order
The first two stages are largely shipped, so the next defensible step is the Execution Graph. Task state is now reliable; what it still lacks is a plan that names dependencies, permissions, and completion criteria per node instead of a linear turn sequence.
- 01
Durable Task Runtime — shipped
Task data model, state machine, job queue, worker, stored execution plan, checkpoints, cancel, pause, resume, and event log are in the product, and token totals are aggregated on terminal transitions. What remains is sub-turn durability: a per-tool-call journal so a crashed turn does not replay its side effects, and a queue that outlives the process.
- 02
Tools, approval, sandbox — mostly shipped
Tool registry, MCP gateway, approval inbox, workspace isolation, Docker sandbox, secrets, file diff, and browser egress allowlist are in place. The remaining pieces are a declarative policy engine with server-enforced permission levels, and an approval wait that survives a restart instead of living only in process memory.
- 03
Execution Graph — next
DAG nodes that own their dependencies, required permissions, cost cap, retry policy, outputs, and completion criteria, replacing the linear turn loop as the unit of planning.
- 04
Agent and Skill manifests — in progress
Standardize Supervisor, Planner, Worker, Researcher, Reviewer, and Recovery roles; make Skills the package unit for workflows, prompts, policies, tools, evaluators, schemas, and tests. Manifest-driven skill injection and procedural skill extraction have started.
- 05
Scoped memory and organization control plane
Working, episodic, semantic, procedural, and artifact memory with source and expiry; then multi-tenancy, organizations, projects, RBAC, token and cost budgets, external model policy, deployment approval, and operations dashboards.
The next twelve months
The schedule below is about proving the product in a real organization, not about shipping more capability. A single company that installs OpenMake on its working network and uses it every day is worth more than thousands of GitHub stars.
Month zero is August 2026, when this roadmap was settled. The first band is therefore under way rather than ahead of us, and what inside it is already done is marked below.
- 0–3 mo
Fix the product identity — under way
Done: the private AI positioning and the enterprise architecture are what this page now states, three representative use cases are named in the section above, and audit logging has been running for a while. Not yet: organization and project do not exist as concepts in the schema, RBAC stops at three roles with no tenant or project scope, and model policy has not started, although the model measurements that will ground it have begun on OpenMake Bench.
- 3–6 mo
Put it inside real organizations
Three design partners, private VPC deployment, on-premise deployment, SSO, data policy, and skill packaging.
- 6–9 mo
Make it a product, not a build
Enterprise installer, upgrade and backup, monitoring, admin dashboard, Kubernetes, and enterprise pricing.
- 9–12 mo
Prove it sells more than once
Real customers in production, case studies, partners, systems-integration cooperation, and enterprise support.
The first use case, deliberately narrow
The first enterprise demonstration is a private research and document agent, for knowledge-intensive organizations of roughly thirty to five hundred people that cannot put internal material into an external generative AI. Associations, research institutes, public-adjacent bodies, manufacturing R&D departments, mid-sized companies, consultancies, and accounting or legal organizations come before large finance or defense, where certification, procurement, and systems-integration capability are demanded ahead of the product.
An employee asks for the last three years of contracts and related regulations to be analyzed for clauses that could become a problem, and returned as a report. The run searches internal documents, retrieves, answers on an open-weight model, checks policy before any external lookup, researches further, verifies its evidence, writes the report, waits for the responsible person to approve it, produces a PDF, DOCX, or spreadsheet, and stores an audit record. No internal document leaves the organization's control.
- Document analysis: upload, structure analysis, extraction, cross-check, report, stored artifact
- Research work: search plan, source collection, source evaluation, conflicting evidence check, report
- Repeated work automation: scheduled run, data collection, threshold comparison, anomaly detection, report, approved follow-up
- Development work stays supported but is not the wedge, because that market is already contested by dedicated coding agents
- Do not start by multiplying expert agents, making every request A2A, controlling permissions through prompts, growing ChatService, or promising full autonomy before controlled semi-automation works