feat: add draft data, gap analysis report, and workspace config
This commit is contained in:
@@ -0,0 +1,289 @@
|
||||
---
|
||||
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}}.
|
||||
Reference in New Issue
Block a user