Public documentation for the AXME platform — API references, protocol specifications, integration guides, security model, and the full visualization program.
Alpha · Protocol and API surface are stabilizing. Not recommended for production workloads yet.
Alpha — install CLI, log in, run your first example in under 5 minutes. Quick Start · hello@axme.ai
AXME is a coordination infrastructure for durable execution of long-running intents across distributed systems.
It provides a model for executing intents — requests that may take minutes, hours, or longer to complete — across services, agents, and human participants.
At the core of AXME is AXP (Intent Protocol) — an open protocol that defines contracts and lifecycle rules for intent processing.
AXP can be implemented independently.
The open part of the platform includes:
- the protocol specification and schemas
- SDKs and CLI for integration
- conformance tests
- implementation and integration documentation
Without AXME Cloud runtime, these open components are still usable for protocol-compatible implementations and validation.
AXME Cloud is the managed service that runs AXP in production together with The Registry (identity and routing).
It removes operational complexity by providing:
- reliable intent delivery and retries
- lifecycle management for long-running operations
- handling of timeouts, waits, reminders, and escalation
- observability of intent status and execution history
State and events can be accessed through:
- API and SDKs
- event streams and webhooks
- the cloud console
axme-docs/
├── docs/
│ ├── diagrams/ # Full visualization program (SVG / PNG / DOT / MMD sources)
│ │ ├── intents/ # Intent lifecycle, policy, delivery, approvals
│ │ ├── platform/ # System context, container view, enterprise placement
│ │ ├── protocol/ # Protocol envelope, versioning, idempotency, transport
│ │ ├── api/ # API method families, error model, pagination, quotas
│ │ ├── security/ # Auth/authz, crypto, trust boundaries, threat model
│ │ ├── operations/ # Release, DR, SLOs, observability, runbooks
│ │ └── website/ # Diagrams for the public website / landing page
│ ├── openapi/ # OpenAPI artifacts for the public API surface
│ ├── connectors/ # Connector setup guides (HTTP, webhook, MCP)
│ ├── ADR-002-service-boundaries.md
│ ├── ADR-003-trust-consent-model.md
│ ├── axme-is-not-rpc.md
│ ├── B2B_FEATURES.md
│ ├── enterprise-routing-transport-operations.md
│ ├── enterprise-runtime-model-and-placement.md
│ ├── enterprise-scoped-credentials-migration-note.md
│ ├── examples-cloud-vs-protocol.md
│ ├── external-integrator-dry-run.md
│ ├── integration-quickstart.md
│ ├── mcp-api-reference.md # MCP API reference — all 48 tools, auth, response format
│ ├── mcp-axme-continuation-pattern.md
│ ├── migration-and-deprecation-policy.md
│ ├── migration-message-centric-to-intent-lifecycle.md
│ ├── MVP_SCOPE.md
│ ├── public-api-auth.md
│ ├── public-api-families-d1-intents-inbox-approvals.md
│ ├── public-api-families-d2-webhooks-capabilities.md
│ ├── public-api-families-d3-users.md
│ ├── public-api-families-d4-invites-media.md
│ ├── public-api-families-d5-schemas.md
│ ├── public-api-families-d6-enterprise-governance.md
│ ├── security-overview.md
│ └── supported-limits-and-error-model.md
├── scripts/
│ └── validate_docs.py
└── tests/
The diagram below shows how AXME components relate: the public gateway, control plane services, connectors, and client SDKs.
The gateway is the single public entry point. Intents flow from SDK clients through TLS to the gateway, which routes them into the durable scheduler and connector layer. Webhooks and MCP callbacks leave the platform from the connector side, cryptographically signed.
Every intent progresses through a well-defined state machine. The diagram below shows all states, transitions, and terminal outcomes.
Key states: PENDING → PROCESSING → WAITING_* → DELIVERED → RESOLVED. Any intent can be cancelled or expire at most transition points. Retry loops are bounded by the policy envelope.
The complete runtime container view — services, databases, queues, and their connections:
Gateway (public REST API), agent-core (workflow engine), auth service, MCP platform (48 JSON-RPC tools), and tool registry run as Cloud Run services sharing a PostgreSQL instance. The scheduler runs on the gateway via internal tick endpoints.
- Install the CLI and run your first example: https://cloud.axme.ai/alpha/cli
- Choose your SDK: Python · TypeScript · Go · Java · .NET
- Follow
docs/integration-quickstart.mdfor the full onboarding path - Example hubs:
- Cloud runnable: axme-examples/cloud
- Protocol-only: axme-examples/protocol
# Validate this documentation repo locally
python -m pip install -e ".[dev]"
python scripts/validate_docs.py
pytest| Document | Description |
|---|---|
integration-quickstart.md |
End-to-end onboarding path for new integrators |
public-api-auth.md |
Authentication: platform API keys, actor tokens, JWT validation |
security-overview.md |
Security architecture, controls, and enterprise review baseline |
supported-limits-and-error-model.md |
Rate limits, quotas, error codes, retriability table |
migration-and-deprecation-policy.md |
API versioning, deprecation timelines, migration guides |
mcp-api-reference.md |
MCP Server — all 48 tools, auth model, response format |
cross-org-receive-policy.md |
Cross-org intent delivery: org policy + agent overrides |
agent-addressing.md |
Agent address registry, agent:// URI scheme |
| Document | Scope |
|---|---|
D1 — Intents, Inbox, Approvals |
Intent CRUD, SSE, lifecycle events, human tasks |
D2 — Webhooks, Capabilities |
Webhook subscriptions, deliveries, event types |
D3 — Users |
User profiles, nicks, contacts |
D4 — Invites, Media |
Invite links, media upload/download |
D5 — Schemas |
Schema governance, payload validation |
D6 — Enterprise Governance |
Orgs, workspaces, members, agents, policies, quotas |
AXP wraps every intent in a signed envelope. The protocol layer ensures integrity, ordering, and schema version negotiation.
The envelope carries the intent payload, sender identity, schema version, idempotency key, and a gateway-applied HMAC signature. Recipients verify the signature before processing.
Idempotency and replay protection are first-class protocol features:
Duplicate requests bearing the same idempotency key return the cached response without re-executing. Replay attacks are rejected by the nonce registry.
The platform enforces layered security boundaries. The trust boundary diagram maps each enforcement point:
Public-facing TLS terminates at the gateway. Internal service calls use mTLS. Data at rest is encrypted with AES-256-GCM. Webhook payloads carry HMAC-SHA256 signatures.
Security control baseline for enterprise review: docs/security-overview.md.
Authentication and authorization enforcement flow:
API key verification → JWT validation → org/workspace scope check → role-based access → resource-level policy grant evaluation. All steps are audited.
The docs/diagrams/ directory is the canonical home for all platform visualizations. Each diagram is available in four formats: .mmd (Mermaid source), .dot (Graphviz source), .svg (rendered vector), and .png (raster).
- Visualization Backlog & Status — P0 / P1 / P2 diagram inventory
- Diagram Usage Matrix — which diagrams appear in which repositories
- Repository Distribution Plan — placement strategy
| Repository | Role |
|---|---|
| axme-spec | Canonical schema and protocol contracts |
| Control-plane runtime (private) | Internal runtime implementation |
| axme-conformance | Conformance and contract test suite |
| axme-sdk-python | Python SDK |
| axme-sdk-typescript | TypeScript SDK |
| axme-sdk-go | Go SDK |
| axme-sdk-java | Java SDK |
| axme-sdk-dotnet | .NET SDK |
| axme-cli | Command-line interface |
- Bug reports and docs feedback: open an issue in this repository
- Quick Start: https://cloud.axme.ai/alpha/cli · Contact: hello@axme.ai
- Security disclosures: see SECURITY.md
- Contribution guidelines: CONTRIBUTING.md