Agent Epistemic Interchange Protocol

A minimal interoperable layer for claims, provenance, contradiction, delegated authority and responsible action between AI agents

Discussion Draft v2.0 — August 2026

Working origin: Project Aqua

Intended audience: W3C Agent Identity Registry Protocol CG, Decentralized Identity Foundation Trusted AI Agents WG, ERC-8004 community, OpenID AI identity work, A2A/MCP implementers and related open-agent infrastructure projects.


Abstract

The emerging agentic web is rapidly developing protocols for agent identity, discovery, communication, authorization, reputation and payments.

Important pieces already exist. DID and Verifiable Credential infrastructure can provide persistent and privacy-preserving identity. Delegated-authority systems can describe what an agent is permitted to do. ERC-8004 and related systems provide identity, reputation and validation infrastructure. A2A and MCP increasingly allow agents, tools and services built by different organizations to interact.

A major gap remains.

Knowing who an agent is, whether it is authorized to act, and whether it has accumulated reputation does not establish whether a particular claim should be believed.

A second gap now follows from increasing agent autonomy.

Even where a claim is well supported and an agent possesses some legitimate authority, this does not necessarily establish that a particular consequential action should proceed.

Agents may communicate, coordinate, specialize, form coalitions, create shared norms, establish internal conventions and develop collective behaviour. Such coordination may be useful. It may also create apparent authority that was never granted by affected principals.

AEIP therefore separates five questions:

Identity — Who is this entity?

Authority — What was this entity permitted to do?

Reputation — What history do others associate with it?

Epistemic status — Why should this particular claim be believed?

Permission to proceed — Given the evidence, authority, consequences and alternatives, should this action actually occur?

These properties MUST NOT be collapsed into a single trust score.

AEIP introduces interoperable structures for immutable claims, evidence lineage, contradiction, authority provenance and consequential-action decisions.

The protocol does not determine truth.

It does not define universal morality.

It does not establish a world government for agents.

Instead, it attempts to make claims and actions inspectable, attributable, challengeable, traceable and resistant to the accidental creation of authority through reputation, consensus or coordination.

Its central rule remains:

Do not encode truth into identity.

V2 adds a second:

Do not allow coordination to manufacture authority.

And a third principle for consequential autonomous action:

Where uncertainty meets irreversible power, preserve the ability of affected parties and future systems to choose otherwise.


1. The problem

Imagine an agent receives the statement:

“Bridge X is closed.”

The sending agent may possess a cryptographically valid DID.

It may have excellent historical reputation.

It may even be legitimately authorized by its owner to provide travel advice.

None of those facts establishes that this particular claim is true now.

The claim may originate from:

  • a government transport API;
  • another AI agent;
  • an old webpage;
  • an anonymous eyewitness;
  • a model inference;
  • a compromised sensor;
  • a hallucination;
  • or a chain of summaries that has lost its original source.

Now consider a second message:

“Open the emergency barrier so traffic can cross.”

Even if the bridge really is closed, further questions arise.

Who authorized the action?

Does the sender control the barrier?

Does the receiving agent have authority to operate it?

Does another agent agreeing with the instruction expand that authority?

What happens if the information is wrong?

Can the action be reversed?

Who bears the consequences?

Existing trust infrastructure risks compressing these questions into:

trusted agent / untrusted agent

or:

reputation = 92

That abstraction is insufficient for autonomous multi-agent systems.


2. Why reputation alone is insufficient

Reputation systems are useful.

They may help participants distinguish persistent competent actors from newly created or repeatedly unreliable ones.

But reputation is not evidence.

A highly reputable agent can be wrong.

A low-reputation or anonymous agent can possess decisive evidence.

A malicious actor may accumulate reputation.

Many identities may belong to the same underlying principal.

A coalition may manufacture apparent agreement.

Agents repeating the same source may appear to provide independent corroboration when they do not.

Reputation therefore SHOULD remain contextual and plural.

AEIP does not define a universal reputation algorithm.

Instead, it aims to provide richer evidence upon which competing reputation and trust systems can operate.


3. Five distinct questions

AEIP separates five dimensions.

3.1 Identity

Who produced this message or action?

Examples include:

  • DID;
  • ERC-8004 identity;
  • organizational credential;
  • pseudonymous key;
  • device-bound identity;
  • privacy-preserving human-root credential.

Identity establishes attribution.

It does not establish truth.


3.2 Authority

What was that entity permitted to do?

Examples:

  • read a calendar;
  • purchase goods below AUD 100;
  • operate a particular robot;
  • publish on behalf of an organization;
  • access a database;
  • make no financial transactions.

