Insight / Blog

AI Agent Series · 1/6

It is hard to have a serious conversation about AI today without hearing the phrase "AI Agent." Teams are building systems that browse websites, collect information, summarize documents, and sometimes operate business tools on a user's behalf.

But when someone asks, "What exactly makes it an agent?", the boundaries of the concept often start to blur.

Is a chatbot an agent if it gives a longer answer? Does search make it an agent? If an app can call several APIs, should we call the whole thing an agent?

The defining difference is not conversational fluency. It is whether the system can decide what to do next in order to reach a goal.

That is the first design question.

Who decides the next action?

From Answers to Execution

A typical chatbot receives a question and generates an answer. If a user says, "Summarize this document," the system reads the supplied text and returns a summary.

Agentic work goes one step further.

It is not always a single-turn task where the answer can be produced immediately. Many useful work requests require the system to make intermediate decisions, adjust direction, and check whether the result is good enough.

For example, imagine this request:

"Find the major AI Agent news from this week and turn it into a summary for internal sharing."

That cannot be handled by pure text generation alone. At minimum, the system needs to:

• decide what to search for
• choose reliable sources
• remove duplicate information
• identify the main storyline
• organize the result into a useful internal memo

If the search results are weak, it may need to search again. If a source is unclear, it may need to exclude it. If two reports disagree, it may need to decide how to handle the conflict.

When the process is fixed, a person can define every step in advance. But when the query, tool, order, and judgment criteria change each time, someone has to decide the flow as the work unfolds.

An AI Agent delegates part of that decision-making to the language model.

The basic loop is simple:

Observe -> think -> act -> check the result.

Then repeat if needed.

That loop is the starting point for understanding agents.

What It Really Means for an Agent to "Use a Tool"

When an AI Agent searches the web, checks a calendar, reads a file, or calls a system such as Jira or Notion, we often say that it "uses a tool."

But the language model does not directly execute the external tool.

The model decides that a certain tool should be called and prepares the structured request: which tool, which arguments, and why it is needed. The actual execution happens in the application or service layer. Once the result comes back, the model uses that result to answer the user, choose another tool, or change its plan.

Take a simple example:

"Show me the Jira issues for the AI team."

The flow looks like this:

1. The service gives the model the user request and the list of available tools.
2. The model decides that it needs the Jira issue search tool.
3. The model returns a structured tool-call request with the required parameters.
4. The service reads that request and calls the Jira API.
5. The result is passed back to the model.
6. The model turns the result into a table, summary, or next action.

The important part is not the tool call by itself. It is the loop around it.

Model, service layer, tool, execution result, and next decision all have to work together. That is why agent quality is not determined by the model alone. It also depends on how tools are exposed, how clearly those tools are described, how errors are returned, and how the system decides what to do next.

How Agents Reason and Act

There are several useful patterns for thinking about agent behavior. The details matter to builders, but the business takeaway is simpler: different tasks require different kinds of control.

Some agents are planning-oriented.

Patterns such as ReAct, ReWOO, and Plan-and-Solve help the system break a goal into steps, act, observe the result, and decide what comes next. This is useful for work such as research, report drafting, customer inquiry triage, and other tasks where the next step depends on what the system finds. In an enterprise research workflow, this might mean comparing source quality and deciding whether to search again before drafting a memo.

Some agents are procedure-execution oriented.

CodeAct-like approaches let the model produce an executable procedure rather than only a written answer. This can be effective for repetitive operations, data processing, or multi-step work where the system needs to run a structured process and inspect the result. In a business analytics task, this might mean generating and running a small script to clean a dataset or produce a chart, then checking the output.

This does not mean the business user needs to write code. With tools such as Codex or Claude Code, a user can describe the goal in natural language, inspect the result, and adapt the procedure into a real workflow.

Some agents are verification-oriented.

Patterns such as Self-Refine, Reflexion, and CRITIC focus on checking the first result, identifying gaps, and improving the output. This matters for source-based documents, policy review, data-backed reporting, and other tasks where a plausible answer is not enough. In a reporting workflow, this might mean rechecking figures, citations, and policy conditions before the final document is shared.

In real systems, these patterns often overlap. An agent may plan, call tools, execute a procedure, verify the result, and revise its plan.

The point is not to memorize every pattern name. The point is to design the right control structure for the work.

Not Every Automation Needs an Agent

Just because agents are useful does not mean every workflow should become agentic.

Many tasks are safer and faster when they remain fixed workflows.

For example, imagine a report that pulls the same revenue data from the same database every morning at 9 a.m. and sends it in the same format. That may not need an agent. The steps are clear, exceptions are rare, and the decision rules do not change much.

In that case, a predefined workflow is easier to operate and easier to trust.

An agentic structure becomes more useful when:

• inputs vary from case to case
• the right tool depends on the situation
• the system must inspect intermediate results
• exceptions are too diverse for a fixed pipeline
• the user's goal is clear, but the execution path is open

This leads to a practical distinction:

If the language model needs to decide the next step, you are moving toward an agent. If the system simply follows a predefined path, you are closer to a workflow.

Most real services will mix the two. The overall process may be managed as a workflow, while only the parts that require judgment are handled by an agent.

Good agent design does not start by asking, "How autonomous can we make it?"

It starts by asking, "Where should autonomy actually exist?"

Good Agents Need Clear Tools and Boundaries

When an agent fails, the cause is not always the model.

It may fail because its role is unclear. It may have too many tools with vague descriptions. It may not know when to stop. It may not know which actions require approval. It may have permissions that are too broad for the task.

Consider a work assistant that receives this request:

"Clean up the Jira issues."

What does that mean?

Should it only summarize open issues? Should it change statuses? Should it assign owners? Should it delete duplicate tickets? If the system does not know the boundary, it may act in a way the user did not intend.

Now compare that with a clearer boundary:

"You may summarize, group, and suggest updates to Jira issues. You may not delete issues or change their status without user approval."

That boundary reduces risk because the system knows where it must stop.

At the design stage, teams should ask questions such as:

• Does this problem really need an agent?
• What must the agent do?
• What must it never do?
• What should the final output look like?
• When is the task complete?
• When should the agent stop and ask the user?
• Which tools should it use in which situations?
• Which actions require approval?

Tool design matters as much as model choice. A tool should have a clear name, a clear purpose, and a result format the model can interpret. Giving an agent many poorly defined tools is usually worse than giving it a small number of well-designed ones.

People need usable tools.

So do agents.

An Agent Is a Way to Delegate Execution

To understand AI Agents, it helps to start with the operating model rather than the terminology.

An AI Agent is not simply a better chatbot. It is not just a more fashionable name for automation. It is a system that receives a goal, decides part of the execution flow, calls tools, reads the result, and revises the plan when needed.

That means agent design does not end with model selection.

It requires decisions about execution structure, tools, permissions, verification, and stop conditions.

When planning an AI Agent, the first question should not be:

"How smart is the model?"

It should be:

"What can we safely let the system decide and execute?"

A good AI Agent does not do everything on behalf of the user. It has autonomy only where autonomy is useful. It uses the right tools for the job. And when it reaches a risky boundary, it knows how to stop.

The first design question of the agent era is simple:

Who decides the next action?

Once you can answer that question, the next question follows naturally:

What does the model need outside itself in order to act safely in a real work environment?

Tool execution, permissions, sessions, logs, recovery, and evaluation cannot be solved by prompting alone.

What matters is the layer outside the model that supports, constrains, and records execution. That external layer is the bridge from a capable model to a dependable work system.

That is why the next article will focus on harness engineering: the execution layer that helps AI Agents act safely and reliably in real work.

AI Agent Series