Agentic AI, Explained Without the Hype

Last Updated on September 13, 2026 by Elizabeth Sramek

You have a proposal on your desk to replace a working workflow with an agent. The deck says autonomous, self-healing and adaptive. It does not say what happens when the model calls your CRM API four hundred times in one run, or how an auditor traces which decision changed a deal stage.

Most explainers of agentic AI stop at the definition and then gesture at the future. This one is written to be used in a build-or-buy meeting. It gives you an operational definition, a capability ladder so you can tell where a proposed system actually sits, the architectural line between what the model decides and what your code executes, the arithmetic that makes agent costs behave differently from workflow costs, and a readiness checklist you can fail a proposal against.

The position here is not that agents are hype. It is that agentic AI is a real architectural shift with a narrow current competence band, and that most teams should be deploying something one rung below what they are being sold.

What agentic AI actually means in operational terms

Agentic AI describes a system where a language model selects its own next action from a set of available tools, observes the result, and decides whether to continue or stop, with the authority to change state in systems outside itself. Four properties have to be present together: a goal rather than an instruction, a tool interface, a loop, and write authority.

Strip any one of those and you have something else with a different risk profile. A chatbot has a loop and a goal but no tools and no write authority, so its worst failure is a wrong sentence. A prompt chain has tools and write authority but the control flow is yours: step two always follows step one, and you can draw it on a whiteboard. A plain workflow has no model in the decision path at all.

The distinction that matters operationally is who decides what happens next. In a workflow, a human wrote the branch conditions and they are visible in version control. In an agent, the branch conditions are produced at runtime by a stochastic process, and the same input can produce a different trajectory on Tuesday than it did on Monday. That is not a bug to be patched out. It is the property you are buying, and the entire discipline of running agents in production is about bounding it.

The capability ladder: five rungs and why you want a lower one

There are five distinct architectures commonly sold under one label, and they differ in what decides control flow, how they fail, how you test them, and what they cost. Placing a proposal on this ladder is the fastest way to find out whether the complexity is being bought for a reason.

Rung	What decides control flow	How failure presents	How you test it	Cost profile
1. Single prompt	Nothing. One call in, one response out.	Wrong or badly formatted output, immediately visible.	Golden input and output pairs. Ordinary assertions.	Fixed per call. Predictable to the cent.
2. Prompt chain	You do. The sequence is hard coded.	A specific step degrades; the rest still runs. Errors localise.	Per step, plus an end to end case set.	Fixed multiple of rung 1. Still predictable.
3. Tool-using model	Mostly you. The model picks arguments, not sequence.	Bad arguments to a real API. Half-valid calls that get accepted.	Schema validation plus argument-level fixtures.	Fixed plus tool cost. Bounded by call count.
4. Agent with a planning loop	The model, per iteration, until a stop condition.	Loops, drift, silent partial completion reported as success.	Trajectory replay against a regression set of real tasks.	Superlinear in iterations. Context grows every turn.
5. Multi-agent system	Multiple models plus an orchestration policy.	Cascade. One agent’s bad output becomes another’s trusted input.	Hard. Failures are emergent and poorly reproducible.	Multiplies rung 4 by the number of participants.

Rungs one to three fail in ways your on-call process already handles. Rungs four and five need new tooling, new logging and new humans watching. If a task has a knowable sequence, encoding it yourself buys determinism for free. Teams reach for rung four because the demo is better, then discover the operating cost is not in the token bill.

Rung five deserves particular suspicion. Our CrewAI reality check covers what breaks when agents hand work to one another in client production: multi-agent frameworks are good for exploration and a poor fit for anything with an SLA attached.

Anatomy of an agent: loop, tools, memory, stopping condition

An agent has four moving parts. Knowing them is what lets you review a design rather than a demo.

The loop

The loop is goal, plan, tool call, observation, revise, repeat. The model gets a goal and the current context, emits a proposed action, your runtime executes it, the result is appended to context, and the model is called again with more than it had before. Every iteration makes the input longer, which is the single most important fact about agent economics.

The tool interface

