What it is
A system that chooses its next step, inside limits you set.
The interesting property of an agent is that it selects its own sequence. That is what makes it useful, and it is the entire reason bounding it carefully is the work.
An agent is given a task, a set of tools it may call, data it may reach, and a boundary. It works out the steps. Where a workflow automation runs a path decided at build time, an agent decides the path at run time, which suits tasks whose shape varies between cases and suits nothing where the path is already known.
Because the sequence is not fixed in advance, three things have to be established explicitly: what the agent may do, where a person must intervene, and how anyone reconstructs what happened afterwards. Those three are the deliverable as much as the agent itself is.
01
The boundary
The tools it may call, the data it may reach and the actions it may take. Enforced by architecture rather than requested in an instruction.
02
The checkpoints
The decisions a person keeps. Irreversible or consequential actions are prepared by the agent and authorised by a human.
03
The audit trail
Every tool call, input and decision recorded, so that the sequence producing any output can be reconstructed.
04
The failure behaviour
What the agent does when a tool fails, when it cannot complete the task, or when it is uncertain — defined rather than emergent.
Fit
When an agent is the right shape, and when it is not.
Agents are frequently proposed for work that a simpler system would do more cheaply and more predictably. The distinction is whether the path varies.
Suited to
- Multi-step tasks where the sequence differs case by case.
- Work requiring several tools or data sources, chosen according to what is found.
- Processes with a natural human authorisation point already in them.
- Tasks where investigation matters more than throughput.
- Work where a full record of what was done has independent value.
Not suited to
- A fixed, known sequence. Use workflow automation — it is cheaper and more predictable.
- High-volume repetitive throughput where per-case reasoning is wasted cost.
- Actions that are irreversible and cannot have a human checkpoint.
- Environments where no audit trail may be retained.
- Any scope described as “let it handle everything”.
Deliverables
What you receive, and what it does not cover.
An engagement has obligations on both sides. Knowing yours is what makes a budget possible.
| Detail | |
|---|---|
| You supply | The task, the tools and data it must reach, and the decisions a person must keep. |
| We do | Agent architecture with defined autonomy and explicit human checkpoints, and bounded interfaces to each tool. |
| You receive | An agent operating within stated bounds, with an audit trail, and handover documentation covering how to adjust the bounds. |
| Not covered | No autonomous action outside the agreed scope, by design. Not a general assistant, and not ownership of your source systems. |
Autonomy
Autonomy is set per action, not per agent.
Treating autonomy as a single dial is the mistake that makes agents unpredictable. It is decided action by action during scoping.
| Level | The agent may | Typical use |
|---|---|---|
| Read only | Retrieve and interpret. It cannot change anything in any system. | Investigation, triage, drafting a recommendation for a person. |
| Prepare | Compose an action — a record, a message, a change — and present it for authorisation. | Anything consequential or irreversible. The default for write actions. |
| Act within bounds | Execute directly, but only inside limits agreed in advance and enforced by the interface. | Reversible, low-consequence, high-volume actions where a checkpoint would defeat the point. |
| Escalate | Stop and hand the case to a named person with the context gathered so far. | Uncertainty, tool failure, or any case falling outside the agreed boundary. |
Worked pattern
An agent on a multi-step internal task.
An illustrative pattern generic to the task class, not an account of a client engagement.
A support request arrives that could relate to billing, provisioning or a known fault. Resolving it requires checking several systems, and which systems depends on what the earlier checks return — the reason a fixed sequence does not fit.
The agent reads the request, queries the account system, and depending on what it finds either checks the provisioning state or searches the fault register. It may call each of those tools because each has been granted explicitly; it cannot call anything else, and an attempt to do so is a boundary violation that stops the run rather than a request that quietly fails.
It composes a resolution and stops. Sending the response to the customer is a prepare-level action, so a person reads the draft, the evidence gathered and the reasoning, and authorises or edits it. Updating an internal triage tag is act-within-bounds, because it is reversible and consequential to nobody outside the team.
When the fault register is unreachable, the agent escalates rather than answering without it. The audit trail records the attempted call, the failure, and the escalation — which is how anyone later establishes that the gap was infrastructural rather than a reasoning error.
Failure modes
How agents fail.
Agent failures differ from automation failures: they are usually failures of scope or reconstruction rather than accuracy.
| Failure mode | What happens | Mitigation |
|---|---|---|
| Scope creep at run time | The agent finds a way to accomplish the task using something it was never meant to touch. | Tool access granted explicitly and enforced at the interface. Anything ungranted is unreachable, not merely discouraged. |
| Plausible reasoning, wrong result | The chain of steps reads convincingly and the conclusion is incorrect. | Checkpoints on consequential actions, and an audit trail that lets the sequence be checked rather than trusted. |
| Checkpoint fatigue | So many actions require authorisation that people approve them without reading, which is worse than no checkpoint. | Autonomy assigned per action during scoping, so reversible low-consequence steps do not consume attention. |
| Silent tool failure | A tool returns nothing and the agent proceeds as though the result were empty rather than unavailable. | Failed calls surface and escalate. The distinction between empty and unavailable is explicit at every interface. |
| Unreconstructable outcome | Something went wrong and nobody can establish what the agent did or why. | The audit trail is an acceptance condition, tested before deployment rather than added after an incident. |
Control
Where an agent runs, and what it retains.
An agent reaches further into your systems than most AI components, which raises the deployment and retention questions earlier.
Because an agent holds credentials for the tools it may call, where it runs and what it retains are scoping decisions rather than deployment details. Agents can run inside your boundary, on dedicated capacity, or in a hosted environment, and the audit trail can be retained under your control regardless of where the agent itself executes.
Deployment and ownership covers the options. The capability register states the maturity and boundary of the underlying engineering.
KyperX AI is an Australian company and works with organisations internationally. Engagements run remotely, with agreed overlap hours and a named point of contact on both sides.
Questions
Common questions about AI agents.
What organisations ask before scoping agent work.
What is an AI agent?
A system that carries out a multi-step task by using tools and data rather than answering a single question. It decides which step to take next within limits set in advance, and stops at defined checkpoints where a person must decide.
How is an AI agent different from workflow automation?
Workflow automation runs a known sequence. An agent selects the sequence at run time, which is what makes it useful for tasks whose path varies, and what makes bounding it the central engineering problem. Where the path is fixed and known, automation is the better answer and costs less to run.
How much autonomy does the agent have?
Exactly as much as is agreed and no more. The scope of tools it may call, the data it may reach and the actions it may take are defined before deployment. Autonomous action outside the agreed scope is prevented by design rather than discouraged by instruction.
How do we know what the agent actually did?
Every tool call, input and decision is recorded in an audit trail. For any output, the sequence that produced it can be reconstructed. This is a deliverable, not a debugging aid.
What stops an agent from taking an irreversible action?
Irreversible actions are placed behind human checkpoints as a matter of architecture. The agent prepares the action and a person authorises it. Which actions qualify is decided with you during scoping, not by the agent at run time.
Can an agent work with our internal systems?
Through bounded interfaces, with the same acceptance checks used elsewhere: the agent reaches only the tools and data it has been granted, and a failed call surfaces rather than being retried silently.
Related
Where this connects.
Agent work almost always sits alongside automation and integration rather than replacing them.
- Workflow automationThe better answer wherever the sequence is fixed and known in advance.
- Custom AI systemsWhere the agent needs an interface and an application built around it.
- AI consulting and assessmentTo establish whether the task genuinely varies enough to warrant an agent.
- How an engagement worksAssessment, pilot, deployment, handover and optional managed operation.
Describe the task.
What the agent would need to reach, and which decisions must stay with a person.