Skip to main content

Overview

Artemis City exposes three primary API surfaces:
  1. Agent API: Task submission and execution
  2. ATP (Agent Transmission Protocol): Structured inter-agent messaging
  3. System APIs: Registry, Memory Bus, Governance (admin-only)
All APIs use HTTP/JSON for REST endpoints and support gRPC where noted.

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 operation
  • search: Semantic or keyword search
  • list: Enumerate items
  • get_status: Check current state
Modification Operations:
  • create: Insert new record
  • update: Modify existing record
  • delete: Remove record
  • upsert: Create or update
Execution Operations:
  • execute: Run task/agent
  • schedule: Queue for later execution
  • cancel: Abort running task
  • retry: Re-execute failed task
Management Operations:
  • register: Register agent or capability
  • revoke: Remove registration
  • approve: Approve pending action
  • reject: Deny pending action
Governance Operations:
  • propose_update: Submit self-update
  • rollback: Revert to checkpoint
  • override: 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:
Response (202 Accepted):

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 status
  • agent_id: Filter by assigned agent
  • created_after: ISO 8601 timestamp
  • limit: Result limit (default: 100, max: 1000)
  • offset: Pagination offset
Response:

Memory Bus API

Write Document

Endpoint: POST /api/v1/memory/write Request:
Response (200 OK):

Read Document (Exact)

Endpoint: GET /api/v1/memory/read/exact?path={path} Response:

Search Documents (Keyword)

Endpoint: POST /api/v1/memory/search/keyword Request:
Response:

Search Documents (Semantic)

Endpoint: POST /api/v1/memory/search/semantic Request:
Response:

Get Memory Health

Endpoint: GET /api/v1/memory/health Response:

Agent Registry API

Register Agent

Endpoint: POST /api/v1/registry/agents Request:
Response (201 Created):

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 capability
  • status: Filter by status
  • trust_tier: Filter by tier
  • limit: Result limit
Response:

Update Agent Scores

Endpoint: PATCH /api/v1/registry/agents/{agent_id} Request:
Response:

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:
Response:

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:
Response:

Reject Update

Endpoint: POST /api/v1/governance/updates/{update_id}/reject Request:
Response:

Propose Rollback

Endpoint: POST /api/v1/governance/rollbacks Request:
Response (202 Accepted):

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:
Response:

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:
Response:

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.
All endpoints require authentication.

Chat completion

Endpoint: POST /api/v1/llm/chat Sends a multi-turn chat completion to the selected provider. Request:
Response:

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:
Response:

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:
Response:

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:
Response:

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:
Response:

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 minute
    • X-RateLimit-Remaining: Remaining requests
    • X-RateLimit-Reset: Unix timestamp of reset

Authentication

Authenticate with either an Authorization: Bearer token or an X-API-Key header:
Health endpoints (/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:
For example:
If no 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 via POST /api/v1/webhooks:
Event payload:
Last modified on July 16, 2026