What "agentic AI" means, and what it doesn't.

"Agentic" has become the word every vendor attaches to every product. Underneath the noise is a real and important shift in what software can do. This guide explains it without the hype, so you can judge where it belongs in your organization.

Three generations of business software

It helps to see agents as the third step in a progression.

1. Automation follows rules you write in advance. If an invoice is over a threshold, route it for approval. Reliable, rigid, and blind to anything the rules didn't anticipate.
2. Assistants and chatbots understand language and generate responses. They answer questions and draft content, but they stop at the edge of the conversation. A person still has to go do the thing.
3. Agents combine both. They understand a goal, make a plan, use tools to gather information and take actions across your systems, check their own results, and hand off to a person when they should.

An assistant tells you the vendor's invoice doesn't match the purchase order. An agent finds the mismatch, checks the receiving record, drafts the dispute, and asks you to approve sending it.

The four capabilities that make something an agent

1. Reasoning over a goal

You give the agent an outcome, not a script. "Process this week's vendor invoices" rather than a flowchart of every step. The model breaks the goal into steps and adapts when a document is unusual.

2. Tool use

The agent can call your systems: query the warehouse, read a ticket, create a record, send a message. This is what separates agents from chat. Increasingly these connections are standardized through the Model Context Protocol, which gives every agent one governed way to reach your tools.

3. Memory and context

Agents carry context across steps and, when designed to, across sessions. They remember what they've already checked, what the policy says, and what happened last time a similar case came through.

4. Self-checking and hand-off

Good agents verify their own work against sources and rules, and they know when to stop and ask a human. This is not optional. It's the difference between a system you can trust and one you have to babysit.

Where agents create value today

The pattern that works is consistent: high volume, moderate complexity, clear rules for what "correct" means, and a person who owns the process today. Concretely:

• Document-heavy workflows. Invoices, applications, permits, contracts, claims. Reading, extracting, validating, routing.
• Tier-one support. Internal IT and HR requests, customer questions with answers in your knowledge base.
• Data questions. "How did region three do last quarter versus plan?" answered from governed data with the query shown.
• Back-office coordination. Onboarding, reconciliation, compliance checks, reporting that touches several systems.
• Engineering toil. Test generation, code review, incident triage, legacy documentation.

Where agents don't belong yet

Honesty here saves money. We steer clients away from agents when:

• The cost of a wrong action is severe and irreversible, and there is no practical approval step.
• The underlying data is unreliable. An agent will confidently act on bad data. Fix the data foundation first.
• The process is truly deterministic. Plain automation is cheaper and more predictable. Use the model only where judgment is needed.
• Nobody owns the outcome. Agents need a business owner who defines success and reviews exceptions.

What "production-ready" actually requires

A demo needs a prompt and a model. A production agent needs an evaluation set built from your real cases, so accuracy is a measured number rather than an impression. It needs scoped permissions, so it can only do what it should. It needs an audit log, so every action can be explained. It needs monitoring for cost, latency, and drift. And it needs an owner and a runbook, so when something changes, someone knows.

None of this is exotic. It's the same engineering discipline that makes any system trustworthy, applied to a new kind of component. It is also the part most pilots skip, which is why so many stall.

How to start

Pick one process using the test above. Assemble twenty to fifty real examples with known correct outcomes. Build the smallest agent that handles them, measure it, and put a person in the approval seat. In four to six weeks you will know whether it works, what it costs to run, and what it would take to scale. That is the whole point of a pilot: a decision backed by evidence.

If you'd like help scoring candidates, our two-week AI Readiness Sprint exists for exactly that.