ietf-draft-analyzer/workspace/drafts/new-drafts/draft-a-aem-agent-ecosystem-model-01.md

---
title: "Agent Ecosystem Model (AEM): Architecture and Terminology"
abbrev: "AEM"
category: info
docname: draft-aem-agent-ecosystem-model-01
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
  - agent ecosystem
  - DAG
  - HITL
  - agentic workflows

author:
  -
    fullname: TBD
    organization: Independent
    email: placeholder@example.com

normative:
  RFC2119:
  RFC8174:
  I-D.nennemann-wimse-ect:
    title: "Execution Context Tokens for Distributed Agentic Workflows"
    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
  I-D.nennemann-agent-dag-hitl-safety:
    title: "Agent Context Policy Token: DAG Delegation with Human Override"
    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

informative:
  RFC9334:
  RFC7519:
  RFC8615:

--- abstract

This document defines the Agent Ecosystem Model (AEM), a shared
architecture and terminology for building interoperable agent
systems that incorporate DAG-based execution, human-in-the-loop
safety, and graduated assurance levels.  AEM is not a protocol.
It is a reference model that establishes common vocabulary and
architectural concepts so that companion specifications (ATD,
HITL, AEPB, APAE) and implementors share a consistent frame of
reference.  The model builds on Execution Context Tokens (ECT)
for execution evidence and ACP-DAG-HITL for delegation policy.

--- middle

# Introduction

The IETF AI/agent landscape includes over 260 drafts proposing
protocols for agent communication, identity, safety, and
operations.  These drafts share many implicit concepts — tasks,
delegation, workflows, safety checks — but use inconsistent
terminology and incompatible models.

AEM provides a single reference architecture so that:

- Companion drafts (ATD, HITL, AEPB, APAE) share vocabulary.
- Implementors understand how the pieces compose.
- New proposals can position themselves within an existing model
  rather than inventing another one.

AEM is deliberately not a protocol.  It defines no wire formats,
no endpoints, and no new token types.  It is the map; the
companion drafts are the territory.

## Design Principles

1. **ECT is the execution backbone.**  All significant agent
   actions produce Execution Context Tokens
   {{I-D.nennemann-wimse-ect}}.  The ecosystem does not define a
   second DAG or audit format.

2. **ACP-DAG-HITL is the policy backbone.**
   {{I-D.nennemann-agent-dag-hitl-safety}} defines delegation
   DAGs and HITL rules.  The ecosystem extends these with
   operational semantics, not replacement structures.

3. **Same model, different assurance.**  The architecture works
   identically from a relaxed K8s dev cluster (ECT L1) to a
   regulated healthcare environment (ECT L3 with audit ledger).

4. **Protocol-agnostic.**  The ecosystem sits above any A2A
   protocol.  Agents may speak different protocols and still
   participate through translation.

# Conventions and Definitions

{::boilerplate bcp14-tagged}

# Terminology {#terminology}

Agent:
: An autonomous software entity that performs tasks, makes
  decisions, and communicates with other agents or humans.

Task:
: A discrete unit of work performed by an agent, recorded as a
  single ECT node.

Workflow:
: A set of tasks linked by dependencies, forming a DAG.
  Identified by the ECT `wid` claim {{I-D.nennemann-wimse-ect}}.

DAG (Directed Acyclic Graph):
: The execution graph formed by ECT parent references (`par`
  claims).  Also used in ACP-DAG-HITL for delegation structure.

Checkpoint:
: An ECT node recording agent state before a consequential
  action, enabling rollback.  Fully specified in ATD.

HITL Point:
: A position in the workflow where human intervention is
  required or available, governed by ACP-DAG-HITL rules.

Override:
: A human-initiated command that alters an agent's autonomous
  operation, taking precedence over the agent's own decisions.
  Fully specified in HITL.

Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one
  agent's assessed reliability of another.  Updated using an
  AIMD model; fully specified in APAE.

Protocol Binding:
: The mapping between ecosystem semantics and a specific A2A
  communication protocol.  Fully specified in AEPB.

