Published: 2026-10-21
Analysis

How Monzo built its Slack coding agent: an MCP gateway, sandboxed remote agents, an egress proxy and a swappable model

Chapters / key moments (click to jump — plays here on the page)

Monzo, a digital bank with more than 3,000 back-end services, says its internal agent "Agent Chip" now authors over 10 percent of merged pull requests and runs more than 1,800 tasks a day. The talk credits an existing platform rather than a clever agent: the interesting part is the architecture that makes a regulated company comfortable letting an agent run loose.

Source video

"A Bank Built Its Own Coding Agent. It Took Off — Felipe Felisola Caso & Francesco Galletta, Monzo" by AI Engineer — Watch on YouTube →

What Agent Chip does

Trigger by reaction. Anyone can turn a Slack message into a prompt by reacting with a particular emoji, or by mentioning the bot. That convenience is what made it spread inside the company.
Jobs. Answer questions about architecture, review code, take Linear tickets, and join an incident channel to investigate logs and traces and keep its messages to a high signal. In "ask channels" (squad-to-squad requests) it drafts a reply for a human, or resolves the ticket itself.
Data quality. An "on call" mode reacts to failures and starts an investigation; a proactive version watches back-end changes and flags likely data impact before the next batch run.
Non-specialists can request a change, get a draft already tested in staging, and then involve an engineer for review and deployment. Review rigor is unchanged.

The architecture to copy

One MCP gateway in front of internal tools and knowledge. They built it first, for local coding agents. It exposes only what they choose (deterministic behaviour) and handles authentication and authorization for each agent.
An orchestration system running remote agents in an isolated namespace. Each agent runs in a sandbox pod. The agent image defines the exact tools, command-line tools and credentials it gets, taken from the gateway.
An egress proxy. The agent reaches their code repositories and other systems only through destinations they allow.
A model-agnostic agent box. The innermost box, where non-deterministic behaviour happens, can be swapped for any model, so they aren't tied to one provider.
Existing platform pieces do the rest: alerting, monitoring, a staging environment, queueing and deployment abstractions.

Gotchas & Caveats

The figures (10 percent of merged PRs, 1,800 tasks a day, 3,000 services) are the speakers' own and we can't check them.
No code or configuration is shown; this is a design description, not a tutorial. A smaller team would not need all of it, but the gateway and egress limits are the parts that carry the safety.
They mention Anthropic's Claude Tag only in passing and don't compare features.

Key Takeaways

Put tools and data behind one gateway with per-agent permissions before building the agent.
Give remote agents only the egress they need and define their tools in the image.
Keep a human review step before anything merges, and keep the model swappable.