A coding model can generate code.
That does not mean it can reliably finish software work.
Between a plausible diff and a completed task, a real software agent still needs memory, execution boundaries, verification, recovery, permissions, and delivery infrastructure.
That is the problem I have been exploring through Agent OS, which I have now released as an open-source project.
GitHub:
https://github.com/earthwalker17/agent-os Agent OS is a local-first AI Project Operating System: a harness around coding models.
The core architecture separates two responsibilities.
The Main Agent handles:
It cannot edit repository code or execute shell commands.
The Coding Agent operates inside one sandboxed project workspace.
It can inspect files, edit code, and run bounded commands, but it cannot modify project memory or access another project’s workspace.
The two sides communicate through summaries and structured artifacts rather than unrestricted shared control.
Agent OS does not accept the model’s own claim that a task is complete.
A coding run must pass a real build or test command.
It can then:
Recovery is deliberately limited. The goal is not unlimited autonomy, but controlled progress with evidence and an audit trail.
Git pushes, pull requests, deployments, database migrations, and Stripe test-mode operations use explicit preview-and-confirm contracts.
The agent can prepare the operation, but it cannot silently mutate an external system because it inferred that the user probably wanted it.
To pressure-test the architecture, I used Agent OS itself to build and deploy Pulseboard, a full-stack SaaS, from an empty repository.
The process included real build, runtime, browser, visual, deployment, and database failures. Those failures became the test for whether the system could collect evidence, expose the problem, and recover instead of simply producing a confident success message.
This is an early public release.
The Windows setup is currently the most thoroughly tested. macOS and Linux users need to follow the manual setup instructions. At least one supported model provider API key is required.
Local-first means that project memory, workspaces, credentials, and execution records remain under the user’s control. It does not currently mean that every supported model runs locally.
I am especially interested in feedback on:
The repository, architecture documentation, installation guide, and production showcase are available here: