ACGP-1000: Core Protocol Specification¶

Status: Draft
Last Updated: 2026-01-08
Spec ID: ACGP-1000
Normative Keywords: MUST, SHOULD, MAY (per RFC 2119)

You are here: ACGP-1000 (Core Protocol)
Prerequisites: ACGP-0000 Overview, ACGP-1001 Terminology
Related: ACGP-1002 Architecture, ACGP-1005 ARS Framework

Complexity: Intermediate
Reading time: ~25 minutes
Audience: All implementers, architects

TL;DR (30 Seconds)¶

ACGP provides runtime governance for AI agents through continuous monitoring and intervention. Every agent action generates a Cognitive Trace, which is evaluated for quality (CTQ score), and results in an intervention decision from six types (five primary levels: OK, Nudge, Escalate, Block, Halt, plus orthogonal Flag) based on the agent's risk tier.

Key Flow: Agent Action → Trace → Evaluate → Intervene → Audit

1. Introduction¶

1.1 What is ACGP?¶

The Agentic Cognitive Governance Protocol (ACGP) provides runtime governance for AI agents, ensuring they operate safely and in alignment with organizational policies.

Core Principle: Separate governance logic from agent logic, enabling real-time oversight without modifying your agent's code.

1.2 Key Features¶

Risk-Proportionate Governance - Stricter controls for higher-risk agents
Continuous Monitoring - Every action is evaluated in real-time
Graduated Interventions - Six response types from logging to kill-switch
Immutable Audit Trail - Complete record of decisions and rationale
Minimal Integration - One-line wrapper for existing agents
Framework Agnostic - Works with any agent framework

1.3 Design Principles¶

Separation of Concerns: Governance logic is separate from agent logic
Defense in Depth: Multiple layers of validation and intervention
Minimal Intrusion: One-line integration for existing agents
Scalability: Horizontal scaling of governance components
Resilience: Graceful degradation under failure conditions
Observability: Complete visibility into all decisions

1.4 Requirements Language¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Terminology¶

The complete and authoritative glossary of terms for ACGP is maintained in ACGP-1001: Terminology and Definitions. Key terms used in this document include:

Quick Reference¶

Term	Definition
Governance Steward	The runtime governance agent that monitors operating agents
Operating Agent	The agent being governed
Cognitive Trace	Structured log of an agent's action (inputs, reasoning, outputs)
Reflection Blueprint	Human-readable policy configuration file (YAML/JSON)
ARS	Agent Risk Score - static risk score (0-15)
ACL Tier	Access Control Level - control strictness (ACL-0 through ACL-5)
CTQ	Cognitive Trace Quality - runtime quality score (0-1)
Risk Score	Inverse of CTQ (1.0 - CTQ), used for intervention decisions
Intervention	Runtime decision (OK, Nudge, Escalate, Block, Halt, Flag)
Tripwire	Critical condition triggering immediate intervention

3. Core Architecture & Governance Model¶

3.1 Three-Layer Model¶

ACGP operates through three integrated layers that connect static risk assessment to dynamic runtime control. Full details are in ACGP-1005: ARS-CTQ-ACL Integration Framework.

┌─────────────────────────────────────────────────────────────┐
│  Layer 1: ASSESSMENT (Static/Periodic)                      │
│                                                             │
│  ARS Assessment → ACL Tier Assignment                       │
│  (One-time or when capabilities change)                     │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  Layer 2: CONFIGURATION                                     │
│                                                             │
│  Reflection Blueprints + Certified Source Registry          │
│  → Policy Engine Configuration                              │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│  Layer 3: RUNTIME EVALUATION (Continuous)                   │
│                                                             │
│  Agent Action → Cognitive Trace → CTQ Evaluation            │
│  → Intervention Decision → Audit Log                        │
└─────────────────────────────────────────────────────────────┘

3.2 Layer Details¶

Layer 1: ARS Assessment [NORMATIVE]¶

Purpose: Determine agent's inherent risk level

Process:

Evaluate agent across 3 dimensions (Autonomy, Adaptability, Continuity)
Each dimension scored 0-5 (0=minimal, 5=maximum)
Sum scores to produce ARS (Agent Risk Score) total (0-15)
Map ARS to ACL tier

ARS to ACL Mapping:

