AI Agents Explained: From Answering Questions to Taking Actions

01 What Changed: One Answer Becomes a Loop

For most of the decade, interacting with a large language model meant a single transaction. You typed a prompt, the model ran once, and it returned text. Whether the interface was a chat window or an API call, the underlying shape was the same: one input, one forward pass, one output. The model could not check anything, could not fetch anything it did not already contain, could not correct itself after seeing the consequence of its own answer. As Wikipedia's summary of large language models puts it, these are models trained on vast text corpora for generation tasks - producing, summarizing, translating on the strength of what was learned during training. Everything the model would ever know about your problem had to be either in its weights or in your prompt.

The systems that came to dominate engineering attention between 2024 and 2026 abandoned that shape. The unit of work stopped being the answer and became the task: reconcile this invoice, migrate this database schema, investigate this alert, book this trip. A task cannot be completed in one forward pass, because it requires information the model does not have yet - the current state of the database, the result of the API call, the content of the web page. So the system was restructured around iteration. The model proposes an action, the environment executes it, the result is fed back, and the model proposes the next action, until some stopping condition is reached. The model is no longer the system; it is the reasoning core inside one.

The IBM Technology video anchoring this article, presented by Maya Murad, frames this as an evolution across five levels: models, then models with tools, then agents, then multi-agent systems, with orchestration emerging as its own discipline along the way. The framing is a vendor's framing - IBM sells agent orchestration - but the underlying observation is vendor-neutral and now consensus across the field: the interesting engineering moved from making models better to wiring models into loops. The rest of this article unpacks that wiring: the loop itself, the tool interfaces that give it hands, the orchestration patterns that scale it, and the failure modes that have made 2026 simultaneously the year of agent deployment and the year of agent incidents.

02 The Agentic Loop: Perceive, Plan, Act, Observe

Strip an agent to its skeleton and four verbs remain: perceive, plan, act, observe. The cycle is old - it is the classical control loop of robotics and the sense-decide-act cycle that artificial intelligence textbooks have taught for decades, and Wikipedia's summary of the intelligent agent concept describes exactly this entity: one that perceives its environment, takes actions autonomously to achieve goals, and may improve its performance through learning. What is new in 2026 is that the decision element is a general-purpose language model, which changes the character of every other element in the loop. A classical controller perceives through dedicated sensors and acts through dedicated actuators; an LLM-driven agent perceives through text - tool outputs, error messages, database rows rendered as strings - and acts by emitting structured requests that a harness translates into real operations.

Walk one turn of the loop. The agent receives a goal and the accumulated context of everything that has happened so far. It plans: in the common formulation this is either an explicit scratchpad of subgoals written before any action, or a purely reactive choice of the next action, and the trade between the two - deliberation cost against adaptability - is one of the live design arguments in the field. It acts: the model emits a structured tool call, a JSON fragment naming a function and its arguments. The harness executes the call against the real world - a database, an HTTP endpoint, a shell. It observes: the return value, or the exception, is appended to the context. Then the loop runs again, with the model now conditioning on evidence it did not possess a moment earlier. Termination is usually a special tool call signaling done, a token budget running out, or a human deciding enough is enough.

The design significance of the loop is that it converts the model's static knowledge into a dynamic procedure. A single-pass model asked to summarize a company's quarterly filings can only summarize what it remembers about the company, which is a rehearsal, not a report. The same model inside a loop can fetch the filing, read it, extract the numbers, notice a discrepancy against the previous quarter, fetch that one too, and produce an analysis grounded in documents that did not exist in its training data. Nothing about the model's parameters changed. What changed is that its output is now contingent on observation - which is the difference between reciting and reporting, and the entire basis of the agent category.

03 Tools and Function Calling: Giving the Model Hands

