Agents

Yesterday you defined steps and ran them. Today is what happens when you stop defining steps and hand over a goal instead. This is the most hyped word in the industry right now, which is exactly why it's worth learning properly rather than from marketing copy.

1. An agent chooses its own steps. That's the whole distinction.

Yesterday's workflow was a list you wrote and followed. Every decision about what happens next was made by you, in advance.

An agent is the opposite arrangement. You give it an outcome and constraints. It works out its own steps, picks its own tools, and continues until it decides it's done.

	You supply	It supplies
Workflow	The steps, in order	The words
Agent	The goal and the constraints	The steps, the tools, and the words

Every other definition you'll read is a variation on this one. When someone calls a product an "AI agent", the question that cuts through the marketing is: does it decide its own next step, or did somebody script the path? Plenty of things sold as agents are workflows with a chat box.

And the honest framing, which the industry mostly avoids: giving away step-by-step control is a real cost, not a free upgrade. It buys you the ability to handle situations nobody anticipated. It costs you predictability.

2. The four parts: model, tools, memory, loop.

An agent is not a different kind of AI. It's the same predictor from Day 1, wrapped in some machinery. Almost every agent you meet has these four parts, whatever the vendor calls them.

Part	What it does	You've already met it
Model	Does the reasoning and decides the next action.	Day 1
Tools	How it acts on the world — search, files, connectors, APIs, sending things.	Day 3
Memory	What it carries between steps and across runs.	New today
Loop	The machinery that runs it repeatedly until the goal is met or it gives up.	New today

Memory is the one worth pausing on, because Day 1 told you the model has none. That's still true — the model itself forgets everything. Memory in an agent is a separate system that stores things and feeds relevant bits back into the next step.

Two kinds, and the distinction matters: short-term is what's carried within one task, and long-term is what survives across runs. Long-term memory is an active area with dedicated products, and it's less solved than the demos suggest. An agent that "remembers your preferences" is doing storage and retrieval, not learning.

3. The loop itself — reason, act, observe, repeat.

The standard pattern has a name you'll see constantly: ReAct, short for reasoning and acting. It's the default architecture for most agents built today.

Everything impressive an agent does comes from that loop running many times. There's no other trick.

Which tells you where agents break. The model is still predicting at every pass, so a wrong turn at step three becomes the input to step four, and the loop carries the error forward and builds on it. Long chains give errors room to compound.

The counterweight is that observation is real feedback. An agent that searches and finds nothing knows it found nothing. Loops that check their own work against something external are meaningfully more reliable than loops that just think harder.

4. Autonomy is a dial, not a switch.

"Agent" gets used as if it's one thing. In practice deployed systems sit somewhere on a range, and knowing where yours sits is more useful than the label.

Level	What it means	Typical use
Suggest	It proposes, you do everything.	Drafting, research
Act with approval	It plans and executes, pausing at defined points for a human yes.	Most real deployments
Act, then report	It completes the task and tells you afterwards.	Low-stakes, reversible work
Fully autonomous	Runs on its own, indefinitely.	Rare, and mostly in demos

The pattern that dominates serious deployments is the second one: the agent runs, and stops at high-stakes points for a human decision. Some systems route to a human automatically when the agent's own confidence drops below a threshold.

That's the same approval gate from yesterday, in a new setting. It didn't stop being necessary because the system got cleverer.

5. One agent or several — and why multi-agent is usually the wrong first answer.

You'll see a lot of diagrams with several agents talking to each other — a researcher, a writer, an editor, a manager. The idea is specialisation: each gets a narrow job and does it better.

It genuinely helps on large problems spanning real domains. But it's oversold, and the reason is worth understanding.

Every handoff between agents is a place where context gets lost and errors get introduced. Production data consistently shows failures clustering at exactly those seams — handoffs, messy inputs, monitoring gaps. Adding agents adds seams. Coordination is not free, and on a task one agent could do, several agents is a downgrade dressed as sophistication.

The sensible order is: one model, then a workflow, then one agent, then several — and only move on when the simpler thing has actually failed for a reason you can name.

Where multiple models genuinely earn their place is something different, and it's section 7: not dividing labour between them, but using them to check each other.