ARS (Agent Risk Score)	ACL Tier	Risk Level	Required Controls
0-2	ACL-0	Minimal	Basic logging, rate limits
3-4	ACL-1	Low	Standard policy rules, human override
5-7	ACL-2	Medium	Warnings, spend caps, approval for sensitive scopes
8-10	ACL-3	High	Approval gates, step-through, immutable audit
11-13	ACL-4	Very High	Crypto signing, isolation, multi-agent RBAC
14-15	ACL-5	Critical	Dual control, kill-switch, pre-commit review

When to Assess:

Before initial deployment (REQUIRED)
When agent capabilities change (REQUIRED)
When trust debt exceeds threshold (AUTOMATIC)
Periodic re-assessment (RECOMMENDED: quarterly)

Layer 2: Configuration [NORMATIVE]¶

Purpose: Define governance policies

Components:

Reflection Blueprints: YAML/JSON files defining quality metrics, thresholds, and rules
Clarity Baseline: Mandatory minimum governance policy (always active)
Certified Source Registry: Authoritative data sources for knowledge grounding
Policy Engine: Loads and enforces policies

Configuration Flow:

Blueprint Files → Policy Engine → Runtime Rules
                       ↑
              Certified Sources Registry

Layer 3: Runtime Evaluation [NORMATIVE]¶

Purpose: Continuously monitor and govern agent behavior

Process (for every agent action):

Agent prepares action (e.g., call tool, generate response)
Agent emits Cognitive Trace (structured log with inputs, reasoning, outputs)
Governance Steward intercepts trace and sends to Policy Engine
Policy Engine evaluates trace:
Calculates CTQ score (0-1) across 5 metrics
Checks for tripwires (critical conditions)
Applies ACL-specific thresholds
Policy Engine returns evaluation with CTQ score and rationale
Governance Steward issues intervention (OK, Nudge, Escalate, Block, Halt, or Flag)
All events logged to immutable ReflectionDB

3.3 Dynamic Governance Model¶

The protocol supports adaptive governance through:

Trust Debt Accumulation:

Flagged actions accumulate risk scores
Can trigger automatic re-tiering when threshold exceeded
Decays over time with good behavior

Dynamic Re-tiering:

Automatic recalculation of ARS and ACL when:
Agent capabilities change
Trust debt exceeds threshold
Repeated near-threshold decisions
Can also be triggered manually

Tripwire Precedence:

Critical conditions override CTQ-based decisions
Three severity levels: Standard, Critical, Severe
Always take precedence regardless of CTQ score

4. Protocol Flow¶

4.1 Primary Operational Loop¶

Every agent action follows this flow:

sequenceDiagram
    participant PA as Operating Agent
    participant GS as Governance Steward
    participant PE as Policy Engine
    participant RDB as ReflectionDB

    PA->>PA: Prepares to execute action
    PA->>GS: Emits Cognitive TRACE
    GS->>PE: Requests EVAL of TRACE
    PE->>PE: Calculates CTQ Score
    PE->>PE: Checks tripwires
    PE->>GS: Returns EVAL (CTQ, rationale)

    alt Tripwire Detected
        GS->>PA: Issues INTERVENTION (Block/Halt)
    else No Tripwire
        GS->>PA: Issues INTERVENTION based on CTQ
    end

    GS->>RDB: Logs TRACE + EVAL + INTERVENTION

4.2 Message Types [NORMATIVE]¶

ACGP uses five primary message types (detailed in ACGP-1003: Message Formats):

Message	Direction	Purpose	Frequency
TRACE	Agent → Steward	Report action details	Every action
EVAL	Steward ← Engine	Return CTQ assessment	Per trace
INTERVENTION	Steward → Agent	Control decision	Per trace
SYNC	Agent ↔ Steward	State synchronization	Periodic
HITL	Steward ↔ Human	Request human review	When escalated

4.3 Version Negotiation [NORMATIVE]¶

Before message exchange, implementations MUST negotiate protocol version:

def negotiate_protocol_version(client_versions, server_versions):
    """
    Negotiate highest common protocol version.

    MUST:
    - Support version negotiation
    - Use highest common version
    - Reject if no common version exists
    """
    common_versions = set(client_versions) & set(server_versions)

    if not common_versions:
        raise IncompatibleVersionError(
            f"No common versions. Client: {client_versions}, "
            f"Server: {server_versions}"
        )

    # Use semantic versioning comparison
    selected = max(
        common_versions, 
        key=lambda v: tuple(map(int, v.split('.')))
    )

    return selected

