Agentic AI examples: one production agent, measured

Generative AI answers one prompt; agentic AI works towards a goal over many steps, keeps state, uses tools and decides what to do when a step fails. Here is how to tell the two apart, with one real system taken apart.

"Agentic AI" is used for everything from a chatbot with a search button to a fleet of cooperating programs. The examples below show what the word should mean, and one production system shows where the agentic parts actually sit.

Agentic AI vs generative AI

Generative AI is a model that produces new content, such as text, code or an image, in answer to a prompt. One request goes in, one response comes out, and a person decides what happens next. A chat assistant that explains a function you paste into it is generative AI.

Agentic AI is a system that pursues a goal across many steps with some independence. It breaks the work down, keeps track of what is done, uses tools such as a file reader, a search or an API, looks at each result and chooses the next step, including what to do when a step fails. Almost every agentic system has a generative model inside it. The difference is the loop, the state and the decisions around the model, not the model itself.

A simple test: remove the person who reads each answer and types the next prompt. If the work still moves towards the goal, the system is agentic.

AI agent vs agentic AI

The two terms overlap and people use them loosely, so it helps to be exact.

• An AI agent usually means one program in which a model runs in a loop, chooses which tool to call, reads the result and repeats until it decides the goal is met. The model is in charge of the control flow.
• Agentic AI is the wider idea: any system that acts towards a goal over many steps. That includes single agents, several agents handing work to each other, and agentic workflows, where code fixes the order of the steps and models do the work inside each one.

The distinction matters when you build one. A model choosing its own tools is flexible but harder to predict, test and cost. A workflow is less flexible, but every path can be tested. Many production systems sit in between.

Common examples of agentic AI

• Coding agents read a repository, edit files, run the tests and try again when a test fails. The goal is a passing change, not one answer.
• Support agents look up an order, check a policy and issue a refund within a limit, handing anything larger to a person.
• Research agents search, read the results, decide what is still missing and search again before writing a summary.
• Document workflows take a large input, such as a contract set or a codebase, through fixed stages of reading, combining and writing, with checks between them.

What they share is more useful than what they do: a goal, state that survives between steps, tools, rules for failure, and points where a person must decide.

The example: what Nehemvix does

Nehemvix turns a Git repository into a documentation guide with architecture diagrams and citations to exact lines, using the person's own model key. It belongs to the last kind above. The goal is a whole guide, not one answer, and getting there takes dozens of model calls that each depend on earlier ones.

It is an agentic workflow, and we say so plainly. The guide pipeline is a fixed LangGraph graph whose nodes call the model, and the model is given no tools. Code decides the order:

ingest → estimate → map → reduce → synthesize → write
       → assemble → evaluate → index → publish

Map reads each file once and summarises it, reduce summarises each folder, synthesize writes the system overview and write produces each section for each audience. On 3 November 2026 it documented pallets/itsdangerous, 46 files, for all three audiences in 38 calls costing $0.0459, against an estimate shown beforehand of $0.036 to $0.077.

Where the agentic parts are

State that survives. Every unit of paid work, such as a folder summary or a section, is stored under a stable key before the graph moves on. A crash, a restart or a model swap never redoes or re-bills a finished unit.

Decisions on failure. The model client classifies each error and decides whether to wait for a per-minute limit, retry, move to the next model in a fallback chain or pause the job. A job that hits a daily quota pauses instead of failing, and can be resumed later on another model. Rate limits, retries and fallbacks covers how the errors are told apart.

Tools that run as code. Fetching the commit, removing secrets, scanning for text aimed at AI tools, checking names against the code and looking up known vulnerabilities are tools the pipeline calls, not choices the model makes. One wrapper records each call, with how long it took and whether it worked.

Agents on the outside. The tool-calling agents in this picture are the assistants that use Nehemvix. They call seven read-only tools over MCP, or send tasks over A2A, to read and search finished guides, as MCP vs A2A describes.

Where a person stays in control

Autonomy stops where money or someone's code is at stake. The estimate node shows a low, likely and high cost, then stops the graph with LangGraph's interrupt() until a person approves, unless the high estimate is under an auto-approve limit that person set. Sending code to a new provider needs that person's consent. An outside agent can only get a link to the app, because agents cannot consent. The full list is in human in the loop for AI agents.

How the agent is measured

An agent that writes documentation can invent names. Nehemvix checks every backticked name and every citation against the code, and those checks are themselves measured: on our hand-checked guides, on names planted on purpose, and in blind rounds written by a tester who never read the checker. The results, including the weaker blind-round number, are on how we check. The offline evals take about two seconds and run before every deploy, so a change that lowers a number stops the release.

What to take from this example

1. Decide where control flow lives. A fixed graph suits a paid, repeatable job; a model choosing tools suits open-ended tasks.
2. Make every paid step resumable before you make it clever.
3. Put a person at the points where money is spent or data leaves, and nowhere else.
4. Measure the agent's output with numbers you can reproduce, and publish the weak ones too.

See the whole pipeline on how Nehemvix works. To read another team's agent code, start with how to understand an agentic AI codebase; for how this one keeps a large repository inside a model's context, see how AI reads a large repository.

Learning this to build your own agent? AELSHA™ can help you design it.