The bridge between the loop's reasoning and the loop's effects is function calling, the convention by which a model emits machine-readable requests for external operations. The mechanics are simple enough to describe in a sentence: the developer declares a set of tools - name, description, parameter schema - the provider fine-tunes or prompts the model to emit calls conforming to those schemas, and the surrounding software executes the calls and returns results as context. The convention hardened into an industry standard as providers converged on compatible interfaces, which is why the same open-source agent frameworks now run against nearly every major model API. (Notably, the term itself never received a dedicated encyclopedia entry; the concept lives inside agent and LLM documentation rather than its own article.)

The catalog of what counts as a tool has expanded faster than anyone's taxonomy of it. The baseline set is retrieval - search engines, document stores, vector databases - which compensates for the model's frozen training data. Above that sits the long tail of enterprise operations: SQL execution, CRM writes, ticket creation, calendar booking, code execution sandboxes, shell access. Then came the tools that operate on the agent itself: memory stores that persist context across sessions, sub-agent spawners that treat other agents as callable functions, and browser automation, which in effect gives the agent the entire web frontend as an API. The through-line is that each tool is a boundary crossing - from the model's world of predicted text into a world of side effects, where actions cannot be undone by drafting a better sentence.

The quality of a tool interface matters as much as the quality of the model, an asymmetry that surprised many teams in the first deployment wave. A model given a vague tool description will call the wrong tool at the wrong time with plausible confidence; a model given a well-specified schema, informative error messages, and tools that fail loudly rather than silently performs dramatically better, without any change to its weights. This is ordinary software engineering transplanted into an unusual place: the API documentation is now read by a statistical process rather than a human, and every ambiguity in it becomes a probability of misuse. Teams that treated tool design as a first-class discipline consistently outperformed teams that treated it as plumbing - a pattern the agent literature of 2025 and 2026 documents repeatedly, and one that transfers no knowledge from the era of prompt engineering.

04 Orchestration: When One Loop Is Not Enough

Scale a single agent along any dimension - task duration, tool count, context size - and it degrades in predictable ways. Long tasks exceed the context window and force lossy truncation; broad tool sets dilute the model's attention across dozens of schemas; a single loop mixes planning, execution, and verification in one context, so that each contaminates the others. The industry's answer was decomposition. Orchestration layers emerged to split work across multiple loops: a planner agent that decomposes the goal, executor agents that each own a narrow toolset, a critic or verifier agent that inspects results before they are committed. The IBM framing presents this as the top of the evolution - from agents to multi-agent systems - and it is the tier where most serious 2026 deployments actually live.

The design space of multi-agent patterns has consolidated around a few archetypes. Sequential pipelines pass a work product down a chain, each agent transforming it - the assembly-line pattern, easiest to debug because the failure is localized to a station. Hierarchical orchestrator-worker patterns have a manager agent decomposing tasks and delegating to specialists, then integrating their outputs - more powerful, harder to observe, prone to the manager hallucinating capabilities its workers lack. Debate or verification patterns run agents adversarially against each other, one producing and one checking, converting a single model's self-consistency into an actual external check. And blackboard-style patterns let independent agents read and write a shared state, coordinating indirectly through the artifact rather than directly through messages - the pattern closest to how human teams actually work, and the hardest to reason about formally.

What orchestration buys is capability; what it costs is everything else. Every additional agent multiplies the token consumption, the latency, and above all the number of interfaces where errors can enter and propagate. The uncomfortable empirical result of the first two years of multi-agent deployment is that added structure helps most on tasks that are genuinely decomposable, and actively hurts on tasks whose steps interact tightly - the orchestrator ends up spending its budget on coordination rather than work, and the system's aggregate accuracy can fall below that of a single well-prompted loop. The strongest 2026 deployments are notably conservative in structure: two or three agents with crisp contracts, not the swarms of a dozen specialists that the 2024 demos advertised. The swarms were a demonstration of composition; the contracts are what makes composition reliable.

05 Implications: Work, Cost, and the New Skill Ladder

