What Is an AI Agent?

An agent is a system that pursues a goal by observing an environment and taking actions over time.

That sentence is older than ChatGPT. It is the definition from AI textbooks (Russell and Norvig): sensors in, actuators out, a policy in the middle. A sensor is anything the system can read. An actuator is anything it can change. A policy is the rule that maps “what I see” to “what I do next.”

A language-model agent uses an LLM as part of that policy. The model is not the agent. The agent is the loop around the model: the goal, the tools, the memory, the stop rules, and the code that calls the model again after each observation. If you only have a model, you have a text generator. If you have a loop that can act without a human in every step, you have an agent.

People confuse three nearby things. A chatbot replies in language and waits. A workflow (a fixed pipeline) runs steps you already drew. An agent chooses the next step because the path is not known in advance. Marketing uses “agent” for anything with a chat box. Engineers should keep the word for systems that act in a loop toward a goal.

The four pieces

Goal. If you cannot write a check for “done,” you do not have a goal. You have a vibe. “Be helpful” is a vibe. “Return a GitHub issue URL whose body contains a reproducible test” is a goal.

Observations. These are the inputs after each action: tool results, files, error messages, the user’s last sentence. If the agent cannot see a fact, the policy cannot use that fact. Hidden logs are not observations.

Actions. These are the allowed verbs. Search, run tests, post a comment, refund, stop. An action with no permission in code is a wish. An action with too much permission is an incident.

Policy. This can be a boring if statement. It can be an LLM that returns a tool name. It can be an LLM plus rules that forbid some tools. Intelligence can come later. The shape is already an agent if these four pieces exist and they loop.

If any piece is missing, you do not have an agent. You have a demo. A model with no tools is a chatbot. Tools with no goal are a script someone clicks. A goal with no stop is a bill that never ends.

Autonomy is a slider, not a switch

Autonomy means how much the system may do without asking you. It is not a badge. It is a risk setting.

• Level 0 — autocomplete. Human does everything. The model finishes a line.
• Level 1 — chatbot. Model replies. Human still acts in the world (copy, paste, click).
• Level 2 — tool-using copilot. Model may call functions. Human approves anything that changes money, data, or production.
• Level 3 — agent. Model loops: think, act, observe, think, until a stop condition.
• Level 4 — long-running or multi-agent. Hours to days, multiple specialists, human on-call.

Joeven focuses on levels 2–4. Level 1 is useful. It is not this course’s product. Most companies should live at level 2 until they have evals (tests for behavior) and traces (logs of each step). Jumping to level 4 because a slide said “multi-agent” is how you get four loops arguing and one customer refunded twice.

A ticket, then a tiny umbrella

A support ticket arrives: “It is raining and I am about to leave. Do I have an umbrella?” That sounds like a chatbot question. As an agent problem it has four pieces.

Goal: if it is raining, the user should have an umbrella before they leave. Observation: a tiny world dictionary, raining and has_umbrella. Actions: take_umbrella or stop. Policy: if raining and no umbrella, take one; otherwise stop.

No LLM is required. The policy is an if statement. That is the point. When you later replace policy with a call to a model that returns an action name, the loop does not change. The world might be a ticket API instead of a dictionary. The action might be issue_refund instead of take_umbrella. The shape stays.

Stop conditions belong in the same design. An agent that cannot stop is a denial-of-service attack against your wallet.

• Success: the goal check is true (if raining, umbrella is true).
• Failure: too many steps, too much money, a forbidden action.
• Handoff: ask a human, then halt.

Write those three before you add tools.

Run to execute this in your browser. Nothing is sent to a server.

First the program prints the starting observation: raining true, no umbrella, so the policy chooses take_umbrella. After the action it prints the new observation: raining true, umbrella true, so the policy chooses stop. Then it prints the final world, how many steps were used (1), and that the goal is met. Set raining to False and run again. The first action should be stop, steps used 0, goal still met — because the goal only requires an umbrella if it rains.

Note:Marketing uses “agent” for anything with a chat box. Engineers should keep the word for systems that act in a loop toward a goal.

What goes wrong

• Calling the LLM the agent. Then you cannot say who owns stop rules, tools, or logs. The model is a component.
• No goal check. The loop “finishes” when the model writes a cheerful sentence. That is a chatbot with extra steps.
• No observations. The policy guesses. Guessing looks fluent and is still guessing.
• Actions that are not real. The model says “I refunded you” but no function ran. Speech is not an actuator.
• Autonomy at 100% on day one. Irreversible tools (refund, delete, email all customers) without a human gate.
• Infinite loop. No max steps. The umbrella policy would be harmless. A paid search tool would not.
• Hidden policy. Prompt in a wiki, tools in another repo, stop rules in someone’s head. If it is not in code, it is not the policy.
• Level mix-up. A chatbot with one button labeled “Agent” is still level 1.

Where this goes next

The next lesson is the loop in slow motion: assemble context, ask the model, parse, execute, append, repeat. Later, the tools track turns actions into real APIs. Evals turn goal_met into a suite. Production adds tracing and spend limits. Multi-agent is level 4, after one agent is honest. This page only gives you the four pieces and the slider.

How agents use this

When you implement an agent, start from the table, not from a framework name.

Put the goal in code as a function that returns true or false. Put observations in a typed object you log. Put actions in a list the model is allowed to name. Put the policy behind one function so you can swap an if for an LLM without rewriting the loop.

• Code: observe, act, policy, goal_met, and a while with a cap. Keep world state separate from the policy so tests can feed fake observations.
• Logs: every step should print observation, action, and whether the goal is already true. That list is the ancestor of a production trace.
• Tests: rain and no umbrella must take the umbrella. Rain and umbrella must stop. No rain must stop. A missing action name must not crash the world into a random state.
• Stop conditions: success via goal_met, failure via max steps or forbidden action, handoff via an action named ask_human that ends the loop.

Replace policy with a call to an LLM that returns an action name, and you have a modern agent. The loop did not change. The rest of Joeven is how to make that swap reliable.