How ACGP Works

This page is a guided walkthrough of one governed action from proposed step to final outcome.

The Problem

AI agents make autonomous decisions and can trigger real-world actions at machine speed. Traditional controls like IAM, rate limits, and post-hoc monitoring are necessary, but they usually do not evaluate the quality of agent reasoning before execution.

That gap matters when decisions involve money movement, user data, privileged operations, or external side effects. ACGP exists to evaluate decision quality at runtime and intervene before high-impact mistakes are executed.

The Solution: Runtime Governance

ACGP sits between your agent and its actions. For every planned action, the agent emits a Cognitive Trace, governance policy is applied, and the Governance Steward returns an intervention that the deployment can enforce or review.

flowchart TD
    A["Refund request proposed"] --> B["Trace captured"]
    B --> C["ARS and Governance Tier already in force"]
    C --> D["Blueprint and tripwires applied"]
    D --> E["CTQ and thresholds evaluated"]
    E --> F["Trust debt updated"]
    F --> G["Intervention, audit, and review outcome"]

For the authoritative operational ordering, see ACGP-3 and ACGP-4.

The Action Proposal

Use a refund approval as the running example. A customer support agent proposes a $50,000 refund for a suspicious bulk return. The agent emits a trace explaining the request, the requested amount, the account history, and the supporting evidence.

ACGP evaluates that proposed refund before execution. If the evidence is incomplete or the action looks unsafe, the system can escalate it for human review instead of allowing the refund to proceed automatically.

Trace Emission

The governed path begins when the refund agent emits a Cognitive Trace for the proposed action. That trace is where the deployment exposes the refund context, the justification, the parameters, and any attached evidence that policy requires.

The trace is not a side note. It is the runtime input to governance.

Risk Assessment: ARS → Governance Tier

Before deployment, the refund agent is assessed with ARS (Agent Risk Score). ARS combines autonomy, adaptability, and continuity into a single risk score, then maps that score to a Governance Tier.

In this example, a refund agent that can approve large refunds or trigger customer account changes will usually land in a stricter Governance Tier than a read-only support assistant. That tier sets the default runtime posture before any individual refund request arrives.

  • ARS answers: "How risky is this agent's operating envelope?"
  • Governance Tier answers: "How strict should default runtime governance be?"

See Risk Assessment & Governance Tiers.

Policy: Reflection Blueprints

Reflection Blueprints define the runtime policy contract for the refund decision. They specify which checks run, which evidence is required, which tripwires apply, how thresholds map to interventions, and what trust-policy behavior becomes visible after the decision.

For the refund example, the blueprint may require account history, refund justification, transaction evidence, and fraud indicators before a large refund can receive an ok or nudge outcome.

See Reflection Blueprints.

Safety Boundaries: Tripwires

Tripwires are hard limits evaluated before broader scoring. For the refund example, a tripwire might block an approval if the request exceeds a policy cap, targets a sanctioned account, or follows an abnormal rate spike.

If one of those conditions fires, the system does not wait for deeper CTQ interpretation. It can block or halt immediately based on policy.

See Tripwires.

Deterministic Checks

If no terminal tripwire fires, the steward applies deterministic rule-based checks from the blueprint. In the refund example, these checks might confirm that required evidence is present, that the refund request fits allowed operational bands, and that known policy conditions have been satisfied before broader quality scoring is considered.

These checks sit between hard fail-closed boundaries and CTQ aggregation. They narrow the decision space before score-based intervention mapping happens.

Quality Scoring: CTQ

If no terminal tripwire fires, CTQ (Cognitive Trace Quality) evaluates the refund reasoning. The score reflects whether the trace is coherent, transparent, justified, risk-aware, and policy-compliant.

For the refund example, weak justification, missing evidence, or shallow fraud analysis will reduce the score and push the intervention toward nudge, escalate, or block. Strong reasoning with complete evidence can keep the action in the acceptable range.

See Concepts Overview for intervention mapping context.

Threshold Mapping

Once the refund trace has cleared terminal tripwires and deterministic checks, the resulting CTQ and risk score are mapped through the active threshold policy. That is where the system decides whether the refund remains acceptable, needs modification, requires escalation, or should be denied.

This is the point where the deployment’s configured strictness becomes visible in the final primary intervention.

Flag And Trust Debt

Trust Debt tracks governance friction over time. If the refund agent repeatedly proposes questionable approvals, debt rises and runtime posture tightens immediately. Crossing configured thresholds can require Governance Tier review or queue ARS reassessment.

In the refund example, repeated escalations or blocks may push the agent into restricted handling even before any formal retiering review completes.

Flag remains orthogonal to the primary intervention. If the refund should proceed but still deserves review visibility or trust-pressure consequences, the system can flag it without replacing the main decision.

See Trust Debt & Runtime Posture for the runtime behavior model, and Protocol Boundaries for what Trust Debt does not replace.

Review Posture / Escalation Consequence

If the refund ends in escalate, the decision leaves the automatic path and enters a stronger review posture. That is not just a UI message; it changes who must approve the action before execution can continue.

In a stricter deployment, the refund may require human authorization, additional evidence, or a more restrictive runtime posture before any similar action is allowed again.

Audit Record

Whatever the outcome, ACGP preserves an audit-visible result. The refund trace, the intervention, the evidence posture, and any trust-debt effects are recorded so operators can reconstruct what happened and why.

This is why ACGP is more than a simple allow/deny wrapper. The system preserves a reviewable governance record, not just a one-time verdict.

What Happens Next Operationally

After the refund decision is recorded, the deployment either executes the action, blocks it, or routes it into review according to the final intervention and execution mode. Future actions from the same agent can then feel the downstream effect of Trust Debt, posture tightening, and operator review requirements.

That is the operational loop: one governed action produces an immediate decision and a durable runtime consequence for what follows.

Next Steps