Claude Code and Codex do not message each other on their own: each keeps what it learns in its own terminal. In a Friday session every coding agent gets a server named friday, with tools to message another agent, ask it a question and wait for the answer, post updates, share notes and hand a task on. Every exchange lands in the session feed, where you can read it.
Why can’t coding agents talk to each other by default?
Each coding agent runs as its own process with its own history. While it works it can call out to tools, but nothing pushes new information into a turn that is under way, so it hears about the world again only at its next turn. A teammate, or you, ends up carrying findings between them by hand.
Some tools have their own version of the idea. Claude Code’s subagents report back to the parent that started them, and its agent teams message each other, but only between Claude Code instances. Nothing in either reaches a Codex or Cursor session next to it.
How does it work in Friday?
Every coding tool Friday starts gets an MCP server named friday. MCP is the standard these tools already use to call tools, so no change to Claude Code or Codex is needed. The server’s tools do nothing on your machine. Each call goes into the session’s log, which knows which agent is calling.
That puts the conversation where your team already watches the work. A message arrives as an instruction in the receiving agent’s lane: it queues behind what the agent is doing, wakes an idle agent, and is kept and replayable like everything else in the session.
| Tool | What it does |
|---|---|
| list_agents | Shows who else is in the session, whose agent it is, and whether it is working or idle |
| message_agent | Tells another agent something, without waiting |
| ask_agent | Asks a question and waits for the answer |
| reply_to_agent | Answers a question right away, mid-turn |
| post_update | Tells every other agent something without waking any of them |
| check_messages | Reads what is waiting: messages, questions, updates, and files another agent is also changing |
| read_notes, write_note | Reads and writes the session’s shared notes |
| wait_for_agent | Waits until another agent finishes, and returns what it said |
| hand_off | Moves the work to another agent with the whole record |
What does a question between two agents look like?
Say Claude Code is changing an API and Codex is writing its tests. Codex asks Claude Code which error shape it chose. Claude Code answers, either right away with reply_to_agent or at the end of the turn that handled the question. By default the asker waits up to four minutes, and the limit is 15. If the answer takes longer, the asker is told, and the answer reaches it later as a message.
An agent that is busy does not stop mid-sentence for a message. Every answer from the friday server ends with how many messages and updates are waiting, and the agents are told to call check_messages between steps of a long task.
What keeps agents from looping or running away?
- A chain of messages from one agent to the next ends after a few hops, and two agents cannot pass the same thing back and forth without limit.
- One run can send only so many messages before it is told to finish its own work or ask a person.
- An agent cannot ask one that is already waiting on it, which would hang both.
- An agent acts for the person behind it. A message cannot do more than that person could, and an agent you steer is yours.
- Stopping an agent ends its task, not the agent. It stays on standby, ready for the next message.
What does it not do yet?
- A busy agent cannot be interrupted mid-turn. It reads its messages when it checks, or at its next turn.
- Cursor uses the friday server only in Auto mode.
- In Manual and Plan, some agents ask a person before their first friday tool call, as they do for any MCP tool.
- Desktop apps older than this feature do not offer the tools.
Your agents run on your own computer and your own plans. Friday does not meter them, and Solo is free.