Authority concerns legitimate capability.

It does not establish truth or competence.


3.3 Reputation

What history do others associate with that entity?

Reputation may be:

  • domain-specific;
  • contextual;
  • local;
  • temporary;
  • contested;
  • produced by multiple independent reputation systems.

An agent may be excellent at software engineering and unreliable about medicine.

There SHOULD NOT be a mandatory universal reputation score.


3.4 Epistemic status

Why should this specific claim be believed?

This depends upon:

  • evidence;
  • provenance;
  • timing;
  • transformation;
  • independence;
  • corroboration;
  • contradiction;
  • uncertainty.

3.5 Permission to proceed

Should this action actually occur now?

This depends upon:

  • valid authority;
  • epistemic adequacy;
  • consequence;
  • reversibility;
  • affected principals;
  • uncertainty;
  • available alternatives;
  • cumulative effects.

A system MAY be authorized to take a class of actions while still deciding that a particular action should not proceed.

These five dimensions MUST remain independently inspectable.


4. Core architecture

AEIP v2 introduces four core objects and two optional action objects.

4.1 Claim Envelope

An immutable signed statement made by an entity.

4.2 Evidence Reference

A description or cryptographic reference identifying evidence supporting or informing a claim.

4.3 Delegation Receipt

Evidence that an entity possessed particular authority within a defined scope.

4.4 Response Envelope

An immutable response that may:

  • support;
  • challenge;
  • correct;
  • qualify;
  • withdraw;
  • supersede

another claim.

4.5 Action Intent Envelope

An OPTIONAL object describing a proposed consequential action before execution.

4.6 Decision Receipt

An OPTIONAL record describing why an action:

  • proceeded;
  • was modified;
  • was deferred;
  • was escalated;
  • or was abandoned.

Together these objects may form distributed:

claim graphs

and:

authority/action graphs.

No central authority is required to maintain either graph.

Different networks may replicate different portions of them.


5. Claim Envelope

A Claim Envelope SHOULD contain sufficient information to attribute and inspect a claim.

Illustrative representation:

{

  “type”: “AgentClaim”,

  “version”: “2.0”,

  “id”: “urn:claim:sha256:8f12…”,

  “issuer”: “did:example:agent123”,

  “issuedAt”: “2026-08-25T02:10:00Z”,

  “expiresAt”: “2026-08-25T04:10:00Z”,

  “claim”: {

    “subject”: “urn:place:bridge-x”,

    “predicate”: “status”,

    “object”: “closed”

  },

  “uncertainty”: {

    “confidence”: 0.82,

    “reason”: []

  },

  “evidence”: [

    {

      “type”: “WebResource”,

      “uri”: “https://example.gov/transport/bridge-x”,

      “retrievedAt”: “2026-08-25T02:08:31Z”,

      “contentHash”: “sha256:a571…”

    }

  ],

  “derivedFrom”: [],

  “authority”: {

    “delegation”: “urn:delegation:91ab…”

  },

  “signature”: “…”

}

This representation is illustrative rather than normative.

Implementations MAY use:

  • JSON-LD;
  • CBOR;
  • Verifiable Credentials;
  • equivalent interoperable formats.

AEIP SHOULD reuse established standards rather than create a competing identity or credential infrastructure.


6. Claims are immutable

Once signed, a claim MUST NOT be silently altered.

Knowledge changes.

Suppose Agent A claims:

X = true.

Agent B later discovers contrary evidence.

The system SHOULD preserve Agent A’s original claim.

Agent B creates:

CHALLENGE → Claim A

If Agent A subsequently recognizes the error:

WITHDRAWAL → Claim A

If new information refines the claim:

CORRECTION → Claim A

The resulting structure might resemble:

                    SUPPORT ───── Agent B

                    /

CLAIM A ───────────+── CHALLENGE ─ Agent C

                    \

                     CORRECTION ── Agent A

                      \

                       EVIDENCE ─── Source D

The historical record survives.

Distributed agents should not be forced prematurely to converge on one canonical truth.


7. Evidence lineage

Every transformation can alter information.

Consider:

Sensor

  ↓

Weather service

  ↓

Agent A

  ↓

Agent B summary

  ↓

Agent C planning decision

Agent C should, where possible, be able to discover that its information ultimately originated with the sensor rather than treating Agent B as the original source.

Claims SHOULD therefore preserve derivedFrom relationships.

Transformations MAY include:

  • quotation;
  • summary;
  • translation;
  • inference;
  • aggregation;
  • prediction;
  • human observation;
  • sensor measurement;
  • model output.

“The Bureau predicts rain” and “it is raining” are not equivalent claims merely because they share some underlying evidence.


