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

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

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

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

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

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

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