Overview
Artemis City exposes three primary API surfaces:- Agent API: Task submission and execution
- ATP (Agent Transmission Protocol): Structured inter-agent messaging
- System APIs: Registry, Memory Bus, Governance (admin-only)
Agent Transmission Protocol (ATP)
ATP is the structured message format for agent-to-agent communication and kernel-to-agent direction.ATP Message Format
ATP Tags Specification
ActionType Values
Query Operations:query: Read/lookup operationsearch: Semantic or keyword searchlist: Enumerate itemsget_status: Check current state
create: Insert new recordupdate: Modify existing recorddelete: Remove recordupsert: Create or update
execute: Run task/agentschedule: Queue for later executioncancel: Abort running taskretry: Re-execute failed task
register: Register agent or capabilityrevoke: Remove registrationapprove: Approve pending actionreject: Deny pending action
propose_update: Submit self-updaterollback: Revert to checkpointoverride: Bypass policy check
ATP Message Examples
Example 1: Query Task from Memory Bus
Example 2: Submit Task for Execution (Kernel)
Example 3: Batch Agent Communication
Example 4: Async Governance Update Proposal
Kernel API
Submit Task
Endpoint:POST /api/v1/tasks
Request:
Get Task Status
Endpoint:GET /api/v1/tasks/{task_id}
Response:
Cancel Task
Endpoint:POST /api/v1/tasks/{task_id}/cancel
Response:
List Tasks
Endpoint:GET /api/v1/tasks?status=completed&limit=100&offset=0
Query Parameters:
status: Filter by statusagent_id: Filter by assigned agentcreated_after: ISO 8601 timestamplimit: Result limit (default: 100, max: 1000)offset: Pagination offset
Memory Bus API
Write Document
Endpoint:POST /api/v1/memory/write
Request:
Read Document (Exact)
Endpoint:GET /api/v1/memory/read/exact?path={path}
Response:
Search Documents (Keyword)
Endpoint:POST /api/v1/memory/search/keyword
Request:
Search Documents (Semantic)
Endpoint:POST /api/v1/memory/search/semantic
Request:
Get Memory Health
Endpoint:GET /api/v1/memory/health
Response:
Agent Registry API
Register Agent
Endpoint:POST /api/v1/registry/agents
Request:
Get Agent
Endpoint:GET /api/v1/registry/agents/{agent_id}
Response:
List Agents
Endpoint:GET /api/v1/registry/agents?capability=nlp&status=active&limit=100
Query Parameters:
capability: Filter by capabilitystatus: Filter by statustrust_tier: Filter by tierlimit: Result limit
Update Agent Scores
Endpoint:PATCH /api/v1/registry/agents/{agent_id}
Request:
Get Agent Violations
Endpoint:GET /api/v1/registry/agents/{agent_id}/violations
Response:
Clear Agent Violations
Endpoint:POST /api/v1/registry/agents/{agent_id}/clear-violations
Request:
Governance API
Propose Update
Endpoint:POST /api/v1/governance/updates
Request: (See ATP Example 4 in section above)
Response (202 Accepted):
Get Update Status
Endpoint:GET /api/v1/governance/updates/{update_id}
Response:
List Pending Approvals
Endpoint:GET /api/v1/governance/approvals?tier=2&status=pending
Response:
Approve Update
Endpoint:POST /api/v1/governance/updates/{update_id}/approve
Request:
Reject Update
Endpoint:POST /api/v1/governance/updates/{update_id}/reject
Request:
Propose Rollback
Endpoint:POST /api/v1/governance/rollbacks
Request:
Get Rollback Status
Endpoint:GET /api/v1/governance/rollbacks/{rollback_id}
Response:
Hebbian Learning API
Get Hebbian Weights
Endpoint:GET /api/v1/hebbian/weights?agent_id={agent_id}
Response:
Get Learning History
Endpoint:GET /api/v1/hebbian/history/{agent_id}?limit=100
Response:
ATP REST endpoints
In addition to the ATP message format above, the API exposes endpoints for building, validating, routing, and inspecting ATP messages directly over HTTP. Use these when you want the server to handle ATP queueing and routing instead of constructing raw messages yourself. All ATP endpoints require authentication.Send ATP message
Endpoint:POST /api/v1/atp/send
Submits a structured ATP message. The server validates the message, assigns it a messageId, and queues it for routing.
Request:
Route ATP message
Endpoint:POST /api/v1/atp/route
Resolves a message to the agent(s) that would handle it without dispatching it. Use this to preview routing decisions.
Request:
Validate ATP message
Endpoint:POST /api/v1/atp/validate
Checks an ATP message for structural and field-level errors without sending it. Useful for client-side form validation or CI tooling.
Response:
Format ATP message
Endpoint:POST /api/v1/atp/format
Accepts the same body as POST /api/v1/atp/send and returns the formatted ATP wire string alongside the stored message. Use this to inspect what a message looks like on the wire.
Inspect modes, priorities, and action types
Look up messages, responses, and queue depth
LLM API
The LLM API is the gateway agents use to call configured LLM providers (Anthropic Claude, OpenAI, local providers via Exo, and others). It centralizes provider configuration, model selection, ATP-aware prompting, and token usage tracking. Use the LLM API when you want:- A single HTTP surface across multiple providers and models.
- Streaming responses for chat UIs.
- ATP-formatted prompts handled and routed automatically.
- Per-provider usage and quota tracking.
Chat completion
Endpoint:POST /api/v1/llm/chat
Sends a multi-turn chat completion to the selected provider.
Request:
Text completion
Endpoint:POST /api/v1/llm/complete
Single-prompt completion for providers and models that support raw text completion.
Request:
Embeddings
Endpoint:POST /api/v1/llm/embed
Generates embeddings for use with the memory bus or the semantic search endpoints.
Request:
Stream chat completion
Endpoint:POST /api/v1/llm/stream
Streams a chat completion using Server-Sent Events (SSE). The request body matches POST /api/v1/llm/chat. The response sets Content-Type: text/event-stream and emits one data: line per chunk, terminated by data: [DONE].
List models
Endpoint:GET /api/v1/llm/models
Returns the models that the API can route to across all configured providers.
List providers
Endpoint:GET /api/v1/llm/providers
Returns providers that have been configured on the server (for example anthropic, openai, exo) and whether each is currently reachable.
Configure provider
Endpoint:POST /api/v1/llm/provider
Registers or updates credentials and base URL for a provider at runtime. Prefer environment variables for long-lived credentials; use this endpoint for runtime overrides such as rotating an API key or pointing at a local Exo instance.
Request:
Process ATP message through LLM
Endpoint:POST /api/v1/llm/atp
Hands an ATP message to the LLM router. The server picks an appropriate model, executes the prompt encoded in the message, and returns the LLM response together with the original ATP context. Use this when you want ATP routing semantics and LLM execution in a single call.
Request:
Usage statistics
Endpoint:GET /api/v1/llm/usage?startDate=2026-06-01&endDate=2026-06-04&provider=anthropic
Returns aggregated token usage and cost estimates. All query parameters are optional; omit provider to receive a breakdown across every configured provider.
Trust API
The Trust API exposes the runtime trust store that gates what each agent (or other entity) is allowed to do. Use it to read or adjust an entity’s trust score, record successes and failures that drive the score, check which operations an entity is permitted to perform, and read or update the Hebbian connection weights between agents. Trust scores are floats in the range[0, 1]. Each score maps to a trust level that controls allowed operations. Successes and failures move the score; idle entities decay over time.
All endpoints require authentication.
Get trust report
Endpoint:GET /api/v1/trust/report
Returns a snapshot of every tracked entity, its current score, level, and recent activity. Useful for dashboards and audits.
Get trust score
Endpoint:GET /api/v1/trust/{entityId}
Returns 404 if the entity is unknown.
Response:
Set trust score
Endpoint:PUT /api/v1/trust/{entityId}
Sets an explicit score. Use this for manual overrides — for normal operation, prefer recording successes and failures so the score evolves from observed behavior.
Request:
score must be between 0 and 1. entityType defaults to agent.
Record success
Endpoint:POST /api/v1/trust/{entityId}/success
Increments the entity’s trust score after a successful operation. Default reinforcement is +0.02; pass amount to override.
Request:
Record failure
Endpoint:POST /api/v1/trust/{entityId}/failure
Decrements the entity’s trust score after a failed or unsafe operation. Default penalty is -0.05; pass amount to override.
Request:
Get permissions
Endpoint:GET /api/v1/trust/{entityId}/permissions
Returns the operations the entity is currently allowed to perform, derived from its trust level.
Response:
Check a specific operation
Endpoint:POST /api/v1/trust/{entityId}/can-perform
Use this in gating code paths before dispatching an operation.
Request:
Get trust levels
Endpoint:GET /api/v1/trust/levels
Returns the trust level definitions used to map scores to operations, plus the decay and reinforcement parameters. Use this to render UI legends or to keep clients in sync with server policy.
Response:
Get Hebbian connection weights
Endpoint:GET /api/v1/trust/hebbian/weights
Returns the matrix of agent-to-agent Hebbian weights used for co-activation-based routing. See Hebbian learning for the underlying model.
Update a Hebbian connection weight
Endpoint:PUT /api/v1/trust/hebbian/weights
Reinforces or weakens the connection between two agents. Positive delta strengthens the link; negative delta weakens it.
Request:
Health checks
The API exposes lightweight, unauthenticated health endpoints suitable for load balancers and orchestration probes:Error Responses
All error responses follow this format:Common Error Codes
Rate Limiting
All endpoints are subject to rate limiting:- Default: 100 requests/minute per API key
- Burst: 200 requests for 10 seconds
- Headers:
X-RateLimit-Limit: Requests per minuteX-RateLimit-Remaining: Remaining requestsX-RateLimit-Reset: Unix timestamp of reset
Authentication
Authenticate with either anAuthorization: Bearer token or an X-API-Key header:
/health, /api/v1/health/*) are public. Every other endpoint requires a valid key.
Configuring API keys
API keys are loaded from environment variables at startup. Each key encodes its user, role, and permissions in a single value:ARTEMIS_API_KEY_* variables are set, the server falls back to MCP_API_KEY with full admin permissions. Set explicit per-user keys in any production environment.
Webhook Events
Subscribe to events viaPOST /api/v1/webhooks:
