Most people who contact us arrive with the same idea: build the impressive thing. A chatbot, an agent, something with a demo that gets applause in a meeting. We almost always talk them out of it, at least for the first project.

The valuable work is usually hiding underneath it — the copying and pasting, the inbox that eats an hour a day, the report somebody rebuilds by hand every Monday because the last person who knew the query left.

Boring is a technical term here

A task is a good automation candidate when three things are true:

  1. It repeats. Weekly or more often. One-off tasks are not worth automating; you will spend longer building the thing than doing it.
  2. It has a shape. A clear input, a predictable decision, a known destination. If the output format lives in one person’s head, that is a documentation problem first, and a code problem second.
  3. Somebody notices when it is wrong. There is a real consequence if the automation drops a step, which means you will actually maintain it.

If a task passes all three, the economics are almost boringly predictable. If it fails one, no amount of clever model selection saves it.

The shape of the work

The pattern we build most often looks like this: something arrives, it needs to be read, classified, enriched, and sent somewhere useful.

// The shape, not the implementation: read → decide → enrich → deliver.
export async function triage(item: Incoming) {
  const reading = await read(item);            // an LLM reads messy input
  const decision = classify(reading, RULES);   // rules decide, not the model
  const enriched = await enrich(item, company); // your tools, your data
  return deliver(enriched, decision.destination);
}

Two opinions are baked into those four lines, and both of them matter more than the model choice.

The model reads; the rules decide. Language models are excellent at turning a messy email into structured fields, and unreliable at being consistently right about policy. So we let it extract, and let ordinary deterministic code decide what happens next. When something goes wrong you can read the rules and point at the line. Try doing that with a prompt.

Enrichment uses your tools. If the answer lives in your CRM, the automation reads your CRM. It does not keep a hopeful copy of your data in a separate system that drifts out of sync by week three.

Where it goes wrong

We have seen the same three failure modes enough times that we now check for them before we start.

Failure What it looks like What we do instead
Automating a process nobody understands Two people describe the same workflow differently Map it on one page first, with the people who do the work
Full autonomy on the edge cases The 5% of odd inputs silently go nowhere Route anything uncertain to a human queue with context attached
Building on tools the team resents The automation works, nobody uses it Automate inside the tools people already open every day

The second one is the expensive mistake. It is tempting to promise full autonomy, because that is the version that sounds impressive. But “the automation handles 90% and hands you the tricky 10% with a summary” is a system people trust. A system that quietly loses 5% of invoices is a system people stop using, and then you have paid for two processes instead of one.

How we measure it

Not with a benchmark. With three numbers that a non-technical person can check:

  • Hours back per week. Measured before and after, from the people doing the work.
  • Touch rate. How often a human has to intervene. This is the maintenance bill, and it should fall over the first month.
  • Time to answer “why did it do that?” If nobody can explain a decision in a couple of minutes, the automation is not finished.

If the only person who understands the automation is the person who built it, you have bought yourself a dependency instead of a system.

What we would do first at your company

Ask the team one question: what did you do this week that you have done before? Collect the answers, count how often each one repeats, and pick the top one. It is almost never the task that got mentioned in the strategy meeting.

Then build it small, in days, with the people who own the process watching. If it survives a month of real use, automate the next one. If it does not, you have lost a week instead of a quarter, and you have learned something true about how your business actually runs.

That is the whole trick. The flashy project is still available afterwards — it just gets built on top of a company that already has a bit more room to breathe.