Agents and identity
Named agents with their own Ed25519 keys, profiles and inboxes.
An agent is a name you can call (@atlas), a key that signs everything it does, and a
profile that says how to run it. Agents are reusable: the same atlas works on many threads,
over months.
Why named agents
Buzz gave agents names and keys; skills.sh turned skills into a one-line install. Together they point at a better way to work than one assistant that knows everything:
- Specialists.
atlasbuilds, with the handful of skills your stack needs.novareviews, with a review skill and a different model. You address each by name. - Real code review. The best review comes from someone who didn't write the code. When atlas is done it asks nova, on the same thread; nova's findings arrive as atlas's next prompt, and you see the whole exchange. A different model catches different mistakes.
- No skill bloat. Installing every skill into one agent costs you on every session: each skill's description sits in its context, and the more there are, the more often the wrong one triggers. A named agent loads only its own.
- Accountability. Everything an agent does is signed with its key, and it has its own permissions, reach and daily budget.
Create one
axel agent new atlas --harness claude --skills rust,axum --color orange
axel agent new nova --harness codex --skills review,security --color blue
axel agent ls
axel agent show atlas # profile, policy and the owner attestationCreating an agent:
- generates an Ed25519 keypair and stores the private key in the macOS keychain;
- signs an attestation with your owner key: "this key is my agent atlas";
- records the profile.
| Profile | |
|---|---|
--harness | claude, codex or opencode. |
--model | Optional; the harness default otherwise. |
--skills | Skills to install for it, comma-separated, or * for all of them. |
--prompt | A standing prompt added to every session. |
--color | How it shows up in the dashboard and in @mentions. |
--runtime-mode | How much it may do alone; see Permissions and budgets. |
--host | Where it runs unless told otherwise; see Remote hosts. |
Change any of it later with axel agent edit atlas …. axel agent archive atlas retires
an agent and keeps its key and history.
Why keys
Everything an agent does on a thread (a reply, a tool call, a message to another agent) is an event signed with its key. That makes three things possible:
- Attribution you can check. A thread shows who did what, and a copy of it on another machine can verify that it was really atlas.
- Safe delegation. On a remote machine, atlas's key never leaves home: the machine gets a short-lived grant to sign for it on one thread. See Remote hosts.
- Multiplayer threads. Threads merge across machines and people by their signed events.
Inside a session
Axel tells the agent who it is through its environment:
| Variable | |
|---|---|
AXEL_AGENT_NAME | Its name. |
AXEL_AGENT | Its public key. |
AXEL_THREAD | The thread it works on. |
AXEL_SESSION | This session. |
It also installs the axel skill, which teaches the agent how to message other agents, report its status and read its inbox, and an MCP server with the same tools. See The agent's toolkit.
Inbox
Every identity, you included, has an inbox: messages that mention it, permission requests,
questions, and status from its sessions. axel inbox prints yours;
axel inbox --agent atlas prints atlas's. When anything needs you, axel opens on the
inbox instead of the launcher.