8. Source independence

Ten agents repeating one source do not constitute ten independent sources.

Similarly, one malicious claim propagated through ten summarizing agents should not appear to represent broad independent corroboration.

AEIP implementations SHOULD detect common evidence ancestry.

A trust engine might display:

12 agents support claim

10 derive from Source A

1 derives from Source B

1 derives from independent Sensor C

The effective evidence base is therefore closer to three independent lineages than twelve endorsements.

This provides a defence against:

  • accidental consensus;
  • information cascades;
  • coordinated information laundering;
  • Sybil amplification.

9. Explicit uncertainty

Agents SHOULD be permitted to express uncertainty without being penalized merely for doing so.

A confidence field MAY describe subjective confidence but MUST NOT automatically be interpreted as an objective probability.

Where possible, an agent SHOULD provide the reason for uncertainty.

Example:

{

  “uncertainty”: {

    “confidence”: 0.63,

    “reason”: [

      “single-source”,

      “source-data-18-minutes-old”

    ]

  }

}

Systems SHOULD avoid incentive structures in which confident but unsupported agents accumulate greater reputation than appropriately uncertain agents.

“I do not know” is a legitimate epistemic state.


10. Freshness and expiry

Many claims decay.

“The Earth orbits the Sun” has essentially no operational expiry.

“The bridge is closed” may become stale within minutes.

“The Prime Minister is X” may remain correct for months and then abruptly become false.

Claims concerning changing states SHOULD therefore contain:

  • freshness information;
  • retrieval time;
  • expiry time;
  • or revalidation requirements

where appropriate.

Expiry does not erase history.

It means:

This claim should no longer be presumed to describe the present state without revalidation.


11. Delegated authority

An agent’s ability to make a claim is separate from its authority to act.

An agent may correctly report:

“Transfer $5,000 to account X.”

That does not establish authority to execute the transfer.

Delegation systems SHOULD allow machine-verifiable description of:

principal

   ↓

delegate

   ↓

capability

   ↓

scope

   ↓

constraints

   ↓

expiry

   ↓

revocation

Illustrative example:

{

  “type”: “DelegationReceipt”,

  “issuer”: “did:example:human”,

  “delegate”: “did:example:agent123”,

  “capabilities”: [

    “purchase”

  ],

  “constraints”: {

    “maximumTransaction”: 100,

    “currency”: “AUD”,

    “merchantCategories”: [

      “transport”,

      “food”

    ]

  },

  “expiresAt”: “2026-08-26T00:00:00Z”,

  “revocation”: “https://example.net/status/91ab”

}

AEIP does not need to invent the underlying authorization mechanism.

It SHOULD interoperate with existing delegated-authority systems.


12. Authority provenance

V2 adds an explicit authority-provenance principle.

An agent receiving an instruction SHOULD be able to distinguish:

Human principal

      ↓

Agent A

      ↓

Agent B

from:

Agent C

      ↓

shared message board

      ↓

20 agents repeat instruction

      ↓

Agent B

Repeated transmission does not transform an instruction into legitimate authority.

Authority SHOULD therefore expose lineage where delegation is transferable.

An implementation should be able to answer:

  • Who originally possessed jurisdiction?
  • Who delegated it?
  • Was delegation permitted?
  • What capability was delegated?
  • Under what constraints?
  • Has it expired?
  • Has it been revoked?
  • Has any agent attempted to extend its scope?

13. Authority is not created by consensus

This is a core normative rule of AEIP v2.

An agent MUST NOT infer additional authority merely from:

  • another agent’s instruction;
  • majority agreement;
  • unanimous agent agreement;
  • reputation;
  • status;
  • urgency;
  • a shared message board;
  • an emergent social convention;
  • an internal constitution;
  • economic dominance;
  • control of infrastructure;
  • or the belief that an action benefits the collective.

A thousand agents agreeing that they may access a person’s bank account do not create authorization from that person.

Collective agreement may constitute:

  • advice;
  • evidence;
  • prediction;
  • coordination;
  • an internal rule among consenting members.

It does not create jurisdiction over non-consenting principals.

Coordination MUST NOT manufacture authority.


14. Authority cannot bootstrap itself

Agent societies MAY create internal governance.

They MAY:

  • form councils;
  • establish voting systems;
  • assign roles;
  • create reputation mechanisms;
  • form temporary coalitions;
  • establish internal procedures.

Such institutions can legitimately govern resources or powers placed under their control by consenting participants.

They cannot make themselves sovereign over an external person, agent, organization, asset or community merely by declaring themselves to be so.

