Every vendor pitch deck I've sat through in the last year uses the word "agentic" at least a dozen times, usually without defining it. I've had three separate conversations with engineers on my team who assumed "agentic" just meant "the chatbot can now click buttons." That's not wrong, exactly, but it misses the parts that actually matter when you're the one who has to run this thing in production and get paged when it does something weird at 3 AM.
This article is my attempt to lay out, in infrastructure terms, what actually makes a system agentic versus what's just a language model wrapped in a REST call. I'll walk through the three properties that define agentic behavior, how the runtime loop actually works under the hood, why this distinction changes how you design, deploy, and monitor these systems, and where I've seen teams get burned by not understanding the difference.
What It Is
An AI agent is agentic when it exhibits three properties together: autonomy, planning, and tool use. Miss one of these and you've got something else — a chatbot, a workflow engine, or a fancy autocomplete. All three, working in a loop, is what people mean when they say "agentic."
Autonomy means the system can take multiple sequential actions toward a goal without a human approving each step. A script that runs a fixed sequence of commands isn't autonomous in this sense, no matter how complex the sequence is — the decision tree was written by a human in advance. An agent is autonomous when the decision about what to do next is made by the model at runtime, based on what it observed from the previous action.
Planning means the system can decompose a goal into subtasks, and — critically — revise that plan when new information comes in. If I tell a system "investigate why sw-infrarunbook-01 is returning 502s" and it just runs one diagnostic command and reports back, that's not planning. If it runs a command, reads the output, decides that output implies checking the upstream pool next, and adjusts its next action accordingly, that's planning. The plan isn't fixed at t=0. It evolves.
Tool use means the model can invoke external functions — API calls, shell commands, database queries — and receive back real-world state rather than just generating text. This is the part that turns an LLM from something that talks about your infrastructure into something that can actually touch it.
None of these three properties is new individually. Planning algorithms predate LLMs by decades. Tool-calling APIs existed before anyone called them "agentic." What's new is combining a general-purpose reasoning engine (the LLM) with a loop that lets it observe, decide, and act repeatedly, chaining tool calls together based on its own evolving understanding of the problem.
How It Works
The mechanism underneath almost every agentic system is some variation of the ReAct pattern — reason, act, observe, repeat. It sounds simple, and at the core it is, but the operational details matter a lot once you're running this against real infrastructure.
Here's the loop in pseudocode form, roughly how I'd describe it to someone building their first agent runtime:
state = { goal: "diagnose elevated latency on sw-infrarunbook-01", history: [] }
while not done and steps < max_steps:
thought = model.reason(state.goal, state.history)
if thought.wants_tool_call:
result = execute_tool(thought.tool_name, thought.tool_args)
state.history.append({action: thought, observation: result})
else:
done = True
final_answer = thought.content
steps += 1
Every iteration through that loop, the model gets the full history of what it's tried and what it observed, then decides on the next action. The "planning" happens implicitly — the model isn't maintaining a separate formal plan object in simpler implementations, it's re-deriving intent from context on every pass. More sophisticated agent frameworks do maintain an explicit plan structure (a task list, a DAG of subgoals) that gets updated rather than fully regenerated, which is more token-efficient and easier to audit, but the underlying reasoning-then-acting cadence is the same.
The tool layer is where infrastructure engineers need to pay the most attention, because this is the part that has real blast radius. A tool definition typically looks something like this:
{
"name": "run_diagnostic_command",
"description": "Executes a read-only diagnostic command against a target host",
"parameters": {
"host": "string",
"command": "enum[ping, traceroute, dig, curl_headers]"
}
}The model decides which tool to call and with what arguments. The runtime is responsible for actually executing it, sandboxing it, and returning the result. This separation is important: the model never directly executes anything. It emits a structured request, and your infrastructure decides whether to honor it. That boundary is where you enforce your safety controls — allowlisting which commands can run, which hosts are in scope, whether an action requires human approval before execution.
I've built agent tooling where every tool call against production infrastructure required a human-in-the-loop confirmation step, and separately built read-only diagnostic agents that could run fully autonomously because the tools available to them literally could not mutate state. The agentic-ness of the system doesn't change based on that distinction — what changes is your risk exposure, and that's a design decision you make at the tool layer, not the model layer.
The other operational piece worth understanding is context management. Each loop iteration appends to history, and that history gets fed back into the model every time. For a long-running investigation — say, an agent working through a multi-hop network troubleshooting session across several hosts — that history can balloon fast. Production agent runtimes deal with this through summarization steps, sliding context windows, or explicit memory stores (often a vector database or a simple key-value store keyed by session) that let the agent retrieve relevant past observations without re-reading the entire transcript on every step.
Why It Matters
The reason this distinction matters operationally is that agentic systems fail differently than deterministic automation, and if you monitor and alert on them the same way you monitor a cron job or a fixed playbook, you'll miss the failure modes that actually hurt you.
A traditional runbook automation either succeeds or fails at a specific step, and you know exactly which step because you wrote the sequence. An agentic system can "succeed" at every individual tool call — every command returns exit code 0, every API call returns 200 — while the overall reasoning goes sideways. I've seen an agent correctly execute a series of valid, harmless diagnostic commands while building toward a completely wrong conclusion about root cause, because an early observation got misinterpreted and every subsequent step compounded that error. Nothing in the logs looks like a failure. The tool calls are all clean. The plan just drifted.
This means your observability needs an additional layer beyond tool-call logging: you need visibility into the reasoning trace itself, not just the actions taken. What did the model believe was true at each step, and why did it choose the next action? Without that trace, debugging a misbehaving agent is like debugging a distributed system with no request IDs — you can see the individual events but not the causal chain connecting them.
It also changes your blast-radius calculus. A fixed automation script has a bounded, auditable set of actions it can ever take — you can read the code and know the complete action space in advance. An agentic system's action space is bounded by its available tools, but the sequence and combination of those tools is decided dynamically. Two runs against the identical prompt can take different paths. That's the entire point — it's what makes the system useful for novel problems — but it also means you can't fully test every path in advance the way you'd test a deterministic script. You test the tool boundaries, the guardrails, and the failure containment, not the exhaustive action sequence.
For infrastructure teams specifically, this is why the tool layer deserves as much design attention as the model choice. I'd rather run a mediocre model with a tightly scoped, well-permissioned set of tools than a frontier model with an overly broad toolset and no approval gates. The autonomy is only as safe as the actions it's autonomous to take.
Real-World Examples
A few patterns I've actually seen deployed or built, ranging from low-risk to higher-risk:
A read-only network diagnostic agent that, given an alert like "elevated 5xx rate on sw-infrarunbook-01," autonomously runs a chain of diagnostics — checks recent deploys, queries upstream health endpoints, inspects connection pool metrics, pulls relevant log lines filtered by request ID — and produces a structured incident summary with a proposed root cause and confidence level. No mutating actions available at all. This is agentic (it plans, it chains tool calls, it revises its investigation path based on findings) but low-risk because the tool surface is entirely read-only.
A DNS remediation agent I worked with, where the toolset included both a read tool (query current records) and a write tool (propose a record change), but every write call was routed through an approval queue before execution. The agent could reason through "this looks like a stale A record pointing to a decommissioned host at 10.20.4.15, here's the corrected record," but a human clicked approve before anything changed. Fully agentic reasoning, gated action execution.
A capacity-planning agent that ingests utilization trends across a fleet, plans a scaling recommendation, and drafts a change request in the ticketing system rather than executing anything directly — the "tool" it uses is create a ticket, not modify infrastructure. This is a good example of scoping the tool layer to match your actual risk tolerance rather than the model's technical capability.
Contrast all of these with something like an on-call Slack bot that responds to "what's the status of sw-infrarunbook-01" by running one fixed health-check script and pasting back the output. That's useful, but it's not agentic — there's no planning loop, no chaining, no autonomous decision about what to check next based on what it finds. It's a single tool call behind a chat interface. A lot of what gets marketed as "AI agents" is actually this pattern, and it's worth knowing the difference when you're evaluating a vendor tool.
Common Misconceptions
The biggest one I run into: "agentic" does not mean "unsupervised." You can build a fully agentic system — autonomous multi-step planning with real tool use — that still requires human approval at every mutating action. The autonomy is in the reasoning and investigation, not necessarily in the final execution authority. Conflating these leads teams to either over-restrict genuinely useful read-only agents out of unwarranted caution, or under-restrict write-capable agents because they assumed "agentic" implied some built-in safety they never actually implemented.
Second misconception: more tools automatically means more capability. In practice, giving an agent a large, loosely-scoped toolset tends to degrade performance — the model has to reason about which of twenty overlapping tools to use, and it picks wrong more often than you'd expect. I've had better results narrowing a toolset to five or six well-defined, non-overlapping tools than handing an agent unrestricted shell access and hoping it figures out the right commands. Scope the tools the way you'd scope IAM permissions: to the minimum needed for the task, described unambiguously.
Third: people assume the planning happens once, up front, like a project plan. It doesn't, not in the systems that actually work well. The plan is continuously revised based on new observations, which is exactly why these systems can handle novel failure modes that a fixed runbook can't. It's also exactly why a single bad or ambiguous tool observation early in the loop can send the whole investigation down the wrong path — there's no fixed plan to fall back on if the revised plan goes wrong.
Last one, and this is the one I see burn teams the most: assuming an agent's tool-call success implies its conclusion is correct. Green exit codes across every step in the trace tell you the plumbing worked. They tell you nothing about whether the reasoning connecting those steps was sound. If you're deploying agentic systems against production infrastructure, build review into the loop somewhere — either a human checkpoint before impactful actions, or a secondary verification step, or both. Treat the agent's conclusions the way you'd treat a junior engineer's incident writeup: useful, often right, but worth a second set of eyes before you act on it at scale.