Most software waits to be told. An agent is given a job, works out the steps, and carries them out, reading a document, checking it against your data, updating a system, escalating when it is unsure. The value is not the model; it is the job it takes off a person.
That also makes it a different kind of risk. An agent acts, so the questions worth asking are about boundaries: what it may touch, what it must escalate, and how you would know if it were quietly getting things wrong.
None of these are about the model. They are the conditions that decide whether an agent is safe to let near real work.
A defined task with a start, a finish and a definition of done. An agent given a vague remit produces vague work, and nobody can tell whether it went well.
The decisions a person makes doing this job, stated explicitly. Where the rules live only in someone's head, writing them down is the project, and it usually improves the process before any software exists.
What it may read, what it may change, and what it must never touch. Permissions that match the job, not the convenience of whoever set it up.
A queue for the cases it should not decide, with the context a person needs to decide quickly. An agent that never escalates is not careful, it is overconfident.
Every action logged in a form someone can audit. When a customer asks why something happened, the answer cannot be that the system decided.
Sampled and compared against what a good result looks like, the same way you would review a new starter. Quality drifts quietly otherwise, and the drift is only visible if you are looking.
Rules first. If the task follows steps you can write down, rule-based automation does it more cheaply, more predictably and with less to go wrong. Reaching for an agent to run a fixed process is paying for judgement you do not need. An agent earns its place where the work needs reading and deciding, an email that could be one of six requests, a document that has to be checked against your data, a case where the right next step depends on what was found. That is judgement, and rules handle it badly.
A person keeps the parts where being wrong is expensive or irreversible. The design we recommend is an agent doing the routine majority end to end, with a clear line where it stops and hands over, and the escalation rate watched as a health measure, not treated as a failure. Most real deployments are all three: rules for the predictable, an agent for the judgement, a person for the consequential. The value comes from putting each in the right place rather than from choosing one.
It starts with a Rapid Insight Workshop at a fixed $9,000 + GST. We look at where the judgement work sits, what it costs you in hours, and which of it is defined well enough to hand over. A good share of what people arrive wanting to automate is not ready, and finding that out for $9,000 is the cheap version.
The build is rarely the expensive part, and model costs are small at business volumes and falling. What takes the effort is access to your data in a form the agent can use reliably, the evaluation setup that tells you whether it is doing the job well, and the boundaries around what it may act on. Running costs are real and ongoing: usage, monitoring, and the review time that keeps quality honest. An agent nobody reviews degrades quietly as your business changes around it, a slower and more expensive failure than one that stops.
A first agent runs fixed-price as an Amplify project. Where agents are being introduced across several processes, it runs as an Apex partnership. The review and tuning cycle is continuous by nature, not a phase that ends.
One task, defined properly, with the decisions a person makes on it written down and agreed. This is where most of the value is, and where projects that skip it come unstuck later.
The agent does the work and a person checks it, on real cases, with the disagreements recorded. That comparison is the evaluation set, and it is the only honest measure of whether it is ready.
Once the agreement rate holds, the agent takes the routine cases end to end and the exceptions keep going to people. The escalation rate stays on a dashboard someone actually looks at.
We map how your business really runs — systems, costs, friction — and return a prioritised roadmap with a business case. $9,000 + GST, fixed.
AI agents that own a job end to end — invoicing, compliance checks, recurring reporting — and only come back to you for the exceptions.
A chatbot answers. An agent acts: it reads, decides, and changes something in a system. That distinction matters because acting carries consequences a conversation does not, so an agent needs boundaries, logging, and a defined escalation path before it goes anywhere near live work.
Anywhere the cost of a wrong action is higher than the cost of a person doing it. Irreversible decisions, anything with a legal or safety consequence, and any process nobody has written down yet. If the rules only exist in someone's head, the first job is writing them down, not automating them.
The same way you would judge a person doing the job: sample the output, compare against what a good result looks like, and watch the rate of escalations. An agent that never escalates is usually not being careful, it is being confident, which is a different thing.
Access to the information the job depends on, in a form it can read reliably, with permissions that match what the agent is allowed to do. Most agent projects that stall are stalled on data access and process definition, not on the model.
Rules follow a path you defined and cannot handle a case you did not anticipate. An agent works out the steps for the job it was given, which is what you want when the input varies and what you do not want when it does not. Use rules for the predictable majority and an agent for the judgement, most real processes need both.
Model usage is small at business volumes. The ongoing costs that matter are monitoring, the review time to keep quality honest, and the changes needed as your process moves. Budget for those from the start, an agent nobody reviews degrades quietly, and that failure is harder to spot than an outage.