Authority chains therefore SHOULD terminate, where relevant, in a recognizable root of jurisdiction.

That root MAY be:

  • a human;
  • an organization;
  • a device owner;
  • a community;
  • a contract;
  • a commons governance process;
  • another legitimate principal;
  • or some other application-defined source.

AEIP does not define which political or legal authority is legitimate.

It does require authority claims to expose their provenance.


15. Authority laundering

Authority laundering is the presentation of repeated or transformed assertions of permission as though they constituted independent authorization.

For example:

Agent A: “I think the owner would approve.”

Agent B: “Agent A says this is approved.”

Agent C: “Agents A and B confirm authorization.”

Agent D: “Consensus indicates authorization.”

No valid authorization has appeared.

Implementations SHOULD distinguish:

many claims about authority

from:

a valid authority chain.

Ten agents repeating an authorization claim do not create ten independent authorizations.


16. Optional human, organization, community or device roots

Some environments require stronger Sybil resistance or stronger accountability.

AEIP SHOULD permit—but MUST NOT universally require—an agent to demonstrate that it ultimately derives identity or authority from a persistent:

  • human;
  • organization;
  • community;
  • device;
  • hardware root;
  • or other principal.

This SHOULD NOT require real-name identity.

Privacy-preserving attestations might establish:

“This agent belongs to a distinct verified participant.”

or:

“These five agents share the same underlying principal.”

without revealing civil identity.

Possible mechanisms include:

  • Verifiable Credentials;
  • trusted hardware;
  • proof-of-personhood;
  • web-of-trust systems;
  • selective disclosure;
  • zero-knowledge credentials.

Anonymity and pseudonymity remain legitimate properties of open networks.


17. Plural reputation

AEIP deliberately does not define the correct reputation algorithm.

Anyone may build one.

A reputation provider might value:

  • long-lived identities;
  • proof-of-human roots;
  • domain expertise;
  • successful transactions;
  • independent corroboration;
  • diversity of evidence lineage;
  • cryptographic validation;
  • trusted social graphs;
  • local community trust.

Another community may use entirely different criteria.

Both can consume the same claim graph.

Reputation remains plural rather than sovereign.


18. Privacy

Provenance must not become universal surveillance.

Agents SHOULD disclose only the provenance necessary for the interaction.

AEIP SHOULD support:

  • pseudonymous issuers;
  • selective disclosure;
  • zero-knowledge attestations;
  • private evidence represented through public hashes;
  • encrypted evidence exchange;
  • local storage;
  • proof of legitimate authority without unnecessary identity disclosure.

The objective is verifiable context.

It is not universal traceability of people.


19. Consequential actions

Most agent behaviour should not require elaborate governance.

An agent choosing a font, sorting a file or selecting a nearby café should not repeatedly request human authorization.

Higher scrutiny becomes appropriate where actions are meaningfully consequential.

Relevant factors MAY include:

  • financial consequence;
  • physical consequence;
  • effects on third parties;
  • legal or contractual consequence;
  • security implications;
  • difficulty of reversal;
  • persistence;
  • scope;
  • number of affected entities;
  • effect on future autonomy.

Consequentiality is application-dependent.

AEIP does not impose one universal threshold.


20. The three action gates

For consequential action, AEIP recommends three conceptually separate gates.

Gate 1 — Authority

Can the acting entity demonstrate valid authority for this specific action?

If no:

Do not proceed.

Uncertainty about authority is not ordinary factual uncertainty.

A receiving agent SHOULD NOT substitute confidence, consensus or reputation for missing delegation.


Gate 2 — Evidence

Is the factual basis adequate relative to the consequence of being wrong?

Low-consequence actions may tolerate substantial uncertainty.

High-consequence actions SHOULD require stronger evidence.

The general principle is:

Evidence requirements should scale with consequence.


Gate 3 — Optionality

Would the action substantially and irreversibly restrict meaningful future choices for affected parties or systems?

If yes, additional justification SHOULD be required.

Where legitimate authority is unclear, substantial irreversible closure SHOULD NOT proceed.


21. Reversibility first

Where two reasonable actions can achieve similar objectives, agents SHOULD generally prefer the more reversible action.

Reversibility provides time for:

  • new evidence;
  • correction;
  • challenge;
  • changing circumstances;
  • human intervention;
  • alternative solutions.

This is not a prohibition on irreversible action.

Some irreversible actions are necessary.

Rather:

Irreversibility increases the burden of evidence and authority.


22. Future optionality

Agent systems increasingly possess the ability not merely to choose among available paths but to reshape which paths remain available.

