OpenMakeThe product definition changes
OpenMake AgentOS is not a replacement for macOS, Linux, or Windows. It is an AI Work Runtime: a system that receives a goal, combines the right agents, models, and tools, executes safely, recovers when work fails, and leaves an inspectable record.
The current path is user request, model selection, prompt execution, response. The AgentOS path is goal input, execution plan, permission check, work execution, state storage, retry and recovery, result verification, audit trail.
- Local-first: the operator owns the server, model gateway, data boundary, and workspace policy
- Open-weight first: local vLLM, Ollama, LiteLLM, and OpenAI-compatible routes remain the default center of gravity
- AgentOS, not chat: chat becomes one interface into durable task execution, not the core service itself
Five operating layers
If these layers are missing, the product is closer to a multi-agent framework than an AgentOS. 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: 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 local execution is harder and more valuable.
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.
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 AgentOS, it has a meaningful head start but still needs the durable execution core. The honest overall read is roughly one third of the AgentOS foundation, with stronger progress in model routing and sandboxed agent tasks than in policy, graph execution, memory scope, and enterprise control.
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 AgentOS model-runtime layer.
Agent task substrate: medium
Agent tasks already have persisted task rows, statuses, steps, plan snapshots, checkpoints, queued and paused states, boot recovery, schedules, and sandbox or local executor selection.
Tool, sandbox, approval: medium
MCP tools, Docker-isolated external servers, task sandbox tools, file and browser execution, and human approval gates exist, but they are not yet a full policy-enforced Tool Runtime.
Execution graph: early
There is structured planning and step status, but not yet a durable DAG where each node owns dependencies, permissions, cost caps, retry policy, outputs, and completion criteria.
Memory and observability: early
User memory, Deep Research evidence, audit logs, task steps, metrics, and debug queues exist. AgentOS still needs scoped working, episodic, semantic, procedural, artifact memory and a first-class audit report.
Enterprise control plane: early
JWT, roles, API keys, usage, admin screens, and operator controls are present, while tenant/project RBAC, budget policy, data egress control, and deployment approval remain future work.
What carries forward
OpenMake 1.19.0 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 Desktop 1.7.1's local-work bridge. These should be repositioned instead of discarded.
- LLM Gateway stays a gateway: provider auth, streaming, token accounting, timeout, fallback, and parameter normalization
- ExecutionPlanBuilder becomes 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. The missing foundation is durable execution: tasks that survive process restarts, checkpoint each step, wait for approval, resume from known state, and produce an audit trail.
Durable Task Runtime
Task model, state machine, queue, worker, event log, checkpoint, cancellation, pause, resume, retry, and idempotency.
Execution Graph
DAG nodes with input, output, agent, model, tool, permission, timeout, retry policy, success criteria, cost cap, and approval requirement.
Policy and Approval
Server-enforced permission levels from read-only work to external impact, deployment, payment, security, legal, and finance actions.
Tool Runtime
A registry with schemas, permission metadata, execution mode, timeout, retry policy, telemetry, and standardized result envelopes.
Workspace Sandbox
Per-task workspace, mounted folders only, process or container isolation, resource limits, network allowlist, and preserved outputs.
Memory and Audit
Scoped memory with source, confidence, sensitivity, expiry, plus traces for plan, model choice, tool calls, cost, approval, failure, retry, and artifacts.
Build order
The most defensible first feature is the Durable Task Runtime with Execution Timeline. Once task state is reliable, models, tools, memory, agents, and skills have an operating substrate to stand on.
- 01
Durable Task Runtime
Task data model, state machine, job queue, worker, stored execution plan, checkpoints, cancel, pause, resume, event log, and Execution Timeline UI.
- 02
Tools, policy, approval, sandbox
Tool Registry, MCP gateway, permission levels, policy engine, approval inbox, workspace isolation, Docker sandbox, secrets, and file diff.
- 03
Agent and Skill manifests
Standardize Supervisor, Planner, Worker, Researcher, Reviewer, and Recovery roles; make Skills the package unit for workflows, prompts, policies, tools, evaluators, schemas, and tests.
- 04
Memory and repetition
Task and project memory, scoped long-term memory, successful procedure extraction, failure case storage, memory verification, deletion, and expiry.
- 05
Organization control plane
Multi-tenancy, organizations, projects, RBAC, token and cost budgets, external model policy, data egress control, deployment approval, and operations dashboards.
MVP scenarios and non-goals
The first AgentOS MVP should prove reliability in real work, not general autonomy in every domain. Four scenarios are enough to make the name meaningful if they are durable, observable, and approval-aware.
- Document analysis: upload, structure analysis, extraction, cross-check, report, stored artifact
- Development work: repo connection, issue analysis, fix plan, sandbox change, test, diff, approval, PR
- 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
- 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