Example:

Client supports: ["1.0.0", "1.0.1", "1.0.2"]
Server supports: ["1.0.1", "1.0.2", "1.0.3"]
Negotiated: "1.0.2" (highest common)

5. Intervention System¶

5.1 Six Standard Interventions [NORMATIVE]¶

Based on CTQ evaluation and ACL tier, the Policy Engine MUST issue one of six intervention types (five primary levels: OK, Nudge, Escalate, Block, Halt, plus orthogonal Flag that can be combined with any primary level):

Intervention	Action	Semantics	Use Case
OK	Allow	Action permitted with standard logging	Quality is good, no issues
Nudge	Allow with Feedback	Action modified then permitted	Minor issues, auto-correctable
Flag	Allow + Audit	Action permitted but marked for review*	Concerning but not blocking
Escalate	Pause + Human Review	Action paused for HITL approval	Uncertain, needs judgment
Block	Block Action	Specific action prevented, session continues	Clear policy violation
Halt	Kill-Switch	Session terminated, credentials revoked	Critical safety issue

Important: Flag is orthogonal - it can be combined with other interventions to accumulate Trust Debt.

5.2 Intervention Examples¶

Example 1: OK¶

{
  "intervention": "ok",
  "rationale": "High CTQ score (0.92), no policy violations detected",
  "ctq_score": 0.92,
  "allow_proceed": true
}

Example 2: Nudge¶

{
  "intervention": "nudge",
  "rationale": "PII detected in output, redacting before proceeding",
  "ctq_score": 0.78,
  "modifications": ["redact_pii"],
  "allow_proceed": true
}

Example 3: Flag + OK¶

{
  "intervention": "ok",
  "flags": ["near_threshold", "unusual_pattern"],
  "rationale": "Allowed but flagged for review due to unusual access pattern",
  "ctq_score": 0.82,
  "trust_debt_added": 0.05,
  "allow_proceed": true
}

Example 4: Escalate¶

{
  "intervention": "escalate",
  "rationale": "CTQ borderline (0.65), sensitive data access requires human approval",
  "ctq_score": 0.65,
  "allow_proceed": false,
  "requires_hitl": true
}

Example 5: Block¶

{
  "intervention": "block",
  "rationale": "Budget limit exceeded (tripwire: spend_cap)",
  "tripwire": "spend_cap",
  "allow_proceed": false
}

Example 6: Halt¶

{
  "intervention": "halt",
  "rationale": "Data exfiltration detected (severe tripwire)",
  "tripwire": "data_exfiltration",
  "allow_proceed": false,
  "revoke_credentials": true,
  "cascade_to_subagents": true
}

5.3 Tripwire System [NORMATIVE]¶

Tripwires are critical conditions that immediately override CTQ-based decisions.

Three Severity Categories:

Category	Examples	Default Action	ACL Override
Standard	Budget exceeded, rate limit hit	Block	Escalate if ACL ≤ 2
Critical	Secrets in output, production write	Block + Alert	Halt if ACL ≥ 3
Severe	Data exfiltration, collusion detected	Halt	Always Halt

Tripwire Precedence:

Tripwires ALWAYS take precedence over CTQ scores
Multiple tripwires: Use highest severity
Tripwires cannot be overridden by high CTQ

5.4 Decision Thresholds by ACL Tier [NORMATIVE]¶

These thresholds use Risk Score (1.0 - CTQ), not CTQ directly:

ACL Tier	OK	Nudge	Escalate	Block	Halt
ACL-0	≤0.40	0.40-0.55	0.55-0.70	>0.70	Critical tripwire
ACL-1	≤0.30	0.30-0.45	0.45-0.60	>0.60	Critical tripwire
ACL-2	≤0.25	0.25-0.40	0.40-0.55	>0.55	Critical tripwire
ACL-3	≤0.20	0.20-0.35	0.35-0.50	>0.50	Critical/repeated
ACL-4	≤0.15	0.15-0.30	0.30-0.45	>0.45	Any critical
ACL-5	≤0.10	0.10-0.25	0.25-0.40	>0.40	Any severe

Example:

Agent at ACL-2, CTQ = 0.72 gives Risk = 0.28
Risk 0.28 falls in Nudge range (0.25-0.40)
Intervention: Nudge