Tools are function definitions the model can request. Be precise about what it does: in OpenAI’s framing of function calling the model executes nothing. It returns a request, your application runs it, you return the result. The same guide advises keeping fewer than twenty functions available at the start of a turn and using enums so invalid states cannot be represented. Tool selection accuracy degrades as the menu grows, and a wide tool surface is a wide attack surface.

Memory, working and persistent

Working memory is the context window for a single run: bounded and disposable. Persistent memory is anything the agent writes that survives the run, such as a vector store, a summary table or a scratchpad the next run reads. It is where designs go wrong, because it turns a stateless component into a stateful one without the discipline you would apply to a database.

Two failure shapes follow. Poisoning: a wrong conclusion is written once, then retrieved as fact by every later run, so one bad trajectory becomes permanent bias. Unbounded growth: retrieval quality falls as the store fills with near-duplicate summaries. Ask who can write to it, what the retention policy is, and how you delete a poisoned entry. No answer means the design is not finished.

The stopping condition

The stopping condition decides when the loop ends, and a weak one is the most common cause of a runaway cost incident. Three kinds exist and you want all three: a semantic stop, which is the model declaring the goal met and the one you cannot trust alone; a hard iteration cap your runtime enforces; and a per-run budget ceiling that aborts regardless of state.

Good tooling ships a cap. n8n’s Tools Agent node exposes a Max Iterations option that, per the n8n documentation, defaults to 10. Ten is reasonable for a triage agent and far too high for a classifier that should finish in two. Set it to the steps the task needs plus a small margin, then alert on runs that hit it, because hitting the cap means the task shape changed. Our n8n LangChain agents tutorial shows the node configuration in context.

Where the determinism boundary belongs

The boundary belongs exactly here: the agent decides, deterministic code executes. The model’s output is a proposal expressed in a constrained vocabulary you defined; validated code owns every side effect. Get this line right and most of the rest is tractable. Get it wrong and no amount of prompt engineering recovers the system.

The anti-pattern is letting the model construct arbitrary calls: SQL you run, a URL and body you forward, shell commands, or free text that becomes a database value. Each hands the model an unbounded action space. Unbounded means untestable, because you cannot enumerate what it might do, and unauditable, because there is no fixed set of things it was allowed to try.

The pattern is a closed action set. The model picks one action from an enum and supplies parameters that a schema constrains. Your executor validates, checks authority, and calls a whitelisted function.

{
  "name": "crm_action",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "action": {
        "type": "string",
        "enum": ["assign_owner", "set_stage", "add_note", "escalate_to_human"]
      },
      "record_id":  { "type": "string", "pattern": "^[0-9]{6,12}$" },
      "value":      { "type": "string", "maxLength": 400 },
      "confidence": { "type": "number" }
    },
    "required": ["action", "record_id", "value", "confidence"],
    "additionalProperties": false
  }
}

# executor: the only place a side effect can happen
proposal = validate_schema(model_output)        # reject, do not repair
require(proposal.action in ALLOWED_FOR[run.role])
require(record_belongs_to(proposal.record_id, run.tenant_id))

if proposal.confidence < 0.70:
    queue_for_human(proposal); return

dispatch = {
    "assign_owner": crm.assign_owner,
    "set_stage":    crm.set_stage,          # value mapped through a fixed enum
    "add_note":     crm.add_note,
}
dispatch[proposal.action](proposal.record_id, proposal.value)
audit.write(run.id, step_index, proposal, actor="agent")

Three things fall out of this. Schema adherence is enforceable: OpenAI’s strict mode requires the model to follow the exact schema without deviation, and the same discipline applies to any provider, which is the subject of our guide to forcing strict JSON out of a model API. Authority is separable, so the agent inherits the run’s role rather than your admin token. And the audit trail is complete, because every state change went through one function that wrote a record.

Constraining the action space is what makes an agent auditable. When someone asks six months from now why deal 448201 moved to closed-lost, you can answer, because the answer is a row: this run, this step, this action from a set of four, this input, this confidence.

What agentic systems are genuinely good at today

Agents are good at tasks where the input is ambiguous, the output space is small, and a wrong turn is cheap to reverse. That combination is narrower than the marketing suggests and wider than the sceptics allow, and it covers real B2B work.