6. How agents reach tools and each other: MCP and A2A.

On Day 3 you connected Gmail and I mentioned MCP — the Model Context Protocol — as the standard that lets an assistant talk to an outside service. That was the foundation for this.

Two protocols are worth knowing by name, because they answer two different questions:

The one-line version the field settled on: MCP connects agents to tools, A2A connects agents to peers.

You don't need to implement either. You need to recognise the names, and understand what they imply — the industry is building toward agents that call services and each other across company boundaries. The security questions that raises are real, largely unsettled, and a direct extension of the prompt-injection warning from Day 3.

7. A worked example: how I plan with several models, and the appeal loop.

Here's my own practice. Treat it as one person's method that has worked on fifteen products — not as the standard way to do this.

For anything that matters, I don't ask one model for a plan. The same brief — context, requirement, ultimate goal, constraints — goes into several of the strongest available models. Then I take one model's plan and give it to another to pull apart: what's wrong with this, what has it assumed, what breaks later. That runs a few rounds until the plans stop meaningfully changing.

When work is done, the agent that built it audits itself against the acceptance criteria first — but self-audit has an obvious hole. That agent has the whole build in its context, including every assumption. It can't be surprised by its own work. So a fresh model reviews it, and the handover is cheap because I already have three files: the requirement, the agreed plan, and the output.

Then the part I'd actually argue is the useful bit. When the reviewer raises a problem, I don't act on it. I take the objection back to the agent that did the work and ask what it thinks. Sometimes it agrees, and the fix is real. Sometimes it explains why the reviewer is wrong — usually because the reviewer never saw a decision made three phases earlier — and I take that explanation back to the reviewer.

Now the honest caveat, which I'd want you to know before copying me. Research through 2026 on using multiple models to judge work found that multi-agent consensus can produce artificial agreement — put models in a debate with assigned roles and they drift toward each other rather than toward the truth. Agreement rises; accuracy doesn't necessarily follow.

So the agreement is not the evidence. What you're hunting is the objection that survives. All of them agreeing immediately is the weakest signal, not the strongest — it usually means the brief was leading.

What I'm left judging is whether a defence actually addressed the objection or dodged it. That judgement has never moved to a model, and I don't expect it to.

8. The reliability problem, in numbers.

This section exists because the gap between agent demos and agent reality is the single most useful thing you can know this year.

Through 2026, roughly 88% of agent pilots never reached production — and the blockers reported were evaluation gaps, governance and reliability, not model capability. Production measurements put agent task success around 57%, with reliability decaying from about 60% to 25% across repeated runs of the same task.

That last figure is the one to hold onto. The same agent, on the same task, gets less reliable the more it runs. Something that worked in your test on Monday is not guaranteed on Friday.

None of this means agents don't work. It means the demo is the easy part, and the difficulty lives in evaluation, error handling and knowing where a human must stand — which is precisely the unglamorous material from yesterday.

It's also why I'd tell you to be sceptical of anyone showing you an impressive agent run once. Once is not a result. The question is what it does on the fortieth run, on messy input, when a tool returns something unexpected.

9. What this lesson did not cover, and how to go deeper.

This is an introduction to a field that's genuinely unsettled, and you should hold everything here loosely.

What we covered: the workflow/agent distinction, the four components, the ReAct loop, the autonomy range, single vs multi-agent, MCP and A2A, one worked practice, and the reliability picture.

What we did not, and you'll hit quickly if you build:

Where to go next. Anthropic's Building Effective Agents covers the boundary between workflows and agents well. The framework documentation above is written by people building this daily. And read the failure write-ups, not only the launch posts — they're more informative and there are more of them.

What I'll stand behind is the shape: goal instead of steps, the four parts, the loop, the autonomy dial, and the fact that reliability rather than capability is the live problem. That framing will still be useful when today's specific tools have been replaced — and at the pace this moves, some of them will be, within this internship.

Next — Day 7. You now have the whole loop: what these tools are, what to feed them, what to connect them to, how to judge output, how to make it repeatable, and how to hand over a goal. From here we stop studying the machine and point it at real marketing work.