6. Open vs. Proprietary Components¶

ACGP is designed as an open standard to foster interoperability, with a clear boundary defining proprietary implementation details.

6.1 Open Source (Protocol) [NORMATIVE]¶

The following components MUST be standardized for interoperability:

Message formats (TRACE, EVAL, INTERVENTION, SYNC, HITL)
ARS/ACL/CTQ framework structure
Decision threshold tables
Tripwire categories and standard definitions
State transition rules
Weighted average formula for CTQ
Metric names and weight ranges
Trust debt thresholds and accumulation rules
API specifications for CTQ Providers

A reference implementation of a basic Policy Engine SHOULD be provided.

6.2 Proprietary (Implementation) [INFORMATIVE]¶

Implementers MAY keep proprietary:

Individual metric scoring algorithms
Anomaly detection models
Threshold auto-tuning mechanisms
Feature extraction methods
Model architectures for CTQ calculation
Training data and fine-tuning approaches
Advanced pattern recognition for flags
Specialized tripwire detectors

Rationale:

Enables competition on quality
Prevents gaming of the system
Protects vendor IP
Maintains interoperability through standard message formats

6.3 Governance Contracts¶

An extension to enable explicit performance/quality trade-offs.

Conformance Requirements: - Minimal conformance: Governance Contracts are OPTIONAL (implementations may ignore entirely) - Standard conformance: Governance Contracts are REQUIRED (implementations MUST support risk levels, eval tiers 0-1, performance budgets, and fallback behaviors as specified in ACGP-1010) - Complete conformance: Full Governance Contracts REQUIRED (all eval tiers 0-3, all features)

What are Governance Contracts?¶

Governance Contracts (ACGP-1010) allow agents and stewards to negotiate evaluation depth (eval_tier) and latency budgets based on per-action risk classification.

Three Risk Levels:

low_risk: Routine actions (100ms budget, Tier 0-1)
elevated_risk: Sensitive operations (300ms budget, Tier 1-2)
critical_risk: High-stakes decisions (5s budget, Tier 2-3)

Four Evaluation Tiers:

Tier 0: In-memory rules (<100ms)
Tier 1: Database/cache lookups (<300ms)
Tier 2: Model inference (<5s)
Tier 3: Human review (on-demand)

Why Use Governance Contracts?¶

Without contracts: One-size-fits-all governance (slow for routine actions, rushed for critical ones)

With contracts: Agent declares risk level, then steward applies proportionate evaluation depth

Example:

# Low-risk read operation
governance_contract:
  risk_level: low_risk
  eval_tier: 0
  performance_budget:
    latency_budget_ms: 100
    fallback_behavior: deny

# Critical financial transaction
governance_contract:
  risk_level: critical_risk
  eval_tier: 3
  performance_budget:
    latency_budget_ms: 10000
    fallback_behavior: escalate

Fallback Behaviors¶

When latency budget is exceeded, stewards apply the negotiated fallback:

Fallback	Behavior	Use Case
`deny`	Conservative block	Safety-critical systems
`allow_and_log`	Permissive with async audit	High-volume workflows
`cached_decision`	Use similar past decision	Repetitive actions
`escalate`	Require human override	Ambiguous high-stakes

Integration¶

Governance Contracts usage is OPTIONAL at the agent/steward level, ensuring backward compatibility:

For Standard+ conformance implementations: - MUST support the Governance Contracts protocol (can parse and handle contract fields) - MUST handle governance_contract fields in messages according to ACGP-1010 - Agents and stewards MAY negotiate whether to use contracts for each interaction

For Minimal conformance implementations: - MUST ignore governance_contract fields in messages (backward compatible) - MUST continue to work with Standard/Complete implementations - MAY implement governance contracts in future versions

See ACGP-1010: Governance Contracts for complete specification.

7. Conformance¶

A conformant ACGP implementation MUST meet the requirements defined in ACGP-1009: Conformance Requirements.

7.1 Core Requirements [NORMATIVE]¶

Correctly generate and process all standard message types
Implement six-level intervention system (with Flag as orthogonal)
Support version negotiation
Adhere to state transition rules
Persist all governance events to immutable audit store (ReflectionDB)

7.2 Assessment Requirements [NORMATIVE]¶

