290 lines
11 KiB
Markdown
290 lines
11 KiB
Markdown
---
|
|
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}}.
|