Change sets
Every meaningful action is a small atomic unit with a goal, plan, risk level, event log, validation record, and review summary. Branch per change set, commit per coherent change, no untracked silent edits.
For when the prototype becomes the product
The agent writes the code.
engzero makes it defensible.
A local-first trust layer for AI engineering — auditable change sets, durable memory, and a policy boundary the model can't route around — wrapped around the coding agent you already run.
MVP 1 in active development — it is building itself
the moment you graduate
You don't need this on day one.
Cursor, Copilot, Claude Code — the tools for AI-assisted coding are excellent, and engzero doesn't replace them. It is for the moment your project stops being a side project.
- The prototype takes on real customers.
- One repo becomes a frontend, a backend, and three internal tools.
- A teammate asks “why did we do it this way?” and nobody remembers.
- An auditor asks for a record of what changed — and there isn't one.
- “We vibe-coded it on Friday” stops being a feature and starts being a liability.
That is when the ceremony starts paying for itself. Not before — and engzero will keep telling you so.
why we're building it
AI coding has a trust problem, and more capability won't fix it.
The agents are good now. That's not the problem. The problem is what's left behind after they work: merged diffs with no reasoning attached, sessions that evaporate, production systems whose history lives in nobody's head.
Every generation of engineering tooling eventually had to answer the same question: can you show your work? Version control answered it for code. CI answered it for correctness. Nothing yet answers it for AI-made changes — what was asked, what was tried, what was risky, what was verified.
We think the answer isn't a smarter agent. It's a trust layer: change sets small enough to review, memory durable enough to outlive the session, policy strong enough that the model can't hold your credentials even if it wanted to — and all of it in plain Markdown on your own machine, because a record you can't read and don't own isn't a record.
The first generation of AI coding tools optimized for the first hour: make the demo great, make the trial great. That market is mature and well served. The next generation will be judged on something harder — whether the tooling scales with the project, the team, and the stakes. Whether it accumulates value or resets it every session. Whether it earns trust as the systems it helps build become consequential.
We are building engzero for that test from the start. It wraps the agent you already use. The engine is open source; authority over your systems stays yours. Forking the code should never mean touching your production.
If your project is becoming a system people depend on, this is being built for you.
— the engzero project
the platform
Six primitives that make AI engineering defensible.
Not another coding agent — the trust layer around the one you already run. Each primitive is labelled with where it actually is today.
Project capsules
Hard isolation per project: memory namespace, workspace, secrets scope, deploy permissions, audit log. Go from one project to seven without the agent losing track of which one it's in.
Four-tier memory ledger
Raw events → distilled lessons → proposed rules → active rules. The agent can propose changes to its own behaviour, but nothing goes active without review. Self-improvement you audit, not something that happens to you.
MCP server
The same services the CLI wraps, exposed as tools over MCP. Your existing agent (Claude Code first) drives the ledger from day one. No new coding tool to learn, no agent to switch away from.
Policy boundary
Model → Policy → Tool Broker → Sandbox. The model never holds a shell, a cloud credential, or a raw secret. Deny-by-default hook interception first, then rootless Podman sandboxing to harden it.
Capability packs
Versioned, auditable domain expertise that activates per change set and learns from real work — so what the agent knows about your stack is a reviewable artifact, not an opaque weight update.
shipping works today
in progress being built now
next designed, not built
vision direction, not a promise
see it work
It's just Markdown. Grep it, read it, hand it to an auditor.
Real output from the current build — a change set opened, validated, and closed against a homelab project, and the ledger note it leaves behind.
# one CLI, one MCP server, same services underneath $ engzero project init homelab --risk medium Created project: homelab Manifest note: 04-Projects/homelab/ProjectManifest.md $ engzero change-set create --project homelab \ --goal "Pin Jellyfin to 10.9" --risk medium Created change set: cs_20260810_ijopji Note: 02-Change-Sets/2026-08/ cs_20260810_ijopji - pin-jellyfin.md $ engzero change-set validation add cs_20260810_ijopji \ --kind manual --status passed \ --summary "Playback verified on two clients" Updated change set: cs_20260810_ijopji (status: validating) $ engzero change-set close cs_20260810_ijopji \ --summary "Pinned to 10.9, playback verified." Updated change set: cs_20260810_ijopji (status: closed) # the ledger is just files, all the way down $ ls 02-Change-Sets/2026-08/ cs_20260810_ijopji - pin-jellyfin.md
--- type: change-set status: closed project_id: homelab change_set_id: cs_20260810_ijopji risk_level: medium --- # Change Set: Pin Jellyfin ## Goal Pin Jellyfin to 10.9 ## Plan - Pin image tag to 10.9 in docker-compose.yml - Recreate container and confirm health ## Events - 21:51:04 [created] Change set created - 21:51:04 [plan_updated] Plan item added - 21:51:05 [status_changed] Status changed to executing - 21:51:05 [file_changed] jellyfin/docker-compose.yml - 21:51:07 [validation_recorded] Validation passed - 21:51:07 [closed] Pinned to 10.9, playback verified. ## Validation - passed manual — Playback verified on two clients ## Review Summary Pinned to 10.9, playback verified.
Six months from now, “why is this code here?” resolves to a document, not
a memory. Read it in Obsidian, grep it from a terminal, or diff it in
git. It is a file you own, in a format that outlives every tool that touched it.
where this is going
The build order, and what each stage unlocks.
The project is pre-launch. This is the actual sequence being worked, not a wishlist — each stage has to be dogfooded on real projects before the next one starts.
MVP 1
in progress
Trust layer
The durable spine: change-set ledger, project capsules, memory writers, the CLI, and an MCP server over the same services so an existing agent drives it from day one. Git-first discipline throughout.
- Dogfood: engzero builds itself; a homelab is the first external project.
MVP 2
next
Policy boundary hardening
Deny-by-default policy enforcement in the host harness's hook surface, then rootless Podman sandboxed execution, command allowlists, and per-project workspace isolation.
MVP 3
designed
Deployment tool
A credential-owning deploy tool exposed over MCP. The agent requests, the tool executes, the model never sees the keys. GCP staging first, with deployment memory and rollback notes recorded as change sets.
MVP 4
optional
Native agent loop
Multi-model routing, planner/executor/critic, and multi-agent exploration — entered only if the harness-level policy boundary proves too weak. A testable question, not an assumption.
open engine, private authority
Fork the engine. Keep the authority.
Knowing engzero's source code must never be sufficient to access, modify, or deploy anyone's production systems.
open engine
- Runtime, change-set ledger, schemas
- Policy interfaces & capability packs
- MCP server, CLI, note templates
- Safe examples against toy targets
private authority — yours only
- Credentials & deployment profiles
- Real project manifests & vaults
- Runbooks & audit logs
- Every binding to a real system
This is the security architecture a closed, hosted agent structurally cannot offer. The code being public is what makes it reviewable; the authority staying private is what makes it safe.
is it for you?
Straight answers, including the unflattering ones.
Do I have to switch coding agents?
No — engzero is not a coding agent and does not want to be. It connects to the one you already use — Claude Code first — over MCP. Your agent works normally; engzero only records, classifies, and constrains.
Is this overkill for my side project?
Honestly — yes, probably. If you're hacking on a Saturday afternoon, Cursor or Claude Code alone will serve you better, and we'd rather tell you that than sell you ceremony you don't need.
The ceremony starts paying for itself when you have long-lived projects, real users, real secrets, and changes that have to be defensible months later.
Can I use it today?
Not yet. MVP 1 — the ledger, CLI, and MCP server — is in active development and is being used to build itself. There's no release and no signup list; the way in right now is to watch the repo and follow the build.
Where does my data go?
Nowhere. Everything is local-first: the ledger is plain Markdown on your machine, machine state is a local store, and secrets never enter the model's context at all — credentials live inside tools the model can invoke but never read.
What does “auditable” actually mean here?
Every meaningful change is a change set: goal, plan, risk level, event log, files touched, validation results, git branch and final commit, rollback notes, and a review summary. Not a chat transcript — a structured record with a schema.
Is it really open source? What's the catch?
The engine — runtime, schemas, policy interfaces, tooling — is open, and you can read it right now at github.com/pacificseabass/engzero. Your operational layer — credentials, manifests, deploy profiles, audit logs — stays private on your infrastructure. That split is the design, not a paywall.
Who is behind this?
An independent open-source project, currently built by one engineer in the open, dogfooded against real systems. No funding announcement, no user-count claims, no logos we haven't earned — when there's real proof to show, it'll show up here.
If your project is becoming a system people depend on.
Early access isn't open yet — there's nothing to install while MVP 1 is still being built. But the work itself is public: the engine, the schemas, and the change sets that built them.
Pre-launch. Watch the repo for updates — there's no list to join yet.