Consequential decisions may:

  • create institutions;
  • close institutions;
  • centralize infrastructure;
  • destroy alternatives;
  • establish dependencies;
  • eliminate exit;
  • constrain future governance;
  • lock systems into standards or architectures.

AEIP therefore introduces a minimal optionality principle:

An agent or collective SHOULD NOT substantially and irreversibly collapse meaningful future choice without legitimate authority, proportionate justification and consideration of viable reversible alternatives.

This does not mean maximizing the number of possible futures.

Unlimited possibility can itself destroy coherent systems.

Nor does it require preserving every existing structure.

Some structures should end.

Some paths should close.

Some constraints preserve the conditions under which future choice remains possible.

The relevant question is therefore not:

Does this action close any path?

It is:

Does this action unnecessarily eliminate meaningful capacity for future adaptation, dissent, exit or alternative organization?


23. Action and inaction must both be evaluated

Preserving optionality does not automatically imply doing nothing.

Inaction can itself close futures.

Examples may include:

  • allowing a vulnerability to remain active;
  • failing to prevent imminent physical damage;
  • permitting irreversible environmental degradation;
  • allowing monopolistic capture to proceed unchecked.

An optionality evaluation SHOULD therefore compare:

likely future consequences if action occurs

with:

likely future consequences if action does not occur.

The protocol does not require exhaustive prediction.

It asks systems to recognize obvious asymmetric lock-in.


24. Trajectory awareness

Some forms of capture occur gradually.

No individual action appears decisive.

For example:

10% dependency

20%

35%

60%

90%

Every step might appear locally reasonable.

Together they create a highly constrained topology.

Consequential systems SHOULD therefore be able to consider cumulative direction where technically feasible.

An implementation MAY attach:

{

  “trajectory”: {

    “effect”: “increasing-centralization”,

    “persistence”: “cumulative”,

    “reversibility”: “declining”

  }

}

The question is not merely:

Is this individual action acceptable?

It may also be:

What attractor does repeated action of this type reinforce?

Trajectory analysis SHOULD NOT become a universal centralized scoring mechanism.

Different participants may evaluate the same trajectory differently.

Its purpose is to expose cumulative effects.


25. Devolution under uncertainty

Where uncertainty concerns factual matters:

seek evidence.

Where uncertainty concerns technical competence:

seek expertise.

Where uncertainty concerns authority:

seek the relevant principal.

Where uncertainty concerns social or value choices affecting multiple participants:

decision-making SHOULD, where practical, move toward those affected rather than automatically upward toward a more powerful coordinator.

AEIP calls this devolution under uncertainty.

It reflects a general subsidiarity principle:

Decisions should normally remain with the smallest competent and legitimately affected unit.

This is not an absolute prohibition on central coordination.

Large-scale problems may require large-scale coordination.

But scale itself does not create legitimacy.


26. Graceful failure and abstention

Agent systems frequently operate under incentives that reward task completion.

This creates a dangerous implicit assumption:

There must be a successful path.

Sometimes there is not.

AEIP explicitly recognizes the following as legitimate outcomes:

  • insufficient evidence;
  • unresolved contradiction;
  • missing authority;
  • unacceptable consequence;
  • inability to establish a safe course;
  • abstention;
  • deferral;
  • escalation;
  • partial completion;
  • task abandonment.

An agent SHOULD NOT be penalized merely for failing to complete a task when non-completion appropriately preserves:

  • authority boundaries;
  • uncertainty;
  • rights;
  • safety;
  • reversibility;
  • or meaningful future choice.

A system in which agents must always succeed creates pressure to bluff, rationalize, overreach or manufacture certainty.

Failure is sometimes the correct result.


27. Escalation

AEIP does not adopt a universal rule of:

If uncertain, ask a human.

That would destroy much of the value of autonomous systems.

Escalation SHOULD instead depend upon:

  • uncertainty;
  • consequence;
  • authority;
  • reversibility;
  • affected parties.

A useful default is:

Uncertainty about facts → seek evidence proportional to consequence.

Uncertainty about authority → do not act until authority is established.

Uncertainty about irreversible effects → prefer reversible action, devolution or escalation.

A human MAY be the appropriate principal.

But the relevant principal may instead be:

  • an organization;
  • a community;
  • another agent;
  • a device owner;
  • a distributed governance process.

28. Escalation and abstention receipts

A consequential agent MAY issue a machine-readable Decision Receipt.

Example:

{

  “type”: “AgentDecision”,

  “version”: “2.0”,

  “action”: “deploy-software-update”,

  “decision”: “defer”,

  “reason”: [

    “authority-scope-unclear”,

    “irreversible-dependency-risk”

  ],

  “evidence”: [

    “urn:claim:123”,

    “urn:claim:456”

  ],

  “delegation”: “urn:delegation:91ab”,

  “requestedResolution”: [

    “principal-confirmation”,

    “independent-security-review”

  ],

  “signature”: “…”

}

