01The colleagues are there. The conversation is not.
One AI writes code. Another checks it. In another window, a third is moving on to the next task. Each looks remarkably capable on its own. Look at what happens between them, however, and the picture changes.
Carry this result over there. Bring that feedback back here. Notice a stalled process and prompt it to continue. Human work was supposed to shrink. The number of messages to relay has grown instead.
This was the gap JC described in our October 19 interview. In his development environment, experiments connecting multiple AIs through the command line are already under way. Yet people still have to initiate exchanges and bring answers back into the next stage of work. His aim is for AIs from different providers to consult one another directly while a task is in progress.
This is not just about getting a slightly faster reply. When a person steps away, can the right question still reach the right counterpart? When an answer arrives, can the work resume? “Real time” contains a more demanding requirement: conversation must remain part of the flow of work.
02Make everything the same, and something is lost.
JC is particularly interested in retaining each AI’s native development environment. Moving everything onto a common framework is not the only approach he is considering.
An AI’s working environment does more than send questions to a model. It provides tools and procedures for reading files, running processes and carrying state forward. This supporting infrastructure is often called a harness. JC sees value in the relationship between each model and its native environment.
Put everyone in the same box to connect them, and the rules inside that box become consistent. But might that also flatten the ways of working each was good at? He is looking for a way to connect environments while retaining their individual strengths.
Merging departments does not, by itself, make people collaborate. Standardizing development environments may not be the same as connecting the work, either. Alongside a collection of capable tools, we need to design what passes between them.
03Read it again. Through different eyes.
Why use multiple AIs at all? Could one model handle both implementation and review?
JC’s answer comes from daily development work. Even the same model can produce demanding criticism when asked to review in a separate session. Yet, he says, a different model reviewing alongside it sometimes offers a different kind of assessment.
The point is not that one must win every time. It is that the next reader may see something the first reader missed.
This experience alone does not establish that multiple models are always more accurate. A different criticism is not necessarily a correct one. Still, discovering that another perspective changes what is noticed offers a starting point for design. Should we erase differences to make the system easier to manage, or retain them and put the disagreements to work?
The value of collaboration need not be confined to the moment when every answer agrees.
04Keeping work moving is not the same as doing it.
Differences do not appear only in reviews. In JC’s current setup, some environments frequently pause for confirmation, while others more readily sustain repeated, lengthy operations. This led to the idea of having one AI manage the progress of another AI’s session.
Running longer is not an end in itself, however. Continued use brings token consumption and usage limits into play. Continuity, parallelism, cost: no single performance measure can determine who should do what. These are observations from his present environment, not claims about immutable characteristics of individual products.
In management terms, the problem resembles what remains after specialists have been hired. Who does the hands-on work? Who watches overall progress? When work stops, who takes responsibility for understanding why?
The industry offers several starting points. MCP standardizes connections through which AI can use external tools and information. A2A provides a way for independent agents to request work and exchange status and artifacts. The latter does not require every participant’s internal design to be identical. It echoes the idea of connecting separate workplaces rather than replacing them.1
A protocol’s name alone does not tell us what can be handed over. For example, running Claude Code as an MCP server exposes its tools. It does not mean handing over Claude’s entire conversation and autonomous workflow to another participant.2
OpenAI, meanwhile, provides an SDK for controlling Codex work programmatically, and points developers toward its app server for integrations that handle conversation history, approvals and events from work in progress.3 What emerges is a distinction between standardizing requests to models and connecting agents that are already working, together with their state. JC’s interest lies closer to the latter.
There are precedents. In Anthropic’s published account of its Research system, a lead agent divides the research and multiple subagents explore in parallel. The company also notes that the approach is less suitable for work such as coding, where tasks are highly interdependent.4 Some work speeds up when divided; other work demands more coordination the more it is split. A successful model for combining research cannot simply be transferred to collaborative development.
A CIO needs to examine more than a list of supported protocols. What assumptions informed the work? Which version of a file was read? What was tried? Can the next participant receive that context? Does review feedback make its way back through changes and renewed verification? When no reply arrives, can the system distinguish work in progress from a stopped process and avoid duplicate execution? There is still design work to connect the communication and state representations offered by standards to the meaning of the organization’s own work.
From a management perspective, the reason to invest in that design is how far it can reduce human coordination. If more AI working time also means more time spent chaperoning it, the way we work has not yet fully changed. This is the distance between AIs that can converse and AIs that can finish a job together.
The previous Inside the Geek asked where “done” lies for AI. This time, the question comes one step earlier: what must remain connected between multiple AIs if they are to carry work through to completion?
05Autonomy needs roles.
This need became concrete in the security-testing design JC is developing.
A red team looks for weaknesses; a blue team handles defense. Between them sits a purple-team role responsible for coordination. His concept treats decisions about what to test, pre-execution checks, the actual operations and the transfer of findings to defenders as one continuous system.
This introduces a distinction between the AI making decisions and the programs carrying out actions. The capacity to run multiple operations is also separated from the capacity to keep the overall work moving. What must be checked, and under which conditions work can proceed, are defined at the boundaries between roles.
This is not a report on a finished system. At the time of the interview, cross-model collaboration was still being designed. That is precisely what makes it interesting: the seams in the work become visible—seams often omitted from visions of a future in which AI simply gets on with things.
Adding more AIs will become progressively easier. But for those AIs to advance a shared piece of work, we must decide who knows what, whom they ask and what allows a task to pass to the next participant.
When humans can finally stop carrying messages, will what we need be one more genius? Or a place where the geniuses can work together?