AI automation

Automate the repetitive work. Keep a human where judgement matters.

Most useful automation is unglamorous: moving data between systems that do not talk to each other, drafting a reply someone reviews, classifying an inbox, or turning a form into a ticket. Language models are good at some of this and unreliable at the rest. We build the parts that work, and are explicit about the parts that need a person.

Start a conversation

You might need this if

  • Someone re-types the same data into two systems every day.
  • Enquiries arrive by email and are triaged by hand before anyone can act on them.
  • Reports are assembled manually from the same three sources every week.
  • A previous automation attempt broke silently and nobody noticed for weeks.
  • You want to use AI somewhere but are not sure where it would actually help.
  • Documents arrive as PDFs and someone copies the figures into a spreadsheet.

What the work covers

Not every engagement includes all of this. The scope is agreed in writing before anything starts.

  • Process automation

    Connecting the systems you already use so data moves without a person copying it, with error handling and alerting when a step fails rather than silent failure.

  • Document and email handling

    Extracting structured data from invoices, forms and emails, routing it onward, and flagging low-confidence results for human review instead of guessing.

  • Drafting and classification

    Language-model assistance for first-draft replies, summaries and categorisation, always with the person who sends it in the loop.

  • Internal tools

    Small purpose-built interfaces — a queue, a dashboard, an approval screen — for where a spreadsheet has stopped being adequate.

  • Integration work

    APIs and webhooks between CRM, email, spreadsheets, accounting and e-commerce platforms, with authentication handled properly and credentials kept server-side.

  • Monitoring and cost control

    Logging, failure alerts, retry behaviour and usage caps, so an automation cannot fail quietly or run up an unbounded API bill.

How we approach it

  1. 01

    Measure the manual process

    How often it runs, how long it takes and what it costs when it goes wrong. Automation that saves ten minutes a month is not worth maintaining.

  2. 02

    Decide what must stay human

    Anything that sends money, contacts a customer unreviewed, or deletes data stays behind a person. We agree these boundaries in writing before building.

  3. 03

    Start with the deterministic parts

    Routing, extraction and formatting first — those are predictable. A language model is introduced only where the task genuinely needs one.

  4. 04

    Build in observability

    Every run is logged with its input, output and outcome, so a failure is visible the same day rather than at the next audit.

  5. 05

    Pilot before committing

    The automation runs alongside the manual process for an agreed period and the outputs are compared, so you have evidence before switching over.

What you end up with

  • A written map of the process, showing which steps are automated and which stay manual
  • The working automation, with credentials held server-side and never in client code
  • Failure alerting and a run log you can inspect
  • Usage and cost limits on any metered API
  • A fallback procedure for when the automation is unavailable
  • Documentation for operating and changing it

Technologies involved

Tools and standards this work is carried out with — listed because they are what the job uses, not as a claim of vendor partnership.

  • Node.js / TypeScript
  • Python
  • Claude API
  • OpenAI API
  • n8n
  • Webhooks & REST APIs
  • PostgreSQL
  • Google Sheets API
  • Docker

What this will not do

Language models produce confident, plausible output that is sometimes wrong. We do not build automations that send external communications or make financial decisions without human review, and we will decline if asked — the failure mode is too expensive.

On client examples: we do not publish case studies, logos or testimonials without written permission from the client, and we have none cleared for publication yet. If you need evidence of relevant work before engaging, ask — we will share what we can, appropriately redacted, and say plainly where something was a lab build rather than a client engagement.

Questions about this service

Will the AI make mistakes?

Yes. Language models produce output that is fluent and sometimes wrong, and they do not reliably signal which is which. That is why we design around it: deterministic code handles anything that can be handled deterministically, confidence thresholds route uncertain cases to a person, and nothing irreversible happens without human approval.

Where does our data go?

Wherever the design says, and we write that down before building. If data must not leave your infrastructure, we say so at the scoping stage and that constrains which tools are available — sometimes to the point where a model-based approach is ruled out. API credentials are held server-side and never shipped to a browser.

What does it cost to run?

Metered APIs charge per use, so the running cost scales with volume. We estimate it from your actual throughput before building, and put a hard usage cap in the implementation so a loop or a retry storm cannot produce an unbounded bill.

What happens when the automation breaks?

It alerts, and there is a documented manual fallback. The failure mode we specifically design against is silent failure — an automation that stops working and is not noticed for weeks is worse than not having built it.

Have a process that eats hours every week?

Describe the steps as they happen today, including the awkward exceptions. We will tell you honestly which parts are worth automating and which are not.

Get in touchHow an engagement works

Related services