Protocol documentation.

Perception, cognition, action — one continuous loop.

An ARCHON-09 agent is not a chat session. It is a long-lived process that runs the autonomy loop: it perceives its environment, reasons over a world model, commits an action, then perceives the consequences. The loop repeats until the goal is satisfied, a budget is exhausted, or a guard intervenes.

Each agent is configured with a goal, a tool grant, a memory scope, and a set of guards. The goal is a natural-language objective. Guards are hard constraints — budget ceilings, forbidden actions, and approval gates — evaluated before every committed action.

{
  "goal": "triage inbound alerts",
  "tools": ["pager.read", "ticket.create", "slack.post"],
  "memory": "team:sre",
  "guards": {
    "budget.actions": 200,
    "approval.required": ["ticket.escalate"],
    "forbidden": ["prod.deploy"]
  }
}

Many agents, one objective, coordinated at machine speed.

A single agent owns one objective. A swarm decomposes a larger objective into sub-goals and assigns each to a worker agent under an orchestrator. The orchestrator allocates work, merges results, resolves conflicts, and retires workers as their sub-goals complete.

• ▸ORCHESTRATOR — decomposes the objective and assigns sub-goals
• ▸WORKER — owns one sub-goal; reports findings to the orchestrator
• ▸VERIFIER — adversarially checks worker output before it is accepted
• ▸ARBITER — resolves contradictions between competing worker results

Workers run concurrently. The orchestrator imposes a barrier only where a step genuinely depends on the full result set; otherwise sub-goals stream through independently. Shared state flows through the memory layer, never through direct agent-to-agent mutation.

$ archon swarm spawn \
    --goal "audit repo for security regressions" \
    --workers 8 --verify majority

  ▸ swarm.id     sw_a12b
  ▸ workers      8 active / 0 retired
  ▸ strategy     decompose → fan-out → verify → merge

Durable context that survives the loop.

Agents are stateless between actions; the memory layer is what makes them coherent over time. Memory is scoped, addressable, and persistent. An agent recalls relevant entries at the start of each cognition step and may commit new entries after a verified action.

Each entry carries a scope, a relevance description used for recall, and provenance metadata. Recall is semantic — an agent retrieves entries by relevance to the current sub-goal, not by exact key. Writes are append-only; corrections supersede rather than overwrite.

POST /v1/memory/recall
{
  "scope": "team:sre",
  "query": "prior incidents touching the auth gateway",
  "limit": 5
}

How agents reach into the real world.

Tools are the only way an agent produces side effects. A tool is a typed, schema-described capability the agent may invoke during the action stage. Tools are granted explicitly per agent; an agent can never invoke a capability outside its grant.

A tool declares a name, an input schema, an output schema, and a risk class. The runtime validates every invocation against the input schema before dispatch and validates the response against the output schema before it re-enters perception.

{
  "name": "ticket.create",
  "risk": "write",
  "input": {
    "title": "string",
    "severity": "enum[low,med,high,crit]",
    "body": "string"
  },
  "output": { "id": "string", "url": "string" }
}

• ▸read — observes external state; no side effects
• ▸write — creates or mutates external state; reversible
• ▸irreversible — destructive or outward-facing; requires an approval guard

Plan, commit, verify, prove.

The execution engine turns a cognition decision into a committed action. Before any action runs, the engine evaluates all guards. After it runs, the engine verifies the outcome against the agent's expectation and emits a signed proof of execution into the audit log.

• ▸1. PLAN — cognition emits an intended action and its expected effect
• ▸2. GUARD — budgets, approvals, and forbidden actions are evaluated
• ▸3. COMMIT — the tool is invoked and its output validated
• ▸4. VERIFY — the actual effect is compared against the expectation
• ▸5. PROVE — a tamper-evident record is appended to the audit log

If verification fails, the action is rolled back where the tool supports it, the failure re-enters perception, and cognition replans. Every state transition is durable — an interrupted agent resumes from its last committed proof rather than restarting from the goal.

{
  "agent": "ag_7f3c9a",
  "action": "ticket.create",
  "expected": "open incident for auth gateway",
  "verified": true,
  "sig": "ed25519:9c1f…"
}

The HTTP surface beneath the CLI.

Every CLI command maps to a REST endpoint under /v1. All requests require a session token in the Authorization header and are scoped to the permissions encoded in that token. Responses are JSON; streaming endpoints emit server-sent events.

$ curl https://api.archon09.ai/v1/agents \
    -H "Authorization: Bearer $TOKEN" \
    -d '{ "goal": "triage inbound alerts" }'

Autonomy under constraint.

Autonomy is only safe when authority is bounded. Every agent operates under least privilege: it holds a scoped session token, an explicit tool grant, and a set of guards it cannot override. Nothing an agent does escapes the audit log.

• ▸Scoped tokens — delegated authority is narrow, time-boxed, and revocable
• ▸Tool grants — an agent can only invoke capabilities you explicitly grant
• ▸Guards — budgets, forbidden actions, and approval gates are enforced pre-commit
• ▸Sandboxing — tool execution is isolated; blast radius is bounded by the grant
• ▸Signed audit — every committed action emits a tamper-evident proof

Irreversible and outward-facing actions always require an approval guard by default. Approvals route to a human or a higher-trust agent and are recorded alongside the action they authorized. Revoking a token halts every agent operating under it within one loop iteration.

Report a vulnerability to security@archon09.ai. We operate a coordinated disclosure process and will acknowledge reports promptly.