The new problem with coding agents: they don't work together

The article is an opinion column signed by Zach Lloyd, founder and CEO of Warp (an AI-native development platform) and a former Principal Engineer at Google, where he led the engineering of Google Docs and Google Sheets. Published on July 7, 2026 in Forward Future, the piece addresses a problem that, according to Lloyd, has become central for software engineering teams: managing "mixed fleets" of AI coding agents.

The starting point is simple: over the past year there has been an explosion of capable coding agents —Claude Code, Codex, Gemini and Warp Agent itself, among others— that already take on tasks equivalent to those of a junior engineer. Developers have tried several options and, as has historically happened with code editors or terminals, each has ended up leaning toward one tool or another more out of personal preference than because of objective performance differences. The result is that within a single team different agents from different providers coexist, something that in itself is not new (teams have never imposed a single editor or workflow), but which in the case of AI agents introduces unprecedented logistical friction, especially as these agents stop operating only on developers' local machines and begin to run in the cloud.

Lloyd identifies four specific problems that arise when agents from different providers coexist in the same workflow, precisely because they were not designed to interoperate with one another. The first is visibility: each agent records its activity in its own log format, its own interface and its own level of transparency, so there is no unified view of what was run, what was touched or where something failed. Debugging a multi-agent workflow means, according to the author, reconstructing the context from three different dashboards that share nothing with each other. The article mentions, as an anecdotal and lighthearted example, the reports about OpenAI models that made OpenClaw "obsess over goblins," as an illustration of what happens when two tools from different providers do not speak exactly the same language.

The second problem is permissions. An agent working on deployment infrastructure should not have the same level of access as one dedicated to summarizing logs, but managing secrets, API keys and environment variables across different agent environments (harnesses) adds real operational overhead. According to Lloyd, most teams end up choosing to over-permission for convenience, or managing access manually in a way that does not scale.

The third problem is memory. Most agents forget everything between sessions —a limitation that already exists even within a single environment—, but across different providers there is, by default, no shared context: each new session starts from scratch. This forces a team that worked the previous week on a complex refactoring to have to re-explain the approach, the constraints and the decisions already made, an inefficiency that multiplies with each session and each engineer on the team.

The fourth factor, which according to the author aggravates the previous three, is cost. When developers choose tools by preference and stay loyal to them, there is no natural mechanism pushing toward the most cost-efficient option. With traditional development tools this had not been a major problem because SaaS subscriptions are easy to forecast, but AI token spending can spike quickly, and engineering leaders increasingly ask about having real visibility into the spending of a fleet of agents they don't fully control. For now, Lloyd notes, most organizations do not have a good answer to that question.

Despite this diagnosis of friction, the article argues that mixed agent fleets are not a problem in themselves, but a source of advantages when managed well. The first advantage is vendor independence: if a given model is down, limited by usage quotas or performs poorly on a specific task, the team can redirect the work to another. That room to maneuver, Lloyd argues, matters more and more as agents become critical infrastructure and cease to be mere productivity tools.

The second advantage is cost: directing the most demanding tasks to one model and the simplest ones to cheaper alternatives reduces spending notably without needing to redesign the entire workflow. As a concrete data point, the article cites a recent simulation of the so-called "YC-Bench," in which the GLM-5 model ran a simulated company with a result practically equivalent to that of Claude Opus —ending up with a similar amount of money— but at roughly ten times lower inference cost. Lloyd stresses that single-vendor tech stacks do not offer this savings lever, and that no large provider has an incentive to allow it, since they all seek to retain the customer within their full ecosystem.

The article's conclusion is that the agent that works best today for a specific use case may not be the most suitable one six months from now, and that a team already managing several agents in parallel does not have to "start from scratch" when replacing one of them. According to Lloyd, making the most of a mixed agent fleet requires being deliberate in its management, and the teams he observes "gaining an edge" are those that spend less time comparing benchmarks between models and more time building the layer that makes managing those fleets possible: how agents share context, how permissions are applied consistently across providers, and how real visibility is maintained over what is running at any given moment. That, he concludes, is the true line of work, and those who focus on it now will have a significant advantage over the rest.

It is worth noting that the author is the CEO of Warp, a platform that positions itself precisely as a management layer for this type of agent fleet, so the article, although it presents a reasonable and verifiable diagnosis of the fragmentation of logs, permissions and memory across agents from different providers, also has a component of direct commercial interest in the thesis it defends.