CentrOS
Agent orchestration platform
Agents do the work, a human approves anything irreversible, and every step leaves a receipt.
I built CentrOS as the runtime underneath every agent demo that actually has to ship. Typed contracts move through gated multi-agent execution, land in an owner inbox when the blast radius is high, and leave an audit trail you can read like a story.
Owner inbox
3 waiting on you · lane B/C only
- Tier R2: Refund — Booking #4421 · $284 CADrouter → executor → adversary → verifier · 8 evidence items Gates passed
- Tier R1: Reply to guest — late check-in for unit 12router → executor → adversary → verifier · 5 evidence items Gates passed
- Tier R3: Tax filing draft — quarterly remittancesource doc >90d old · 11 evidence items Adversary flagged
Why it exists
3
Three reasons agent demos don’t survive production.
I kept hitting the same three walls building agentic workflows for real ops. Everything in CentrOS answers one of them — if a feature can't be filed under one, I don't build it.
- Durable runtimeMost agents are stateless prompts. Real ops need durable state.Crash recovery, checkpointing, replay and idempotent retries are not optional when an agent's action touches money or communication. CentrOS contracts are PostgreSQL rows with explicit lifecycle states; a crash resumes from the last gate, not the beginning.
- Governed autonomyMost demos auto-execute. Real ops need approval gates.Legal sign-offs, monetary actions and irreversible writes all need a human "yes." Policy lanes route high-blast-radius actions to an owner inbox before any write, and the audit trail records who approved what, on what evidence.
- Reusable workflowsMost platforms ship one workflow. Real ops scale through reusable patterns.A new vertical is new triggers, atomic work units, tool boundaries, linters and approval rules — not a new platform. The runtime, gate engine, owner inbox and observability layer stay the same, inside the same Workbench shell.
How it works
Router · executor · adversary · verifier — then a person.
Five terms first
5
- Contract
- A typed, atomic work unit with risk tier, policy lane, and required gates. Lives as a row in PostgreSQL with a strict lifecycle.Why: makes agent intent inspectable, durable, and resumable across crashes.
- Risk tier
- R1 / R2 / R3 — escalates with the blast radius of the action. Communications < money < regulatory.Why: the runtime can refuse high-tier work without manual escalation criteria; tier maps to lane.
- Policy lane
- A (auto), B (confirm), C (careful). Determines whether the executor proceeds, waits for owner sign-off, or pauses for adversarial review first.Why: maps intent to autonomy level — not the other way around.
- Gate
- Evidence · Adversary · Verifier · Rollback · Stop-Ship. Every contract must pass its required gates before close. Failure is a first-class outcome with its own state.Why: non-deterministic systems need deterministic acceptance criteria.
- Workbench mode
- Ask · Books · Legal · Plan. The same shell renders different tool boundaries and linters depending on which mode the operator opens.Why: verticals share infrastructure but need domain-specific controls at the edges.
Four agents
each row opens
Every contract moves through four agents. Open one to see what it reads, writes, can fail at, and hands off.
Routerclassify · assign lane · materialize contract
The router reads the intake event and decides what it actually is. Then it produces a typed contract with the right risk tier and policy lane.
- Reads
- Raw intake (email body, webhook payload, calendar event, GitHub hook).
- Writes
- Contract row with intent classification (DO / DECIDE / DEVELOP / DOCUMENT), risk tier, lane, required gates.
- Fails when
- Intent is genuinely ambiguous → escalates to owner inbox as an unclassified contract rather than guessing.
- Hands off to
- Executor (lane A) or owner inbox (lane C straight to confirm).
Comparable to LangGraph state-machine entry node, Temporal workflow signal handler, MCP capability discovery.
Executortool calls · RAG · state writes · checkpointing
The executor does the actual work. It calls tools from a per-contract tool registry, pulls retrieval-backed context, and writes state at every checkpoint so the runtime can resume from the last gate if anything dies.
- Reads
- Contract spec + retrieval results from the RAG layer + tool registry permissions.
- Writes
- Tool-call evidence, intermediate state, checkpoints, structured outputs (Zod-validated).
- Fails when
- A tool returns an error, validation fails, or the contract enters an illegal state — the DB layer enforces it.
- Hands off to
- Adversary, with everything the executor did captured as evidence.
Comparable to LangChain / CrewAI tool-use loops, Temporal durable activities, agent-runtime function execution.
Adversarycritique · find failure modes · escalate
The adversary's job is to find what the executor missed. It reviews the evidence and asks: "what could go wrong if this ships?" If it finds a real issue, it escalates the contract — back to the executor for a retry, or straight to the owner inbox for a human call.
- Reads
- Executor evidence + contract acceptance criteria + adversarial prompts tuned per workflow.
- Writes
- Critique notes, severity axes, escalation recommendation.
- Fails when
- Critique is shallow (eval flags low confidence) — itself a trigger for human review.
- Hands off to
- Verifier, with adversary critique appended to the evidence trail.
Comparable to LLM-as-judge eval patterns, golden-dataset regression scorers, safety review checkpoints.
Verifieracceptance check · gate pass · close or escalate to the owner inbox
The verifier is the gate runner. It checks that all required gates passed, writes the contract's final acceptance state, and either closes the contract (lane A) or routes it to the owner inbox (lane B/C).
- Reads
- All evidence + adversary critique + required gate list from the contract spec.
- Writes
- Final gate-pass state, audit summary, close timestamp or escalation reason.
- Fails when
- Any required gate is unfulfilled — contract enters
gate-pendinguntil owner resolves it. - Hands off to
- Owner inbox (lane B/C) or contract archive (lane A passed).
Comparable to LangFuse trace span aggregation, CI gate-pass checks, approval-workflow state machines.
Where every contract goes
11 states
Choose a state to read what it means.
Contract closed and durable. Evidence, tool calls, gate decisions, and approver (if any) are retained for audit. Read-only from this point — the audit trail outlives the runtime.
All 11 states, defined8 on the main path · 3 failure paths
- draft
- Contract materialized but not yet routed. Risk tier and lane assigned by the router on the next tick.
- routed
- Contract has been classified and assigned a policy lane. Lane A proceeds to executor; lane B/C waits for owner confirmation first.
- executing
- Executor is calling tools, pulling RAG context, and writing checkpoints. Crash here resumes from the last checkpoint, not the beginning.
- eval-pending
- Executor finished; adversary is critiquing the evidence trail. Low-confidence outcomes route to gate-pending or held.
- gate-pending
- Required gates haven't all passed. Verifier holds the contract until evidence/adversary/verifier all return ✓ or the owner intervenes.
- approved
- Owner approved a lane B/C contract from the inbox. Executor proceeds to perform the action.
- executed
- Action complete. Final state written. Contract awaits archival.
- archived
- Contract closed and durable. Evidence, tool calls, gate decisions, and approver (if any) are retained for audit. Read-only from this point — the audit trail outlives the runtime.
- rolled-back
- A gate detected an issue post-execution. Rollback gate reversed the action and the contract closed with a failure summary in the audit trail.
- held
- Owner clicked Hold from the inbox. Contract paused until evidence is refreshed or owner re-decides.
- stop-ship
- Critical gate (e.g., adversary flagged a hard violation) fired. Contract is hard-blocked and only an admin override can release it.
Versus assembling it from partsLangGraph · Temporal · LangFuse · Pydantic · MCP · n8n/Workato/Zapier · approval tools
All of these tools are good. Stitched together, they leave seams — different governance models, different observability surfaces, different state stores. CentrOS is one runtime where the seams don't exist.
| What you'd stitch together | CentrOS gives you |
|---|---|
| LangGraph state machine | Router + policy lanes + contract state |
| Temporal durable execution | Contract lifecycle + gate runner + rollback gate |
| LangFuse traces & eval scores | Gate evidence + run history + owner inbox audit trail |
| Pydantic typed tool I/O | Zod contract schemas + Drizzle row schemas + linter passes |
| MCP tool servers | Tool registry + scoped auth + audit logs per call |
| n8n / Workato / Zapier connectors | Same trigger surface + risk lanes + approval gates + verifier |
| Separate approval-workflow tool | Owner inbox: Approve / Hold / Deny on the same contract row |
The owner inbox
Where humans actually decide.
Lane B and lane C contracts route here. The owner sees the contract, its gate results, the full evidence trail, and three choices: approve, hold, deny.
The owner inbox is the only place CentrOS lets agents act on R2/R3 work. Approvals are reversible by design: every action has a rollback path, and the audit trail captures who approved on what evidence. Lane A contracts never touch this surface — they auto-close once gates pass.
It doesn’t grade its own homework
What the executor proposes
“Partial refund, $284 CAD.”
A proposal — not evidence yet
Evidence trail · refund #4421
- routerclassified as DECIDE · R2 · lane B
- executorfetched booking, cancellation policy, refund window
- executordrafted refund authorization ($284, partial)
- adversary
matches policy; guest 1d outside full-refund window — partial is correct
Matches - verifierEvidence ✓ · Adversary ✓ · Verifier ✓
Gates passed waiting on the owner — nothing has been refunded yet
In production
as of Oct 2026
It runs where someone is waiting on an answer.
Built solo since Feb 2026; running daily in a 23-unit hospitality operation.
- 3,980+Vitest tests passing on main
- 347test files across the runtime and workbench
- 23hospitality units running CentrOS in production
- 4 → 1vendor primitives consolidated into one governed layer
- Deployment
- 23-unit hospitality operation · daily live ops since Feb 2026 · CI-gated releases on main
- Cadence
- Solo founder build · daily commits · 3,980+ tests across 347 files passing on main
- Practice
- 3+ years of LLM tool-calling, multi-agent patterns, RAG, evals and HITL approval design, formalized into the runtime in Feb 2026
- Design partners
- Closed showcase · selective conversations with operators in regulated and high-stakes verticals · email for access
Hospitality operations
23 units · GTA · primary production vertical
- Triggers: guest email/SMS, vendor invoices, maintenance tickets, compliance asks
- Atomic work units: guest reply, refund decision, booking adjustment, vendor PO, compliance log entry
- Lane B/C ratio: roughly 60% — most actions touch revenue or regulated communication
- Linters: refund policy bounds, communication tone, regulatory date windows
Conscious Creations
accommodations consulting · lighter-weight automations
- Triggers: client guest enquiries, ops workflow asks
- Built the public guest-triage demo here — Infinite-Summoner
runPipelinepattern - Python/FastAPI automations alongside CentrOS contracts for shared workflows
- Pairs with operator judgment — never fakes domain licensure
Built onPostgreSQL · TypeScript · Hono · OpenAI and Anthropic SDKs · Expo
- Data
- PostgreSQL · Drizzle ORM · Zod schemas · migration-managed
- Runtime
- TypeScript · Node.js · Hono · Vitest
- Agents
- LLM tool-calling · OpenAI SDK · Anthropic SDK · structured outputs
- UI
- Expo · React Native · Workbench shell · owner inbox · modes: Ask · Books · Legal · Plan
- CI / eval
- Vitest suite (3,980+) · contract / gate tests · synthetic eval cases · gate-pass on main
Try it
Guest triage in three stages — try it.
Classification → plan → draft, with escalation to a human surfaced in the output. Mock mode runs in your browser on sample data and sends nothing.
On a phone the demo opens full screen: the same three stages, on the same sample data.
The demo runs in your browser, so it needs JavaScript.
Built by
I’m Shren Patel. I built CentrOS.
Open to Canada-remote Staff AI Engineer, Agent Runtime, AI Platform, AI Architect, Workflow Automation and Forward-Deployed roles. The platform is the proof; let's talk about how it maps to your problem.
- Emailpatel.shrenil@gmail.com Email
- LinkedInlinkedin.com/in/shrenp (opens in a new tab)
- Roles I fit
- Experience
- All contact details
Before CentrOS: AXED, a WEBTOON Original with 40M+ reads.