What agentic AI means

A customer emails: “I never got my refund — I expected it three weeks ago.” To answer, your system has to look up the order, check the refund status in Stripe, read the policy, maybe ping the billing team, and then write a reply. A single LLM call can’t do any of that — it can only produce text. An agent (in the software sense: a program that perceives its environment and acts on it) is an LLM that can also do something with that text — call a function, look something up, write a file, ask a human, call another agent — and then continue the conversation with the result.

The simplest agent loop is:

1. LLM receives a prompt.
2. LLM responds with EITHER a final answer OR a tool call.
3. If it's a tool call -> run the tool -> feed the result back to step 1.
4. Repeat until the LLM produces a final answer.

That’s the whole structural change. Everything else — frameworks, patterns, observability — is just managing this loop well.

Workflows vs agents (the distinction that matters)

Anthropic’s Building Effective Agents draws a line that’s now the standard vocabulary:

• Workflows — LLMs and tools are orchestrated through predefined code paths. The shape of the system is fixed by your code; the LLM fills in the blanks. Predictable, easy to debug, cheap.
• Agents — the LLM dynamically directs its own process and tool usage. The shape of each run is decided by the model. Flexible, but harder to reason about, more expensive, fails in more ways.

The thesis: start with the simplest solution that works. A single prompt beats a workflow. A workflow beats an agent. Reach for agentic autonomy only when the task genuinely needs unbounded steps and the model has to decide what’s next from real feedback.

The five workflow patterns plus the agent

Most production “agent” systems are actually one of these workflow shapes:

1. Prompt chaining

Decompose a task into a fixed sequence of LLM calls — each call processes the previous output. Add programmatic gates between steps. Good when sub-tasks are clear and accuracy benefits from focus (e.g. outline then draft then polish).

2. Routing

Classify the input, then dispatch to a specialized prompt or model. Good when inputs fall into distinct categories that benefit from different handling (e.g. refund queries vs. technical support).

3. Parallelization

Run multiple LLM calls concurrently. Two flavours: sectioning splits the task into independent parts; voting runs the same task many times and aggregates (majority vote, average, ranking). Good for speedups or for higher-confidence outputs.

4. Orchestrator-workers

A central LLM dynamically decomposes the task and delegates sub-tasks to worker LLMs, then synthesizes the results. Use when the sub-tasks aren’t knowable up front.

5. Evaluator-optimizer

One LLM generates, another evaluates, you iterate until the evaluator approves (or a budget runs out). Good when criteria are clear and iteration measurably improves quality (translation, code, structured extraction).

…and then “the agent”

The maximally flexible shape: an LLM in a loop with tools. The model picks the next action, runs it via a tool, reads the result, and decides again. This is the right answer when steps can’t be enumerated in advance and the model needs ground-truth feedback to plan.

When do you actually need an agent?

You don’t need an agent when:

• A single LLM call answers the question.
• The task is purely transformation (summarize, translate, classify).
• You can do it with a rules-based pipeline plus one LLM step.

You do need an agent when:

• The model needs current information (search, database).
• The model needs to compute something exactly (calculator, code).
• The model needs to act in the world (send email, update record).
• The task requires multiple decisions where each depends on the previous result.

The first two are tool use with a single LLM-tool-LLM cycle. The last two need a multi-step loop.

The frameworks you’ll see

There are four major frameworks covered in this section:

They all do roughly the same things; the choice usually comes down to which cloud you’re on and whether your team prefers declarative or imperative code.

What’s hard about agents

The honest answer: evaluating them. A single LLM call has one input and one output — easy to test. An agent has a loop, side effects, and non-deterministic intermediate states. Building good evals for agents is a discipline of its own (covered in the design patterns lesson).

You’ll also fight:

• Latency: 3–10 LLM calls per agent run is normal.
• Cost: same — multiply by the number of users.
• Reliability: tools fail, models hallucinate tool calls, JSON parsing breaks.

These are all solvable, but they’re real engineering work. You’ll notice that an agent is mostly plumbing — the LLM is a small part.

In one breath

• An agent is an LLM that can act, not just answer — it loops: respond with a final answer or a tool call, run the tool, feed the result back, repeat.
• Workflows orchestrate LLMs through predefined code paths; agents let the LLM direct its own process — start simple and escalate only when the task genuinely demands it.
• Most production “agents” are really one of five workflow patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — plus the open loop itself.
• You need a real agent only when steps can’t be enumerated in advance and the model must plan each next action from real feedback.
• An agent is mostly plumbing (loop, tool dispatch, context, stop conditions); the hard part is evaluating it, and “multi-agent” is rarely the right default.

Quick check

Next

The next lessons go through the design patterns above in detail, then into each framework, starting with LangChain.