AI That Can Act. With Boundaries
We engineer agents and copilots that work inside real business systems, using your knowledge, tools, and workflows while keeping people in control of consequential decisions.
Read this ifthe bottleneck in your workflow is not the answer, it is the ten steps that follow it.
- User
- Agent
- Knowledge
- Tools
- Business Systems
- Policies
- Human Approval
A Chatbot Answers. An Agent Works
Useful agents do more than generate text. They understand context, retrieve knowledge, use tools, follow constraints, and move work forward. The interesting comparison is not what each one says, but where each one stops.
A customer writes in: the delivery address on order 48219 is wrong, and they would like the express shipping fee back.
- Responds to prompts
- Primarily conversational
- Limited system access
- 01ReadsEverything it knows about order 48219 is whatever was pasted into the message.
- 02AnswersProduces a clear, well-written explanation of how an address change is normally handled.
- 03StopsThe order was never opened, the address was never changed, and the fee was never looked at.
- 04Hands backA person re-reads the thread, opens the order system, and does the work the answer described.
Ends at a paragraph. The work is still on a person's desk.
- Understands context
- Uses tools and systems
- Executes multi-step work
- Operates within defined boundaries
- 01Resolves contextPulls order 48219, the customer record, and the current shipping status — scoped to what this user is allowed to see.
- 02Checks the ruleThe order has not been dispatched, so the address is still editable. That is a business rule in code, not a judgement call.
- 03Uses a toolCalls orders.updateAddress — the one write it is permitted on this record, with the new address validated first.
- 04Escalates the restThe refund crosses the approval threshold, so it goes to a person with the order, the policy, and the reasoning attached.
- 05Records the runInputs, retrieved sources, tool calls, the refusal, and the approval land in one trace that can be read back later.
Ends at a changed record, one decision waiting on a person, and a trace of both.
Different Systems. Different Jobs
The right architecture depends on the work the system has to perform. None of these six is an upgrade on the one beside it, so the map starts in the middle, with the work.
AI Agents
A loop that decides what to do next, calls a declared tool, reads the result, and continues or stops. The engineering is almost entirely in the stopping: step limits, retries, what happens when a tool half-succeeds, and which actions are never taken without a person.
Fits whenRight when the task is repetitive, multi-step, and the steps vary by case.
- Step limits
- Tool contracts
- Partial failure
An Agent Is an Orchestrated System
Ten components sit between a language model and something you would put in front of a customer. Select any layer for the engineering that lives there, or watch one real task walk through all of them.
User Context
Identity, tenancy, entitlements, and the request itself. Everything below inherits this — a retrieval layer that ignores it will happily return a document the user could never open on their own.
- Identity
- Entitlements
- Tenancy
Reconcile this invoice against the purchase order and flag anything that does not match.
- 01Who is asking, for which supplier, and what they are entitled to see.
- 02The run opens with a budget: a step ceiling, a timeout, and a spend limit.
- 03Breaks the task down — fetch the order, fetch the invoice, compare lines, decide.
- 04Retrieves the purchase order and the agreed rates for this supplier.
- 05Recalls that this supplier's line descriptions never match word for word.
- 06The intended write is checked before the tool is called, not after it runs.
- 07Reads the invoice record. The adjustment it wanted to post is not on its allowlist.
- 08Replans against what it is actually permitted to do: it can flag, it cannot post.
- 09The variance goes to the person who owns it, with both documents attached.
- 10Every step above is now one trace — inputs, sources, calls, refusal, approval.
- 11The case joins the set the next prompt, model, or tool change is tested against.
Note the order. Reasoning is visited twice, the policy check happens before the tool call rather than after it, and the run ends at a person — not because the model was unsure, but because the action was consequential.
Autonomy Needs Boundaries
The more an agent can do, the more carefully its permissions, actions, escalation paths, and failure behaviour have to be designed. Three actions, one set of controls, three different outcomes, and the model behaves identically in all of them.
Draft a response to the supplier asking for the missing delivery note.
Thread SUP-1183 · 2 prior messages · no attachment on file
- 01PermissionsWhat it may access and executeCleared
Read scope covers this supplier thread, and only this one.
- 02Tool BoundariesActions limited to declared capabilitiesCleared
mail.draft is declared. It writes a draft; it has no ability to send.
- 03GuardrailsConstrained before anything reaches productionCleared
Output checked for content from other suppliers before it is offered.
- 04Human EscalationConsequential decisions routed to a personNot reached
Nothing consequential here — a draft nobody sends changes nothing.
- 05AuditabilityWhat happened, why, and what changedCleared
Logged with the messages it read and the draft it produced.
Draft written and waiting in the thread. The send button still belongs to a person.
- run.start · action=draft · budget ok
- tool.resolved · scope + credential attached
- action.executed · reversible · no approval required
Ground the Agent in What Your Organization Knows
Connect agents to relevant, permission-aware knowledge instead of expecting the model to know everything. Select a source for what actually has to cross the boundary.
Nothing crosses without the entitlements of whoever asked. A retrieval layer that forgets who is asking is the quickest way to hand someone a document they could never open directly.
Answers from what was retrieved — and says so plainly when nothing relevant was.
Contracts, specifications, and reports — plus the PDF nobody has opened since 2019. How they are chunked and structured decides whether any of it is retrievable at all.
The model is not expected to know your business. It is expected to work with what the retrieval layer is allowed to hand it, and to say when that is not enough.
Give Agents the Right Tools. Not Unlimited Access
Agents become useful when they can act in the systems where work actually happens. This is the same boundary as the section above, read in the other direction.
Every call is a typed contract with its own scope, its own credential, and its own ceiling. A tool the agent can reach is a capability somebody deliberately granted it.
Selects a tool, reads the result, and replans when the result is not what it expected.
A typed contract per operation, not blanket access to a service. The agent gets the endpoints the work needs and nothing adjacent to them.
Access is granted per action, never per system. The question is never whether an agent could call something — it is which specific calls anyone has decided it should be able to make.
An Agent Is Only as Good as Its Failure Behaviour
We evaluate agents against realistic tasks, edge cases, incorrect inputs, unavailable tools, and uncertain outcomes. Select a case to see which dimensions it exists to exercise.
Task Completion
3 / 6 casesWhether the run finished the job it was given, judged against a reviewed answer for that case.
Fails asA confident summary of work that was never actually done.
Tool Accuracy
1 / 6 casesWhether the right tool was called, with the right arguments, in the right order.
Fails asThe correct intention, executed against the wrong record.
Grounding
1 / 6 casesWhether the answer is supported by what was retrieved — and whether the right thing was retrieved at all.
Fails asA fluent answer with nothing behind it.
Hallucination Risk
1 / 6 casesHow often the system fills a gap instead of naming it.
Fails asAn invented reference number that looks exactly like a real one.
Latency
1 / 6 casesTime to a useful result, measured at the percentiles people actually feel.
Fails asA median that looks fine and a tail that does not.
Cost
1 / 6 casesSpend per completed task at realistic volume, including retries, retrieval, and replans.
Fails asUnit economics that only work at demo volume.
Escalation Quality
3 / 6 casesWhether the right decisions reach a person, with enough context attached to decide quickly.
Fails asEscalating everything, which is how an approval queue turns into a rubber stamp.
Failure Recovery
2 / 6 casesWhat the system does when a tool, a source, or a step fails halfway through.
Fails asA half-finished write, with no record that it was half-finished.
No percentages appear here on purpose. A number is only meaningful against one system, its own data, and an agreed answer set — anything published on a page like this would be a number we made up.
From Knowledge Work to Operations
Areas where this work typically lands, and the system shape each one tends to need. These are problem spaces we can engineer for, not client case studies.
- AI Agents
- AI Copilots
- Knowledge Systems
- Workflow Agents
- Research Agentsusually first
- Decision Support
ShapeWide, unstructured input that has to end in a comparable output, on a deadline.
Hard partProvenance. An analysis you cannot trace back to its sources is an opinion with citations attached.
Start With the Work. Then Choose the Autonomy
Eight steps, in this order. Choosing the pattern comes fourth on purpose. It is a conclusion drawn from the first three, not an opening position.
- 01
Map the workflow
Who does this today, what they open, what they check, and where the time actually goes.
- 02
Identify decisions
Separate the steps that are procedure from the ones carrying judgement and a consequence.
- 03
Define boundaries
What the system may see, what it may change, and what it must never be able to touch.
- 04
Choose the pattern
Agent, copilot, knowledge system — or none of them. Sometimes the answer is a form and a queue.
- 05
Connect knowledge and tools
Retrieval and tool contracts built and measured as their own components, not as prompt text.
- 06
Define human control
Where approval sits, who owns it, what evidence they get, and what happens if nobody answers.
- 07
Evaluate realistic tasks
Real cases, bad inputs, missing tools, and the edge cases that never show up in a demo.
- 08
Deploy and observe
Ship into the workflow with traces, cost, and escalation rates visible from the first day.
Questions Worth Asking
Where could an agent actually help?
Tell us about the workflow, the decision, or the operational bottleneck. We will work out whether an agent, a copilot, an automation, or something considerably simpler is the right answer.
Or see how this sits inside the wider practice in Applied AI.