Agent Experience Protocol

The Agent Experience Protocol (AEP) standardizes how agent systems built in different frameworks coordinate across runtime boundaries by sharing a common experience record for execution, decisioning, review, outcomes, and governed adaptation.

AEP is a security-native experience protocol for runtime assurance that preserves the evidence and feedback signals implementations use to detect novel or risky behavior, strengthen runtime controls, and fold repeatedly validated controls into safer default agent behavior over time.

Similar to how LSP standardized editor-language-server integration and ACP standardized client-agent sessions, AEP standardizes the experience boundary across agent runtime systems.

Current protocol version: 2026-04-02

Install

npm install agent-experience-protocol

Use this package when you want the bundled AEP schemas, fixtures, and protocol artifacts in your project. This package is a protocol artifact package, not a full runtime SDK or CLI.

Implementations

AEP is independent of any one implementation. Concrete implementations may expose AEP clients, servers, adapters, or protocol-aligned runtime surfaces.

• @coreax/sdk - Reference TypeScript implementation and adapter surface aligned with AEP.

Companion Skill

If you are using an agent to build against AEP, point it at the companion agent-experience-protocol-skill and its aep-implementer skill.

The skill is not part of the wire protocol. It is the implementation harness that makes AEP easier to adopt across agent environments and other systems. It helps an agent:

• read the spec in the right order
• choose the smallest conforming subset
• scaffold a client, server, or adapter
• keep the translation layer narrow
• validate against bundled schemas and fixtures

Use it when you want interoperable boundaries instead of another one-off integration. It covers the parts most teams miss when they try to implement the agent harness themselves, and keeps the agent focused on conformance instead of rediscovering the protocol from scratch.

Why AEP?

Agent systems increasingly cross more than one boundary:

• one node proposes an action
• another executes it
• a runtime engine evaluates whether it should continue
• a review or clarification system resolves uncertainty
• a memory, replay, or learning system consumes the result later

Without a shared protocol, that creates the same problems repeatedly:

• integration overhead between runtimes, gateways, review systems, and assurance services
• fragmented records for execution, risk, compliance, and outcomes
• weak replayability and poor portability across implementations
• tight coupling between runtime control and downstream learning or export pipelines

AEP is designed to make those boundaries interoperable without forcing every system to share the same internal implementation.

What AEP Standardizes

AEP is a versioned protocol built around three layers:

1. Session and binding
   • peers call initialize
   • they negotiate protocolVersion, capabilities, auth, and limits
   • the required binding is JSON-RPC 2.0 over HTTPS
2. Experience model
   • ExperienceRef provides stable identity for a governed run
   • ExperienceEvent preserves append-only chronology
   • derived records such as Submission, Decision, Clarification, Resolution, Execution, Outcome, Improvement, OptimizationJob, and Rollout attach to the same experience
3. Method families
   • aep.invoke for cross-hop execution
   • aep.runtime.* for runtime decisioning and control resolution
   • aep.clarification.* and aep.review.* for authoritative oversight
   • aep.execution.*, aep.reflection.*, and aep.outcome.* for lifecycle recording
   • aep.export.*, aep.memory.*, aep.improvement.*, aep.promotion.*, aep.rollout.*, and optional aep.optimize.* for replay, learning, and governed adaptation

The protocol is commonly composed into narrower profiles:

• A2A for hop-to-hop agent coordination
• A2P for agent-to-platform or oversight-service coordination
• AP2 for verifiable intent and cart mandates on side-effecting calls

Typical Lifecycle

At a high level, an AEP interaction looks like this:

1. A caller initializes a session and learns what the peer supports.
2. The caller opens or references an experience.
3. New facts are appended as ExperienceEvent records.
4. A candidate action is captured as a Submission.
5. Another node may be invoked and/or a runtime decision may be requested.
6. Clarification, review, execution, reflection, and outcome records are attached as the run continues.
7. Replay, export, improvement, promotion, rollout, and optional optimization artifacts may be derived later from the same durable experience.

The important design point is that chronology comes first. Source events remain replayable even when derived records are recomputed or interpreted by another system later.

What AEP Is Not

AEP standardizes the portable boundary, not the internals behind that boundary.

It does not prescribe:

• local SDK ergonomics or framework integrations
• proprietary scoring models, optimizer prompts, or search strategies
• review UIs, operator workflows, or storage engines
• vendor-specific remediation, rollout, or optimization logic

Implementations can differ internally as long as they preserve the protocol semantics and wire contract.

Get Started

• Introduction
• Architecture
• Runtime Assurance
• Governance
• Risk
• Compliance

Protocol

• Overview
• Initialization
• Profiles
• Experience Model
• Method Families
• Schema
• Implementers Guide
• Full Specification
• Versioning
• Examples
• Fixtures

Project

• Status
• Implementation Status Model
• Non-Goals
• Contributing
• Code of Conduct
• Governance
• Maintainers
• License

Contributing

AEP is a protocol intended for broad adoption across the ecosystem; we follow a structured process to ensure changes are well-considered. Read the Contributing Guide for more information.

Contribution Policy

This project does not require a Contributor License Agreement (CLA). Instead, contributions are accepted under the following terms:

By contributing to this project, you agree that your contributions will be licensed under the Apache License, Version 2.0. You affirm that you have the legal right to submit your work, that you are not including code you do not have rights to, and that you understand contributions are made without requiring a Contributor License Agreement (CLA).

How To Cite

If you use AEP in a paper, proposal, or implementation report, cite the protocol repository and the protocol version you used.

Suggested citation:

teluashish0. Agent Experience Protocol (AEP). GitHub repository. Protocol version 2026-04-02. https://github.com/teluashish0/agent-experience-protocol

BibTeX:

@misc{aep2026,
  author = {{teluashish0}},
  title = {Agent Experience Protocol (AEP)},
  year = {2026},
  howpublished = {\url{https://github.com/teluashish0/agent-experience-protocol}},
  note = {Protocol version 2026-04-02}
}

References

1. Brat, Guillaume, and Ganesh Pai. 2023. Runtime Assurance of Aeronautical Products: Preliminary Recommendations. NASA Technical Memorandum NASA/TM-20220015734. PDF
2. Schierman, John D., Michael D. DeVore, Nathan D. Richards, and Matthew A. Clark. 2020. "Runtime Assurance for Autonomous Aerospace Systems." Journal of Guidance, Control, and Dynamics 43(12): 2205-2217. DOI
3. DeepDelver. Delve - Fake Compliance as a Service - Part I. Substack. Link