Most automation projects fail quietly. Not with an outage — with a dashboard nobody opens, a bot that answers the wrong question confidently, or a monthly bill that grows faster than the work it was meant to remove. The technology usually works. What's missing is a way to tell whether it changed anything.
What we build for clients are custom automations wired into the systems they already run on — calling, follow-ups, data entry, reporting, screening. Not a generic assistant bolted to the side. The value isn't the model; it's that the automation touches the same order, the same CRM record, the same warehouse table that the business already lives in. Below is the pattern we hold every build to, three workflows where it earns its keep, and — because this is the part vendors skip — where automation does not pay.
The pattern: agent, tools, a metric, a kill-switch
Every automation worth shipping has four parts, and the failures are almost always missing one of them.
An agent is the thing that decides what to do next — not a fixed flowchart, but something that can plan a step, see it fail, and try another route. A rigid script breaks the first time reality doesn't match the diagram. An agent bends.
Tools are how the agent touches the real world: reading a CRM, writing a row, sending an email, running a query. An agent with no tools is a chatbot. An agent with the right tools is a colleague who can actually finish the job. The tools are also where the risk lives, which is why the last two parts matter so much.
A metric is one sentence, agreed before any code is written, describing what has to move — and it has to be something already counted in your systems. 'Reduce time-to-first-response on inbound leads.' 'Cut the hours spent compiling the Monday report.' If measuring the outcome requires building the measurement, it's the wrong metric, and we'll say so. Automation without a metric isn't a project; it's a hobby with a budget.
A kill-switch is the ability to stop the whole thing at once, plus a hard cap on what it can spend or do before a human is asked. Every agent will eventually meet an input its authors didn't imagine. The question is whether that costs you a strange log line or a five-figure afternoon. The kill-switch is what makes the difference boring.
Three workflows where it pays
Calling. A voice agent works an inbound or outbound list, handles objections, books the slot, and scores every conversation 0–100 for buying intent. The tools are the phone system and the CRM; the metric is usually reps' time spent on qualified conversations versus dead ones; the kill-switch is per-call cost tracking and an operator stop that halts every line. The productivity gain isn't 'the AI made calls' — it's that a rep's day stops being spent on the eighty per cent that was never going to buy.
Reporting and data entry. The dullest work in any company is moving a number from one system into another and rebuilding the same report every week. An agent with read and write access to both systems does it on a schedule, escalates the genuine exceptions, and logs every action. The metric is hours reclaimed, and it's the easiest one to measure honestly because the hours were always on someone's timesheet. This is the work nobody was hired to do, and getting it back is the clearest productivity win we sell.
Screening. A single open role draws hundreds of resumes, and the good ones in the back of the pile get missed. An agent reads every one against the role spec, ranks them with a written reason for each placement, and hands a shortlist to a recruiter. It never auto-rejects without a reason a human can audit — because screening is exactly where bias and legal exposure live. The metric is time-to-shortlist; the guardrail is that a person still makes the call.
Where automation does not pay
Being honest about this is the whole job. We turn down more automation work than we take, and it's usually for one of these reasons.
When the outcome can't be measured. If nothing in your systems already counts the thing that should improve, there's no way to know whether the automation helped, and 'it feels faster' is not a result. We'd rather decline than ship something that can't be settled.
When the task changes shape every time. Automation earns its cost on repetition. A job that is genuinely different on every instance gives an agent nothing to learn, and a person is both cheaper and better. The dull work that repeats is the opportunity; the varied work that doesn't is a trap dressed as one.
When a human is the point. Some conversations exist to build trust — a large, considered sale; a sensitive HR or clinical discussion. An agent can qualify, take notes, and handle the follow-up, but if you automate the relationship itself you've cut the thing the work was for. Automate the admin around the human, not the human.
When the data underneath is a mess. An agent that answers questions from contradictory tables will answer confidently and wrongly. Clean the warehouse first, or scope the work to the parts you actually trust. Speeding up a wrong answer is not a productivity gain.
How we build them
For the curious: we orchestrate these agents with LangChain and ship them fast with AI pair-programmers like Claude Code and our own Hermes. That's worth one sentence and no more — the tooling is how the work gets done, not why it's worth doing. What a client is buying is the metric moving, deployed into their live environment, with a kill-switch behind it. The stack is our problem to get right.
The reason to lead with the outcome rather than the tools is the same reason we publish our prices and put a third of our fee behind the result: in a market with a documented failure rate, the only claim worth making is one you can settle. An automation that can't tell you whether it worked is indistinguishable from one that didn't.
Where to start
If you're weighing an automation, the useful first question isn't 'which model' or 'which framework.' It's: what one number, already counted in your systems, should move — and can you switch the thing off if it misbehaves? If you can answer both, you have a project. If you can't, you have more thinking to do, and that's worth knowing before anyone writes code.
We built a short readiness test that scores exactly that: whether the outcome is measurable, whether the data exists, whether someone owns it, and whether it can be stopped. It takes a few minutes, the result is immediate, and it will sometimes tell you not to hire us.