Most products that advertise "multi-agent" support mean something fairly narrow: you can open several AI coding agents at once, and none of them will ever know the others exist. That's a genuinely useful capability — fan the same prompt out across five agents, let each one work in total isolation, and keep whichever result actually holds up. But it stops being enough the moment you want one agent to actually manage the others: to hand out discrete pieces of work, wait for a real answer instead of guessing, and know when a task is actually finished rather than merely quiet. Agent Orchestration is Influxx's answer to that harder problem — an experimental capability, built for teams pushing multi-agent workflows further, that gives a coordinator agent and its worker agents an actual communication protocol instead of just a shared window.
Isolation Was the Easy Half of Multi-Agent
Running several agents side by side, each in its own isolated git worktree, has been Influxx's model since day one, and it solves a specific, real problem well: no collisions, no shared mutable state, no agent quietly overwriting another agent's in-progress edit. Fan out the same prompt across five agents and you get five independent, comparable attempts at the same problem — pick the one that actually holds up, discard the rest.
That model has a boundary, though, and it's worth being precise about where it sits. Fan-out-and-compare works when a task decomposes into "try this several different ways and pick a winner." It has no answer for a task that decomposes into "break this into pieces and hand the pieces to different specialists," because that second shape requires the pieces to report back — and it requires someone to actually be listening when they do. An agent sitting in complete isolation can't tell a coordinator it's stuck, can't ask a clarifying question, and can't signal that it finished ten minutes ago and has been idling since. Isolation was never going to solve that. It wasn't built to.
Treating a Coordinator and Its Workers Like an Actual Team
Agent Orchestration — an experimental capability found in Influxx's settings, aimed at developers running sophisticated multi-agent setups — starts from a different premise: a coordinator agent and its worker agents should behave like an actual small team, with a real protocol connecting them, rather than a set of sealed rooms that happen to share a sidebar. Concretely, that means:
- Threaded messaging between sessions: a coordinator and its worker agents can exchange messages the way people in a team channel do, instead of each one operating in a sealed room with no way to reach any of the others.
- A blocking "ask and reply" mechanic: a coordinator can pose an actual question to a specific worker and wait for a real reply, instead of either guessing at an answer or giving up after an arbitrary timeout.
- Group addressing: a coordinator can send one message to every agent matching a description — every currently running instance of a specific CLI, for example — without needing to know each session's individual identity ahead of time.
- A structured task system: work gets broken into discrete, trackable units instead of handed off as one long freeform instruction that a worker either nails or doesn't.
- Explicit "done" and escalation signals: a dispatched unit of work reports back when it's actually finished, or flags that it needs a human, instead of a coordinator inferring completion from silence.
- Decision gates: structured work can pause at a specific point until an explicit decision gets made, instead of an agent barreling ahead on an assumption nobody actually confirmed.
None of that is exposed only as buttons for a human to click. It's exposed through Influxx's own command-line interface, so a coordinator agent can create and update tasks, dispatch work with context injected directly into it, and drive the entire coordination flow itself. The orchestration layer is something an agent can operate on its own — not only a UI a person clicks through on the agent's behalf.
"A terminal pane is a view, not a source of truth. It can end up with a brand-new underlying handle the moment Influxx restarts, and if we'd tied a dispatched unit of work's validity to that handle directly, an ordinary app restart would have silently orphaned whatever was in flight. So the lifecycle authority for a piece of dispatched work lives with stable identifiers for the task and the dispatch itself — not with whatever terminal happens to be displaying it right now. The terminal is just where you're looking. It isn't what makes the work real."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
Guardrails a Coordinator Can't Talk Its Way Around
Giving a coordinator this much reach — the ability to dispatch work, address groups of agents, and drive the whole flow through its own commands — only makes sense if the protocol underneath it refuses to do obviously reckless things on the coordinator's behalf. Two safeguards do that job:
- A drift threshold on dispatch: by default, Influxx refuses to dispatch further work onto a worktree whose branch has fallen too many commits behind its base branch. The threshold is deliberately conservative, because work dispatched onto a badly stale worktree tends to produce a result that's expensive to reconcile later — better to refuse and ask than to hand a worker a foundation that's already shifted out from under it.
- A heartbeat with real teeth: every worker session is expected to send a periodic heartbeat while it's active. Miss it for roughly twice the mandated interval, and Influxx treats that session as hung rather than merely quiet — which means a coordinator, or a human watching the coordinator, finds out and can intervene instead of waiting indefinitely on a worker that silently died.
Neither safeguard is subtle, and that's deliberate. A coordinator agent is still an agent — capable of being confidently wrong about whether a worktree is fit to build on, or whether a worker that stopped talking is just thinking hard. The protocol doesn't ask a coordinator to be a perfect judge of either question. It refuses the risky path by default and makes the failure visible instead of silent.
Getting Group Addressing Right
Two Lists That Were Supposed to Match
Group addressing is a good example of how this feature actually gets hardened, because it broke in a specific, mundane, very real way. Addressing "every running instance of this agent" as a group originally worked by matching against a fixed list of known agent group names that somebody maintained by hand. That list lived apart from Influxx's general agent catalog — the registry that decides whether a given CLI is installed, launchable, and has working status detection.
Those two lists were supposed to describe the same set of agents. They didn't, once a newer supported agent CLI joined the general catalog. The new agent was fully launchable and had complete status detection — you could open it, run it, and watch its state update like any of the longer-supported agents. Nobody had also remembered to add it to the separate, hand-maintained list that group addressing checked against. So you could dispatch work to that agent individually, by name, without any trouble. You just couldn't address it as part of a group the way you could with agents that had been in the product longer, because group addressing was still consulting a list that had never heard of it.
We fixed the specific gap once it was reported. It's worth naming honestly rather than glossing over, though, because it's a textbook version of a very real distributed-systems problem: two lists that are supposed to stay in sync, maintained separately, drift apart the moment a change to one doesn't get mirrored in the other.
"The honest version of this story is that we had two sources of truth for 'which agents exist' and only updated one of them when a new CLI landed. That's not an exotic failure — it's the default outcome any time two lists are supposed to describe the same thing but live in different places, maintained by different steps in the process. Closing the specific gap was easy once someone reported it. The more useful takeaway is treating it as a prompt to ask, anywhere else we've got two lists doing the same job, why there are two."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
Not Every Mention of a Name Is the Agent Itself
Group addressing doesn't match against raw process names — it matches against terminal and session titles, because that's the layer Influxx can actually see reliably across every supported CLI. That choice buys flexibility, but it also creates a specific hazard the matching logic has to actively guard against: ordinary English overlaps with agent names more often than you'd expect. A session working on something completely unrelated to a given agent CLI can still end up with that agent's name sitting in its own task-summary title, purely as coincidental language, with no actual instance of that CLI running anywhere near it. The matching logic has to be deliberately careful not to treat that coincidence as evidence the session is actually running that agent — otherwise a group message could land on a worker that has nothing to do with the group it appears to belong to.
Why This Stays Labeled Experimental
We label Agent Orchestration experimental in Influxx's settings on purpose, and we'd rather explain why than let the word do the work by itself. It's built for developers already comfortable running several agents side by side who want to go a step further and have one of them actually manage a team of the others — not for someone opening their first agent session. And it's genuinely still being hardened: the group-addressing gap above is exactly what that hardening looks like in practice, not a footnote we'd rather leave out. A coordination protocol this new either gets tested against real, messy usage or it doesn't get tested at all, and we'd rather find the two-lists-drifted-apart bugs from an actual report than pretend the surface is more finished than it is.
"I stopped tabbing through five terminals trying to guess which agent had actually finished its slice of a migration. I dispatch the pieces from one coordinator session now, and I hear back — done, blocked, or 'here's a decision I need you to make' — instead of guessing which one has quietly stalled. The decision gate is the part I didn't expect to lean on so much. It's nice knowing nothing downstream proceeds until I've actually said yes."
— Owen Fitzgerald, engineering lead at a data-infrastructure startup and Influxx user
Frequently Asked Questions
Is Agent Orchestration just a fancier way to run multiple agents at once?
No. Running several agents at once, each in its own isolated worktree, is something Influxx already does without Agent Orchestration involved. What orchestration adds is communication: a coordinator agent that can message workers, ask them questions and wait for real answers, break work into trackable tasks, and get an actual signal when a piece of work is done. Isolation and orchestration solve different problems, and you can use either one without the other.
Where do I turn this on, and why is it labeled experimental?
Agent Orchestration lives in an experimental area of Influxx's settings. We label it that way on purpose — it's aimed at developers running sophisticated multi-agent setups who want a coordinator directing several workers, not at someone running their first agent session. It's real and usable today, but it's also still being actively hardened, and we'd rather be upfront about that than quietly ship it as if the surface were more finished than it is.
How does a coordinator know a worker is actually done, rather than just quiet?
Dispatched work carries explicit "done" and escalation signals as part of the protocol. A worker reports that its unit of work is actually finished, or flags that it needs a human, instead of a coordinator inferring completion from the absence of new output. That distinction matters — quiet and finished aren't the same thing, and treating them as interchangeable is exactly how a coordinator ends up acting on work that never actually completed.
What happens if a worker agent stops responding mid-task?
Every worker session is expected to send a periodic heartbeat while it's active. If that heartbeat goes missing for roughly twice its mandated interval, Influxx treats the session as hung rather than merely slow, so a coordinator — or a human watching the coordinator — can notice and step in instead of waiting indefinitely on a worker that silently died.
Can I address every running instance of a specific agent CLI without tracking each session's name myself?
Yes — that's what group addressing is for. A coordinator can send a single message to every agent matching a description, such as every currently running instance of a given CLI, instead of having to know and target each session individually. It works by matching against session titles, with logic specifically built to avoid mistaking a coincidental mention of an agent's name for an actual running instance of it.
Does dispatched work survive if I restart Influxx mid-task?
Yes, by design. The lifecycle authority for a dispatched unit of work is tied to stable identifiers for the task and the dispatch itself, not to a terminal's session handle, because a terminal pane can end up with a new underlying handle after a restart. Tying validity to the terminal directly would have made dispatched work fragile across perfectly ordinary restarts, so we deliberately didn't build it that way.
Agent Orchestration exists because "run several agents at once" and "have one agent actually manage a team of others" are different problems, and we didn't want to keep pretending the first one solves the second. It's experimental, it's aimed at people already comfortable running multiple agents side by side, and it's still getting hardened in public — the group-addressing gap above is what that looks like in practice, not a detail we'd rather have skipped. We'd rather ship the real, unfinished shape of coordination than a polished demo of agents that never actually talk to each other.