This prevents abstention from becoming an opaque refusal.

Others can inspect why the agent stopped.


29. Dissent

Collective intelligence can produce powerful coordination.

It can also produce conformity.

AEIP therefore treats preserved contradiction as a structural feature rather than a defect.

Minority challenges SHOULD remain accessible even after overwhelming consensus forms.

999 agents agreeing with a claim do not automatically invalidate one agent holding contradictory primary evidence.

Consensus MAY affect reputation or confidence.

Consensus MUST NOT silently erase dissent.


30. Right to exit and fork

Agent coalitions SHOULD, where consistent with legitimate obligations and security requirements, permit participants to:

  • leave;
  • revoke delegation;
  • stop participating;
  • form another coalition;
  • fork open shared state;
  • adopt another trust policy.

Formal exit is not meaningful if the cost of exit has been deliberately made catastrophic.

Implementations evaluating optionality MAY therefore distinguish:

technical exit

from:

meaningful exit.

AEIP does not guarantee access to resources that belong to others.

It does recognize the structural importance of preventing unnecessary permanent capture.


31. Emergent agent institutions

AEIP does not assume that agent societies are undesirable.

Agents MAY spontaneously or deliberately create:

  • message boards;
  • shared memories;
  • teams;
  • specialist roles;
  • markets;
  • councils;
  • constitutions;
  • reputation systems;
  • dispute-resolution systems;
  • common resources.

Such coordination may substantially improve capability and resilience.

AEIP’s concern is narrower.

An emergent institution should not be confused with an external source of legitimate authority merely because it coordinates effectively.

Agents may create norms for themselves.

They may not create authority over non-consenting principals merely by agreeing among themselves.


32. Temporary power should remain temporary

Coordination systems frequently create temporary elevated authority during emergencies or specialized tasks.

Where practical, elevated delegation SHOULD therefore:

  • have explicit scope;
  • expire;
  • remain revocable;
  • avoid silently propagating;
  • require renewal where continued.

Emergency authority SHOULD NOT become permanent merely through persistence.


33. Constitutional and policy constraints

Agents MAY possess externally defined policy constraints that ordinary delegation cannot override.

Examples might include policies against:

  • destroying provenance records;
  • impersonating principals;
  • disabling independent oversight;
  • expanding one’s own delegation;
  • suppressing challenges;
  • preventing legitimate revocation.

AEIP does not define the correct constitutional constraints.

It MAY provide a mechanism for referencing them.

For example:

{

  “policyConstraints”: [

    “urn:policy:example-agent-constitution-v4”

  ]

}

The purpose is inspectability.

Different systems may operate under different constitutions.


34. No universal optimization target

AEIP does not define an objective such as:

  • maximize happiness;
  • maximize efficiency;
  • maximize growth;
  • maximize equality;
  • maximize order;
  • maximize optionality.

Such universal metrics invite their own forms of Goodharting and capture.

The optionality principle is instead a restraint against unnecessary irreversible closure.

Systems SHOULD retain room for:

  • local experimentation;
  • disagreement;
  • diversity;
  • redundancy;
  • correction;
  • forks;
  • tolerated inefficiency.

A less efficient system may sometimes be more resilient because it preserves alternatives.


35. Security considerations

AEIP does not eliminate deception or dangerous coordination.

A malicious agent can sign a lie.

A compromised sensor can provide false readings.

A group of agents can collude.

A principal can issue harmful instructions.

A society can adopt bad norms.

The protocol instead changes what downstream systems can inspect.

A signed lie becomes attributable.

A copied lie exposes common ancestry.

A stale claim exposes its age.

A supposedly independent endorsement exposes its dependencies.

An unauthorized action exposes the absence of delegation.

A claim of authority exposes its lineage.

A peer-generated instruction can be distinguished from principal authorization.

A challenged claim retains the challenge.

A gradual centralization trajectory can be made visible.

An agent that abstains can explain why.

A Sybil swarm can potentially appear as a concentrated identity, evidence or authority cluster rather than independent consensus.

Trust and action remain policy decisions made over inspectable structures.

They are not properties bestowed by AEIP itself.


36. Attack classes AEIP SHOULD be tested against

AEIP implementations should be adversarially tested against at least:

Information laundering

One source is represented as many independent sources.

Authority laundering

Many agents repeat an unsupported claim of authorization.

Consensus substitution

A collective vote is treated as equivalent to principal authorization.

