The last 18 months of progress in agentic AI have been hard to ignore. At Monzo, we’ve trialed a range of tools and have seen adoption growing rapidly, with nearly all of our engineers now using at least one coding agent regularly as part of their day-to-day.

With so much appetite, we identified the opportunity to have our own engineering focused agent that would be tailored to our environment, having all the context it needs to build and verify its work with a similar level of confidence that an engineer would have.

We built an agent ecosystem, which is now authoring ~10% of all merged PRs at Monzo, and is routinely running more than 1800 tasks every day.

We wanted to drive the following outcomes:

To begin, we built the foundations to allow us to achieve this:

In parallel, we defined the key requirements we needed to keep in mind:

It became clear looking at these requirements that building our own tool would be the best path forward. We spent around three weeks focusing on getting to a minimum viable product, and that’s how Agent Chip was introduced to the world of Monzo.

Agent Chip is an omnipresent tool that is available across Slack, Linear, Github and locally on a users machine.

Agent Chip gives access to the vast majority of our repositories, documentation and observability systems etc. at a click of a button - or a one sentence prompt.

A few use cases stand out so far:

Incidents. When something breaks, the cost of a slow first response is high. Agent Chip pulls together context across systems, surfaces likely causes, and can draft a fix while a humans are co-ordinating the response. We’ve seen multiple times our ‘Agent Chip Incident Mode’ catching errors from responding engineers that could have made incident resolution more complicated or extend our resolution time.

Allowing non-engineers to ship small fixes and UX improvements. Some of the most valuable and magical changes to our products aren't deeply technical, they are copy tweaks, small UX inconsistencies, edge cases caught by customer operations. With Agent Chip, the people closest to the problem can describe a fix in plain English and get a pull request out of it. An engineer still reviews and merges, but the bottleneck moves from "find an engineer with capacity" to "find a reviewer". That changes who gets to improve the product.

Routine engineering work. Library upgrades, repetitive refactors, the kind of work that's important but rarely the most exciting thing on someone's plate. Agent Chip eats that work, and the time saved compounds.

This high-level architecture diagram shows how we have a series of inputs into the Agent Chip infrastructure. The key part is the ‘agent bundle’ that is deployed into sandboxed environment well away from all the services we use to run the bank.

The bundle is used to isolate an agent running in our production environment sufficiently enough that we can pick and choose what access the agent has on a per task basis. The agent can be run on an environment specific docker image depending on the job assigned and is given a single isolated proxy to speak with over HTTP. Doing this allows us to isolate secrets and de-risk agent access to the outside world.

It’s important to say at this point - reliability is at the heart of our bank. We built Agent Chip ourselves to maintain flexibility and full control over the underlying coding agent. If a model provider suffers an outage or its performance degrades, we can quickly and seamlessly swap in another. This prevents both vendor lock-in and ensures our tools are always available for Monzonauts who need to use them.

The current setup executes on single, ‘one shot’ jobs, such as:

All of these ‘Chips’ leverage some foundational work we did to get agents to access metrics, logs, code and our knowledge base. This base level of functionality is what makes Agent Chip versatile and has driven adoption in the company across many use cases.

To make the most of our engineering community in Monzo, and to allow fast iteration, we designed for federated adoption: creating a clear barrier to separate Agent Chip ‘the platform’ and Agent Chip ‘the product’.

The entry point is a service called remote-code-agent-trigger, which comes with a set of consumers of various events from our internal systems (a Slack message, a Linear task, webhooks, etc.) these consumers then map onto “workflows”.

Workflows are the interface that all jobs that are executed on Agent Chip adhere to. They help us maintain observability of use cases, attribute jobs to teams, and monitor cost at a product level without having too much business logic within the core remote-code-agent service.

Workflows define the ‘throughput type’ (batch job/ASAP), the structure of the response from the agent and how to handle the responses from the agent.

This approach has helped folks across the business quickly setup agent chip integrations without much effort (many integrations have been created by Agent Chip itself!).

We’re still very early on in the lifecycle of our Agent Chip product. The next 6 months are going to look very different from the last 6, and we intend for Monzo to be one of the places where the shape of agentic engineering actually gets figured out, not just talked about.

There are a few things lined up to come next:

If you're an engineer who finds this kind of problem energising — building the systems that turn AI into a competitive advantage inside a real, large, customer-focused company — we'd love to hear from you.

We're hiring directly into this team and the wider Platform engineering teams that enable and support this kind of work. The work is concrete, the loop is fast, and the impact lands on real customers quickly.

Come build with us!