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

The article is an opinion column by Zach Lloyd, founder and CEO of Warp (an AI-native development platform) and former Principal Engineer at Google, where he led engineering for 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's own Warp Agent, among others—that already take on tasks equivalent to those of a junior engineer. Developers have tried out several options and, as has historically happened with code editors or terminals, each has ended up favoring 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 that in the case of AI agents introduces unprecedented logistical friction, especially as these agents stop operating only on developers' local machines and move to running in the cloud.

Lloyd identifies four concrete problems that arise when agents from different providers coexist in a single workflow, precisely because they were not designed to interoperate with one another. The first is visibility: each agent records its activity with 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 separate dashboards that share nothing with one another. The article mentions, as an anecdotal and lightly humorous example, the reports about OpenAI models that caused OpenClaw to become "obsessed with 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 spent the previous week on a complex refactor to explain again the approach, the constraints and the decisions already made, an inefficiency that is multiplied by each session and by 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 spending on AI tokens can skyrocket quickly, and engineering leaders increasingly ask for real visibility into the spending of a fleet of agents they do not 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 fleets of agents 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: routing the most demanding tasks to one model and the simplest ones to cheaper alternatives reduces spending significantly without having 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 virtually equivalent to that of Claude Opus—ending with a similar amount of money—but at an inference cost roughly ten times lower. 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 fleet of agents requires being deliberate in its management, and the teams he sees "pulling ahead" are those that spend less time comparing benchmarks between models and more time building the layer that makes it possible to manage those fleets: how agents share context, how permissions are applied consistently across providers, and how real visibility is maintained over what is being run 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 offers 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.