Assurance Level:
: The degree of cryptographic and audit protection applied to
  ECTs, defined in {{I-D.nennemann-wimse-ect}}:

  | Level | ECT Format | Non-repudiation | Tamper detection | Audit ledger |
  |-------|-----------|----------------|-----------------|-------------|
  | L1 | Unsigned JSON | No | Transport only | No |
  | L2 | Signed JWT | Yes | Signature | No |
  | L3 | Signed JWT | Yes | Signature | Yes (ledger-committed) |
  {: #fig-levels title="ECT Assurance Levels"}

Assurance Profile:
: A named configuration (Relaxed, Standard, Regulated) selecting
  which mechanisms are required at a given deployment.  Fully
  specified in APAE.

Blast Radius:
: The set of agents and systems affected by a single failure.

Translation Gateway:
: A service converting messages between two agent protocols,
  recording each hop as an ECT DAG node.  Fully specified in AEPB.

# Architectural Model {#architecture}

The ecosystem is organized in four layers:

~~~
┌─────────────────────────────────────────────────────┐
│                  Policy Layer                        │
│  ACP-DAG-HITL: delegation DAG, HITL rules,          │
│  node constraints, trust thresholds                  │
├─────────────────────────────────────────────────────┤
│               Semantics Layer                        │
│  ATD: execution order, checkpoints, rollback,        │
│       circuit breakers, resource hints                │
│  HITL: override levels, approval gates, escalation   │
│  AEPB: capability ads, negotiation, translation      │
│  APAE: trust scoring, behavior verification,         │
│        provenance, assurance profiles                 │
├─────────────────────────────────────────────────────┤
│               Evidence Layer                         │
│  ECT: signed DAG of execution records (L1/L2/L3)    │
│  inp_hash/out_hash, ext claims, audit ledger         │
├─────────────────────────────────────────────────────┤
│               Identity Layer                         │
│  WIMSE / X.509 / OAuth / JWK: agent identity         │
└─────────────────────────────────────────────────────┘
~~~
{: #fig-stack title="Ecosystem Layer Stack"}

Identity Layer:
: Answers "who is this agent?"  AEM does not define identity
  mechanisms; it assumes WIMSE, X.509, OAuth, or equivalent.

Evidence Layer:
: Answers "what did this agent do?"  ECT provides per-task
  signed records linked into a DAG, with three assurance levels.

Semantics Layer:
: Answers "what does it mean and what to do about it?"  The
  four companion drafts define operational semantics on top of
  ECT:

  - **ATD** (Agent Task DAG): execution order, checkpoints,
    rollback, circuit breakers, resource hints.
  - **HITL** (Human-in-the-Loop): override levels, approval
    gates, escalation paths, explainability.
  - **AEPB** (Agent Ecosystem Protocol Binding): capability
    advertisement, protocol negotiation, translation gateways,
    agent lifecycle.
  - **APAE** (Assurance Profiles): dynamic trust scoring,
    behavior verification, data provenance, assurance profiles.

Policy Layer:
: Answers "what's allowed?"  ACP-DAG-HITL defines delegation
  constraints and HITL trigger rules.  Companion drafts extend
  `constraints` with protocol-specific fields (trust thresholds,
  checkpoint policies, protocol restrictions).

## How ECT Extensions Work {#ect-ext}

Each companion draft defines `ext` claim namespaces on ECT:

| Draft | `ext` prefix | Example claims |
|-------|-------------|----------------|
| ATD | `atd.*` | `atd.reversible`, `atd.severity`, `atd.circuit_state` |
| HITL | `hitl.*` | `hitl.level`, `hitl.operator_id`, `hitl.prior_state` |
| AEPB | `aepb.*` | `aepb.source_protocol`, `aepb.dest_protocol` |
| APAE | `apae.*` | `apae.trust_score`, `apae.confidence`, `apae.hops` |
{: #fig-ext title="ECT Extension Namespaces"}

No draft MAY use another draft's `ext` namespace without a
normative reference to that draft.

## How Policy Extensions Work {#policy-ext}

Each companion draft defines `constraints` fields on
ACP-DAG-HITL DAG nodes:

| Draft | Constraint fields |
|-------|------------------|
| ATD | `atd.checkpoint_policy`, `atd.circuit_threshold` |
| HITL | (uses ACP-DAG-HITL HITL rule fields directly) |
| AEPB | `aepb.allowed_protocols`, `aepb.max_translation_hops` |
| APAE | `apae.min_trust`, `apae.min_confidence`, `apae.assurance_profile` |
{: #fig-constraints title="ACP-DAG-HITL Node Constraint Extensions"}

# Assurance as an Orthogonal Axis {#assurance}

The entire semantics layer operates identically at all ECT
assurance levels.  The DAG structure, HITL processing, trust
scoring, and protocol translation are the same whether the ECT
is unsigned JSON (L1) or a ledger-committed signed JWT (L3).

What changes across levels is the security envelope (see
{{fig-levels}}).  A deployment MAY use different levels for
different workflows.  Internal dev pipelines might use L1;
cross-org integrations L2; regulated clinical workflows L3.

Implementations MUST ensure consistency across layers: an L3
evidence configuration provides no additional assurance if the
policy layer accepts unsigned tokens.

# Protocol Agnosticism {#agnosticism}

The ecosystem layer sits above any A2A communication protocol.
Agents communicate via their native protocol (A2A, MCP, SLIM,
uACP, etc.) while the `Execution-Context` HTTP header
{{I-D.nennemann-wimse-ect}} carries ECTs alongside protocol
messages.

When two agents speak different protocols, a translation gateway
(defined by AEPB) converts between protocols while preserving
ECT DAG continuity.  The translation hop is itself an ECT node,
so the cross-protocol path is one auditable DAG.

# Relationship to Existing Standards {#standards}

The ecosystem builds on existing IETF and industry standards.
It does not replace any of them.

| Standard | Scope | Relationship to AEM |
|----------|-------|---------------------|
| WIMSE (draft-ietf-wimse-arch) | Workload identity and security context propagation | Identity Layer; AEM assumes WIMSE for agent credentials and context propagation. |
| ECT (I-D.nennemann-wimse-ect) | JWT-based execution evidence; DAG linkage via `par` | Evidence Layer; every significant action in the ecosystem produces an ECT. |
| ACP-DAG-HITL (I-D.nennemann-agent-dag-hitl-safety) | Delegation DAG policy; HITL trigger rules | Policy Layer; ATD/HITL/AEPB/APAE extend `constraints` fields, not replace the policy language. |
| OAuth 2.0 / RAR (RFC9396) | Authorization for API access | Identity Layer; operators and agents authenticate to HITL endpoints and capability documents via OAuth. |
| RATS (RFC9334) | Remote attestation for verifying evidence freshness | Informative to APAE Regulated profile; behavior verification attestations are RATS-compatible. |
| SPIFFE/SPIRE | Workload identity URI scheme (`spiffe://`) | Identity Layer; agent identities in ECT `sub` and ACP-DAG-HITL node `agent` fields use SPIFFE URIs by convention. |
{: #fig-standards title="Relationship to Existing Standards"}

## Working Group Targets

| Companion Draft | Suggested WG | Rationale |
|----------------|-------------|-----------|
| AEM (this document) | NMOP | Informational reference model for network operations automation. |
| ATD | NMOP | Execution semantics and error recovery for network agent workflows. |
| HITL | NMOP or OPS | Human override for autonomous network management. |
| AEPB | DISPATCH or ART | Protocol binding and interoperability layer; dispatch to appropriate WG. |
| APAE | RATS or Security Dispatch | Attestation-based trust and assurance profiles for agents. |
{: #fig-wgs title="Suggested Working Group Targets"}

# Companion Draft Summary {#companions}

| Draft | Abbrev | Concern | Gaps Addressed | Normative/Informative |
|-------|--------|---------|----------------|----------------------|
| Agent Task DAG | ATD | Execution, checkpoints, rollback, circuit breakers | #1 Resource Mgmt, #3 Error Recovery | Normative |
| Human-in-the-Loop | HITL | Override, approval, escalation, explainability | #7 Human Override, #11 Explainability | Normative |
| Protocol Binding | AEPB | Interop, translation, lifecycle | #4 Cross-Protocol, #5 Lifecycle | Normative |
| Assurance Profiles | APAE | Trust, verification, provenance, dual-regime | #2 Behavior Verification, #8 Cross-Domain, #9 Dynamic Trust, #12 Provenance | Informative/Normative |
{: #fig-companions title="Companion Draft Family"}

Together with ECT (evidence) and ACP-DAG-HITL (policy), these
six documents cover all 3 critical and 6 high-severity gaps
identified in the IETF AI/agent draft landscape analysis.

# Implementation Guidance {#implementation}

## Choosing an Assurance Level

Operators select the assurance level based on deployment context:

Relaxed (L1):
: Appropriate for internal development, testing, and
  observability pipelines.  No cryptographic overhead.
  Operators SHOULD NOT use L1 where ECT records could be
  relied upon as evidence in disputes.

Standard (L2):
: Appropriate for production cross-organization deployments.
  Signed ECTs provide non-repudiation.  RECOMMENDED as the
  default for any deployment where agents cross trust domains.

Regulated (L3):
: Required for deployments subject to regulatory audit
  requirements (healthcare, finance, critical infrastructure).
  ECTs are committed to an append-only audit ledger.
  Operators MUST use L3 when a regulatory framework mandates
  tamper-evident audit trails.

## Minimum Viable Implementation

An implementation is AEM-compliant if it satisfies:

1. **Evidence**: Emits ECTs for all consequential actions.
   MAY use L1 initially.

2. **Policy**: Evaluates ACP-DAG-HITL node constraints before
   delegating tasks.

3. **Checkpoints**: Implements ATD §4 (checkpoints before
   consequential actions).  MUST declare `atd.reversible`.

4. **HITL endpoint**: Implements HITL `/.well-known/hitl/override`
   and responds within 1 second.

5. **Capability document**: Serves AEPB `/.well-known/aepb` so
   peers can discover protocol support.

The following are OPTIONAL at L1 but REQUIRED at L2+:

- Cryptographic signing of ECTs.
- APAE trust scoring.
- Behavior verification.

The following are REQUIRED only at L3 (Regulated profile):

- Audit ledger commitment.
- Continuous behavior verification.
- Provenance claims on data-transforming ECT nodes.

## Upgrade Path

Upgrading from L1 to L2:
: Add a signing key (WIMSE WIT or X.509).  Update ECT emission
  to sign tokens.  Update all agents to verify signatures.
  No protocol changes needed; ECT format is compatible.

Upgrading from L2 to L3:
: Configure an audit ledger endpoint.  Update ECT emission to
  commit each ECT.  Enable APAE continuous behavior
  verification.  Enable provenance claims.

Operators MUST NOT downgrade assurance level during an active
workflow.

# Security Considerations

## Threat Model

The AEM threat model covers the following adversary classes:

**Compromised Agent**: An agent that emits false ECTs, fabricates
errors, or attempts unauthorized rollbacks.  Mitigated by ECT
signature verification (L2+) and ACP-DAG-HITL policy validation.

**Rogue Operator**: A human who issues unauthorized overrides.
Mitigated by HITL authentication requirements (signed JWTs,
mutual TLS) and multi-operator approval for Level 4 TAKEOVER.

**Translation Gateway Attack**: A malicious or compromised
gateway that alters message content in transit.  Mitigated by
ECT `inp_hash`/`out_hash` integrity checks; receivers MUST
detect hash mismatches.

**Trust Score Manipulation**: An agent accumulates high trust
through benign behavior, then executes a malicious action.
Mitigated by APAE double-penalty for `policy_violation` events
and anomaly detection.

**Downgrade Attack**: An attacker forces use of L1 ECTs where
L2+ is required.  Mitigated by explicit assurance level checks
in ACP-DAG-HITL constraints (`apae.assurance_profile` field).

## Layer Consistency Requirement

Implementations MUST configure the semantics, evidence, and
policy layers consistently.  Specifically:

- An L3 evidence deployment MUST NOT accept L1 ECTs as proof
  of action in audit or policy decisions.
- A Regulated assurance profile MUST be paired with L3 ECTs.
- HITL Level 2+ (approval required) MUST be authenticated.

## Translation Gateway Supply Chain

Translation gateways are privileged intermediaries: they have
access to plaintext message content and can inject ECT nodes.
Operators MUST:

- Authenticate gateways using the same identity mechanisms as
  agents (WIMSE/SPIFFE).
- Audit gateway ECT nodes at L2+ for tamper detection.
- Limit `aepb.max_translation_hops` to prevent unbounded
  delegation chains through untrusted gateways.

# IANA Considerations

## AEM Ecosystem Extension Registry

This document requests the creation of the "AEM Ecosystem
Extension Registry" under IANA.  This registry collects:

1. **ECT Extension Namespaces**: Companion draft `ext` claim
   prefixes (see {{fig-ext}}).
2. **ACP-DAG-HITL Constraint Field Namespaces**: Companion draft
   `constraints` field prefixes (see {{fig-constraints}}).
3. **ECT `exec_act` Values**: All `exec_act` strings registered
   by companion drafts (see each companion's IANA section).

Registration policy: Specification Required.

Initial entries: as defined in {{fig-ext}}, {{fig-constraints}},
and the companion draft `exec_act` registrations.

--- back

# Acknowledgments
{:numbered="false"}

This architecture builds on the Execution Context Token
specification {{I-D.nennemann-wimse-ect}} and the Agent Context
Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}.  The
working group targets in {{fig-wgs}} reflect the current IETF
AI/agent draft landscape analysis.