Your first AI agent should be boring.

Almost every AI conversation we have with a new client starts with a chatbot: a customer-facing assistant, trained on the website, answering questions around the clock. It's the most visible idea in the room — and usually the wrong place to start.

Chatbots talk to your customers, which makes every mistake public. They're judged on open-ended conversations, which makes them hard to test. And their value is hard to measure: a deflected question might be a saved support ticket, or a buyer who gave up. When the first project is that fuzzy, the second one rarely gets funded.

The projects that pay back are less glamorous. They live in the back office, in the queue of work someone gets through every morning with two browser tabs and a spreadsheet.

A few of the first agents we've shipped for clients:

• Reading supplier invoices from a shared inbox, matching them to purchase orders and flagging the ones that don't reconcile.
• Enriching new inbound leads with company details, scoring them against the sales team's criteria and routing them to the right owner in the CRM.
• Sorting support emails into categories, pulling the customer's order history and drafting a reply for a person to approve.
• Turning intake forms and uploaded documents into clean, structured records, then chasing the customer for anything missing.

None of these would make a keynote. All of them take hours of repetitive work off someone's week, have an obvious definition of done and fail in ways that are easy to catch.

We score candidate workflows before we write a line of code. A good first agent gets a yes to most of these questions.

1. 01

   Is it high-volume?

   Dozens or hundreds of items a week. Small volumes don't justify the build or the monitoring.

2. 02

   Are the rules mostly written down?

   If two people would handle the same item differently, settle that first. An agent can't automate a disagreement.

3. 03

   Is the data reachable?

   The inbox, CRM, accounting system or drive the agent needs has an API or export we can use without workarounds.

4. 04

   Are mistakes cheap and reversible?

   A mis-routed lead can be re-routed. A wrong payment can't. Start where errors are recoverable.

5. 05

   Can we measure the before?

   Time per item, backlog size or error rate today. Without a baseline, you can't show the agent helped.

The word “agent” suggests autonomy. For a first project, we deliberately keep it on rails. The structure is a normal automation — trigger, steps, outputs — with a language model doing only the parts that need judgment over messy input: reading a document, classifying an email, extracting fields, drafting text.

Everything around the model is deterministic. Lookups go through APIs, not guesses. Outputs are validated against a schema before they're written anywhere. Anything the model is unsure about goes to a human review queue instead of straight into the system of record. Every run is logged, so when someone asks why the agent did something, there's an answer.

Before launch we also collect a set of real past examples — usually somewhere between a few dozen and a couple of hundred — with the correct outcome for each. Every prompt or model change runs against that set first. It's the closest thing to a unit test that language models have, and it's what lets us change things without holding our breath.

This shape is also cheaper to maintain. When a model is updated or replaced, a narrow task with a test set of real examples is easy to re-check. An open-ended assistant isn't.

The failures we see are rarely about the model. They're about scope and ownership.

• The scope creeps before launch. “While we're at it, could it also…” turns a two-week build into a quarter. Ship the narrow version, then extend it.
• Nobody owns it. Every agent needs a named person who reviews its queue, reads its error alerts and decides when the rules change.
• The edge cases are invisible. The first month surfaces exceptions nobody mentioned in the workshop. Budget time to handle them, and add each one to the test set.
• Success is never defined. If the target — hours saved, backlog cleared, error rate — isn't agreed before launch, every result looks ambiguous afterwards.

We report three numbers for every agent: the share of items it handles without human edits, the time saved per item against the baseline, and the error rate found in spot checks. If the first two go up and the third stays flat, the project is working. If not, we narrow the scope until it does.

Once a boring agent is running quietly, the chatbot conversation gets much easier. The team trusts the tooling, the data is cleaner and there's a real return to point to. That's when we'd build the customer-facing assistant — on the same foundations. If you already have a workflow in mind, our AI automation team can help you score it, and our comparison of n8n and Make covers where to build it.

Written by

Daniel Reyes

Head of AI Automation · 9 years in automation

Daniel leads our AI automation practice, designing the agents and workflows clients run every day — from invoice matching to lead routing. He's an engineer first, and writes here about the unglamorous automations that actually pay back.

More from DanielLinkedIn