Automation that survives contact with the work.

Not a chatbot bolted onto a website. We mean the work itself: a tender response drafted from your own prior submissions, supplier invoices read and reconciled without somebody retyping them, a quote that stops waiting three days for an internal reply, a month-end close that does not need a fortnight of manual assembly.

Some of that is classic rules-based automation and does not need AI at all. Some of it needs a language model because the input is messy human text. The useful distinction is not whether something is AI, it is whether the step is high-volume, low-judgement and reliably shaped.

It pays where the same shape of work happens many times a week, where the input is text or documents, and where a person can check the output quickly. Drafting, summarising, extraction, classification, retrieval and first-pass reconciliation all qualify.

It does not pay where the judgement is the job, where volume is low, or where being wrong is expensive and hard to notice. A model will produce a confident answer in all three cases, which is precisely the danger. We say no to these in writing, as part of the readout.

Agents that read across a business and act inside it are real and genuinely useful, and they are also where most of the current hype sits. The version that works has narrow scope, explicit permissions, visible reasoning and a person approving anything that leaves the company.

That is the rule our own products are built on: agents draft, people send. If a vendor is offering you autonomous action over customer-facing work with no human in the loop, ask what happens the first time it is confidently wrong.

It starts with an Operational Audit, so the build is scoped from a real process map rather than a wish list. Then it runs in phases, each one shipping something usable, because a nine-month build that reveals its problems at the end is how automation projects die.

Where it makes sense, builds run on Iris — a custom operating system for your business on a retrieval data core, so your data is somewhere a model can actually read from instead of scattered across systems that do not talk. Orchid, our flagship, goes further: it resolves what your systems and your people know into one permission-aware model and runs agents over it that find what is outstanding and draft the action. Both are described on their own pages, including what is not built yet.

Nobody wants to replace a working ERP to get automation, and you usually should not. Most of what we build reads from and writes to what is already in place — the accounts package, the CRM, the project tool, the shared drive — rather than asking a business to migrate first.

Where the existing data genuinely is the problem, that is a finding worth having early, and the audit surfaces it before anybody has committed to a build.