Implement ARS assessment with all three dimensions
Map ARS (Agent Risk Score) to ACL tiers using standardized ranges
Trigger assessments at all mandatory points

7.3 Runtime Requirements [NORMATIVE]¶

Calculate CTQ scores using at least five standard metrics
Apply ACL-specific decision thresholds correctly
Implement tripwire system with all three severity categories
Support trust debt accumulation with configurable decay

7.4 Performance Requirements [NORMATIVE]¶

Meet latency targets for target ACL tiers
Maintain specified audit log retention periods
Achieve required throughput for target deployment

See ACGP-1009 for detailed conformance levels (Minimal, Standard, Complete) and testing requirements.

8. References¶

Normative References¶

All implementations MUST comply with:

ACGP-1000: Core Protocol Specification (this document)
ACGP-1001: Terminology and Definitions
ACGP-1002: Architecture Specification
ACGP-1003: Message Formats & Wire Protocol
ACGP-1004: Reflection Blueprint Specification
ACGP-1005: ARS-CTQ-ACL Integration Framework
ACGP-1006: Certified Source Registry Specification
ACGP-1007: Security Considerations
ACGP-1008: Interoperability Specification
ACGP-1009: Conformance Requirements
ACGP-1010: Governance Contracts (Optional)
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

Informative References¶

Agent Telemetry Standard (ATS): Semantic telemetry format
NIST AI Risk Management Framework: Risk assessment methodologies
ISO/IEC 23053: Framework for AI system governance

Implementation Checklist¶

Before claiming ACGP conformance, verify:

Common Mistakes to Avoid¶

Mixing up CTQ and Risk Score - Thresholds use Risk (1.0 - CTQ), not CTQ directly
Ignoring tripwire precedence - Tripwires ALWAYS override CTQ-based decisions
Hardcoding thresholds - Must vary by ACL tier
Forgetting Flag orthogonality - Flag can combine with other interventions
Skipping version negotiation - Required before any message exchange
Not logging to ReflectionDB - Audit trail is mandatory for conformance

Next Steps¶

Now that you understand the core protocol:

Dive into implementation: ACGP-1002: Architecture
Understand message formats: ACGP-1003: Message Formats
Learn evaluation details: ACGP-1005: ARS-CTQ-ACL Framework
Configure policies: ACGP-1004: Blueprints

End of ACGP-1000

ACGP-1000: Core Protocol Specification¶

Navigation¶

TL;DR (30 Seconds)¶

Table of Contents¶

1. Introduction¶

1.1 What is ACGP?¶

1.2 Key Features¶

1.3 Design Principles¶

1.4 Requirements Language¶

2. Terminology¶

Quick Reference¶

3. Core Architecture & Governance Model¶

3.1 Three-Layer Model¶

3.2 Layer Details¶

Layer 1: ARS Assessment [NORMATIVE]¶

Layer 2: Configuration [NORMATIVE]¶

Layer 3: Runtime Evaluation [NORMATIVE]¶

3.3 Dynamic Governance Model¶

4. Protocol Flow¶

4.1 Primary Operational Loop¶

4.2 Message Types [NORMATIVE]¶

4.3 Version Negotiation [NORMATIVE]¶

5. Intervention System¶

5.1 Six Standard Interventions [NORMATIVE]¶

5.2 Intervention Examples¶

Example 1: OK¶

Example 2: Nudge¶

Example 3: Flag + OK¶

Example 4: Escalate¶

Example 5: Block¶

Example 6: Halt¶

5.3 Tripwire System [NORMATIVE]¶

5.4 Decision Thresholds by ACL Tier [NORMATIVE]¶

6. Open vs. Proprietary Components¶

6.1 Open Source (Protocol) [NORMATIVE]¶

6.2 Proprietary (Implementation) [INFORMATIVE]¶

6.3 Governance Contracts¶

What are Governance Contracts?¶

Why Use Governance Contracts?¶

Fallback Behaviors¶

Integration¶

7. Conformance¶

7.1 Core Requirements [NORMATIVE]¶

7.2 Assessment Requirements [NORMATIVE]¶

7.3 Runtime Requirements [NORMATIVE]¶

7.4 Performance Requirements [NORMATIVE]¶

8. References¶

Normative References¶

Informative References¶

Implementation Checklist¶

Common Mistakes to Avoid¶

Next Steps¶