Automate the work, keep the judgment.

Why most AI pilots stall

A pilot usually fails for one of three reasons, none of them about the model.

The work was never specified. A process that lives in three people's heads cannot be handed to an agent, because the agent is given the what and left to invent the why. It will invent confidently.

Nobody owns the output. When an agent drafts something and no human is accountable for what ships, quality drifts until trust collapses, and then the tool quietly stops being used.

It was built where the work is not. An assistant in a separate window competes with the systems people already have open. Automation that lives inside the existing workflow gets used; automation that asks for a detour does not.

How we choose what to automate first

Not by what is most impressive. By four questions, in this order:

• How often does it happen? Weekly beats spectacular-but-annual, every time.
• Is the input structured enough? If a competent new hire could do it from written instructions, an agent can too. If they would need to ask three colleagues first, write the instructions before you write the code.
• What does a wrong answer cost? This decides how much human review stays in the loop — not whether to build it.
• Can we measure the before? If we cannot say what it costs today, we will not be able to prove it improved.

What we build

Agents for sales, support and back office

Qualifying inbound enquiries, drafting replies against your actual precedent, pulling together the documents a case needs, reconciling records between systems that were never designed to talk. The pattern that works: the agent prepares, a person approves, and the approval becomes training data for the next one.

Workflow automation across existing tools

Most companies do not need a new system. They need the six they already pay for to stop requiring a human to copy data between them. This is unglamorous work with an immediate return, and it is usually where we start.

Custom internal software

Dashboards that answer the question your team actually asks each morning, internal tools that replace a spreadsheet three departments are editing at once, integrations between systems whose vendors have no interest in connecting them.

Deployment, monitoring and handover

Anything we build gets logging you can read, alerting when it misbehaves, and documentation written for whoever inherits it. We would rather your team ran it without us than that you had to keep us on retainer to keep the lights on.

We run on this ourselves

Our own company operates on an agentic system we built — client work, product development, reporting and internal operations all move through it, at roughly thirty commits a day across products and client systems. It is the reason we can be specific about what fails: we have hit most of it ourselves first.

Nothing we recommend is theoretical, and nothing we sell is something we would not run internally.

What you own at the end

The compliance question, answered in-house

Putting company data through a model raises real questions: what may be processed, on what legal basis, under which contracts with which providers, and what has to be recorded. Because our own law office sits inside the company, that gets answered as part of the build rather than discovered afterwards by someone else's counsel. See Legal.

When we are the wrong choice

If you want a demo for a board meeting rather than something that runs on Monday, we are an expensive way to get one. If the underlying process is broken, automating it produces the same mess faster — we will say so, and the fix is a process conversation first. And if nobody internally is willing to own the output, do not start: the tool will be abandoned within a quarter regardless of how well it is built.