How we build production AI agents for UK service businesses

Most AI agent projects die in the gap between the demo and the Monday morning where real work shows up. The demo handled one happy path. Production is malformed emails, half-filled CRM fields, APIs that time out, and a model that confidently does the wrong thing at 2am.

We build agents that survive that Monday. Here is the approach, from real builds.

What counts as a production agent

A production agent is a system that does a defined job inside your operations without a person babysitting it. It reads from and writes to your actual tools. It handles the inputs you actually get, not the inputs a demo assumes. When something goes wrong, it fails loudly and safely instead of quietly and expensively.

That definition rules out most of what gets shown on social media. A chat window that answers questions about your docs is a feature. An agent that classifies every inbound reply, drafts the follow-up, books the meeting, and routes the record into your CRM is a system. We build the second kind.

Start with the workflow, not the model

The first week of every engagement is an audit of how work actually moves through the business. The agent design falls out of that, not out of the model’s capabilities.

Anthropic’s own engineering guidance says the same thing: use the simplest pattern that does the job, and only add autonomy where the task genuinely needs it. In practice most of the systems we ship are a deterministic pipeline with the model doing focused cognitive steps inside it. The model classifies, drafts, extracts, and decides. Plain code does the moving, saving, sending, and retrying. That split is what makes the system debuggable when something breaks.

One build of ours makes the point. Our email auto-responder runs as pure Python on Modal: the model classifies the reply and drafts the response, then deterministic code handles the Calendly booking and the CRM routing. No orchestration framework, no agent loop where one is not needed.

Tools are the real engineering

An agent is only as good as the tools you wire it to. This is where most of the build time goes, and where most public advice is thin.

Numbers from a production voice agent we run for a UK B2B client: four webhook tools and a nine-field post-call analysis on every single call. Those tools are typed, validated, and tested independently of the model. The agent can only do what its tools allow, which means the tool surface is also the safety surface.

The same discipline applies to inputs. Our cold email infrastructure chains Apify scraping, Claude classification for fit, and NeverBounce verification before a single message goes out through Instantly. Each stage validates before the next stage runs. The model never gets to improvise past a failed check.

Put deterministic rails around every external action

The single most important architecture decision we make: the model never touches the outside world directly. Every external action, sending, posting, writing to a live record, goes through plain code that validates first.

Our document automation builds are review-gated by design. Structured inputs go in, branded outputs come out, and a person approves before anything reaches a customer. Our UGC creative engine runs a three-layer architecture with over 40 scripts, and publishing is a separate, controlled step at the end. The generation layer cannot publish. That separation is not overhead. It is the reason the system is trusted enough to run.

Plan for the model being wrong

Models fail in ways normal software does not: confidently, plausibly, and inconsistently. Production agents assume this.

Concretely, that means bounded retries with different framing rather than infinite loops. Structured outputs validated against a schema, with a repair pass when validation fails. Logs of every model decision so you can trace why the agent did what it did. And a defined failure posture: when the agent cannot complete the job safely, it stops and tells a human, with context.

This is also why we put working software in front of clients every week during the build. Edge cases surface early, while they are cheap to fix.

Handover is a feature, not an afterthought

You own the build. That is a structural choice, not a slogan. The system runs in your accounts, the documentation is written for your team, and the optional retainer exists for iteration, not for dependency.

The test we design for: could your team run this without us next month? If the answer is no, the build is not finished.

What we have shipped

All client work is under NDA, so no names. The shape of it:

• A cold email pipeline: Apify scraping, Claude classification and personalisation, NeverBounce verification, Instantly sending, with replies routed through HubSpot and Slack.
• A CRM lead triage system: webhook intake, Claude scoring, hot, warm and cold routing, Slack alerts, Airtable as the state layer.
• An inbound voice agent for a UK B2B client on Retell AI: calls handled end to end with four webhook tools and a nine-field post-call analysis.
• An AI email auto-responder in pure Python on Modal: reply classification, follow-up drafting, Calendly booking, CRM routing.
• A B2B partner onboarding orchestration across M365, Planner, SharePoint, Zendesk and a custom portal API.
• A UGC creative engine: 40+ scripts, three-layer architecture, Claude, Gemini and Whisper, with Meta ad performance analysis feeding back into generation.

Different businesses, same pattern: deterministic spine, model inside it, rails around every external action.

Where to start

Do not start with “we need an agent”. Start with the workflow that eats the most hours or leaks the most leads. That is what the audit week is for: we map your operations, pick the highest-leverage system, and give you a fixed scope and price before any code is written.

If you want that map for your business, book a strategy call. 30 minutes, no pitch. You leave with a clear picture either way.