An agent is not a bigger automation.
If you take one thing from this page, take this. The two are priced differently, fail differently and are operated differently, and a supplier who blurs them will sell you the wrong one.
A defined procedure handles predictable input reliably and cheaply. It is the right answer far more often than people expect. It stalls the moment something arrives that nobody described in advance, which is why every automation we ship has an exception queue with a person at the end of it.
B
Agent
A goal, plus judgment.
Give it a goal, a boundary and a set of tools, and it decides which steps to take. Ask it to create ERP line items and it can read two orders written differently, because it is working from content rather than from format.
Agents take on the document-heavy routine that used to need a human to interpret it — which is exactly where time and know-how leak out of a company today. That makes them valuable and it makes them risky in the same breath.
It is not magic; it is engineering. What separates an agent that runs for two years from one that demos well in March and is switched off in June is whether the eight things in the next section were defined before anyone wrote code.
The agent does the typing. A person still presses the key that matters.
Every agent we build has named points where it stops and waits for someone. Those points are written down before anything is built, not discovered afterwards when something has already gone through.
Eight things, defined before a line of code.
An agent is a system of defined parts, not one clever model. Each of these is load-bearing: drop one and the agent works in the demo and fails in the third month.
We map the process, then write down what the agent does and, just as carefully, what it does not. The boundary is the reliability.
Every PDF, email or query has a defined output: ERP rows, a draft reply, an import file. That is what makes the result testable rather than impressive.
What it may do alone, and where it has to stop and wait. This is what makes access to a live system something you can sign off on.
ERP, SharePoint, Microsoft 365, CRM, PDM and CAD, email, WhatsApp, connected through APIs where they exist and through the interface where they do not.
Company documents consolidated, scans run through OCR, and answers drawn only from approved context — always with the source attached.
The agent recommends and prepares. A person approves. We define each handover point by name, not by principle.
Errors, response time, work returned and adoption, all measured against the baseline we took before building. An agent nobody measures is an agent nobody can defend.
Ownership, access and AI-use rules designed at the start. Sensitive workloads can run entirely on your own infrastructure.
!
The limits, stated plainly
What an agent never does.
- It does not send anything outside the company without approval.
- It does not delete data.
- It does not make financial decisions.
- It does not decide anything with legal exposure — pricing, credit, hiring. It prepares the case; a person signs it.
- And your data is not used to train a model for anyone else, contractually on our side and on the model vendor's.
Six kinds of agent, all of them in production somewhere.
These are not a product menu. Each one exists because a client had the problem first. We pick the model and the tooling per task and per data sensitivity, not per fashion.
Turns drawings, bills of materials, invoices and contracts into structured data.
Pulls order lines out of free-form messages into the ERP and drafts replies to recurring queries.
Answers from your own documentation and cites the source document. It does not answer from memory.
Turns meeting notes and tickets into tasks, owners and escalations a team can actually run.
Answers plain-language questions against the ERP or the warehouse.
Handles web, WhatsApp and inbox traffic around the clock, and hands off to a human cleanly.
Your tenant, your rules.
Chosen for the task and for how sensitive the data is. When it cannot leave the building, it does not leave the building.
Matched to the stack your own people will maintain after we hand over, not to what we happen to like.
Official APIs where they exist. Database, files or the interface itself where they do not.
GDPR and the EU AI Act designed in at the start rather than argued about at go-live.
A trustworthy agent knows when it does not know.
The engineering that matters is not making an agent capable. It is drawing the line where its confidence runs out and the decision goes back to a person — and drawing it before deployment, not after the first bad week.
In practice that means the agent reads the fields it can read reliably and refuses the ones it cannot. On one machine-shop engagement it reads the title block and the parts list and leaves ambiguous dimensions to the process engineer by design, because a wrong dimension costs more than the time it saves.
It also means we will tell you when the answer is an automation, or no software at all. That conversation happens in stage two, before there is a budget to defend.
Fixed-track work, the five layers we cover, and where we stop.
How we build automation →