Module 01 · ~45 min

Foundations: agents & the loop

What an "agent" actually is, the loop that powers every one of them, when to use an agent vs. a plain workflow, and why a single agent isn't enough for something like Jarvis.

1. What we mean by "LLM agent"

Strip away the hype and an LLM agent is just this:

Definition

An LLM agent is a program where a language model decides what to do next — usually by choosing among a set of tools — and the program executes that decision in a loop until the task is done.

Three things make it an agent rather than a fancy chatbot:

The model is in the driver's seat. It picks the next step. The control flow isn't hard-coded by you.
Tools. The model can do things in the world — query a database, send an email, file a ticket — not just talk.
A loop. Take an action → observe what happened → decide again. Repeat until the goal is reached or you give up.

Analogy

Think of an agent as a very junior employee with internet access. You give them a goal. They pick a thing to try (Google it, draft an email, open a ticket). They look at the result. They decide what to do next. They stop when done. The "brain" is the LLM; the "hands" are the tools; the "loop" is them sitting at a desk repeating think → act → observe all day.

2. The agent loop (a.k.a. ReAct)

Almost every modern agent follows this exact cycle, originally described in a 2022 paper called ReAct: Reasoning and Acting:

User goal

→

LLM
"think"

→

Tool call
"act"

→

Tool result
"observe"

↩

The loop continues until the LLM emits a final answer instead of a tool call.

Concretely, on each turn the LLM looks at the running conversation (the user's goal + everything that has happened so far) and outputs one of two things:

A tool call — "call search_kb(query="printer floor 3")". The runtime executes the tool, appends the result, and re-invokes the LLM.
A final answer — "I've filed ticket #4821 and booked the room." The loop ends.

★ Jarvis through this lens

"Print on floor 3 is jammed and book conference room 2pm with Priya":
→ LLM: I should file an IT ticket. Call open_it_ticket.
→ Tool returns ticket ID #4821.
→ LLM: Now I need to book a room. Call find_room.
→ Tool returns "Room 4B available 2-3pm".
→ LLM: Call schedule_meeting(room="4B", with="priya@acme.com", time=...).
→ Tool returns confirmation.
→ LLM: Final answer to user. ✅

3. Workflows vs. agents — when to use which

"Agentic" is fashionable but agents are not free: they're slower, more expensive, harder to debug, and less predictable than plain code. Sometimes a plain workflow is better.

Workflow	Agent
You wrote the step sequence: `parse → enrich → classify → route`.	The LLM picks the next step from a toolbox at runtime.
Predictable, cheap, fast, easy to test.	Flexible, can handle open-ended goals, but slower and pricier.
Good when the path is known and the inputs vary.	Good when the path itself varies with the input.
Example: "Summarise every PDF dropped in this folder."	Example: "Help this employee with whatever they ask, using any of these 20 tools."

Rule of thumb

Start with the simplest thing that could possibly work. If the steps are knowable in advance, write a workflow. Only reach for an agent when the choice of step depends on what the previous step returned in a way you can't pre-script. Jarvis qualifies because we don't know in advance whether the user will ask about printers, leave balances, or restaurant recommendations.

4. Why a single agent isn't enough

Imagine giving one agent 50 tools (IT, HR, calendar, CRM, accounting, security, building-management, knowledge base, …). What goes wrong?

Tool overload. LLM accuracy at picking the right tool drops once the toolbox grows past ~15–20 options. Latency and token cost grow with every tool description in the prompt.
Context bloat. All HR's docs, IT's runbooks, finance's policies stuffed into one prompt — the model loses focus.
Mixed authority. The IT helpdesk agent shouldn't be able to issue refunds; the finance agent shouldn't reboot servers. One agent = one set of permissions, and that's almost never what you want.
Specialised prompting. A great IT-troubleshooting prompt looks nothing like a great HR-policy prompt. Cramming both into one system message is a compromise that helps neither.

The fix is the central insight of this course:

Key insight

Break the work into multiple specialised agents — each with focused tools, a focused prompt, and focused permissions — and put an orchestrator in front of them. The orchestrator (called a supervisor in the patterns we'll see in Module 7) routes each user request to the right specialist, and stitches results back together.

User

→

Supervisor
"who handles this?"

IT agent

HR agent

Calendar agent

Knowledge agent

The Jarvis architecture we're heading toward. Each specialist has its own tools, its own memory, and its own approval rules.

5. What every production agent needs

An agent that just runs the loop is a demo. To take it to production — which is the whole point of this course — you also need each of these layers:

Reasoning loop the LLM decides what to do next (Module 1, 3)
Tools how the agent acts on the world (Module 5)
Memory short-term & long-term recall (Module 6)
Orchestration multi-agent routing & handoffs (Module 4, 7)
Human-in-the-loop approvals before risky actions (Module 8)
Control plane deploy, scale, manage at runtime (Module 9)
Observability traces, evals, monitoring (Module 10)
Hardening security, cost, reliability (Module 11)

Each module of this course adds one of these layers. By the end, you can build all of it.

6. Vocabulary you should now own

If you can say what each of these means in one sentence, Module 1 has done its job. (Full definitions in the glossary.)

LLM agent
Tool
The agent loop (a.k.a. ReAct)
Workflow vs. agent
Supervisor / orchestrator
Multi-agent system

1. What we mean by "LLM agent"

2. The agent loop (a.k.a. ReAct)

3. Workflows vs. agents — when to use which

4. Why a single agent isn't enough

5. What every production agent needs

6. Vocabulary you should now own

Quick check