Agentic AI explained: tools, loops and guardrails

"Agentic AI" means everything in a pitch deck and very little in a code review. For engineers, agentic AI has a concrete meaning: a program where a language model decides the next step, calls a tool to take it, reads the result, and repeats until the task is done or a limit stops it. That loop, the tools it can touch, and the guardrails around it are the whole system.

I've been exploring this through my Agentic AI Engineer project, which looks at autonomous, multi-step engineering workflows driven by LLM agents. This post is the mental model I wish I'd had at the start.

What makes a system agentic

A plain LLM feature is one request and one response. You send a prompt, you get text back, and your code decides what to do with it. The control flow lives in your code.

An agent moves some of that control flow into the model. The model gets a goal, a list of tools it may call, and the history so far. On each turn it either asks for a tool call or says it's finished. Your code runs the tool and feeds the result back.

So the useful question is "who decides what happens next?" If your code decides, you have a workflow with LLM steps. If the model decides, you have an agent. Most production systems sit somewhere in between, and I wrote a separate post on choosing between an AI agent and a deterministic workflow.

The three parts: model, tools, loop

The model

The model is the planner. It reads the goal and the transcript and picks an action. On its own it can't read a file, query a database or open a pull request. It can only ask your code to do those things.

The tools

Tools are functions you expose with a name, a description and an input schema, usually JSON Schema. A tool might read a file, run a test suite, search a codebase or call an internal API. The model sees the description and the arguments. Your implementation stays on your side.

Good tools are small, clearly named and return compact, structured results. A tool that dumps thousands of lines of logs fills the context window and muddles the next step. A tool that returns "3 tests failed, with names and the first error line" gives the model something to reason about.

The loop

The loop is ordinary code:

1. Send the goal, the tool definitions and the history to the model.
2. If the model asks for a tool, validate the arguments and run it.
3. Append the result to the history.
4. Repeat until the model says it's done or you hit a limit.

I walk through a full implementation in building a tool-using AI agent in TypeScript. The loop itself is short. The hard engineering is everything around it.

Where agents earn their cost

Agents are slower and less predictable than a single call, so they need to buy you something. They're worth it when:

• The steps aren't known up front. Debugging a failing build is a good example: what you look at next depends on what you just found.
• The task needs feedback from the real world. Run the tests, read the output, change something, run them again. A fixed pipeline can't express that loop well.
• A person would otherwise do tedious exploration. Finding every caller of a function, reading each one and summarising the risk of a change.

They're a poor fit when the steps are always the same. If you can draw the flowchart, write the flowchart. My default is to start with a fixed pipeline and hand control to the model only at the specific step where the path genuinely varies.

Guardrails are part of the design

An agent with tools is a program that writes and runs its own plan. Give it the same suspicion you'd give any code that takes input from outside your system, because the model's choices are shaped by whatever text lands in its context, including text from files and pages it reads along the way.

The guardrails I'd put in from day one:

• Least-privilege tools. If the job is reading code, register read tools only. A write tool that was never registered can't be misused.
• Hard step and token budgets. Every run gets a maximum number of turns and a token ceiling. When it hits the limit, it stops and reports what it has.
• Human approval for irreversible actions. Deleting data, sending email, merging, deploying, spending money. The agent proposes and a person confirms.
• Argument validation. Check every tool call against its schema before running it. Models produce malformed arguments more often than you'd expect.
• An audit log. Record every model call, tool call, argument and result under a run id. When something odd happens, you want the full transcript.

I go deeper on each of these in guardrails for AI agents in production.

The problems the demo skips

Once the loop works, the real work starts.

Context grows every turn. Each tool result is appended to the history. Long tasks run out of room, or the model starts drifting from early instructions. You need a plan for trimming or summarising old turns and for keeping durable state outside the model.

Errors compound. A single call that's right most of the time is fine. Ten chained decisions, each with the same error rate, are far less reliable. Short tasks, narrow tools and checkpoints where code verifies progress help a lot.

Evaluation gets harder. You're judging a whole trajectory: did it pick sensible tools, stop at the right time, and leave alone what it should have left alone? That calls for recorded test cases and checks over the entire run.

People can't see inside the loop. A run that sits silent for twenty seconds feels broken, even when it's working. In the AI assistant I built for the Recond Flutter app, replies stream in and the UI shows what the agent is doing while it works, so the user can tell it's looking something up and roughly what. Emit an event per step and let the interface render it.

Cost and latency add up. Every turn is a model call. A smaller, cheaper model for routine steps and a stronger one for planning is often a better trade than one model for everything.

Where I'd start

Give your first agent one narrow job, two or three read-only tools, a step limit of around ten and a log of every turn. Then read the transcripts. An afternoon of reading logs teaches you more about where it goes wrong than any framework's documentation. If you want help scoping an agent for your own product, that's the kind of work on my services page.