The New Coding Agents Problem: They Don’t Work Together

_{Zach Lloyd, Founder and CEO of Warp, an AI-native developer platform. Previously a Principal Engineer at Google, he led engineering for Google Docs and Google Sheets.}

The past year saw an explosion of coding agents, like Claude Code, Codex, Gemini, and Warp Agent, highly capable tools increasingly taking on the work of a junior engineer. Developers have spent the year testing and trialing them, and individuals have gravitated toward one or another, not necessarily because it performs better or is more capable, but because of personal preference. As a result, software engineering teams are growing fleets of mixed agents: some people using one, some using another.

This isn't a new phenomenon: it’s how developers have always worked. Nobody expects every engineer to use the same code editor, terminal, or to organize their workflow the same way, and most organizations are set up structurally to support a variety of tools being used across the team. 

Developers have always picked their own tools, and that's unlikely to change any time soon. When it comes to coding agents, though, that freedom of choice presents logistical challenges. Managing fleets of mixed coding agents is inherently difficult, and as agents move off of developer’s local machines and into the cloud, teams will require new infrastructure to support both centralized agentic systems and developer choice.

Agents from different providers weren't designed to work together. You may have already seen this play out in unexpected ways, like reports of OpenAI models making OpenClaw suddenly obsessed with goblins. It's funny, but it's also a glimpse of what happens when two tools from different providers don't quite speak the same language.

The most immediate problem is visibility. When agents come from different providers, each one surfaces what it's doing differently: different logging formats, different interfaces, different levels of transparency. There's no unified view of what ran, what it touched, or where something went wrong. Debugging a multi-agent workflow today often means stitching together context from three different dashboards that have nothing in common. 

Permissions are also an issue. An agent working on deployment infrastructure shouldn't have the same access as one summarizing logs, but managing secrets, API keys, and environment settings across different agent harnesses adds real overhead. Most teams end up either over-permissioning for convenience or managing access manually in ways that don't scale.

Memory is a third problem. Most agents forget everything between sessions—a limitation even within a single harness. Across providers, there's no shared context at all by default. Every new session starts from zero. A team that worked through a complex refactor last week has to re-explain the approach, the constraints, and the decisions already made. That's not just inefficient, it multiplies across every session and every engineer on the team.

Cost compounds all of this. When developers choose tools on preference and stick with them, there's no natural mechanism pushing toward the most cost-efficient option. With past dev tools, this hasn’t been a major problem because SaaS subscriptions are easy to forecast. AI token costs, however, can quickly spiral, and engineering leaders are increasingly asking how to get visibility into what they're actually spending across a fleet they don't fully control. Right now, most don't have a good answer.

None of these challenges mean the mixed fleet is working against you. When your team is managing them properly, the benefits go beyond having your preferred agent for each job. For one, you're not dependent on any single provider, so if one model is down, rate-limited, or underperforming on a specific task, you can route around it. That optionality matters more as agents become load-bearing infrastructure rather than productivity tools.

Cost is another factor. Routing more demanding tasks to one model and simpler tasks to cheaper alternatives sharply reduces cost without requiring you to rebuild your entire workflow. In a recent YC-Bench startup simulation, GLM-5 ran a simulated company about as well as Claude Opus, ending with about the same amount of money left, but at roughly one-tenth of the interference cost. Single-vendor stacks don't give you that lever, and they're not designed to. Every major provider is incentivized to keep you on their full stack. The agent that works best for your use case today may not be the one you want in six months, and if you're running multiple agents already, swapping one out doesn't mean starting over.

Getting multiple agents to work well together requires being deliberate about how you run them. The teams I see pulling ahead are spending less time on benchmarks and more time on the layer that makes managing these fleets of agents possible: how agents share context, how permissions get enforced across providers, and how you maintain visibility into what's actually running. That's the real work, and the teams focused on it now will have a meaningful head start.