One orchestrator. A fleet of agents. A model that learns.
This is the technical account of ZB Stack: how CORA decomposes work and spawns agents to do it, what verifies each of them, how a change moves from a sentence to a deployed system, and how the Cortex — the model behind every agent — improves with each build.
Screenshots on this page are from the CORA demo, which runs on a simulated ceramics studio called Alder & Oak and says so in every frame’s corner.
Four layers, and what each one owns.
You
Work arrives as language: a product idea, a feature, a fix, an upgrade.
CORA — orchestration
Holds the product: the spec, every decision and its reasoning, the state of the build, and what is live. Decomposes work, spawns agents, verifies results, integrates.
The agent fleet
Specialists, spawned per task with scoped context.
Shared substrate
What every agent draws on, and writes back to.
CORA is not a chat session. It is the product’s memory.
One product, one CORA. It is the persistent system of record for that product: the spec, every decision and the reasoning behind it, the state of the build, and what is currently live. When work arrives it decomposes it into tasks, spawns an agent for each, runs them in parallel where the dependency graph allows, verifies the results against the spec, and integrates them.
Because it accumulates context for as long as the product lives, the tenth change starts from everything the first nine established — which is the mechanism behind “first point of contact for every change”. There is no re-explaining the system to a fresh session.
Spawned per task, with scoped context.
An agent receives the slice of spec, code, and history its task needs, and nothing else. It exists for the task; its output and the measured outcome of that output persist. Scoping the context is what keeps a large product tractable — and what keeps one agent's mistake inside one task.
| Agent | Owns | Verified by |
|---|---|---|
| Spec | Requirements, architecture, and the cost model | CORA, against the product's history — and you, before the build |
| Design | Screens, flows, and the interface | The Spec agent, against the plan — and you, at the read-back |
| Build | Implementation | The test suite, plus a review agent that did not write the code |
| QA | The test suite, and the gates every change must pass | The record — a miss that reaches production lands in it, named |
| Security | Data boundaries, access, secrets, and dependency audit | Policy checks that run on every change, not on a schedule |
| Deploy | Releases and the path to live | Rollback gates, armed on every release |
| DevOps | Infrastructure, monitoring, and run cost | Service objectives |
| Learning | Outcome capture, Cortex updates, and improvement proposals | Measured results in the record — the projection is kept beside it |
The roster is open. When a task class appears that no specialist covers — a payments integration, a data migration, a store connector — CORA spawns a specialist for it, gives it the context that task needs, and verifies what comes back the same way.
No agent ships its own work unverified. Every result is checked by something that did not produce it — a test suite, a review agent, a policy check, or a service objective.
Every agent runs on a model trained on product work.
The Cortex is trained on specs and their outcomes, builds and their defects, and changes and what they did in production. Two loops keep it improving, and they run at different scales.
Per product
CORA carries your project. Every decision, incident, and measured result becomes context that the next task on that product starts from.
Across the platform
The Learning Agent feeds measured outcomes back into Cortex training. Each product built makes the system better at building the next one.
That is recursive self-improvement stated concretely: the system that builds products retrains on the results of the products it builds. The loop closes because the record already holds what every change cost and what it returned — the training signal is a by-product of running the work, not a separate data-collection exercise.
Software has always decayed after launch. Built here, the product and the builder both compound.
One artifact, three jobs.
Append-only, per product: every change, its cost, its approver, and its measured result. It is the audit trail, the invoice, and the training signal at once — which is why none of the three can quietly disagree with the others.
A record that can only report good weeks is a brochure. This one has a week that reads “No change — watched” and a projection that came in two points under.
From a sentence to a deployed system.
The lifecycle every change runs, whether it is the first release or the fortieth improvement.
Request
“Customers keep asking to pay by invoice.” Plain language arrives; CORA resolves it against the current spec.
Scope
A spec delta, a cost, and a projected effect — written before any code exists.
Spawn
Build and Security agents run in parallel where the dependency graph allows; Deploy prepares the release path.
Build and gate
Implementation against the spec, with the test suite and the policy checks on every commit.
Deploy
Released behind a check. DevOps watches the service objectives with rollback armed.
Measure
The result lands next to the projection, in the record — including when it lands under.
Learn
The Learning Agent writes the outcome to the Cortex. The next change of this class starts from it.
What “scope” produces
The read-back at the end of the interview: the position, who it is for, the six screens shipping first, the two things held back with the reason for each, and the cost — about $340 of a $500 budget to build, about $28 a month to run. This exists before any code does.
Model routing, per task
The build log assigns a frontier model to design and architecture at $4.10, a fast model to screens and styling at $1.80, and a small model to boilerplate and tests at $0.22. Routing by task rather than by habit is why the whole build lands at $340 rather than the budgeted $500 — six screens, 41 tests, all passing.
The whole stack, on one product.
It starts with a product interview: twenty minutes, and you leave with a plan, a budget, and a first release date.
Every screenshot on this page is from the demo, which runs on a simulated studio and says so in its corner.