---
title: "Agent Ecosystem Model (AEM): Architecture and Terminology"
abbrev: "AEM"
category: info
docname: draft-aem-agent-ecosystem-model-00
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:

informative:
  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/

--- 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.

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.

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.

Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one
  agent's assessed reliability of another.

Protocol Binding:
: The mapping between ecosystem semantics and a specific A2A
  communication protocol.

Assurance Level:
: The degree of cryptographic and audit protection applied to
  ECTs: L1 (unsigned JSON), L2 (signed JWT), L3 (signed +
  audit ledger).  Defined by {{I-D.nennemann-wimse-ect}}.

# 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

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"}

## How Policy Extensions Work

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

| Draft | Constraint fields |
|-------|------------------|
| ATD | `atd.checkpoint_policy`, `atd.circuit_threshold` |
| HITL | (uses HITL rules 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:

| Property | L1 | L2 | L3 |
|----------|----|----|-----|
| Structured execution records | Yes | Yes | Yes |
| DAG validation | Yes | Yes | Yes |
| Non-repudiation | No | Yes | Yes |
| Tamper detection | Transport only | Signature | Signature + ledger |
| Regulatory audit trail | No | No | Yes |
{: #fig-assurance title="Assurance Level Properties"}

A deployment MAY use different levels for different workflows.
Internal dev pipelines might use L1; cross-org integrations L2;
regulated clinical workflows L3.

# 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.

# Companion Draft Summary {#companions}

| Draft | Abbrev | Concern | Gaps Addressed |
|-------|--------|---------|----------------|
| Agent Task DAG | ATD | Execution, checkpoints, rollback | #1 Resource Mgmt, #3 Error Recovery |
| Human-in-the-Loop | HITL | Override, approval, escalation | #7 Human Override, #11 Explainability |
| Protocol Binding | AEPB | Interop, translation, lifecycle | #4 Cross-Protocol, #5 Lifecycle |
| Assurance Profiles | APAE | Trust, verification, provenance | #2 Behavior Verification, #8 Cross-Domain, #9 Dynamic Trust, #12 Provenance |
{: #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.

# Security Considerations

AEM defines no protocol mechanisms and therefore introduces no
direct security considerations.  Security properties are
inherited from the evidence layer (ECT assurance levels) and
the policy layer (ACP-DAG-HITL validation).

Implementors MUST ensure that all layers are consistently
configured: an L3 ECT deployment provides no additional
assurance if the policy layer accepts unsigned tokens.

# IANA Considerations

This document has no IANA actions.

--- 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}}.