LLM vs AI Agent: What Is the Difference?

Most confusion about AI agents comes from one mistake: thinking the LLM is the agent. It is not. The agent is the runtime built around the model, the loop that takes a tool call, executes it, hands the result back, and asks the model what to do next. Hold that thought; everything below is just making it concrete.

1. What an LLM really is

A Large Language Model is a statistical reader-writer. It has read a huge slice of the internet, compressed that reading into billions of weights, and given a prompt it predicts the next most-likely token, again and again, until a stop signal. That is the entire trick. No database lookup, no live browser, no knowledge base.

Every answer an LLM gives is a chain of these ranked picks, one token after another.

For a tester, the most useful framing: an LLM is a brilliant intern. Confident, articulate, well-read, and unable to verify anything it claims unless you give it a way to check.

The vocabulary you actually need

Term	Plain definition	Why a tester cares
Token	A chunk of text, roughly three quarters of an English word	Cost, speed and context windows are measured in tokens
Context window	How much text the model can see at once	Long DOMs and screenshots eat this fast
System prompt	Hidden instructions a tool sets before your turn	It is where the rules for your agent live
Temperature	How randomly the model picks the next token	For test code keep it low: determinism beats creativity
Tool call	The model emits a structured JSON request	The entire bridge between an LLM and Playwright

2. Where LLMs hit a wall

A model that has read the internet is still a model that cannot do anything in the world. Six honest limitations, and note how every single one is a gap a tool can fill:

No live world. Without a tool it cannot browse, query, or execute.
Hallucinations. It will confidently invent selectors, library APIs and URLs. Test code makes this easy to catch: hallucinations fail fast.
Knowledge cutoff. Anything released after training is invisible: new Playwright APIs, your last sprint's DOM.
No memory. Each request starts blank. State must be carried in the prompt or persisted by the runtime around it.
Limited context. A whole repo will not fit. Choosing what to show is itself a skill.
Cannot verify itself. It cannot run the test it just wrote. It needs an executor to close the loop.

Every limitation in that list is a gap you can fill with a tool.The reason agents exist.

Testing is a closed-loop discipline: write a check, run it, observe the result, decide. An LLM alone can only do the first step. The remaining three need something on the other end of a tool call.

3. The bridge: the formula on the whiteboard

LLM+ Memory+ Tools= AI Agent

Picture two robots. One has a head and nothing else: it can think but it cannot do. The other has the same head, plus a body, hands holding tools, and a notebook. Same brain in both. The difference is what surrounds it.

LLM = brain only

Reads, writes, reasons
Predicts the next token
Articulate and well-read

cannot click - cannot fetch - forgets every turn

AI Agent = brain + memory + tools

Same LLM brain at the core
+ Hands and legs (tools: browser, files, APIs)
+ Notebook (memory across turns and sessions)

can click - can fetch - remembers why it is doing this

4. The whole difference in one table

	LLM	AI Agent
What it is	A next-token predictor: a brain in a jar	That brain + memory + tools, inside a loop
Can think / write	Yes: reads, reasons, drafts	Yes: the same brain at the core
Can act in the world	No: cannot click, fetch, or run anything	Yes: tool calls drive a browser, files, APIs
Memory	Forgets every turn; each request starts blank	Carries state across turns and sessions
Live knowledge	Frozen at the training cutoff	Fetches the current state through tools
Can verify its own work	No: cannot run the test it just wrote	Yes: executes, observes the result, decides
For a tester	Writes the check	Writes, runs, observes, decides: the closed loop
Failure mode	Confident hallucination (invented selectors)	Caught fast: the invented selector fails on a real DOM
Example	"Write a login test" gives plausible code with guessed locators	A Playwright MCP agent opens the app, reads the real DOM, writes a passing test

5. So why does MCP matter?

Once you accept that an agent needs tools, the next question is wiring. The hard way: custom integration code for every tool in every host, a bespoke browser library here, a bespoke Jira client there, redone for Claude Code, Cursor, and every other app. It does not scale.

MCP (Model Context Protocol) solves it with one standard. Write a tool server once; every MCP-aware agent can use it. Ship a Playwright MCP server and Claude Code, Cursor and Claude Desktop all get browser automation for free. Switch models; your servers keep working.

	Without MCP	With MCP
Wiring	Custom glue code per tool, per host	One protocol (JSON-RPC) for every tool, every host
Reuse	Each app reinvents browser control, file I/O, API calls	Playwright MCP works in Claude Code, Cursor, Claude Desktop
Discovery	The model cannot list what tools exist	The model auto-discovers tool schemas at startup
Switching hosts	Rewrite every integration	Servers keep working unchanged
Tool authors	Target one app at a time	Ship once, reach every MCP client

The headline. Without MCP, every agent reinvents the wheel for every tool. With MCP, every agent gets every tool for free. The full protocol, the Playwright MCP server, and the hands-on labs are in the Playwright MCP Masterclass.

Where this fits

This page is the what. The natural next steps:

Prompt vs Skill vs Agent: how instructions graduate from a chat message into infrastructure.
Build a skill live: a Jira story into a PDF + XLSX test plan, and the free 36-skill QA suite.
The Playwright MCP Masterclass: the full course this page was distilled from.