Two layers, listed in the order they matter. The supervision layer establishes what delegated work actually did, keeps uncertainty explicit, and decides what needs a person. The production layer underneath it is the runtime, identity, policy, evidence, and lifecycle machinery that makes those decisions enforceable and operable.
Status is honest rather than aspirational: Available runs in the platform today, Preview is built and being proven, Planned is scoped and not yet built. See how these are adopted, or how they compose into the platform architecture.
The supervision layer. These capabilities read the systems that hold the result, resolve each unit of work to an outcome, and keep uncertainty explicit rather than letting it become a completion.
| Capability | What Cogward provides | Why delegated work needs it |
|---|---|---|
| Unit of work as the tracked object Preview |
A run opens or continues a durable unit of accepted work, so supervision attaches to the work rather than to a session or a transcript. | A business result spans retries, pauses, and more than one agent, none of which a session boundary respects. |
| Effect identity before dispatch Preview |
A state-changing action is recorded with a stable identity before the call leaves, while the result is still unknown. | After a process dies mid-dispatch, later evidence can show the state but not which attempt produced it, or whether a retry would double it. |
| Outcome states Preview |
Each unit of work resolves to confirmed, partial, contradicted, or unknown, tracked separately from whether the check itself could run. | "The work failed" and "the verifier could not run" are different problems with different owners, and collapsing them produces false negatives. |
| Evidence status Preview |
Every reading of an authoritative system carries whether it was fresh, still inside its propagation window, stale, or unavailable. | An unknown caused by a disconnected system is a binding gap to fix; an unknown caused by a real ambiguity is not. |
| Durable unknown Preview |
Uncertainty survives a crash and holds the work, blocking a second real-world effect until the first is resolved. | Anything can report the word unknown. Only a component that owns dispatch and retry state can make it binding. |
| Authoritative source bindings Planned |
Declared bindings from a completion condition to the system that establishes it, over connectivity you already have: direct APIs, MCP servers, iPaaS, event streams, and warehouses. | Establishing a result means reading the customer's own systems, and rebuilding a connector estate is the wrong race to enter. |
| Context bindings Planned |
Declared bindings from the systems that hold organizational meaning, contracts, policies, procedures and operating circumstances, to the work they apply to. Cogward consumes whichever context or knowledge systems the enterprise already runs rather than building another one. | A refund that is correct under a customer's contract amendment is an overpayment without it, and an action that is reasonable during a declared major incident is not reasonable on an ordinary Tuesday. |
| Advisory and binding context Planned |
Retrieved knowledge carries its provenance, scope, authority and effective version. It is advisory by default and binds only where you have declared that source authoritative for that scope. Two authoritative sources that disagree hold rather than resolving by recency. | Without a default, a passage that a search returned as similar could hold a large action. Without a conflict rule, the system picks a winner in advance, which is the guess the exception queue exists to remove. |
| Entity correlation Planned |
Resolution of the identifiers that refer to one episode of work across several systems, so evidence can be attributed to the right work item. | A customer id in the CRM, an account in billing, and a case number in the ITSM tool have to be recognised as the same work before evidence means anything. |
| Reconciliation and safe retry Planned |
Recovery that asks the target what happened rather than retrying blind, releasing a retry only on authoritative proof of non-application. | A timed-out transfer is the common case, and both retrying and not retrying are wrong without evidence. |
| Compensating actions Planned |
A declared compensating action, treated as its own supervised work with its own evidence and outcome. | Some effects cannot be undone by retrying or reversing, so the compensation itself has to be established. |
| Reversal detection Planned |
Continued observation of a confirmed result, so a later reversal reopens the work rather than passing unnoticed. | A confirmed refund that is charged back afterwards is not a completed outcome. |
What turns established outcomes into an operating model: the queue a person actually works, and the measure a sponsor is held to.
| Capability | What Cogward provides | Why delegated work needs it |
|---|---|---|
| Evidence-generated exception queue Planned |
The work a person sees is selected by what the evidence could not establish, rather than by a sampling rate or a risk rule written in advance. | A sample catches a fraction of what went wrong, and a rule flags only what somebody already anticipated. |
| Declared bounds across scopes Planned |
A bound is a scope and a quantity: action scope, delegated authority, spend, business exposure, and unresolved risk, declared across the work item, the agent, the workflow, the user acted for, the tenant, the counterparty, or a time window. | Entitlement is a type check and says nothing about how much. An action can sit inside every individual limit and still be the one that takes the estate past a limit that only exists in aggregate. |
| Unresolved effects consume authority Planned |
An unresolved consequential effect reserves against the applicable bound until it is reconciled, so uncertainty tightens what the estate may do next rather than sitting in a status column. Exposure attaches to the effect, not to the work item's outcome state. | Twelve unresolved transfers are an unquantified amount of money that may already be gone. An unknown notification delivery is not, and reserving against it would paralyse an estate for no reason. |
| Routing by uncertainty and exposure Planned |
Per work type, a declared route from each unresolved state: continue, verify, reconcile, hold, or dispatch a bounded human case. | Not every uncertain result deserves a person, and a conservative deployment should be able to send every one to a person until it earns otherwise. |
| Human dispatch from durable state Preview |
An escalation arrives as a bounded case carrying the work, its authority, the evidence gathered, and what remains unresolved, and the work resumes from durable state on a decision. | An escalation that arrives as a transcript makes a person reconstruct the episode before they can act on it. |
| Unattended completion rate Planned |
Per workflow, the share of eligible delegated work reaching its intended completion state without human review, tracked over time with the residue broken out by cause. | The sponsor is measured on how much work runs without a person, so the product has to report in that unit. |
| Autonomy readiness baseline Planned |
A first-pass measurement over work that already ran: what can be established today, what has no establishable result, and what the routine checking costs. | Enterprises do not know their unknown rate, because nothing currently measures it. |
| Drift against declared intent Preview |
Continuous checking of in-flight behaviour against the declared intent of the work, before the effect lands. | Outcome verification is after the fact. Drift is the same discipline applied while the work can still be steered. |
Progressive by design. An implicit objective is enough to produce evidence and an unknown rate; a formal definition is what work heading toward running on its own requires.
| Capability | What Cogward provides | Why delegated work needs it |
|---|---|---|
| Declared completion conditions Planned |
A small reviewed artifact naming the postconditions that must hold, the authoritative system for each, and the conditions under which the result is unknown. | Completion has to be evaluated against something the customer declared, not inferred from the agent's own report. |
| Versioned definitions Planned |
Completion definitions carry versions and are bound to the agent version that ran under them, so a settled outcome is attributable to both. | Rolling back an agent version does not roll back its effects, and the release path needs to know which definition a result was established against. |
| Required-effect checks Planned |
A definition can name effects the work required, in order where order is real, and forbidden effects, settled against the record of what actually crossed the dispatch boundary. | Some procedures are only complete if specific steps happened, and the record establishes that without scoring the agent's choices. |
| Definition authoring assistance Planned |
Proposed conditions and bindings drawn from material you already have: tool and data schemas, SOPs, agent instructions, and work that completed cleanly before. Reviewed and approved by your team. | If every definition is authored by hand, supervision scales like a consulting engagement rather than like infrastructure. |
| Workflow archetypes Planned |
Reusable starting definitions for recurring shapes of work: refunds, provisioning, access grants, incident remediation, and invoice reconciliation. | The second deployment of a familiar shape should start from what the first one established. |
| Loss-aware autonomy expansion Planned |
Expansion of a workflow's operating envelope against accumulated outcome evidence, expected loss, and tail severity rather than against a success rate. | Evidence from the envelope a workflow runs in today does not carry automatically to a wider one. |
The deepest supervision depth. Work that runs here gets durable state, safe recovery, and enforcement at the point an action becomes a real effect.
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Isolated agent runtime Available |
Each agent runs inside an isolated execution sandbox with infrastructure-enforced resource and tenant boundaries, from millisecond responses to multi-day autonomous work. | Agents choose actions dynamically and can run for days, so execution must be isolated and recoverable. |
| Durable sessions Available |
Long-running work is checkpointed so a session can recover and continue after an interruption, keeping its tenant, user, version, and approval context. | An agent carries multi-step work that cannot simply be retried from the start. |
| Tenant isolation at the runtime Available |
Workspace, memory, session state, and IAM are boundaried per tenant at the infrastructure layer, beneath application code. | Many agent frameworks provide no infrastructure-level multi-tenant isolation, so that boundary must sit beneath the framework. |
| Resource ceilings Available |
Per-run CPU, memory, and session limits are enforced at the execution layer, and idle sessions are reclaimed. | An agent can consume unbounded compute, so the runtime has to cap it. |
| Budgets and circuit breakers Planned |
Spend budgets, loop detection, and automatic circuit breakers that halt a runaway run at the broker. | A tracked overage still completes; a circuit breaker stops the loop first. |
| Agent density and efficiency Available |
Many sessions share the underlying compute: each borrows a worker only while active and releases it when idle, with warm restore on the next turn. | Agents spend most of their life waiting, so dedicating capacity to each idle session wastes resources at fleet scale. |
| Framework- and model-independent control Available |
The same governance layer supports multiple harnesses (Claude Agent SDK and deepagents/LangGraph today) with per-run model selection, without embedding control into the agent. | Teams build on different frameworks and providers, so control has to be framework-independent. |
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Run-scoped identity Available |
Every run receives a unique machine identity issued by the Cogward control plane and recorded on each governed action, never a borrowed user account or a shared service key. | An agent acts on its own initiative, so every action must trace to a distinct actor. |
| Dual attribution Preview |
Every governed action records the acting agent today; attribution of the authorizing human is in preview as the delegated-authority path is wired. | Agents act on a person's behalf, so the record must show both who acted and under whose authority. |
| Delegation chain Planned |
Multi-agent hand-offs where authority narrows at each boundary and the chain is recorded. A single human-to-agent exchange exists today; multi-agent chains are planned. | Agents delegate to other agents, and privilege must never expand along the chain. |
| Least-privilege, short-lived credentials Preview |
A token broker mints short-lived credentials scoped to only what the run needs. It is live for governed connectors today, with per-run scoping for the agent identity rolling out. | A lingering, broadly-scoped agent credential is a standing breach. |
| Registry as authority of record Available |
One place where every agent is declared, versioned, and governed, with identity issued at registration and the release authority for the estate. | The fleet fragments across teams; without one control tower, the weakest local setup sets the posture. |
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Runtime enforcement point Preview |
Model, tool, MCP, and outbound network calls are routed through runtime enforcement points below the framework. Blocking is enforced today at the connector and network planes; the unified per-action decision point records verdicts and is moving from shadow to enforce. | An agent decides its own actions at runtime, so they cannot be enumerated in advance. |
| Credential custody Preview |
The runtime custodies upstream credentials and attaches them per approved destination. This is live for governed tool and MCP connectors, and is extending to the model path. | If the agent never holds the key, it cannot route around the enforcement point to use it. |
| Per-call policy enforcement Preview |
Every call is evaluated against the agent's declared contract and the decision is recorded today; blocking enforcement is enabled per tenant in preview. | Agent behavior drifts without a code change, so the permitted set has to be checked continuously, not fixed once at deploy. |
| Fine-grained entitlements Preview |
Per-tool-verb entitlements are enforced at the gateway today; per-resource and per-model-capability scopes are in preview. | An agent needs exactly the access its task requires, and no broader. |
| Governed model access Preview |
Per-tenant model gateways route and isolate model traffic today; contract-based model allow-listing and per-tenant spend and rate caps are rolling out. | An agent chooses models at runtime and can send sensitive data to the wrong one. |
| Governed tool and MCP connectors Available |
Tools are attached from a governed catalog, entitlements are enforced at the gateway, and tool definitions are pinned so a changed tool is caught. | Agents pick tools dynamically and external MCP servers can silently change what a tool does. |
| Tool-call validation Planned |
Beyond pinning the tool definition, each call's arguments are checked against the tool's schema at the broker, so a permitted tool cannot be invoked with out-of-schema or smuggled inputs. | Injection and tool-poisoning usually ride in through arguments, not the call itself. |
| Bring-your-own guardrails Planned |
Third-party content guardrails (prompt-injection, PII, toxicity) plug into the policy path as a callout, with their verdict enforced and recorded. | Content safety is a fast-moving specialist market you should stay free to choose and swap. |
| Per-user connected accounts Preview |
A person connects their own account to an external tool via OAuth and the agent acts under that grant. It is live as a GitHub canary today; broader support is in preview. | An agent often needs to act as the specific human it works for, not one shared bot account. |
| Governed network egress Available |
Outbound access is deny-by-default per agent and per tenant: each reaches only the hosts its contract allows, the runtime holds the credentials, and every allow or deny is recorded. | Without runtime restrictions, agent code may attempt outbound access beyond the destinations required for its task. |
| Human-in-the-loop checkpoints Available |
High-risk tools are marked to require approval; the action holds durably for a human decision that is recorded as evidence. | Agents take actions that change something autonomously, so the pause has to live below the agent. |
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Behavior traces Preview |
A read-only trace of model interactions, tool use, decisions, and execution steps, tenant-scoped and correlated to the evidence record. | Whether a request succeeded says nothing about how the agent behaved to get there. |
| Version-aware evaluation Preview |
Governed traces are the evidence base for candidate evaluation before release; scoring and shadow release-gates are in preview, with production drift detection to follow. | Agent quality degrades silently as models and prompts shift. |
| Cost and behavior visibility Planned |
Token, cost, tool-mix, and outcome patterns attributed per agent and per tenant across production. | Agent cost and behavior vary run to run and per customer. |
These capabilities operate as one governed lifecycle, from registration and versioning through promotion, production control, evaluation, and rollback. See the governed agent lifecycle →
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Versioned deployment and rollback Available |
A staged path from development to production with per-tenant enablement, percentage-share canary, and atomic rollback. Each session runs to completion on the version it started under. | You promote deliberately rather than replacing the artifact and killing what was mid-flight. |
| Evaluation-driven release gates Preview |
Promotion gated on evaluation evidence; shadow gates are in preview, with enforcing gates to follow. | Tests pass on a version that still regresses in production, so the gate has to read real behavior. |
| Tenant-specific version pinning Available |
A tenant can remain on an approved version until it accepts a change, while other tenants move to the new one. | Regulated customers approve changes on their own schedule and cannot be force-migrated. |
| Kill, suspend, and drain at any scope Available |
Stop a single run, a version, or an entire tenant, or drain in-flight work first, without touching what runs alongside. | A misbehaving agent must be haltable mid-flight, at precise scope. |
| One-command authoring and deploy Available |
Scaffold, register, and deploy an agent from any repository with no direct infrastructure access. | Every team ships many agents onto the same layer, so standardized authoring keeps the fleet consistent. |
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Tamper-evident evidence Preview |
A cryptographically verifiable, append-only record of every governed action, built on hash chains and Merkle-tree structures. Verified end-to-end in development; rolling out to production on the durable substrate. | Regulators ask what an agent did and under whose authority, and expect proof it was not altered. |
| Two records, produced automatically Preview |
An operational events journal for engineering (live) and a compliance ledger for auditors (rolling out with the durable ledger), both without extra instrumentation. | No single artifact serves both an SRE mid-incident and an auditor a year later. |
| Privacy by reference Preview |
The ledger stores content hashes and data classifications; the content stays in the tenant boundary. | Agent inputs and outputs are sensitive, so evidence must prove what happened without copying the data out. |
| Independent verification Preview |
A standalone verifier recomputes the ledger and checks its proofs with no live Cogward service, with a self-contained offline export; in preview as the ledger reaches production. | Auditors need to validate evidence without relying on a live vendor, or the vendor still existing. |
| OTel and OCSF export Preview |
Evidence projected into OTel and OCSF for your SIEM. The projectors are implemented; the export pipeline ships with the ledger. | Auditors and SIEMs consume evidence in their own formats, not raw logs. |
| Regulation-specific evidence packs Planned |
Per-regulation evidence packs (DORA and SOC 2 first) built on the anchored ledger. | Raw logs do not map to a control framework on an auditor's schedule. |
| Signed and digest-pinned images Available |
Agent images are cryptographically signed and pinned by digest, and each session runs the exact pinned digest. | Agents pull code and dependencies from many sources, and a deploy should not trust whatever the pipeline pushed. |
| Fail-closed signature enforcement Planned |
A gate that verifies signatures and refuses unsigned images at promotion. | A signed image only protects you if something refuses unsigned ones before they run. |
| Capability | What Cogward provides | Why agents need it |
|---|---|---|
| Runs in your environment Planned |
Execution, enforcement, and evidence deployed inside your own cloud, on AWS, Azure, GCP, or on-premise infrastructure. | A regulated buyer cannot relocate agent risk to a vendor they then have to audit. |
| Operational independence Planned |
In the stricter deployment tiers, the runtime and its governance keep working with no connectivity back to Cogward. | In stricter deployment models, enforcement and evidence must keep working even when connectivity to the vendor is unavailable. |
| Per-tenant encryption (CMEK) Preview |
Each tenant's workspace, memory, session state, and evidence are encrypted with a dedicated per-tenant key today; customer-owned (BYOK) keys are in preview. | Isolation must be provable at the infrastructure layer, not asserted in code. |
| Customer-owned evidence anchor Preview |
The audit chain can be anchored and verified with the customer's own key, in preview as the first anchor adapter. | The record of what your agents did cannot depend on the same vendor whose product you are auditing. |
Cogward turns them into one reusable production foundation.
Building an agent platform internally means owning all of these capabilities as frameworks, models, security requirements, and customer deployment expectations keep changing.
Bring us an agent, its deployment constraints, and the requirements blocking production. We will map what is available today and what we can complete together as a design partner.