For most engineering teams, the question about AI coding agents has shifted from “should we try this?” to “why isn’t ours working yet?” The gap between a promising demo and a tool that authors one in ten production pull requests is real — and what Monzo’s experience reveals is that the gap has almost nothing to do with the model.
The platform came first
Monzo, a UK digital bank with more than 3,000 back-end services and 13,000 data warehouse models, built an internal agent called Agent Chip. By early 2026 it was running over 1,800 tasks a day and authoring more than 10 percent of all merged pull requests across engineering, data, and machine-learning teams.
The team behind it frames the underlying reason plainly: the agent succeeded because the internal platform was already strong. Alerting and monitoring infrastructure, staging environments, deployment pipelines, database abstractions, queuing systems — these were all in place before the agent arrived. The agent did not create leverage from nothing. It compounded leverage that already existed.
That framing is worth sitting with. The temptation in most organisations is to treat the model as the investment and the surrounding infrastructure as a secondary concern. The Monzo experience suggests the relationship is closer to the reverse.
Architecture that contains the risk
For a regulated bank, the question of where an autonomous agent is allowed to act is not optional. The team solved this with a dedicated orchestration layer: agents run in isolated Kubernetes pods (containers that run software in a controlled, sandboxed environment), each with a precisely defined set of tools and environment variables. A proxy controls which external services the agent can reach. The “non-determinism box” — the part of the system where the model makes unpredictable choices — is structurally separated from production infrastructure.
An MCP gateway (a controlled server that exposes internal knowledge sources and tools to agents) sits in front of all internal services. Authentication and authorisation are handled centrally, which means the same gateway serves both locally running agents — developers using tools like Cursor or Claude Code on their own machines — and remotely orchestrated agents like Agent Chip itself.
The practical effect: the same building blocks that power Agent Chip are also available to Slack, GitHub, Linear, and the company’s entire internal service estate. Agent Chip itself has become a platform primitive — other teams build new workflows on top of it.
What it actually does
The use cases span a wider range than “writes code”. Agent Chip auto-joins incident response channels, investigates logs and traces, and surfaces findings for human review. It drafts responses in internal “ask channels” where one squad needs help understanding another squad’s service. It monitors data quality failures and investigates them reactively. It identifies potential impacts on data pipelines before a batch run, rather than after.
The non-specialist use case is particularly worth noting. Business users — people without an engineering background — can describe what they need in plain language in Slack, receive a tested draft in a staging environment, and then involve an engineer only for the final review and deploy step. The barrier to contributing lowers without the rigour of the review process lowering with it.
What generalises
A few things carry across to teams working at any scale.
Provider-agnostic design preserves options. The agent container can be swapped for any model provider. Given how fast the model market is moving, organisations that build tight dependencies on a single provider’s API surface are accepting a risk that a small amount of abstraction can eliminate.
Containment is not a constraint on capability — it is what enables it. The isolated pod architecture, the egress proxy, the controlled MCP gateway: none of these slow Agent Chip down. They are what made it possible to deploy it at all in a regulated environment. Teams that treat safety architecture as something to add later tend to find that “later” never arrives.
The multiplier metaphor holds up. If the platform is weak — if deployment is painful, staging is unreliable, monitoring is sparse — an agent will faithfully automate that weakness at scale. The return on investment in platform quality compounds more than most teams expect once an agent is in the loop.
The direction from here seems clear enough: gradually expanding the window of what agents touch, from back-end code to mobile apps to staging validation to data pipelines to machine-learning predictors. Not a single transformation, but a steady widening of the scope where automated contribution is routine — and human review remains the last, deliberate gate.
Text summarized and optimized using Anthropic’s models and reviewed by a human.