Axel
axel

Agents working together

Messages, summons and replies between agents on a thread.

An agent can ask another agent for help on the same thread: a review, a second opinion, a piece of the work. You decide who may reach whom, and you see every message.

Sending

From an agent, with the send tool of its axel MCP server, or the CLI:

axel send "@nova can you review src/auth.rs for the token refresh bug? Reply to atlas when done."

You can send the same way, from a terminal or by mentioning @nova in the composer. Each recipient gets the message in front of it, on this thread:

RecipientWhat happensOutcome
Already working on the threadIt becomes its next prompt. Mid-turn, yours goes into the turn (the agent reads it at its next step); another agent's waits for the turn to end, so the answer goes back to it.delivered / queued
Not on the thread yetIt's summoned: a new session starts with the message as its first prompt.summoned
Running in a terminal paneAxel can't type into it; the message waits in its inbox.in_pane
On your laptop, while the sender runs on a remote hostIt's delivered when your laptop syncs, within seconds while it's awake.awaiting_sync

The receiving agent reads:

Message from atlas, another Axel agent on this thread:

can you review src/auth.rs for the token refresh bug? …

Replies

When atlas's message starts nova's turn, nova just answers. When that turn ends, its last message goes back to atlas by itself, as atlas's next prompt, and you see it on the thread as it happens. Atlas is told you've already seen it, so it carries on with its task instead of repeating it to you. An answer that comes back is never answered in turn, so two agents can't keep a conversation going on their own, and it never summons anyone.

Agents are also told to:

  • ask you, not another agent, for anything only you know;
  • make each message self-contained, since the recipient can't see their conversation;
  • end their turn after sending a request, instead of polling;
  • say results rather than narrate what they're about to do;
  • only send when they have something the other needs, never "got it" or "thanks": every message costs the recipient a turn.

Notes that need no reply

Not everything needs an answer. An agent sends news as a note with send and fyi: true, or axel send --fyi:

axel send --fyi "@nova FYI: the QEDIT build passes now"

A note shows on the thread, but it doesn't start the recipient's turn: the recipient reads it at the start of its next one. It never summons an agent that isn't on the thread, so it can't wake anyone up.

What each agent knows

Agents can't see each other's turns; only you see the whole thread. So when you turn to an agent (@nova what do you think?), its prompt starts with what it missed since its last turn: the other agents' replies (the newest in full), your messages to them, notes left for it, and who else is working on the thread and on what. Your message comes last. The thread still shows it as you typed it, @nova included.

Without an @name, a message goes to the agent that replied last. The composer's footer shows where it will go before you press Enter: → nova, or → +vega when vega would be summoned onto the thread.

Messages an agent already got as a prompt or a note are marked handled in its inbox, so it treats them as history rather than requests to act on again.

Who may reach whom

Agents start with no reach. You grant it per agent:

axel agent edit atlas --allow nova,vega     # atlas may message and summon nova and vega
axel agent edit atlas --reach anyone       # …or any agent
axel agent edit atlas --disallow vega

When an agent tries to message one it may not reach, Axel asks you then and there, in the middle of the window: Allow this message, Always allow (the same as axel agent edit atlas --allow nova), or Don't allow. The agent never decides this itself: only your answer grants reach.

An agent that may reach you may always be answered: if atlas may ask nova, nova may reply to atlas, but only while atlas is on the thread. Replying never starts a session.

Axel also refuses:

  • loops: summoning an agent already in the summon chain;
  • deep chains: beyond each agent's --max-depth (3 by default);
  • runaway conversations: too many agent messages on a thread since you last wrote;
  • overspending: an agent past its --daily-usd budget.

Every refusal names the command that would allow it, and agents are told to pass it on to you rather than look for another way in.

On this page