ES
Trajectory enforcement for AI agents

Govern the trajectory.
Not just the next tool call.

DiaCroma evaluates every action routed through it against what the agent — and the agents around it — have already done. It adds durable, deterministic enforcement without replacing your agent platform, identity system, runtime or cloud.

Per-action controls ask, “Is this call allowed?” DiaCroma also asks, “Is it still allowed after everything already done?”

Interposed on governed routesDecides before executionSurvives restartsReconciles the real effectMulti-cloud by design

The control loop

Every action routed through DiaCroma passes through five explicit states.

The agent still reasons in its own runtime. DiaCroma governs the transition from proposed intent to business effect.

01 · DECLARE

Sign the authority.

Mission, tools, caps, budgets, resources, invariants and acceptable evidence become a versioned anchor.

02 · PROPOSE

The agent asks to act.

A tool call, delegation, message or other effect arrives at a boundary outside the model.

03 · EVALUATE

Read the live trajectory.

DiaCroma checks cumulative authority, sequence, lineage, shared constraints and evidence against durable state.

04 · DECIDE

Return a deterministic verdict.

The structural decision does not depend on a language model.

ALLOWWARN_REPLANBLOCK_ESCALATE
05 · SETTLE

Close against the real effect.

The permit is consumed, the resulting effect is reconciled, and the evidence row is sealed for replay.

A permit is valid only against the live trajectory state that produced it. If that state moves first, the proposed effect is no longer authorized.

Adoption path

Start with one governed route.
Expand coverage deliberately.

The first implementation proves one effecting route end to end: proposal, decision, execution, receipt, settlement and replay. Coverage expands only as additional routes are integrated and alternate paths are closed.

HOSTED

HTTP API

Call DiaCroma before the business effect, receive the decision contract and return the resulting receipt after execution.

CUSTOMER-CONTROLLED

SDK or container

Run the library or container in infrastructure you operate, with durable trajectory state backed by SQLite or Postgres.

PROTOCOL SEAM

MCP or A2A boundary

Carry the same decision contract through MCP, HTTP or the DiaCroma A2A endpoint while platform validation remains explicit.

See the integration paths →

Integration makes DiaCroma reachable. Route closure makes it enforceable. A route remains partial whenever the same business effect can bypass the boundary.

Product boundary

What your platforms keep.
What DiaCroma adds.

DiaCroma consumes identity, policy and tool context from the surrounding stack. It does not rebuild the layers enterprises already operate.

YOUR CONTROL PLANE

Identity and lifecycle

  • Agent identity and ownership
  • Registry and inventory
  • Permissions and Conditional Access
  • Runtime and orchestration
YOUR PER-ACTION CONTROLS

One proposed call

  • Tool allowlists and argument caps
  • Gateway and MCP policy
  • Content and data controls
  • Sandbox and supply-chain controls
DIACROMA · TRAJECTORY ENFORCEMENT

The cumulative system

  • Authority spent across actions and agents
  • Sequence, delegation and shared budgets
  • Cross-agent and cross-system lineage
  • Effect settlement and deterministic replay

Multi-cloud deployment model

Local boundaries.
One signed trajectory.

Agents and business tools stay where they run. DiaCroma places an execution boundary near the effecting route while the same signed authority, trajectory state and evidence follow the work across platforms.

EXISTING ESTATE

Agent runtime

A runtime connected through a validated adapter proposes an action. Platform validation is reported separately.

LOCAL ENFORCEMENT

DiaCroma boundary

Builds context, reads the live trajectory and returns a permit, replan or block.

BUSINESS EFFECT

Tool or system

On a closed governed route, executes only with a valid permit and returns the receipt required for settlement.

Customer-controlled placementBoundary and state can run in infrastructure you operate.
Protocol-neutral coreMCP, HTTP and the DiaCroma A2A endpoint carry the same decision contract; external platform validation is reported separately.
Shared evidenceEvery decision and effect joins the same recomputable trajectory record.

The architecture is multi-cloud; validation is platform-specific. See what is running today, and what is coming next, on the Evidence page →

What the enterprise signs

What you do not declare
is not governed.

REQUIRED

Authority and identity

Mission anchor, deployer credential, agent identity, allowed tools and the version of the authority being enforced.

LIMITS

Caps and cumulative budgets

Exact per-argument ceilings plus the authority that may be spent across the lifetime of a trajectory or delegation tree.

RELATIONSHIPS

Resources, lineage and sequence

What agents read and write, which resources are coupled, and which operation classes cannot follow one another.

EVIDENCE

Claims, receipts and settlement

What each tool can prove, how fresh that evidence must be, and how the proposed action closes against the effect that actually occurred.

Product truth

What DiaCroma does not claim to be.

Not a control plane or runtime

It does not replace identity, registries, fleet lifecycle, orchestration or cloud administration.

Not a content-safety model

Structural controls are deterministic; optional semantic signals are identified separately.

Not complete when routes bypass it

Coverage is graded explicitly. A reachable gateway is not an inevitable execution boundary.

Not tied to one cloud

The authority and trajectory model remain neutral even while platform integrations mature at different speeds.

Next: validate a governed route

Prove the control loop
end to end.

Choose one agent, one business effect and one execution route. Validate allow, block, receipt, settlement and replay before expanding coverage.