• Triage and routing under ambiguity. Inbound tickets, RFPs, vendor email. Rules handle the clean cases and fall apart on the messy ones. An agent that reads the thread, checks a system of record and picks one of six queues beats a regex tree, and a misroute costs one reassignment.
• Extraction from unstructured input. Contracts, invoices, scanned forms where the same field sits somewhere different every time. The loop earns its keep when extraction needs a lookup: read the vendor name, query the vendor table, resolve the ambiguity, extract the rest.
• Drafting for human review. Replies, summaries, first-pass documentation. The reviewer is the control, so the agent needs no external write authority at all.
• Multi-step research where a wrong turn is cheap. Enrichment, competitive scans, context-gathering before a call. A dead end costs tokens and seconds, nothing else.

They are bad at four things, structurally rather than a version away from fixed. Exact repeatability, because the same input can produce a different trajectory. Expensive-to-reverse actions: refunds, external communications, deletions. Anything an auditor must follow step by step, unless you built the constrained action set above. And high-volume, low-margin unit economics, where a deterministic parser costs a fraction as much per item and is right more often.

Which architecture for which task shape

Pick the architecture from the task’s characteristics, not the technology you want to use. Four shapes cover most B2B automation work, and only two want an agent.

Task characteristics	Right architecture	Why	The failure you avoid
Structured input, known rules, fixed sequence, high volume	Plain workflow, no model	The logic is knowable and cheap to express. Determinism is free.	Paying per token for a decision an if statement makes correctly every time.
Fixed sequence but one step needs judgement or unstructured parsing	Workflow with a single constrained LLM step	You keep the control flow and buy only the classification or extraction.	Non-reproducible control flow. The blast radius stays inside one step.
Number and order of steps depend on what earlier steps reveal, reversal is cheap	Agent with a planning loop, closed action set, hard caps	The sequence genuinely cannot be enumerated in advance.	A brittle decision tree that breaks on every input variant nobody predicted.
Any of the above where an action is expensive to reverse	Agent proposes, human approves, code executes	The control sits on the irreversible step, not the whole run.	An autonomous refund, a sent email, a deleted record with no undo.

Cost and latency scale with iterations, not tasks

Agent cost scales with loop iterations rather than task count, and because each iteration carries the whole conversation forward, the growth is superlinear in steps. A budgeting model built on cost per task will be wrong in the direction that hurts.

Worked example. Assumptions, all stated: Claude Sonnet 5 at 2 dollars per million input tokens and 10 dollars per million output tokens, per Anthropic’s published pricing. System prompt plus tool schemas plus the initial task is 4,000 input tokens. Each iteration appends roughly 1,500 tokens of tool observation. The model emits about 300 output tokens per step. No prompt caching, no batch discount. This is arithmetic on stated assumptions, not a measurement.

Trajectory	Total input tokens	Total output tokens	Cost per run	Cost at 10,000 runs per month
3 iterations	17,400	900	0.044 USD	440 USD
12 iterations	166,800	3,600	0.370 USD	3,700 USD

Four times the iterations produces about eight and a half times the cost, because input tokens are re-sent and grow every turn. Now add the tail. If 90 percent of runs finish in 3 steps and 10 percent run to 12, the blended cost per run is about 0.076 dollars, which is 1.7 times the happy-path figure. A retry loop that pushes a small fraction of runs to the ceiling is a budget incident that will not show up in your average until the invoice does.

Three controls cap it. Set the iteration limit to task shape plus margin and alert when runs hit it. Enforce a per-run token ceiling in the runtime rather than the prompt, because a model cannot be relied on to count its own spend. And route cheap steps to cheap models: classification, tool selection and formatting rarely need your frontier model. Once you have a per-run figure, our automation ROI calculator is where it belongs.

Latency follows the same curve: twelve steps is twelve sequential round trips, each slower than the last because the context is longer. Anything user-facing needs a hard latency budget and a fallback path.

How to evaluate and observe an agent

Unit tests alone do not work on agents because there is no single correct trajectory to assert against. Two runs can take different paths, use different tools and both be right. You test outcomes and constraints, not the sequence.

