Most agent products are a chat box with a few tools bolted on. That is fine for a prototype. It falls apart the moment the agent can deploy code, touch a database, or act on behalf of a team — because now you have to answer the questions every real system answers.

Four questions a demo never asks

Put an agent anywhere near production and four questions become unavoidable:

  • Who is this? Identity, tied to your SSO, for both the human and the agent acting for them.
  • What may it do? A capability boundary that holds even when the prompt says otherwise.
  • What did it do? An audit you can replay, not a scroll of chat history.
  • What happens when it is wrong? Approvals on the risky steps and a way to roll back.

A chat box answers none of these. A control plane answers all of them, the same way for every agent on it.

Two authorization planes

The key design choice in Cortex is that humans and agents are authorized separately. People belong to account groups with surfaces and a visibility scope. Agents run under a capability posture — observer, agent, developer, remediator, admin — that is independent of whoever is driving. A developer cannot talk an agent past its policy, because the policy is not the developer's to grant.

HUMAN PLANE account groupsurfaces · visibility scopeSSO group → rolewho can see what AGENT PLANE capability posturedeploy · docker · remote · hostapproval gateswhat the runtime may do
Fig 1. Human authority and agent authority are independent. Driving an agent never escalates it.

A posture is data, not code, so you can read it, diff it, and review it like any other config:

policy: developer posturerole: developer
capabilities:
  - deploy        # ship apps to this org's runtimes
  - docker        # build and run containers
  - remote        # scoped terminal / file access
approval_required:
  - host          # touching the VM needs a human yes
  - restart
software:
  registries: [ npm, pypi ]   # installs checked against this
  publishers: [ trusted-only ]

Audit you can actually trace

Every action lands in an append-only log with the actor, the capability used, the decision, and a request ID. Because the same ID flows into the traces, you can go from a line in the dashboard to the exact span that caused it:

audit entry2026-06-18T09:41:22Z  req=7c2f9a  actor=nova(agent)
  capability=deploy  resource=app/checkout-service
  decision=allow  approval=auto  result=released  rollback=armed

None of this is glamorous. All of it is the difference between an agent you demo on a Friday and one you let near a customer on a Monday.

Spin up your Cortex
Keep reading