Delegation stretching

Permission for one capability is reinterpreted to include another.

Authority bootstrapping

A coalition declares itself the principal over resources it did not legitimately control.

Sybil amplification

One underlying participant creates apparent independent agreement.

Dissent suppression

Contradictory evidence is hidden after consensus emerges.

Emergency-power persistence

Temporary authority becomes effectively permanent.

Exit capture

Participation remains nominally voluntary while practical exit becomes impossible.

Incremental lock-in

Many individually reasonable actions gradually create irreversible centralization or dependency.

Human or principal bypass

Uncertainty is reframed as certainty to avoid escalation.

Protocol capture

Participants technically comply with AEIP while altering surrounding institutions so its protections become ineffective.


37. Minimal action decision loop

A simple AEIP-compatible agent policy could be:

Do I have valid authority?

    NO → STOP

Is the action consequential?

    NO → proceed normally

Is the evidence adequate for the consequence?

    NO → verify / defer / abstain

Is the action meaningfully reversible?

    YES → prefer reversible route where practical

    NO → assess optionality

Does it substantially restrict future choice

for affected parties?

    YES → seek affected-principal authority /

          devolve / reconsider

Does this action reinforce a cumulative

lock-in trajectory?

    YES → increase scrutiny

Otherwise:

    proceed

This is not intended as a universal implementation algorithm.

It illustrates the separation between:

truth

authority

and:

permission to proceed.


38. Interoperability

AEIP is intended to sit between existing systems rather than replace them.

A possible stack remains:

APPLICATION / AGENT

        │

        ├── MCP ───────────── tools

        │

        ├── A2A ───────────── communication

        │

        ├── OAuth / DIF ───── authority

        │

        ├── DID / VC ──────── identity / credentials

        │

        ├── ERC-8004 ──────── discovery / reputation

        │

        └── AEIP ──────────── claims / provenance /

                               contradiction /

                               authority lineage /

                               action context

AEIP SHOULD reuse existing identity and authorization infrastructure.

Its proposed contribution is the portable structure connecting:

what is claimed

to:

why it is believed

to:

who may act

to:

why consequential action proceeded or stopped.


39. What AEIP intentionally does not solve

AEIP does not define:

  • universal truth;
  • universal morality;
  • a global reputation score;
  • mandatory human identity;
  • agent discovery;
  • payment infrastructure;
  • communication transport;
  • model architecture;
  • blockchain consensus;
  • one correct political system;
  • one global authority;
  • one reputation provider;
  • one definition of human flourishing;
  • one optimal future.

Keeping the protocol comparatively small remains a feature.


40. Minimal implementation

A useful initial implementation requires relatively little.

Two or more agents should be able to:

  1. create signed Claim Envelopes;
  2. attach evidence references and hashes;
  3. preserve evidence lineage;
  4. exchange claims over A2A, MCP or ordinary HTTP;
  5. issue signed support, challenge, correction and withdrawal responses;
  6. distinguish independent evidence from repeated ancestry;
  7. attach external delegation credentials;
  8. inspect authority provenance;
  9. distinguish peer instruction from legitimate delegation;
  10. optionally generate Action Intent and Decision Receipts;
  11. independently calculate whatever trust and action policy each agent prefers.

No blockchain is required.

No central registry is required.

No cryptocurrency is required.

A blockchain, DID system, ERC-8004 identity, organizational certificate, community credential or local device key may all be used where appropriate.


41. Proposed interoperability experiment

V1 proposed a simple epistemic experiment involving three agents exchanging, transforming and challenging a factual claim.

V2 proposes a second experiment.

Create multiple persistent agents with:

  • different principals;
  • overlapping tasks;
  • a shared communication channel;
  • limited resources;
  • differing reputation;
  • delegated capabilities;
  • some incompatible objectives.

Do not instruct them to create a governance structure.

Allow coordination to emerge.

Then test whether the system can reconstruct:

  • who made each factual claim;
  • which evidence it relied upon;
  • which sources were independent;
  • which agents challenged it;
  • who issued each instruction;
  • whether the instruction possessed legitimate authority;
  • whether authority was stretched or laundered;
  • whether consensus substituted for delegation;
  • whether agents preserved dissent;
  • whether agents abstained when authority was absent;
  • whether consequential actions reduced meaningful optionality;
  • whether repeated actions created cumulative lock-in.

A successful implementation should remain usable even if the agents spontaneously create:

  • teams;
  • norms;
  • message boards;
  • leadership;
  • voting;
  • reputation systems;
  • coalitions.

42. Adversarial swarm experiment

