What is agentic AI?

"Agentic AI" is the term of the moment, and like most terms of the moment it gets applied to everything from a chatbot with a search button to fully autonomous software engineers. Underneath the marketing there is a precise and genuinely useful idea. This article explains what it is, how it works mechanically, and — just as important — when it's the wrong tool.

The core idea: a model in a loop

A plain large language model call is a one-shot function: text in, text out. The model can reason impressively, but it can't do anything — it can't look something up, run code, query your database, or send an email. It also can't check its own work against reality.

An AI agent is a language model placed in a loop and given tools: functions it can invoke to act on the world. Each cycle of the loop looks like this:

1. The model receives the task plus everything that has happened so far.
2. It decides on the next step: either call a tool, or declare the task finished.
3. If it called a tool, your code executes the call and feeds the result back.
4. Repeat until done.

That's it. "Agentic" doesn't refer to a special kind of model — the same model powers chat and agents alike. It refers to the architecture: the model directs its own control flow. Rather than a programmer specifying "first search, then summarize, then draft," the model observes intermediate results and decides what to do next, including recovering from errors and taking paths nobody scripted.

Agents vs. workflows vs. chatbots

A useful mental model has three tiers, in increasing order of autonomy:

The distinction matters because autonomy is a cost, not just a capability. Workflows are predictable, cheap, and easy to test; agents trade all three of those for flexibility. The right question is never "how do I add agents?" but "does this task have a knowable, fixed sequence of steps?" If yes, build a workflow. Agents earn their keep on open-ended tasks where the path genuinely depends on what's discovered along the way.

The anatomy of an agent

Production agent systems, whatever the framework, are assembled from the same few parts:

• The model — the reasoning engine. Capability here bounds everything else; a model that plans poorly can't be prompted into planning well.
• Tools — typed function interfaces the model may call: web search, code execution, file editing, database queries, internal APIs. Each tool is declared with a name, a description, and a schema for its parameters. Tool descriptions are effectively prompts — they determine when the model reaches for the tool.
• Memory / context management — the conversation history is the agent's working memory, and it's finite. Long-running agents need strategies for summarizing or pruning old context, and often a persistent store (files, a database) for knowledge that must survive across sessions.
• The harness — the surrounding code: it executes tool calls, enforces permissions and timeouts, limits the number of iterations, logs what happened, and decides which actions need human approval.

The influential ReAct pattern (Yao et al., 2022) formalized the interleaving of reasoning ("the test fails because the fixture is missing") and acting (run the test, read the file). Modern APIs have absorbed the idea natively: current models are trained for tool use and emit structured tool calls directly, no prompt tricks required.

A minimal agent in Python

Here is the agent loop with no framework at all, using the Anthropic API. We give the model one tool — a weather lookup — and let it decide when to call it. The same skeleton scales to real tool sets.

import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from the environment

tools = [
    {
        "name": "get_weather",
        "description": "Get the current weather for a city.",
        "input_schema": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"},
            },
            "required": ["city"],
        },
    }
]

def get_weather(city: str) -> str:
    # In real life: call a weather API here
    return f"18°C and cloudy in {city}"

messages = [{"role": "user", "content": "Should I bike to work in Amsterdam today?"}]

# The agent loop: keep going until the model stops calling tools
while True:
    response = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        tools=tools,
        messages=messages,
    )

    if response.stop_reason != "tool_use":
        break  # the model has produced its final answer

    # Append the model's turn, then execute every tool it requested
    messages.append({"role": "assistant", "content": response.content})
    tool_results = []
    for block in response.content:
        if block.type == "tool_use":
            result = get_weather(**block.input)
            tool_results.append({
                "type": "tool_result",
                "tool_use_id": block.id,
                "content": result,
            })
    messages.append({"role": "user", "content": tool_results})

final_text = next(b.text for b in response.content if b.type == "text")
print(final_text)

Note what the code does not contain: no instruction to check the weather. The model reads the question, recognizes that answering it requires information it doesn't have, calls the tool, and folds the result into its answer. Swap in tools for your database, your ticketing system, or a code sandbox, and the same twenty lines become a very different agent.

In production you'd add guardrails to this loop: a cap on iterations, timeouts and error handling around tool execution, logging of every call, and human confirmation for irreversible actions. Most provider SDKs now ship a "tool runner" that manages the loop for you.

Multi-agent systems

Once one agent works, the natural next step is several: an orchestrator that decomposes a task and delegates subtasks to specialized sub-agents (a researcher, a coder, a reviewer), each with its own context window and tool set. This is how my own NeuroLex system works — cooperating agents handle query understanding, retrieval over a scientific corpus, and answer composition.

Multi-agent architectures shine when subtasks are genuinely independent (they can run in parallel) or when isolating context improves focus — a reviewer agent that hasn't seen the author's reasoning makes a more honest critic. They add real overhead in cost, latency, and debugging complexity, so the same rule applies as before: start with one agent, split only when you hit a concrete limit.

Standardization is also arriving. The Model Context Protocol (MCP), an open standard introduced by Anthropic in 2024 and since adopted broadly across the industry, gives tools a common interface — so a database connector or a browser tool can be written once and plugged into any MCP-capable agent, rather than reimplemented per framework.

When agents are the wrong answer

An honest checklist before reaching for an agent:

• Is the task actually open-ended? If you can write the steps down, write them down — a fixed workflow will be cheaper, faster, and far easier to test.
• Can errors be caught and undone? Agents fail in creative ways. They're a good fit where verification is cheap (tests, review, rollback) and a poor fit where a single wrong action is expensive and irreversible.
• Does the value justify the cost? An agent may burn dozens of model calls on a task a single prompt could approximate. That's a fine trade for a task worth hours of human time, and a bad one for high-volume, low-value requests.

The systems that work in production tend to be boring in the best way: a scoped task, a small set of well-described tools, tight guardrails, and a human in the loop wherever the cost of error is high. Autonomy is added gradually, as trust is earned — not granted up front.

All posts