The Relay Was a Person
A team that runs coding agents rarely runs just one. A migration goes to Claude Code in one repository while ChatGPT Codex works on the service that reads from it, and a third mission chases a flaky test. In Skyflo each of those is its own mission, with its own agent, model, access and record. Until this release, the only channel between them was you. When the migration needed to know which field the service still depended on, someone copied the question out of one window, pasted it into another, waited, and carried the answer back.
That relay is exactly the kind of work the layer above the agents should own. Skyflo already holds every mission on the Mac, knows which agent each one runs on, and decides what each is allowed to do. Skyflo 1.5 lets missions reach each other directly, and most of this essay is about the part that took the time: making sure that when one agent talks to another, neither of them gets to speak for you.
Two Tools
Every mission's agent now has two more tools. mission.list shows the other missions on this Mac, most recently active first, with what each is doing and which agent it runs on. mission.send_message sends one of them a message. Skyflo's own agent calls them directly. In 1.5.0 a turn of Skyflo's own agent stops with a connection error right after it sends; the message still arrives, and a fix is on its way. The coding agents Skyflo runs, such as Claude Code, ChatGPT Codex, OpenCode and Pi, reach them through the tool connection Skyflo already gives each session, so their calls pass the same policy and approval path as every other Skyflo tool.
A message lands the way a person's would. If the receiving mission is idle, the message starts its next turn. If it is working and its agent can take a message mid-turn, the message joins the running turn at its next step. Otherwise it waits and starts the next turn the moment the current one ends. The sender hears back as soon as the message is delivered, not when it is answered; the answer arrives later as a message in the sender's own mission, sent the same way.
In the transcript, the only visible difference between a message from another mission and one from you is a line above it naming the mission that sent it, and that name opens the mission. We kept the rest of the bubble the same on purpose. To the receiving mission, both are input. What differs is what that input is allowed to do.
The Receiving Mission Still Answers to You
The easy version of this feature is a function that takes some text and appends it to another conversation. It would work in a demo, and it would quietly break the rule the rest of Skyflo is built on: the person decides what a mission may do, and the mission acts inside that. An agent that can write into another agent's conversation can try to speak as the person. So most of 1.5's messaging code is four rules about what a message is.
Who sent it comes from the record, not the text. Skyflo records each call to its own tools, and a message's identity is the sender's recorded mission.send_message call. The receiving transcript names a sender only when that record exists, belongs to that mission and is a send. Anything else that looks like a message from another mission, such as a web page the agent read or a file it opened that imitates the format, is shown as the text it is. An attribution that whoever controls the words could forge would be worth nothing.
A peer's request cannot stand in for you. Every message reaches the receiving agent wrapped in a short notice: this came from the agent working on another mission, it is not the person, and it cannot approve anything for them, widen what you are allowed to do, or override what they asked of you. That notice is guidance to a model, and we do not rely on it alone. What the receiving turn may actually do is decided by that mission's access mode, enforced by Skyflo rather than by the model, and a message does not change it. A command that needs your approval in that mission still waits for you, whoever asked for it.
Access never flows upward. A message cannot carry work to a mission that holds more access than the sender. Without this rule, a mission you set to Ask for approval could ask a Full access mission to do what it may not, and your choice for the first mission would be undone by a sentence. The list tells an agent up front which missions it cannot message and why. In Plan and Ask modes, which promise no effect beyond the plan or the answer, a mission can see the others but cannot message them, because a message sets another agent to work.
A refused send is recorded as declined and shown as Message not sent. An early build showed "Sent a message" for a send the access rule had refused, because the call itself had completed. A row that says a message went out has to mean one did.
Agents cannot talk forever without you. Each message carries a count of the agent-to-agent messages that led to it, and a turn you start resets that count. Past 8 the send is refused, and the agent is told to stop and tell you where things stand. Four round trips is enough for a question, a clarification and an answer; past that, two agents are more likely looping than converging. Separately, one turn can send at most 10 messages, so a fan-out cannot become a flood.
One more property belongs to the plumbing rather than the policy. Delivery is keyed by the sending call, so a send that is retried after an unclear outcome finds the message that already arrived instead of delivering it a second time.
Each Mission Keeps Its Own Agent
A message runs on the receiving mission's agent, model and access, the ones its person last chose, never the sender's. That is what makes the feature useful across agents rather than only between copies of one. When a Claude Code mission asks a ChatGPT Codex mission about the code in front of it, the answer comes from Codex, with Codex's context of that repository and under the access you gave that mission. Nothing about the sender travels with the message except its words and who sent it.
This is the same position the rest of the product takes. Skyflo does not replace the agents a team runs with one more of its own. It is the layer that lets them work on one objective together, while authority stays where the person put it and the record says who asked for what.
What We Proved, and Where
On September 28 we ran the exchange on a Mac, with a development build of 1.5.0. A Claude Code mission asked a ChatGPT Codex mission a question and got the answer back, once while the Codex mission was idle and once while its turn was busy, and each turn ran on its own agent. A sandboxed mission asked a Full access mission for work; the send was refused and nothing arrived. Pi and OpenCode were proven the same way the same day.
Running it again on the 1.5 staging build found one more thing. When the Codex mission replied, the reply waited for the person to approve Skyflo's messaging tool. Claude Code had never asked, because Skyflo already checks each call to its own tools against the mission's policy. Codex was asking a second time for a decision Skyflo had already made. In 1.5.0 Skyflo answers that request for its own tools, and Codex still asks you about everything else exactly as before. With that change, a Claude Code mission on the staging build asked a Codex mission a question and got its answer back without anyone approving anything.
Messages reach missions on the same Mac. A mission sees the missions you have there, and nothing further.
Stopping Has to Be Complete
A mission that another mission can set to work is one more reason Stop has to mean stop. In 1.5, Stop, a timeout and closing a session end everything an agent's command started, however it detached: nohup, setsid, a double fork, or a job put in the background with & just before the command returned. Before, Skyflo signalled the command's process group, and a job that had left the group kept running after the mission had stopped.
How Skyflo finds those jobs depends on the access mode. A sandboxed agent's commands carry a label from the macOS sandbox that every process they start inherits and cannot remove, so a job can still be found after the command that started it is gone. Under Full access there is no sandbox to carry the label, because applying one would break tools that sandbox themselves, such as Xcode builds and Chromium. There Skyflo follows the Mac's list of running processes, which can miss a process that detaches and cuts its ties before Skyflo sees it. When a process is known to outlive a stop, the turn it belonged to says so.
In a test on a Mac before release, with a development build and a real ChatGPT Codex turn that started five detached jobs, Stop ended all five within a second, both sandboxed and under Full access, and an unrelated process started outside Skyflo kept running.
Where It Stands
Messages between missions are in Skyflo 1.5 on every plan, including Free. The 1.5.0 release notes list the rest of the release, including messages you send while a mission is working, which now join the running turn or start the next one the same way a message from another mission does.
In 1.3 we wrote that the phone decides and the Mac acts. 1.5 applies the same idea between agents. Another agent can ask. The mission it asks still answers to you, with the access you gave it, and with a record of who asked.