A model answers.
An agent can act.

Generation alone does not complete a task.

A language model can interpret an instruction and produce a response. To carry out a task in an environment, a larger system may also need to choose an action, call a tool, observe the result, and decide what to do next.

There is no single definition of “agent” used across every field. Here, it means an application where a model can use permitted tools and observations to choose subsequent steps toward a stated goal. The surrounding software still decides which tools exist, checks permissions, and executes or rejects each call. A tool request by itself does not grant the model authority. See the full guide to tool calling and execution ↗.

Real products often combine these patterns. A fixed application can call a model, run a deterministic check, then give the result back to the model. The useful question is not which label sounds more advanced; it is who chooses the next step and how that choice is controlled.

An agent is a loop with consequences.

A typical interaction starts with a goal. The system selects a tool, the application checks and executes the request, and the result becomes a new observation. The model can use that observation to revise its plan, choose another permitted action, return an answer, or stop.

The ReAct research studied a pattern that interleaves reasoning and actions, using the results of actions to inform later steps. Its experiments include question-answering and interactive environments. That makes ReAct a concrete example of a model-and-tool loop, not proof that every task benefits from an agent or that an agent will act reliably.

A wrong assumption can lead to the wrong tool call. A misleading result can redirect the plan. A task can appear complete even when the underlying action failed. For that reason, important steps need observable outcomes and clear success conditions.

Read Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models” ↗

Use an agent when the next step cannot be written down in advance.

A fixed workflow is often the better choice when a task has a known sequence and predictable branches. It is easier to inspect, test, and repeat. An agent is more useful when the work depends on changing context, uses unstructured information, or requires choosing among steps that cannot be fully anticipated.

That flexibility has a cost. Agentic systems can add latency, model and tool calls, new failure paths, and review effort. Anthropic’s engineering guidance recommends starting with the simplest solution and adding agent behavior only when evaluation shows that the extra flexibility improves the result. OpenAI’s practical guide similarly points to workflows that resist ordinary automation, such as complex decisions or heavy reliance on unstructured data.

“Can we build an agent?” is an easy question. A more useful one is whether its ability to choose steps improves a real outcome enough to justify the extra moving parts.

Set the boundaries before the first tool call.

Instructions can describe the task, but safeguards should also exist in the application that owns the tools. Separate read access from write access. Limit which data and actions each tool can reach. Put confirmation or human review in front of consequential or difficult-to-reverse operations.

• Define the goal and the evidence that counts as completion.
• Give each tool only the access it needs for that task.
• Set limits for retries, time, and actions, with a clear stop condition.
• Record tool requests and results so a person can review what happened.
• Test failure cases and compare the agent with a simpler baseline.

“Agent” is not a guarantee of autonomy, accuracy, or reliability. The design of the runtime, permissions, checks, and recovery path determines what the system can do and how people can respond when it goes wrong.

The law follows the system’s use, not the agent label.

“AI agent” is not a separate legal category in the EU AI Act. The European Commission explains that an agent will usually be part of an AI system, often alongside a general-purpose AI model. The system’s intended purpose, actual use, and the role each organisation plays determine which rules may apply; calling a product an agent does not decide its classification.

Start with the system people use. An agent designed to interact with people or generate content may fall within Article 50’s transparency duties, which have applied since 2 August 2026, subject to the article’s specific scope and exceptions. If its intended purpose places it in an Annex III use case, or it is a safety component of a product covered by Annex I legislation, high-risk requirements apply from 2 December 2027 or 2 August 2028 respectively. Those later dates affect the high-risk requirements; they do not postpone every other obligation.

Then examine the model-provider side separately. For a general-purpose model with potential systemic risk, the Act’s Annex XIII criteria include evaluations of the tasks it can perform, its autonomy and scalability, and the tools it can access. Those criteria inform assessment of the underlying model; they do not make every agent product or every model automatically “systemic risk.”

For the full role and application-date map, read the EU AI Act guide ↗. The Commission’s AI Act Service Desk FAQ on AI agents ↗ explains how the Act addresses them; its summaries are practical guidance, while the Regulation remains the binding text.