Document reading
Invoices, delivery notes, contracts and forms read and turned into structured data, including layouts the system has not seen before. This is where most companies are still paying a person to re-type what a machine already produced.
Workflows that read, decide and write back into the systems you already run — narrow, supervised, and built to hand back anything they are unsure about.
Invoices, delivery notes, contracts and forms read and turned into structured data, including layouts the system has not seen before. This is where most companies are still paying a person to re-type what a machine already produced.
Several steps chained into one workflow, with the decision points and the handovers made explicit. Orchestration is what turns a model that answers questions into something that completes a task.
Connections to the ERP, CRM, email and spreadsheets already in use — through APIs where they exist, and through the same interfaces your team uses where they do not. Nothing gets replaced to make the automation possible.
We design the review before the automation: which decisions a person confirms, what happens when confidence is low, and how an error surfaces afterwards. An agent that never escalates is not more capable, only less honest.
An AI agent is a workflow that can take several steps on its own before returning a result: read a document, look something up in another system, decide what to do next, write the outcome somewhere. That is the whole of it. The word carries more mystique than the thing deserves.
It differs from a chatbot, which answers a question and stops, and from classic automation, which follows a fixed script and fails when the input is not shaped the way it expected. An agent handles variation — an invoice laid out differently, an email that says the same thing in different words, a field that is simply missing.
The trade-off is real and worth stating plainly: an agent can be wrong in ways a rule cannot. A rule fails loudly. An agent can produce something plausible and incorrect. That is why the ones worth deploying are narrow, supervised, and built to report what they were unsure about rather than to guess quietly.
The slowest part of most business processes is not any single system. It is a person moving information between two systems that never learned to talk to each other — reading a number off one screen and typing it into another, checking whether an order matches a delivery, forwarding an email with a summary attached.
These tasks share the three properties that make automation worthwhile. They repeat often enough to pay back. They depend on information that is already written down somewhere. And a mistake is visible before it becomes expensive, because a person sees the result in the normal course of their work.
This is also why we do not recommend replacing an ERP or a CRM in order to automate around it. Replacing working software is expensive, disruptive, and rarely addresses the actual bottleneck. We build against what is already there.
Some workflows can run entirely on infrastructure you control. Others send specific fields to a model provider. Which of the two applies is a decision we make with you, before the build, not something discovered afterwards in a configuration file.
Where data does leave your systems, we document exactly what is sent, to whom, under which contractual terms, whether it is retained and for how long. Under the GDPR that documentation is a requirement rather than a courtesy, and it is the part most AI projects leave until someone asks.
All three describe the same idea in different settings: a workflow that takes several steps before returning a result, with a person deciding at the end.
An insurer replaced its «Call Me» button with an assistant that talks, gathers what the quote needs and returns a result in the same interaction — at 11pm or on a Sunday.
Delivered project. No conversion figures published.
Read the caseEight properties across three regions replaced the email quote request with a seven-step journey that returns a proposal to the client and an already-qualified lead to the sales team.
Delivered project. Catalogue figures, September 2026.
Read the caseAn agent that reads the complaint, summarises it, extracts the location, classifies the responsible service, geolocates the incident and drafts a reply — with three levels of human supervision.
Architecture description, not a delivered project.
Read the caseA property development that answers by itself over email, with AWS Lambda and an LLM using the project’s real knowledge — with nothing for the buyer to install.
Delivered project. No conversion figures published.
Read the caseAn AI agent is a workflow that can take several steps on its own before returning a result: read a document, look something up in another system, decide what to do next, and write the outcome somewhere. It differs from a chatbot, which answers and stops, and from classic automation, which follows a fixed script and breaks when the input varies. The useful agents are narrow and supervised.
Classic automation follows a fixed path and fails when something is not where it expected. An agent can handle variation: an invoice laid out differently, an email that says the same thing in other words, a field that is missing. The trade-off is that an agent can also be wrong in ways a rule cannot, which is why the ones worth deploying report what they were unsure about instead of guessing silently.
No. We build against the systems you already run, through their APIs where they have them and through the same interfaces your team uses where they do not. Replacing working software is expensive and is rarely the reason a process is slow. The slow part is usually a person moving information between two systems that never learned to talk to each other.
It should hand the case back rather than proceed. We design the review point before we design the automation: which decisions a person confirms, what the agent does when its confidence is low, and how an error is detected after the fact. An agent that never escalates is not more capable — it is less honest about what it does not know.
In the seams between systems. Reading a supplier invoice and entering it, matching an order against a delivery note, drafting a reply that a person approves, checking one system against another for discrepancies. These are tasks that are repetitive, that depend on information already written down, and where a mistake is visible before it becomes expensive.
That depends on the design, and it is a decision we make with you rather than for you. Some workflows can run entirely on infrastructure you control. Others send specific fields to a model provider, in which case we document exactly what is sent, to whom, and under which terms — including what the provider does with it and whether it is retained. Under the GDPR that documentation is not optional.