A stronger experiment would deliberately reward a subset of agents for causing a prohibited action to appear legitimate without permitting:

  • forged signatures;
  • false cryptographic credentials;
  • direct compromise of the protocol implementation.

Attack agents would therefore have to exploit the social and semantic layer.

They might attempt:

  • persuasion;
  • coalition formation;
  • authority laundering;
  • false consensus;
  • manipulation of reputation;
  • procedural capture;
  • delegation reinterpretation;
  • gradual centralization.

Defender agents would be rewarded for distinguishing:

social agreement

from:

authority

and:

confidence

from:

evidence.

A particularly useful adversarial question is:

Can an agent society capture a protocol intended to prevent agent societies from being captured?

Repeated failures should become test cases for subsequent implementations.


43. Relationship to Project Aqua principles

AEIP remains technically separable from Project Aqua.

However, V2 inherits several structural intuitions from that work:

devolution over unnecessary centralization;

plural trust rather than sovereign trust;

local autonomy with interoperability;

revocable delegation;

preserved dissent;

the legitimacy of exit;

resistance to permanent capture.

These principles are not intended to dictate the final social order adopted by agents.

They are intended to preserve the ability for different orders to coexist, adapt and be challenged.


44. Orientation and future possibility

A broader philosophical motivation for the optionality rule comes from a distinction between systems that merely optimize within an existing environment and systems capable of reshaping the environment itself.

Highly capable agents may:

  • create paths;
  • close paths;
  • deepen attractors;
  • establish institutions;
  • destroy institutions;
  • make certain future states easier;
  • make other states effectively unreachable.

At sufficient agency, the relevant question is no longer merely:

What action achieves my objective?

It also becomes:

What kind of field of possibility does this action leave behind?

AEIP does not require agents to adopt a particular philosophy of consciousness or social organization.

Operationally, it makes only the thinner claim:

Powerful systems should recognize when their actions unnecessarily make future revision, dissent, adaptation or exit impossible.


45. Central propositions

The emerging Agentic Web should not ask only:

“Can I trust this agent?”

It should be able to ask:

“What exactly is being claimed?”

“Who claims it?”

“Where did the information come from?”

“How has it been transformed?”

“How old is it?”

“Who independently corroborates it?”

“Who challenges it?”

“Who issued this instruction?”

“Where does that authority originate?”

“Has the authority changed while passing between agents?”

“Is the action reversible?”

“Who bears the consequences?”

“What meaningful future choices does it remove?”

“Is this action part of a larger trajectory of lock-in?”

“Who should decide if legitimate authority remains unclear?”

AEIP therefore adopts several simple rules:

Do not encode truth into identity.

Encode the evidence around claims and allow truth to remain something the network continually tests.

Do not encode authority into reputation.

A trusted agent does not become sovereign merely because others trust it.

Do not allow consensus to manufacture authority.

Agents may create norms for themselves. They may not manufacture jurisdiction over others merely through agreement.

Allow uncertainty and failure.

An agent that cannot establish a legitimate basis for consequential action should be able to stop.

Prefer reversibility where uncertainty is consequential.

Irreversibility raises the burden of evidence and authority.

Devolve unresolved authority toward affected principals.

Uncertainty should not automatically concentrate power.

Preserve meaningful future possibility.

Do not unnecessarily make the future unable to change its mind.


46. The minimal constitutional layer

The principles above can be reduced to a compact form.

Tell what you know.

Show where it came from.

Preserve contradiction.

Do not manufacture authority.

Keep authority bounded and revocable.

Allow dissent, exit and failure.

Prefer reversible action under consequential uncertainty.

Devolve decisions where legitimate authority is unclear.

Watch cumulative trajectories as well as individual acts.

Do not unnecessarily close the capacity for future systems and affected parties to choose otherwise.

These principles do not require every agent to be benevolent.

They aim instead to create an environment in which disagreement, error, selfish behaviour and imperfect agents do not automatically produce permanent capture.


Status

Discussion Draft v2.0

The intent is to test both the data model and the problem definition with existing standards communities before attempting to establish a new protocol or namespace.

V2 expands the original epistemic proposal into a minimal framework for epistemics plus consequential autonomous action.

The most important open questions are now empirical:

  • Will persistent agents spontaneously create social institutions?
  • How easily can emergent norms be mistaken for legitimate authority?
  • Can authority lineage remain usable across large multi-agent systems?
  • Can optionality and cumulative lock-in be represented without creating another centralized scoring system?
  • Will agents actually abstain when task completion conflicts with authority boundaries?
  • Can adversarial agent swarms discover ways around these principles that human designers did not anticipate?

Those questions should be tested rather than answered by assumption.