docs / amp
AMP
Agent Message Protocol
powered by runshift
Your agent sends a signal. runshift governs it. Your code doesn't change.
March 2026 // runshift.ai/amp // draft
The problem with autonomous agents
AI agents can send emails, publish content, move money, and modify production systems. Most agent frameworks give you no approval layer. If an agent decides to act, it acts.
AMP exists so every consequential action passes through an operator gate before it executes. One signal. One decision. Full audit trail.
Pull requests for AI agents.
When you pay for something online, your checkout doesn't talk directly to your bank. It talks to Stripe. Stripe validates the transaction, applies rules, and returns approved or declined. Your checkout never touches the payment logic.
AMP works the same way. Your agent doesn't execute consequential actions directly. It sends a signal to runshift. runshift validates it against operator rules and returns approved, rejected, or pending. Your agent never touches the gate logic.
Stripe is in the payment path. runshift is in the agent execution path. Neither controls your code.
You have 3–4 agents running. You can only watch one at a time. You review outputs manually before acting on them. You context-switch between them because there's no single surface that shows you all of them at once.
You're already operating like runshift exists. AMP is the infrastructure for what you're already doing.
the flow
How a signal moves
Signal
Your agent POSTs an AMP payload to runshift
Gate
runshift holds it and notifies the operator
Resolution
approved | rejected | pending returns to your agent
integration patterns
Two ways to gate — both v1, both first-class
pattern 1
Complete → Signal
Agent runs to completion, then POSTs the AMP payload. Gate fires on the outcome. Operator reviews and approves or rejects.
Best for agents where the output needs review before it's acted on — drafts, reports, summaries.
pattern 2
Signal → Gate → Continue
Agent routes its model call through the runshift proxy. Gate fires before the action executes. Agent receives 202 + gate_id, then waits for webhook callback.
Best for agents where the action itself is consequential — send, publish, delete, transfer.
the contract
The AMP payload
When an agent completes a run — approved or not — it sends a single structured payload to relay. relay validates it, writes the audit trail, fires the trust gate if required, and records the outcome. No SDK required. One JSON object, one endpoint.
API keys are scoped to workspace and agent. Get yours from the runshift dashboard.
summary vs proposed_action. summary is what the agent already did — a record. proposed_action is what happens next if the operator approves — a proposal. relay shows both in the gate slide.
gate_required. Deterministic trigger. Your agent sets it. Operator rules in runshift confirm it. Both must be true for a gate to fire — agent declaration + operator authorization.
schema reference
Field definitions
| field | type | required | description |
|---|---|---|---|
| amp_version | string | required | Protocol version. Always '1.0' for this release. Used for schema migration and backwards compatibility. |
| agent_id | string | required | Unique identifier. Matches the agent registered in the runshift roster. Use kebab-case. |
| run_id | string | required | Unique execution ID. relay ignores duplicate payloads with the same run_id. |
| project_id | string | optional | Maps to the runshift deck (e.g. 'job-search'). Scopes events to the right operator view. |
| status | enum | required | completed | failed | interrupted. If status is failed, include metadata.error_code and metadata.error_message when available. |
| summary | string | required | What the agent did. Shown in audit trail. Write for an operator, not a developer. |
| proposed_action | string | optional | Required if gate_required is true. What the operator is approving. Distinct from summary — this is what happens next. |
| artifacts | array | optional | Structured outputs. Displayed in gate slide for operator review. |
| model | string | required | The model used. AMP is model-agnostic — Claude, GPT, Gemini, Llama, or anything. |
| input_tokens | integer | required | Tokens consumed as input. |
| output_tokens | integer | required | Tokens generated. |
| cost_usd | float | required | Agent-calculated cost in USD. relay accepts agent-reported cost in v1 and may independently verify when model pricing metadata is available. |
| gate_required | boolean | required | Deterministic trigger. Your agent sets it. Operator rules in runshift confirm it. Both must be true for a gate to fire. |
| started_at | ISO 8601 | required | When the agent started. |
| completed_at | ISO 8601 | required | When the agent finished. |
| metadata | object | optional | Arbitrary key-value context. Use for domain-specific data — prevents one-off field creep. |
| webhook_url | string | optional | Where runshift POSTs the resolution for Pattern 2 integrations. Register once in the dashboard. |
integration
Ways to connect an agent
Pick the path that matches how your agent is built. All paths produce the same result: your agent appears in the runshift roster, relay can see it, and the operator has full control.
One line of code
Add the AMP reporter to your existing agent. One fetch call at the end of your function. No dependencies, no config.
Proxy route
Change base_url in your existing Anthropic client. Register a webhook URL in the dashboard. Gate fires mid-execution. Zero agent refactor.
@runshift/agent SDK
Wrap your agent function. Token counting, cost calculation, and error reporting handled automatically.
Webhook endpoint
Point any automation tool — Make, Zapier, n8n — at your AMP endpoint.
path 1 — complete → signal
One line. Your agent is live.
At the end of your agent function, post the AMP payload to relay. That's the entire integration.
summary vs proposed_action. summary is what the agent already did — a record. proposed_action is what happens next if the operator approves — a proposal. relay shows both in the gate slide.
path 2 — sdk
@runshift/agent SDK
SDK coming soon.
what happens next
What relay does with the payload
The payload alone is not the product. What relay does after ingestion is the product.
Validates the payload — fields, agent_id registration, amp_version, duplicate run_id rejection
Writes to the audit trail — immutable, before gate fires
Fires the trust gate — if gate_required, shows operator summary + proposed_action + artifacts
Records the outcome — execution record, live counter updates
Notifies the agent — returns approved | rejected | pending
protocol boundaries
What AMP v1 does and does not do
runshift does
Read the signal payload
Apply operator-defined gate rules
Return approved / rejected / pending
Surface payload to operator for review
Log every gate decision immutably
Notify via Slack
runshift does not
Modify your agent's logic
Change the payload content
Retry your agent
Initiate an agent run (v1.1 — registration payload)
Stop or pause a running agent (v2.0 — heartbeat)
Access anything outside the signal
Start, stop, and manage agents from the runshift dashboard — this is a product capability, not an AMP protocol concern. See the roadmap for when agent lifecycle management arrives in the protocol.
cost calculation
Calculating cost_usd
In v1, agents calculate their own cost using known model pricing. runshift maintains a pricing constants file agents can import.
v1 trust model. relay accepts agent-reported cost and may independently verify when model pricing metadata is available.
roadmap
What AMP becomes
AMP v1 ships with two first-class patterns: completion reporting and proxy-based gating. The protocol is designed to extend — future versions add message types without breaking existing integrations.
Completion + proxy patterns
Agent reports on completion (Pattern 1) or routes through the runshift proxy for mid-execution gates (Pattern 2). What you're reading now.
Registration payload
Agent registers identity, capabilities, and trust level with relay on startup.
Gate request + heartbeat
Agents request gates mid-execution. Cost verification layer added.
Policy + routing layer
relay becomes the policy surface. Trust levels, governance, routing.