Protocol Specification

Autonomous Multi-Agent Coordination Protocol

Governance contract specification for agentic API execution
Version1.0.0
StatusDraft — Private Beta
PublishedMarch 2026
AuthorARMS Technologies Inc.
Abstract

This document specifies the Autonomous Multi-Agent Coordination Protocol (AMCP), a governance layer for agentic API execution. AMCP defines a two-endpoint interface through which AI agents resolve natural language intent to a specific API primitive and receive a cryptographically bound execution contract specifying both the exact execution blueprint and the minimum governance handling required before the action may execute. The protocol addresses a structural gap in current agentic architectures: the absence of any mechanism for determining what an agent should be permitted to execute, as distinct from what it can execute. AMCP encodes consequence-awareness at the primitive level through a scored risk ontology applied at ingest time across 5,960 production API primitives spanning 7 providers.

Section 1

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.

Section 2

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.
Section 3

Endpoints

AMCP exposes two endpoints. All requests are authenticated via Bearer API key. All requests and responses are application/json.

Base URL

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

intent
string
required
Natural language description of the desired action. Maximum 512 characters.
context
object
optional
Additional structured context to improve resolution accuracy. Accepted fields: provider (string, constrain resolution to a specific provider), parameters (object, partial parameter values).
sessionId
string
optional
Caller-provided session identifier for grouping related decisions. Stored with the contract for audit purposes.

Response Schema

decision
enum
always
One of: EXECUTE, CONFIRM, CLARIFY, INSUFFICIENT, NO_MATCH. See Section 4.
contractId
string
if resolved
Unique contract identifier. Format: cnt_[uuid]. Present when decision is EXECUTE, CONFIRM, or CLARIFY.
primitive
string
if resolved
Dot-notation primitive identifier. E.g. stripe.customers.create.
primitiveRiskScore
integer
if resolved
Risk score 0–240. Computed at ingest time. Immutable per primitive.
risk
object
if resolved
Governance contract. Fields: level, minimumHandling, reasoning, overridePolicy. See Section 6.
question
string
if CLARIFY
Single targeted question to resolve ambiguity. Caller should present this to the user and resubmit with the updated intent.
missing
array
if INSUFFICIENT
Array of required parameter names that were not provided or inferable.
expiresAt
ISO 8601
if resolved
Contract expiry timestamp. Contracts not redeemed before this time cannot be executed.

Example Response — EXECUTE

POST /decide — Response 200
{
  "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

Python — complete AMCP integration
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)
Important

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

contractId
string
required
Contract identifier returned by /decide. Format: cnt_[uuid].
approvalToken
string
conditional
Required when 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

primitive
string
always
Confirmed primitive identifier. Matches the value returned by /decide.
endpoint
string
always
Fully qualified API endpoint URL.
method
string
always
HTTP method. One of: GET, POST, PUT, PATCH, DELETE.
parameters
object
always
Complete parameter schema. Fields: path (object), query (object), body (object). Each field includes type, required flag, and description.
auth
object
always
Authentication requirements. Fields: type (Bearer, ApiKey, OAuth2), header (header name), scopes (array, OAuth2 only).
contentType
string
always
Required Content-Type header for the request.
executedAt
ISO 8601
always
Timestamp of contract redemption. Contract is invalidated after this call.
Implementation Requirement

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.

Section 8

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.

Section 9

Error States

Error codeHTTP statusDescription
UNAUTHORIZED401API key missing, invalid, or revoked.
INTENT_TOO_LONG400Intent field exceeds 512 characters.
CONTRACT_NOT_FOUND404Provided contractId does not exist or was issued under a different API key.
CONTRACT_EXPIRED410Contract has passed its expiresAt timestamp and can no longer be redeemed.
CONTRACT_ALREADY_REDEEMED410Contract has already been redeemed by a previous call to /execute.
CONTRACT_INVALID422Contract signature validation failed. The contract has been tampered with.
APPROVAL_REQUIRED403minimumHandling requires an approval token. approvalToken was not provided or is invalid.
RATE_LIMIT_EXCEEDED429Request rate limit exceeded. See response headers for retry timing.
PROVIDER_UNAVAILABLE503Temporary unavailability of the resolution index. Safe to retry with exponential backoff.
Section 10

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.

Scope of this specification

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.

Stability Guarantee

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.

Beta Access

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.

Register for Beta Access

No payment required. No spam. API key delivered before beta closes.

Appendix

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.

About

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

ProductDescription
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

Technical contact
Headquarters
Canada

AMCP Protocol Specification v1.0.0 · ARMS Technologies Inc. · getamcp.com · Draft — Private Beta · March 2026