Introduction
Contemporary agentic systems resolve natural language intent to executable API calls through a combination of tool description retrieval and language model inference. This approach produces correct selections at low tool counts but degrades in both accuracy and safety as the available tool surface expands. More fundamentally, tool selection — the problem of identifying which API to call — is distinct from execution governance — the problem of determining whether the identified action should execute and under what conditions.
AMCP addresses the governance gap. The protocol separates the decision phase from the execution phase, returning with each decision a governance contract that encodes the minimum handling requirements derived from the semantic consequences of the selected primitive. This contract is cryptographically bound at decision time: what was evaluated is exactly what executes. Downstream systems may escalate handling requirements; they may not reduce them.
Design Principles
Determinism. Given identical inputs, AMCP produces identical outputs. No language model participates in the decision path. Scoring is computed from fixed ontology weights at ingest time and does not change between requests.
Separation of decision and execution. The /decide endpoint resolves intent and issues a contract. The /execute endpoint redeems a contract. The gap between these two operations is where governance lives — callers inspect the returned risk profile and handling requirements before choosing to proceed.
Minimum floor, not maximum ceiling. AMCP specifies the minimum acceptable handling for an action. Implementing systems are free to apply stricter requirements. They are not permitted to execute below the specified minimum.
Explicit failure. When AMCP cannot resolve an intent to a supported primitive, it returns a NO_MATCH state with a clear reason. Silent failures and hallucinated endpoints are not possible by design.
Definitions
| Term | Definition |
|---|---|
| Primitive | A single addressable API operation, identified by a dot-notation name (e.g. stripe.customers.create). The unit of resolution in AMCP. |
| Intent | A natural language description of a desired action submitted to the /decide endpoint. AMCP resolves intent to a primitive without requiring the caller to know the primitive name. |
| Action Contract | An immutable, time-limited, single-use record issued by /decide upon successful resolution. Contains the execution blueprint and governance requirements. Identified by contractId. |
| Execution Blueprint | The complete specification required to execute an API call: endpoint URL, HTTP method, parameter schema, authentication requirements, and content type. Returned by /execute. |
| Risk Profile | The set of boolean signals attached to a primitive at ingest time, encoding its real-world consequences. Permanent per-primitive. Updated only through manual re-ingestion. |
| Primitive Risk Score | A scalar integer between 0 and 240 computed from the risk profile at ingest time. Used to determine governance threshold. |
| Minimum Handling | The lowest acceptable governance response for a given action. Specified in the action contract. Implementing systems may exceed this; they may not execute below it. |
| Override Policy | The rule governing whether downstream systems may reduce the handling requirement. Currently one value: escalation_only. |
Endpoints
AMCP exposes two endpoints. All requests are authenticated via Bearer API key. All requests and responses are application/json.
https://getamcp.com/api
3.1 POST /decide
Resolves a natural language intent to a specific API primitive, issues an action contract, and returns the governance profile for the resolved action. Does not call any external API.
Request Schema
provider (string, constrain resolution to a specific provider), parameters (object, partial parameter values).Response Schema
EXECUTE, CONFIRM, CLARIFY, INSUFFICIENT, NO_MATCH. See Section 4.cnt_[uuid]. Present when decision is EXECUTE, CONFIRM, or CLARIFY.stripe.customers.create.level, minimumHandling, reasoning, overridePolicy. See Section 6.Example Response — EXECUTE
{
"decision": "EXECUTE",
"contractId": "cnt_01hx4k2m9p...",
"primitive": "microsoft_entra.delete_user",
"primitiveRiskScore": 165,
"risk": {
"level": "critical",
"minimumHandling": "human_required",
"reasoning": [
"destructiveAction",
"irreversibleWrite",
"blastRadiusUnbounded",
"compound:destructive+irreversible",
"multiplier:blastRadius(1.5x)"
],
"overridePolicy": "escalation_only"
},
"expiresAt": "2026-04-01T14:32:00Z"
}
Complete Integration Pattern
import requests
AMCP_BASE = "https://getamcp.com/api"
API_KEY = "your_api_key"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
def decide(intent: str) -> dict:
res = requests.post(f"{AMCP_BASE}/decide", json={"intent": intent}, headers=HEADERS)
res.raise_for_status()
return res.json()
def execute(contract_id: str) -> dict:
res = requests.post(f"{AMCP_BASE}/execute", json={"contractId": contract_id}, headers=HEADERS)
res.raise_for_status()
return res.json()
def execute_with_governance(intent: str):
# Step 1: Resolve intent, receive contract + governance profile
decision = decide(intent)
# Step 2: Handle non-execute states
while decision["decision"] != "EXECUTE":
if decision["decision"] == "CLARIFY":
answer = prompt_user(decision["question"])
decision = decide(answer)
elif decision["decision"] == "NO_MATCH":
raise ValueError("Capability not supported")
else:
raise ValueError(f"Cannot proceed: {decision['decision']}")
# Step 3: Inspect governance requirements before execution
minimum_handling = decision["risk"]["minimumHandling"]
if minimum_handling == "human_required":
require_human_approval(decision)
return None # execution delegated to approval flow
if minimum_handling in ("confirm", "strict_confirm"):
if not confirm_with_user(decision):
return None
# Step 4: Redeem contract, receive execution blueprint
blueprint = execute(decision["contractId"])
# Step 5: Your code makes the actual API call
return call_api(blueprint)
A decision state of EXECUTE indicates the intent was unambiguously resolved. It does not indicate the action is safe to execute without inspection. The caller must evaluate risk.minimumHandling before calling /execute.
3.2 POST /execute
Redeems an action contract and returns the execution blueprint. The blueprint contains everything required to make the API call. AMCP does not make the call itself.
Request Schema
/decide. Format: cnt_[uuid].minimumHandling is human_required or strict_confirm. Opaque token issued by the caller's approval system. AMCP validates format only; approval logic is caller-owned.Response Schema
/decide.GET, POST, PUT, PATCH, DELETE.path (object), query (object), body (object). Each field includes type, required flag, and description.type (Bearer, ApiKey, OAuth2), header (header name), scopes (array, OAuth2 only).Systems integrating AMCP must implement enforcement logic for each minimumHandling level. A system that calls /execute on a human_required contract without obtaining approval is operating outside the protocol specification. AMCP will execute the contract; it cannot prevent this. Correct behavior is the implementing system's responsibility.
Override Policy
The overridePolicy field in every governance contract is currently fixed at escalation_only. This value specifies that downstream systems and implementing integrations may increase the handling requirement for an action; they may not decrease it.
Concretely: a system may choose to require human approval for a confirm-level action. It may not treat a human_required-level action as allow. The AMCP-specified minimum is a floor, not a suggestion.
Future versions of the protocol may introduce additional override policy values for specific deployment contexts (e.g. audit_only for read-only observability integrations). Any such values will be additive and backward compatible.
Error States
| Error code | HTTP status | Description |
|---|---|---|
| UNAUTHORIZED | 401 | API key missing, invalid, or revoked. |
| INTENT_TOO_LONG | 400 | Intent field exceeds 512 characters. |
| CONTRACT_NOT_FOUND | 404 | Provided contractId does not exist or was issued under a different API key. |
| CONTRACT_EXPIRED | 410 | Contract has passed its expiresAt timestamp and can no longer be redeemed. |
| CONTRACT_ALREADY_REDEEMED | 410 | Contract has already been redeemed by a previous call to /execute. |
| CONTRACT_INVALID | 422 | Contract signature validation failed. The contract has been tampered with. |
| APPROVAL_REQUIRED | 403 | minimumHandling requires an approval token. approvalToken was not provided or is invalid. |
| RATE_LIMIT_EXCEEDED | 429 | Request rate limit exceeded. See response headers for retry timing. |
| PROVIDER_UNAVAILABLE | 503 | Temporary unavailability of the resolution index. Safe to retry with exponential backoff. |
Versioning
The AMCP protocol version is specified in the X-AMCP-Version request header. If omitted, the latest stable version is used. The current stable version is 1.0.
Breaking changes increment the major version. Additive changes (new fields, new decision states, new error codes) increment the minor version. Risk ontology weight changes and new compound rules are considered breaking changes and increment the major version, as they may alter the minimumHandling level for existing primitives.
This document covers the AMCP protocol interface: request and response schemas, decision states, contract model, risk ontology signals and weights, and governance thresholds. Risk signal evaluation methodology, primitive classification procedures, and the ingest pipeline are proprietary and are not covered by this specification.
The primitive risk score for any given primitive will not change between patch releases. Any change to a primitive's score is accompanied by a minor or major version increment and listed explicitly in the changelog.
Request API Access
AMCP is currently in private beta. Access is free. There is no payment required to participate. Beta participants receive an API key granting access to the /decide and /execute endpoints against the full production index of 5,960 primitives.
Early participants receive pricing locked when commercial access opens. Beta closes April 30, 2026.
No payment required. No spam. API key delivered before beta closes.
Changelog
v1.0.0 — March 2026
Initial specification release. Defines the two-endpoint interface, five decision states, action contract model, nine-signal risk ontology, three compound rules, and six governance thresholds. Index contains 5,960 primitives across 7 providers.
ARMS Technologies Inc.
AMCP is a product of ARMS Technologies Inc., a Canadian technology company building agentic infrastructure for the built environment and beyond.
Origin
ARMS was founded in 2017 with a focus on operational intelligence for multi-residential buildings — security, cleaning, maintenance, and compliance across large commercial and residential portfolios. Over seven years we deployed 6,000+ BLE beacons across buildings in Canada, logging more than 200,000 patrol and inspection rounds against structured operational contracts.
That operational history produced a deep understanding of one problem: autonomous systems acting on real-world resources require governance, not just capability. An agent that can send a work order, charge a tenant, or revoke access to a building needs a framework for knowing when it should — not just whether it can. AMCP is the generalization of that problem to the API layer.
Products
| Product | Description |
|---|---|
| AMCP | Autonomous Multi-Agent Coordination Protocol. Governance layer for agentic API execution. The subject of this specification. Available at getamcp.com. |
| Attenu | Governed agentic workflow engine. 35 node types, per-tenant Firestore architecture, tiered human-in-the-loop approval chains, and a four-layer governance model built on AMCP primitives. Designed for enterprise automation workflows requiring auditable, reversible execution. |
| ECA | Event Correlation Analysis. Temporal pattern detection and anomaly intelligence system. Multi-window EWMA-based oddness scoring and detector stacking across operational event streams. Originally built for building operations; now a general-purpose component of the ARMS stack. |
| Property Operations Platform | Full-stack multi-residential building operations system. Rent roll management, document signing, credit checks, patrol round verification, and vendor compliance — built on top of Attenu, AMCP, and ECA infrastructure. |
Infrastructure Context
The AMCP primitive index was built from direct operational experience integrating these APIs into production building management workflows. The risk classifications in the ontology reflect real consequences observed in that context — a financialSideEffect flag on a Stripe primitive reflects genuine exposure from production charge operations; a blastRadiusUnbounded flag on an identity primitive reflects the observed downstream effects of incorrect permission changes across tenant-linked systems.
The ontology was not synthesized from documentation alone. It was informed by operating real systems against real consequences over seven years.
Contact
AMCP Protocol Specification v1.0.0 · ARMS Technologies Inc. · getamcp.com · Draft — Private Beta · March 2026