The labor implications of agents differ from those of bare models in kind, not just degree. A model that produces text competes with tasks measured in pages; an agent that completes tasks competes with work measured in workflows. The 2024-era question - will this replace copywriters - has been displaced by the 2026 question - will this replace the junior analyst whose week consists of pulling data, reconciling reports, drafting summaries, and escalating anomalies. Those are exactly the properties agents were engineered for: multi-step, tool-mediated, verifiable-at-the-end. The economic literature is far from settled, but the deployment evidence of the last two years points at administrative and analytical pipelines first, customer-facing judgment later, and physical work untouched by any of this software, since the loop's hands are still APIs.

The cost structure changes the calculus in a way the single-call era never had to confront. A chat answer costs fractions of a cent; an agent run that makes forty model calls, each conditioning on an accumulating context, costs orders of magnitude more - and costs that recur every time the loop iterates, errors, and retries. This produced a new engineering discipline, uncomfortable for a field accustomed to measuring progress in benchmark scores: agent economics. Token budgets, cache hits, model routing that sends cheap steps to small models and hard steps to large ones, and aggressive early-exit heuristics are now standard components of production systems. The teams that mastered them run agents profitably on tasks no human would accept at the price; the teams that did not discovered that an agent doing a two-dollar job with thirty dollars of inference is not automation but expensive theater.

For individuals, the skill ladder has been rebuilt. Prompt engineering - the 2023 skill - matters far less than it did, because the loop's structure absorbs most of what careful prompting used to accomplish. What matters now is the adjacent work: specifying tools and their schemas, writing the contracts between agents, designing the verification steps that catch the loop before it commits a mistake. This is closer to systems engineering and process design than to conversation, and it is where the observable hiring demand of 2026 has concentrated. The uncomfortable reading, consistent with every prior automation wave, is that the jobs most transformed are the ones that supervised the tasks being automated: managing an agent that does the junior analyst's work is a job for someone who understands the junior analyst's work, which keeps judgment in the loop even as execution leaves it.

06 The Limits: Compounding Errors and the Trust Boundary

Every strength of the agent architecture is paired with a structural weakness, and the first is arithmetic. If a single model call succeeds with probability p, an agent that requires k consecutive correct calls succeeds with something like p raised to the k - error compounding, the exponential tax on long loops. A model that is right ninety-five percent of the time and a ten-step task yields a success rate around sixty percent, which is a toy; a fifty-step task yields something no one would deploy. Two decades of reinforcement learning research - the field whose summary appears in this article's references, concerned with how an agent should act to maximize reward - wrestled with exactly this credit-assignment and horizon problem, and its lessons transfer: the effective horizon of a reliable agent is short, and lengthening it requires either better base reliability or verification steps that catch errors early, before they compound.

The second weakness is that the loop's failures are no longer linguistic but operational. A single-pass model that hallucinates produces a wrong sentence; an agent that hallucinates produces a wrong action - a deleted record, a mispriced order, an email sent to the wrong customer, a shell command run with real privileges. Hallucinated tool calls, where the model invents a plausible function or fabricates arguments that pass schema validation and fail semantically, are their own documented category. The security surface widens accordingly: prompt injection becomes an attack on actuators rather than on text outputs, since a poisoned web page or database field that the agent observes can steer its subsequent tool calls - the loop's greatest strength, conditioning on the environment, is also its intake channel for adversarial input. The response patterns - capability scoping, sandboxed execution, human gates on irreversible actions - are all variants of one admission: the trust boundary around an agent must be drawn by the harness, because the model itself has no concept of it.

The third weakness is the mirror of the second: agents behave well exactly where verification is cheap. The successful 2026 deployments share a profile - narrow domain, machine-checkable success criteria, reversible actions, an audit log a human can replay. Coding assistants thrive because tests either pass or fail; data-pipeline agents thrive because schemas either validate or do not. Open-ended tasks with subjective success criteria remain stubbornly human-supervised, and the honest position, which the more careful vendors themselves now state, is that autonomy is not a property of the model but an earned property of the whole system - granted task by task as evidence accumulates that the loop's failure modes are contained. The question What are AI Agents?, the title of the source video, turns out to have a shorter answer than the industry's demos implied: they are models with hands, a loop, and a trust problem - and the next several years of the field will be spent, productively, on the trust problem.