AI & automation

AI is the work we lead with. We build systems that read documents people used to type up by hand, gather and summarise evidence, carry a multi-step process end to end, and modernise code nobody else wants to touch. We run them on infrastructure you own when the data is too sensitive to send anywhere else.

That last part is why clients come to us for it. We have spent more than a decade building and hosting systems that hold citizen, financial and legal records, so privacy, audit trails and a security review before release are the default, not an upgrade.

We scope these projects the same way we scope everything else: understand what you’re actually trying to automate or connect before choosing a model or a chip, build and test against that, then hand over something your team can run. That means monitoring, documentation and support behind it, not a proof of concept that stops working once we leave.

What these projects usually are

Several disciplines share one page because they usually share one project: a line that needs sensors on it, a model to read what they produce, and a screen a supervisor can act on. In practice the work takes four shapes:

• A decision somebody makes over and over. A model reads the data and proposes the answer; a person still signs it off. The value is in the hundredth repetition, not the first.
• A pile of documents nobody can search. Paper statements, depositions and archived web pages are read by a model, checked, and turned into something a team can query, share and explain.
• A workflow nobody should be doing by hand. Form routing, document classification and approval chains, or moving data between two systems that were never going to talk to each other. This is increasingly handled by an agent that completes the task rather than a script that moves a file.
• A conversation at volume. WhatsApp and on-site chatbots taking first-line questions, bookings and order status, handing over to a person the moment the question stops being routine.
• Something physical that needs to report. Sensors, firmware and a board design, so equipment in the field produces data you can act on rather than a light on a panel nobody is watching.

How we decide it’s worth building

Automation fails in a specific and predictable way: it works in the demo, gets handed over, and is quietly abandoned within a quarter. We scope against that outcome.

• The problem comes before the technique. An off-the-shelf API, a trained model, or a rule someone could have written in an afternoon are all acceptable answers. We pick the one that leaves you with less to maintain, not the one that’s more interesting to build.
• The prototype runs on your data. Real inputs, real edge cases, real volume. A proof of concept tested on a clean sample tells you nothing about the Tuesday it breaks.
• Somebody owns it after we leave. Named at the start, trained during handover, with documentation and monitoring behind them. If nobody on your side can own it, that’s worth knowing before the build, not after.
• We’ll say when it isn’t worth it. Some processes are cheaper to leave alone. That’s a legitimate outcome of the discovery stage, and we’d rather reach it in week one than month six.

Longer term, the same team handles the hosting, monitoring and support underneath (see cloud hosting & AMC), so an automation that runs in production has someone watching it.