How it works

The machine underneath.

Doric runs a closed loop: a team decomposes your intent, a swarm of agents builds it across parallel threads, the system verifies the result against reality, and the architecture map stays correlated to the code. Here is what is actually happening.

01 · The blueprint

You approve the plan before anything is built

Describe what you want. Phoebe maps the product and Theo lays out the data schema, live, as you talk. You review and edit the whole blueprint — and the team only starts building once you say go.

  • No spec template and no forms — it forms through conversation.
  • Edit anything that's off before a line of code exists.
  • Nothing runs away: generation waits for your approval.
blueprint · review & approve
MAPTenants · Dashboard · Records
SCHEMAtenant · user · record · event
Approve & build Edit the plan
02 · The team

A standing team, plus a swarm you direct

Three specialists hold the project, and the orchestrator fans out helper agents on demand for the actual building. Each agent reads a role-scoped view of one shared project store — not a private chat history — so nothing drifts out of sync.

  • Phoebe — Product. Turns intent into a spec: mission, features, acceptance criteria. Keeps the plan coherent as scope grows.
  • Theo — Strategist & Verifier. Sequences releases, names the risks, and independently checks finished work against the evidence. He recommends and verifies; he never writes the code, so his sign-off is a real second set of eyes.
  • Niko — Orchestrator. Decomposes the work, dispatches helper agents across parallel threads, and reconnects them at the seams. Keeps the map correlated to the code.

Every agent works against the shared store and the contracts; their output is tested and written to an evidence log before it counts as done. Effort you can audit, not just trust.

Product

Phoebe

Strategist · Verifier

Theo

Orchestrator

Niko

+ swarm of builder agents
03 · Parallel development

Automated fan-out, reconnect at the seam

Niko splits a goal into independent development threads, each scoped to a seam with its own contract, and runs them at the same time. When a thread finishes, it reconnects at the seam — a clean integration lands automatically; a conflict stops and asks rather than overwriting.

  • Fan-out is automatic: the orchestrator decides what can run in parallel and dispatches it.
  • Each thread is isolated — branch-per-thread on cloud storage, with a database lock as the gate.
  • Reconnection is contract-aware: threads integrate at defined seams, so a week of roadmap can land in an afternoon without collisions.
niko · fan-out → reconnect
base automated fan-out thread · payments thread · search thread · auth seam
04 · The coherence gate

"Done" is computed, not claimed

A feature's status is not a flag an agent sets. It is derived from evidence: a spec exists, the indexer finds the code that implements it, a smoke test passed, it deployed, it was accepted. Only system actors — the test runner, the indexer, the deployer — can emit that evidence.

  • Lineage: every decision and feature gets an id at birth that its spec, code, tests and deploys all carry — so scattered evidence resolves back to the right item.
  • Append-only evidence log: agents can propose and narrate, but cannot write "the test passed." That capability isn't theirs, so the loop can't be faked.
  • Status is a read-only projection over that evidence — if it's missing, drift shows on the map instead of shipping behind a green check.
approve / reject · coherence
● spec exists
● code implements it
● smoke test … pending
○ deployed
○ accepted
status = in progress (computed)
The full list

Twenty things Doric does so you don't have to.

From parallel threads that don't fragment context and compounding memory, to verified-not-narrated builds, a living map and the Data Gateway — each is something Doric handles for you, and something you'd be doing by hand without it.

See the twenty →
Time travel for project state

Try anything. Roll the whole project back.

Snapshot and fork the entire project — not just files, but the state it was in. Take a thread somewhere experimental, and if it doesn't work, roll back to any prior snapshot and lose nothing else.

Underneath, every version is retained; on the surface you navigate the milestones you chose to mark. When you're ready, the same project deploys to your own cloud through one clean seam — no migration, no lock-in.

Why this matters →
time machine · project state
v1 v2 v3 now fork: experiment ↩ roll back to v2 · nothing lost
dependencies · spec → code → deploys
Approve / reject topic spec code staging production your cloud deployments
Dependency-aware, end to end

Trace any change across everything it touches.

Doric knows your dependencies — in the spec and in the code. So any topic can be followed along its full reach: from the decision that shaped it, through the code that implements it, out to every place it's deployed.

Change-impact stops being guesswork. Before you touch a feature you can see its whole blast radius, and after you ship you can see everywhere it landed.

data gateway · move clouds, not code
your app one interface Doric Data Gateway Firestore Supabase AWS
True ownership

Build it here. Run it anywhere.

Your app talks to one narrow, Postgres-shaped interface — the Doric Data Gateway — with the real backend behind an adapter. Move from a Firestore preview to enterprise AWS without a rewrite. No proprietary runtime, no lock-in.

And your whole project is one click from leaving — a full export any time. Ownership by export, not by where the files happen to live.

Secure by design

Your work is sealed inside Doric.

Confidential, regulated or competitive work — every project is fully isolated, sealed and private, with nothing crossing between projects.

Access is enforced server-side, never in the browser; membership is the single gate, written only by the server; logs are secret-scrubbed and files are served through short-lived signed URLs. The platform you can trust with the real thing.

project isolation
project a project b project c sealed · isolated · nothing crosses between
Context engineering

It gets sharper and cheaper as it grows — not worse.

Most AI threads rot: the longer they run, the slower, vaguer and pricier they get. Doric is built the other way — it stays fast, focused and economical as the project grows.

Every turn carries only the least-sufficient context, switches models solely at a cache boundary (where a switch is free), routes to the model that returns the most value, and distils long threads so they never bloat.

Under the hood →
each turn · context · cache · model
project memory intent architecture component code least context this turn cache · warm ✓ model · routed for value result

Bring your Claude or Antigravity project.

Doric exists because building in Cowork, Antigravity and Cursor turns into a mess at any real size. Bring an existing project and Doric gives it a map, contracts and an R&D team — so you can finally grow it.

Start with your project