The short answer
An agentic app is business software that can be given a job rather than operated step by step. You describe an outcome in ordinary language, the application works out which records the answer depends on, gathers them, applies the business rules, uses reasoning for the parts that genuinely vary, and returns a result you can check. Where the job would change something consequential, it prepares the action and asks.
That definition deliberately says nothing about chat. A chat box is one possible interface, and often not the best one. The agentic part is what happens behind it: the application holds a responsibility, has the means to carry it across several systems, and operates inside limits that the business has set in code rather than in a prompt.
The clearest way to tell whether something is agentic is to look at what a user has to know. In conventional software, the user has to know the process: which screen, which filter, which export, in which order. In an agentic application, the user has to know the outcome they want. The software owns the route.
A concrete example, because the abstract version is useless
Take a self-storage operator with four sites. Every Monday somebody exports the customer list, exports the invoices from the accounting package, downloads the bank feed and spends an hour in a spreadsheet working out who has paid, who has not, and who paid the wrong amount. The answer matters, the work is dull, and only two people in the business can do it.
None of that is a data problem. Every figure already exists in a system the operator pays for. It is a coordination problem: the answer lives in four places and only a person currently holds them together, along with the untidy knowledge that unit 27 pays the old rate because the standing order was never updated after an upgrade.
An agentic application answers the same question directly. It reads the agreements, invoices, payments and credits, applies the operator definition of overdue, matches money to obligations, and returns a list where every line carries the reason it appears. Bay 27 is short by eighteen pounds and will be short again next month, because the standing order still pays a pre-upgrade rate. Bay 40 has a payment that arrived without a reference and cannot be matched with confidence, so it is presented rather than allocated. Bay 63 is behind, but on a plan agreed a fortnight ago, so it should not be chased.
That last distinction is the whole point. The arithmetic was never hard. Knowing which of six overdue accounts should actually be contacted is the part that kept the job manual.
Four things that have to be true
A useful agentic application needs four properties. Software missing any of them is something else, which is fine, but it should be called what it is.
- A bounded responsibility. Not “an AI assistant for the business” but one job with a recognisable owner, a definition of done and a way to tell whether it was carried out well.
- Context it can assemble itself. The application decides which records the job depends on and reads them through typed capabilities, under the permissions of the person asking, rather than relying on whatever was pasted into a box.
- Bounded means of action. Named, typed operations with their own authorisation, rather than broad credentials. What the application cannot do should be a property of its tools, not of its instructions.
- A control boundary proportionate to consequence. Reading is cheap. Sending a message to a customer, moving money or changing a contract is not, and each needs the approval the business would demand of a member of staff.
What an agentic app is not
It is not a chatbot with your documents behind it. Retrieval over a knowledge base can explain your notice period; it cannot tell a customer whether they are inside it, because that requires reading their agreement under their identity. The engineering difference is identity, scope and typed tools, and it is most of the work.
It is not automation with better marketing. Automation is the right answer whenever the trigger, the rule and the next step are all predictable, and it is cheaper, faster and easier to test than anything involving a model. A well-built agentic application contains a great deal of ordinary automation and reaches for inference only where the right answer genuinely changes with the situation.
It is not autonomy. Autonomy is not a feature you switch on, it is the sum of the scope, the tools and the approvals the application has been given. A system that drafts every overdue payment message and sends none of them is fully agentic and entirely supervised, and that is usually the correct first release.
It is also not a replacement for your systems of record. The ledger still holds the balance. The CRM still holds the customer. The agentic application coordinates across them and is accountable for the coordination, not for the truth.
Where the difficulty actually is
Teams new to this expect the model to be the hard part. It rarely is. The difficulty is in four unglamorous places, and a proposal that does not address them is not a plan.
The first is context assembly: deciding what the application should read for this job, for this person, and reading it under their permissions rather than through a service account with access to everything. The second is the boundary between rules and judgement, which has to be drawn explicitly, because anything left ambiguous will end up in the model by default and become untestable.
The third is evidence. An answer without provenance is a rumour with good grammar. Every line an agentic application produces should link back to the record that produced it, both so a person can check it in seconds and so a wrong answer can be traced to a cause rather than blamed on the model.
The fourth is what happens when it is wrong, because it will be. What does a bad answer cost, who notices, how quickly, and what undoes it? A system whose worst realistic failure is a slightly odd summary can be released early. A system whose worst realistic failure is an inappropriate letter to a customer in arrears needs approval before anything leaves the building.
How to judge whether a job is a good candidate
The best first candidates share a shape. The work crosses systems, happens repeatedly, currently depends on one or two people, and produces something a person reviews rather than something that fires straight into the world.
- Somebody does it manually every week, and it takes long enough to be worth naming.
- The answer needs at least three systems, or one system plus knowledge held in a person head.
- Getting it wrong is visible and recoverable, rather than silent and expensive.
- A person can tell within a minute whether the output is right.
- There is a clear owner who cares about the outcome and can judge the quality.
A reasonable first release
Narrow, read-only, and useful enough that somebody would notice if it disappeared. One site, one period, one question, with citations from the first day. Run it alongside the existing manual process and compare the two until they agree, then keep comparing on a sample.
Only after that should authority expand, and it should expand one capability at a time, each with its own evidence. Drafting before sending. Proposing before allocating. Reversible actions long before irreversible ones. The pattern is deliberately conservative because the cost of an early mistake is not the mistake, it is that nobody in the business trusts the system afterwards.
If a supplier proposes the opposite order, starting broad and adding controls later, that is worth questioning. Controls added after a system is in use tend to be the controls that were convenient to build rather than the ones the business needed.
The honest summary
An agentic app is not a new category of magic. It is business software with an inference loop inside it, built by people who were careful about which parts of the job genuinely need reasoning and which parts must stay in code that can be tested. When that separation is done well, the result is unremarkable to use and quietly removes a job that used to take somebody an hour every Monday.
When it is done badly, the result is a confident answer nobody can check, produced by a system with more access than anyone intended. The difference is entirely in the engineering, which is why the first question worth asking about any agentic application is not what model it uses, but what it is not permitted to do.