01 · Identity
- Agent acts under its own identity, not a shared key
- Expired or revoked agents → 403
- Owner, risk tier, and scope on every run
Architecture
How Cortex governs every run.
Every agent action flows through the same lifecycle — human to outcome — and the same eight gates, recorded in a tamper-evident ledger. One runtime, ~22 services, one Postgres schema, your choice of models and deployment.
Human → Agent → Skill → Prompt → Policy → Model → Tool → Artifact → Outcome → Approval
The agent lifecycle
Ten hops, fully linked, from human intent to signed approval.
Cortex doesn't run a prompt in a black box. Every run is a chain of typed, attributed hops — and each link is captured so any outcome can be traced back to the human who triggered it and the policy that allowed it.
- 01
Human → Agent → Skill
A person (or schedule, channel, or workflow) invokes a registered agent acting under its own identity — and a specific declared skill, never the raw model.
- 02
Prompt → Policy → Model
The composed prompt is bound to a policy decision. Only then does the run reach an allowed model — provider and version checked against the agent's identity.
- 03
Tool → Artifact → Outcome → Approval
Tool calls pass the MCP gateway, produce attributed artifacts, settle into an outcome with a signed receipt, and high-risk outcomes wait for human approval.
The gate pipeline
Eight gates. Deny is the default.
Between the prompt and execution, every run passes the same ordered gates. Any gate can fail-closed — and when it does, the run stops with a specific, auditable code instead of silently proceeding.
02 · Budget
- Per-tenant and per-agent 30-day USD caps
- Hard cap blocks the run at 100% → 402
- Soft cap raises an alert and keeps the ledger honest
03 · Guardrails
- Input guardrails screen prompts before the model
- PII / DLP and prompt-injection checks
- Plain-English rules compiled to enforcement
04 · Registry
- Model and tool must be on the agent's allowlist
- Disallowed model → run denied
- Versions pinned, drift surfaced
05 · Control Tower
- Live fleet view with a single kill switch
- Concurrency and rate limits enforced
- Pause a fleet without a deploy
06 · Execute
- Model call runs only after gates 01–05 pass
- Tool calls routed through the MCP gateway
- Cost and latency metered per call
07 · Output guardrails
- Generated output re-screened before it leaves
- Grounding and citation coverage checked
- Unsafe or ungrounded output held
08 · Audit
- Every run hash-chained into the Trust Ledger
- Signed receipt, verifiable offline
- verifyChain detects any later edit
Fail-closed, with codes you can audit
budget hard cap402 BUDGET_EXCEEDEDexpired identity403 EXPIREDpack tamper409 hashOk:false
System architecture
One runtime, ~22 services, one schema.
Cortex is a Next.js console over a runtime of ~22 NestJS microservices — agents, actions, ontology, policy, ledger, observability, and more — backed by a single Postgres cortex schema. Every read and write is scoped to the caller's tenant, so isolation is enforced at the data layer, not bolted on.
- Next.js console — one simple/advanced UI over the same governed APIs
- ~22 NestJS microservices behind the eight runtime gates
- One Postgres cortex schema with row-level multi-tenant isolation
- Pluggable LLMs and downstream systems — no provider or vendor lock-in
Multi-tenant by design
Tenancy is enforced in the data path, not the UI.
The same gates and the same ledger apply to every tenant — but no tenant can ever read, write, or import into another. Isolation is checked on every query and every pack import.
Scoped data
- Every query bound to the caller's tenant
- Ontology objects and properties tenant-owned
- No cross-tenant reads, ever
Scoped runtime
- Agent identities live inside a tenant
- Budgets, policies, and oversight are per-tenant
- Control-tower kill switch is tenant-aware
Scoped ledger
- Each tenant gets its own hash chain
- Receipts verifiable offline per tenant
- Pack import lands only in the caller's tenant
Deploy anywhere
Cloud, VPC, or fully air-gapped — your data stays where you put it.
The same runtime runs in our cloud, inside your VPC, or in a disconnected environment. Bring your own local models, pin residency, and keep the tamper-evident ledger underneath it all.
Cortex Cloud
Managed, multi-region
Region-pinnedInternet
BYO local models (vLLM · Ollama · TGI)
Your VPC
Single-tenant in your account
Your regionPrivate link
BYO local models (vLLM · Ollama · TGI)
Air-gapped
Disconnected / on-prem
On-prem onlyNo egress
BYO local models (vLLM · Ollama · TGI)
Same runtime underneatheight gates · cortex schema · tamper-evident Trust Ledger · residency pinning
~22NestJS microservices in one runtime
8Governance gates on every run
10-hopProvenance from human to approval
1Postgres schema, tenant-isolated
For developers
Governed by default — through the API, the CLI, or a signed pack.
You don't trade control for productivity. The same gates that protect the console protect every programmatic call, so an agent you ship by API is as governed as one you build by hand. Define ontology, policy, actions, and agents as code, then export them as a signed, verifiable Solution Pack.
- Same eight gates whether a run starts in the UI, a workflow, or an API call
- Policy-as-Code, ontology, and actions versioned alongside your agents
- Signed Solution Packs — verifyPack checks hashOk + signatureOk before import
- Replay any run from the ledger to reproduce exactly what happened
See the whole run, end to end.
From the human who triggered it to the policy that allowed it to the receipt that proves it — Cortex makes every agent run accountable.