Agentic AI, explained.

Agentic AI

Software that pursues a goal rather than following a script: it decides its own next step, uses tools to act on real systems, and escalates to a person when it is unsure.

Agent vs workflow

A workflow follows a path someone drew in advance; an agent is handed the outcome and works out the route itself.

Where autonomy belongs

Reading, matching, drafting and routing. Consequential actions stay behind human approval gates, with an audit trail behind every run.

What ASCENTI builds

Agent teams and workflow automation designed around a business's existing systems, built by an Australian AI consultancy based in Helensvale on the Gold Coast.

Typical timeline

Discovery in days to a couple of weeks; where a build follows, commonly four to twelve weeks to production depending on scope and the systems it touches.

The word 'agent' has been applied to enough different things in the last two years to lose most of its meaning. Here is the definition worth holding: an AI agent is a system given a goal, a set of tools it may use, and permission to decide for itself which tool to reach for next, repeatedly, until it has finished or hit a boundary.

That is the whole distinction. A chatbot produces text. A workflow follows a path someone drew in advance. An agent is handed an outcome and works out the route.

Consider a supplier invoice arriving that does not match its purchase order. A workflow routes it to an exceptions queue, because that was the path drawn for it. An agent can pull the original PO, check the delivery docket, find the partial delivery that explains the variance, check whether your policy tolerates that variance, and either resolve it or escalate with the explanation already written. Nobody drew that path in advance; it worked it out from the specifics.

The goal

What 'done' means, stated precisely enough to be checkable. Vague goals produce agents that stop too early, run too long, or optimise for something nobody wanted.

Tools

The specific scoped actions the agent may take: read this mailbox, query this table, draft this record, send this notification. Not system access. Each tool is a defined door with its own lock.

Memory

What the agent carries between steps and between runs. Also, and just as importantly, what it must forget: an agent that retains one client's details into another client's task is a privacy incident waiting for its moment.

Guardrails

The boundaries it cannot cross. Spend limits, data it may not read, actions that require sign-off, conditions that force an escalation. Enforced in code, outside the model, never asked for politely in a prompt.

Evaluation

A test set of real cases with known-good outcomes, run whenever the agent, the prompt or the underlying model changes. This is the difference between a system you can maintain and one you can only hope about.

Notice that only one of these is the AI. When a vendor says 'we use agents', the useful follow-up questions are all about the other four: which tools, what boundaries, what memory, and how do you know it still works.

The instinct is to build one capable agent that handles everything. It degrades in a predictable way. Its instructions grow with every capability added. Its context fills with material irrelevant to the task at hand. Its tool list becomes broad enough that a mistake can reach anything. And its behaviour becomes progressively harder to reason about, right at the point where you most need to.

So agentic systems are structured the way a business structures a function: a coordinator and a set of specialists with narrow remits and narrow permissions.

The structure is not organisational theatre. Narrow scope makes each agent more accurate and cheaper to run, and it means a failure localises to one specialist rather than to one enormous prompt nobody can debug. Separating the agents that can act from the agents that can only read is the single most useful security decision in an agentic design.

The public debate treats autonomy as a philosophical position. In a real system it is a setting, chosen per action, on evidence.

The level can differ per action inside a single agent. Drafting a routine reply might run unsupervised while issuing a credit note always stops at a gate. Deciding which actions sit where is a business decision, and it should be made by the person who carries the consequence of getting it wrong.

Agentic systems fail in characteristic ways. None of them are mysterious, and all of them have known mitigations, but only if the mitigation is designed in rather than added after the incident.

Prompt injection deserves particular attention because it is specific to this class of system and widely underestimated. If an agent reads an incoming email and that email contains text instructing it to forward the mailbox contents, a naively built agent may comply. It cannot reliably distinguish your instructions from instructions embedded in data it was asked to read. The defence is architectural: content the agent reads is never treated as instruction, and any action with consequence passes a gate that does not.

1. 01What exactly can it do to our systems, and what can it not? A vendor who cannot list the tools has not scoped them.
2. 02What happens when it is unsure? 'It is very accurate' is not an answer. 'Below this threshold it stops and escalates with context' is.
3. 03Show me the log of a real run. Production systems have structured logs. Demonstrations have a chat transcript.
4. 04How do you know it still works after a model update? If the answer is not an evaluation suite, the answer is that they find out from you.
5. 05Which actions require human approval, and who configured that? If the vendor chose, rather than the client, the design has the wrong person carrying the risk.
6. 06What does one run cost? A team that has not measured this has not run it at volume.

None of these questions require technical knowledge to ask, and the quality of the answers is usually obvious within a minute. A team that has shipped one of these will answer all six comfortably. A team that has only demonstrated one will reach for adjectives.

Not with the most impressive process. Start with one that has three properties: it happens often enough that a saving compounds, it currently consumes senior time on work that is not senior, and getting it wrong is recoverable.

That last one is the constraint people resist and should not. The first agentic system in a business is also the mechanism by which the organisation learns what these systems do well and badly. That education is much cheaper on a process where an error means a rework than one where it means a regulatory breach.

Once one is running, the second is dramatically easier. The integration work is done, the governance conversation has happened, and the team has a real sense of where the gates belong.