Warp, the AI-native terminal company, shipped a major update to its cloud agent platform Oz on May 19, adding support for orchestrating Claude Code and OpenAI’s Codex alongside its own Warp Agent from a unified control plane. The announcement, published on Warp’s blog by CEO Zach Lloyd, positions Oz as the governance layer that sits above individual coding agents rather than competing with any one of them.

The framing is deliberate. Oz is not pitching a better agent. It is pitching a better manager of agents.

Multi-harness orchestration is the headline feature. Engineering teams can now spin up cloud agents running any of the three supported harnesses, compare their effectiveness on equivalent tasks, apply per-team billing caps, and maintain consistent audit logs across all sessions. Warp’s stated rationale is that agent performance depends on both the model and the harness together, so locking into one vendor costs organizations the ability to benchmark and route intelligently.

This positions Warp in a category that at least three other companies have moved toward simultaneously. Sourcegraph’s Cody has operated as a multi-model layer for over a year. Replit has built execution and deployment infrastructure above model providers. Vercel has tied agent invocation into its deployment pipeline with similar governance goals. None of those products yet offer harness-level routing with cross-harness memory. That is the specific gap Oz is targeting.

Agent Memory is the more technically ambitious piece and currently in research preview. The system builds an index of organizational knowledge drawn from files, MCP servers, databases, and completed agent sessions. That index is writable: as Oz runs tasks, it records what worked, which means a code review agent accumulates knowledge of a team’s style over time, and a deployment agent retains the topology of production systems across sessions.

Single-vendor agent memory is not new. GitHub Copilot has workspace context; Claude Code maintains project-level memory via CLAUDE.md files. What Warp is claiming is different: memories formed during a Claude Code session are available in a Codex session, and vice versa. The organizational knowledge store is portable across harnesses rather than scoped to one. That claim is worth verifying at production scale. Warp has not disclosed independent evaluation results for Agent Memory retention or retrieval accuracy.

The governance features are targeted squarely at enterprise procurement objections. Oz now supports per-team billing, individual credit caps, and least-privilege permissions for individual agents. A production deployment agent receives different service access than a CRM analysis agent. The company also expanded self-hosting to support Kubernetes pods and direct execution environments without Docker, addressing the infrastructure ownership requirement that Lloyd says comes up consistently in enterprise conversations.

The expanded API is worth noting for teams building on top of Oz. Warp has added return values from agent sessions, including raw conversation objects and artifacts, and made session handoff easier across local and remote environments. That makes Oz a plausible substrate for teams that want to wire agent outputs into existing pipelines rather than consuming Warp’s interface directly.

What Warp has not yet published: pricing for multi-harness orchestration beyond beta, benchmarks comparing harness performance on specific task categories, or any disclosure of how many enterprise customers are currently running Oz in production. The announcement is a company blog post without third-party verification.

For teams currently evaluating multi-harness agent setups, the practical question is not whether a control plane is useful (it is) but whether the memory and governance layer justifies adding a vendor above the vendors they already manage. The answer depends on how many harnesses a team is actually running. A shop standardized on Claude Code has little to gain. A team running Claude Code for coding tasks, Codex for test generation, and an internal agent for deployment scripts has a real coordination problem that something like Oz is designed to solve.

Engineering leaders planning agent infrastructure for the second half of 2026 should pressure-test cross-harness memory claims specifically: ask Warp for evidence that memories formed in one harness are retrieved with sufficient precision in another before committing to the governance layer as a dependency.

Source: Warp’s blog (warp.dev/blog), published May 19, 2026, authored by Zach Lloyd.