Build a regression set of real tasks with expected outcomes. Pull 50 to 200 historical inputs, label the correct end state for each, and score every candidate prompt, model or tool change against the whole set before it ships. Score three things separately: right outcome, stayed inside the action set and authority limits, iterations taken. A change that adds two points of accuracy and doubles median iterations is a cost regression wearing a quality badge.

Log every step of the trajectory, not just the final answer: run ID, step index, model and version, the prompt or a stable hash of it, the proposed action, the validation result, the tool called with arguments, the observation, tokens in and out, latency, and the stop reason. The stop reason is the field teams forget and the one that tells you whether a run completed or was cut off. OpenTelemetry maintains a GenAI semantic conventions repository, and standard attribute names are worth the small upfront cost.

Treat human-in-the-loop as a design element, not an admission of failure. An approval gate on the one irreversible action in a run is not a phase you graduate from. It is the correct permanent architecture when reversal cost is high, and it is what OWASP recommends for privileged operations. Design the queue properly: batched, with the agent’s reasoning attached, and the reviewer’s decision captured as a labelled example that feeds the regression set.

Failure modes that put agents in the incident channel

Agent failures differ from workflow failures because most do not raise an error. The system reports success and the damage surfaces later, which is why the general automation failure modes playbook needs an agent-specific supplement.

Failure mode	What it looks like	Control
Near-infinite loop	The agent alternates between two tools, each result convincing it to try the other. No error is thrown.	Hard iteration cap, per-run budget ceiling, and an alert on repeated identical tool calls within one run.
Tool-call hallucination against a permissive API	The model invents a field or a plausible ID. The API returns 200 and quietly ignores or misapplies it.	Strict schemas with enums and patterns. Validate before dispatch. Verify the write by reading it back.
Silent partial completion	Three of five subtasks are done. The final message says the goal is complete because the model believes it.	Machine-checkable completion criteria evaluated by your code, never the model’s own summary.
Prompt injection through fetched content	A web page, PDF or inbound email carries instructions the agent follows, with write authority attached.	Least privilege on the run’s credentials, segregation of untrusted content, and human approval on privileged actions.
Cascading failure between agents	Agent A produces a confident wrong fact. Agent B treats it as an input and builds on it.	Validate at every handoff. Carry provenance. Do not let one agent’s prose become another’s ground truth.
Provider outage mid-trajectory	The loop stops halfway with state already changed in downstream systems.	Idempotent tool functions, checkpointed run state, and a cross-provider fallback route.

The outage case needs its own plan, because a half-finished trajectory is worse than a failed one: the partial writes are already live. Make tool functions idempotent, checkpoint the run so it resumes rather than restarts, and configure a second provider. Our guide to LLM fallback routing during an outage covers the switching logic.

Verdict: the agentic AI readiness checklist

If you cannot answer all nine of these, do not ship an agent yet. Ship the rung below it, which will probably do the job.

1. Can you name the closed set of actions the agent may take, and is it fewer than twenty?
2. Does every one of those actions run through validated code you wrote, with the model never constructing a call directly?
3. Is there a hard iteration cap and a per-run budget ceiling enforced by the runtime?
4. Can your code decide whether the goal was met without asking the model?
5. Do you have 50 or more real labelled tasks to regression-test changes against?
6. Is every step of every trajectory logged, including the stop reason?
7. Does the agent hold its own scoped credentials at least privilege, rather than a shared admin token?
8. Is every expensive-to-reverse action behind a human approval gate?
9. Do you know the blended cost per run including the slow tail, and does it survive contact with the volume you expect?

If you run ops on structured data with knowable rules, an agent is the wrong tool and a workflow with one constrained model step will outperform it on cost, latency and reproducibility. If you are drowning in unstructured inbound where the next step depends on what the last step found, and a wrong turn costs a reassignment rather than a refund, agentic AI is the right architecture and it is ready now. If you are being sold a multi-agent system to solve a routing problem, ask what the second agent does that a function call could not.

The shift is real. The competence band is narrow, it sits squarely on ambiguous input with cheap reversal, and the teams getting value out of it are the ones who put the determinism boundary in the right place before the first deploy rather than after the first incident.

Frequently asked questions