What Makes an Agent

Goal

Distinguish a bounded agent from a single model call or fixed tool workflow by identifying repeated decisions, changing observations, explicit state, and stopping rules.

In Level 10, you built workflows where a model could propose a tool call. Many of those workflows followed a mostly known path: validate the request, run a tool, return the result, and finish.

An agent adds a different kind of uncertainty. The application may not know the exact number or order of useful steps before the run begins. After an action returns new information, the system can decide what should happen next.

That does not mean every multi-step program is an agent. A fixed script that always runs A, then B, then C has multiple steps, but it is not choosing among next actions from new observations.

A practical definition

For this course, call a system agent-like when it repeatedly does four things:

observe current situation
→ choose a next action
→ act through an allowed capability
→ use the result to choose again or stop

The choice can involve a language model, deterministic rules, or both. The important engineering fact is that later actions depend on evidence produced during the run.

Suppose a support system first calls get_order. If the result says “still shipping,” it may answer directly. If the result says “delivered and damaged,” it may check refund eligibility. The second action depends on the first observation.

More decisions create more failure opportunities

A one-step mistake is usually local. A loop can carry a mistake forward. Wrong state can cause a wrong tool choice, which can create a misleading observation, which can influence the next step.

This is why an agent needs explicit bounds. The application should know the maximum number of steps, which actions are allowed, which actions need approval, what counts as completion, and which repeated patterns mean the run is stuck.

The model can help choose the next step, but it should not be the only source of those limits.

Agency is not authority

“Agent” describes a decision pattern, not a permission level.

A read-only agent may be allowed to search and summarize but never change external data. A more capable agent may propose a refund, but application code can still require a human approval bound to the exact order and amount.

This repeats the Level 10 rule: a model-produced action remains a proposal until trusted application logic allows execution.

Compare three systems

System A: one prompt produces one answer. There is no external action and no loop.

System B: a fixed workflow always runs lookup → format → answer. It has tools, but the action order is predetermined.

System C: after each lookup, the system chooses among another lookup, asking for approval, answering, or stopping because progress is impossible. That changing next-step choice is the agent-like behavior we care about.

The label matters less than recognizing the control problem. System C needs state, bounds, and trajectory evaluation because a bad choice can influence several later choices.

Predict

A program always runs lookup_customer, then lookup_orders, then summarize, with no branching from results. What is the best description?

A fixed multi-step workflow, because later actions are predetermined rather than chosen from new observationsA bounded agent, because any program with three tool calls is automatically an agentAn unrestricted autonomous agent, because it can access more than one external tool

Run the local Lab

From the repository root:

python labs/notebooks/level-11/l11-01-agent-boundary.py

The script prints three small systems.

1. Run it unchanged and confirm only agent-like-loop is classified as agent-like.
2. In the third system, find "next_action_depends_on_observation": True. Before editing, predict its classification if that single field becomes False while the step count stays 3.
3. Change only that value to False, then rerun.
4. Confirm the third system is now classified as fixed. Explain why multiple steps alone do not create agent-like control flow.

Loading lab…

Quick Check

1. Which property most clearly separates the agent pattern in this lesson from a fixed tool pipeline?

The system uses at least three tools before it may produce an answerThe model receives a longer prompt that describes it as an agentThe next action can change after a new observation updates the run state

2. Why does an agent loop need explicit application-level bounds?

Because a fixed step limit makes every decision inside it correctRepeated decisions can spread mistakes or stallBecause learners need to see a countdown printed at every step

3. What does calling a system an agent imply about its permissions?

Once it forms a full plan, the plan counts as its permissionIt needs write access to every connected tool so it can act freelyNothing; permissions still come from app policy

0 of 3 questions answered.

Explain it back

Take a familiar workflow such as booking, support, or research. Describe one version with a fixed sequence and one version whose second action changes after the first result. Then name one application-level stopping rule each version would need.

Key Takeaways

• An agent repeatedly chooses next actions from changing observations and state.
• Multiple steps do not automatically make a workflow agent-like.
• More decisions create more opportunities for error propagation and looping.
• Agency does not grant authority; tools, permissions, and approvals remain application controls.
• A bounded agent needs explicit completion, failure, and budget rules.

Next Lesson

Next, turn the definition into a concrete observe–decide–act cycle and track exactly what changes between steps.

References

• Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models.