"AI Engineering for Newbies: Agents, MCP, Tokens and Caching, With Numbers"

Open a large job board and search for job ads that mention "AI agent". As of October 28, 2026, there are 1,458 of them. LLM comes up in 1,261 ads, RAG in 520, MCP in 245. Now search for "prompt caching": 13 ads. Tokens are mentioned in 19.

Job board search, 2026-10-28.

That's an odd picture. The market wants agents built at scale. Yet almost nobody asks what an agent costs or why it works. Let's go through these terms one by one: what each one is, why it exists and what it looks like inside. Then we'll count the tokens and the money on a single agent task. With caching, the same task costs 6.6 times less, and you'll see why. There's a checklist at the end.

This is the first part of a series. In the second I'll cover reliability: durable execution, transactions and idempotency. In the third I'll show how a chain differs from an agent and put everything together in one application, using a support agent as the example.

TL;DR

• An AI engineer doesn't train their own model. They build a system around a ready-made one: feed it the right data, give it tools, check the result and watch the cost.
• The model remembers nothing and does nothing by itself. On every step the harness sends it everything again: the tools, the rules and the whole history.
• That's why, over 30 steps, the agent read 1.63 million tokens, even though it was never given more than 100 thousand at once.
• The cache reads the repeating start of a request at 5–10% of the price. But only if it matches the previous request down to the character. So put what never changes at the start and what is new at the end.
• Russian text costs about 1.27 times more Claude tokens than English.

What AI engineering is and why it concerns every developer

Chip Huyen explains the difference from machine learning well in her book "AI Engineering". An ML engineer trains the model: collects and labels data, trains, evaluates. An AI engineer takes a ready-made model that someone else trained, such as Claude or GPT. Their job is to ask the right question, give the model the data it needs and sometimes fine-tune it a little. For them the model is just an external service, like a database or a payment gateway. With one difference: it answers in text and sometimes gets things wrong.

For an ordinary developer this is no longer exotic. In the 2026 Stack Overflow survey, 73% of respondents said they write code with assistants and agents every day. The agents named most often were Claude Code (66%) and GitHub Copilot (59%). And in the 2025 survey the top complaint was "AI answers that are almost right, but not quite". 66% said so.

The gap between "almost" and "right" rarely hides in the prompt. For an agent to solve the task without eating the budget, you need to understand four things. What the model receives on each step. Who actually performs the actions. Where the agent usually goes wrong. And what each step costs.

Glossary

Term	In short
Token	a piece of text; the model reads in tokens, and money is counted in them
Context window	how many tokens the model reads in one request
System prompt	rules for the model, sent with every request
Tool use	the model asks for a function to be called, your code runs it
Chain and agent	the steps are written in code, or the model picks them itself
Agent loop	request → tool call → result → request again, until the task is done
Harness	all the code around the model: Claude Code, Cursor, your service
MCP	a standard for connecting tools and data to any AI application
Skill	a folder of instructions the agent reads only when it needs them
Subagent	a helper with its own context that returns only the result
Hook	your script on a harness event: block, ask a human, add context, check
RAG	find the right documents and put them into the request before answering
Eval	a set of tasks used to check that the agent has not broken
Prompt cache	the repeating start of a request at 5–10% of the price

The model and its context

Token. The model reads text not letter by letter and not word by word, but in pieces. These pieces are called tokens. Everything is counted in tokens: how much fits into a request, what the limits are and how much you pay. More on them in the section about tokens.

Context window. How many tokens the model reads at once, including its own answer. For most new Claude models it's 1 million. Filling the window to the brim is a bad idea. Every token costs money, and the longer the context, the worse the answers. Anthropic calls this "context rot".

System prompt. Rules for the model that come before the user's messages: who it is, what's allowed, what form the answer takes. In Claude Code, the repo's CLAUDE.md lands here too. The system prompt goes out with every single request, so you pay for each extra line in it again and again.

How the model acts

Tool use. This is how the model gets hands to work with. You describe a function: its name, what it does, what parameters it takes. For example, get_weather with a location parameter. The model doesn't run the function itself. It answers: "call get_weather for Paris". Your code calls the function and returns the result to the model. Anthropic calls this a contract: you decide what the model may do, and it decides when.

Chain (workflow, agents chain) and agent (AgentsLLM). In a chain the order of steps is written in code. For example: figure out what the request is about and send it down the right branch. An agent picks the order itself: which steps to take and which tools to call. A chain is more predictable and cheaper, an agent is more flexible. Anthropic advises starting with the simplest option. Often one well-built request to the model is enough.

Agent loop. The same thing repeats: request, tool call, result, request again. It goes on until the model answers with text. This loop is what turns a model with tools into an agent. Pseudocode and a diagram are below, in the section on how the system works.

Harness. All the code around the model. It builds the request, runs the loop, calls the tools, keeps the history and checks the actions. Claude Code, Cursor, the Agent SDK and your Python service are all harnesses. The same model behaves differently in different harnesses. In practice, the harness is what an AI engineer builds most of the time. Firecrawl's article "What Is an Agent Harness?" covers its parts in detail.

What extends an agent

MCP (Model Context Protocol). An open standard for connecting external systems to AI applications. It's often compared to USB-C. An application, for example Claude Code, connects to MCP servers. A server gives it tools, data and ready-made prompt templates. An integration with GitHub, a database or Jira is written once and works in any application that supports MCP. The standard changes fast. I rely on the version from July 28, 2026.

Skill (Agent Skill). A folder with a SKILL.md file, sometimes with scripts and reference files as well. At first the model sees only the skill's short description, about 100 tokens. It reads the full text, up to 5 thousand tokens, when the task matches the description. The other files cost nothing until they are opened. And if there's a script inside, only what it prints gets into the context.

How a skill gets into the context. Numbers from Anthropic's Agent Skills documentation.

Subagent. A helper with its own context and its own tools. The main agent gives it a task and gets back only the result. Why this matters: noisy work, such as searching the code or reading logs, doesn't clutter the main context. A subagent can be given a cheaper model. But its requests count toward the same limits.

Hook. Your script that the harness runs by itself when something happens. The model has nothing to do with it. There are many triggers: session start, a new user prompt, the moment before a tool call and after it, the end of a response, context compaction, a subagent launch.

The script receives JSON with the details as input: for example, which tool is being called and with which parameters. In response it can block the action: exit with code 2 or return deny with a reason, and the model will see it. It can hand the question to a human (ask) or allow it without an extra question (allow). It can add text to the model's context. Or it can simply do its own job: run a linter after a file edit, write the action to a log, send a notification.

Project hooks live in .claude/settings.json. Hooks that are mandatory for the whole company go into managed settings: a developer can't turn them off. There are also hooks that ask a model themselves when judgment is needed. But an ordinary hook works without a model and behaves the same way every time. That's how it differs from a line in the prompt: the model may skip an instruction, but a hook always fires. Rule of thumb: a skill advises, a hook guarantees.

Quality and data

RAG (retrieval-augmented generation). Before calling the model, the system finds the relevant pieces of documents and puts them into the request. The model answers from what was found, not from memory. More and more often agents are simply given a search tool and look things up themselves.

Eval (evaluation). These are tests for an agent. You collect tasks for which you know the right answer and run them after every change of model, prompt or tools. A normal test expects an exact result, while the model answers a little differently every time. That makes checking an agent harder. Huyen considers evaluation the main difficulty of AI engineering.

The cache got a single line in the glossary table. Judging by the job ads, it's asked about least of all, so it gets a section of its own.

How the system works

The model remembers nothing between requests. Everything the agent "knows" about the task, the harness collects and sends again on every step. A request is always built the same way: first the tool descriptions, then the system prompt, then the whole conversation history.

What an LLM system consists of. The model receives the assembled request and returns text or a request to call a tool.

In Anthropic's documentation the agent loop itself is an ordinary while. Here it's in pseudocode:

# Agent loop pseudocode
history = [user_task]
while True:
    response = model(tools, system_prompt, history)
    history.append(response)
    if response.stop_reason != "tool_use":
        break
        # the model answered with text: done
    results = [run(call) for call in response.calls]
    history.append(results) # tool_result blocks

The stop_reason field explains why the model stopped. If it's tool_use, the model wants to call a tool, and the loop goes on. Any other value, such as end_turn or max_tokens, means the model has finished or hit a limit. Then the loop ends.

Step 3 is run by the application code. This is exactly where a hook can block an action.

The loop itself is short. Almost all the work happens around it:

• tools: your own, those connected through MCP, and server-side ones that the vendor runs itself, such as web search or code execution;
• subagents: take a part of the work and return a short report;
• hooks: check actions before and after;
• memory: kept not in the model but in files and in git.

Anthropic explains why memory is needed in its article about long-running agents. Every new session starts from a blank slate. So the agent leaves the next session a progress file, a task list with statuses and the commit history.

You can see this in an ordinary Claude Code setup. In my personal repository, a hook before every Bash, Write and Edit call writes risky actions to a log. Another hook suggests, on every prompt, which model fits the task. There are three subagents: a cheap read-only one, a medium one and a strong one. And more than a dozen skills that load only when needed. It's all plain config files, yet they decide what reaches the model and what the agent may do.

A common trap: the agent confidently says "done", and only half the work is finished. In the same article Anthropic describes two typical failures. The agent tries to do everything in one go. Or it declares too early that it has finished. Pleading in the prompt barely helps. What helps is the harness: a list of requirements with statuses and a way to check the result. For example, running the tests or opening the application in a browser.

How tokens are counted

You pay for an LLM in tokens, and input and output tokens are priced differently. As of October 28, 2026, a million input tokens for Claude Sonnet 5.5 cost $2, and a million output tokens cost $10. Output is 5 times more expensive. Tool descriptions also count as input. In an example from the documentation, one tool with a short schema plus the user's question take 403 tokens together.

The model remembers nothing, so on every step it's sent the whole history again. Let's count on an illustrative example:

• at the start of every request there are 12 thousand tokens: tool descriptions and the system prompt;
• the user's first message takes 200 tokens;
• on each step the model replies with 400 tokens, and the tool returns another 2,500;
• 30 steps in total, on Sonnet 5.5.

Illustrative scenario. Sonnet 5.5 prices as of 2026-10-28.

On the last step the request weighs 96,300 tokens. That's less than a tenth of the window. But over all 30 steps the model read 1.63 million tokens, 17 times more. Every step pays again for everything that came before it, and the sum grows faster than it seems. Without the cache this task costs $3.38. The model's answers across all steps take only 12 thousand tokens together. Almost all the money goes to input.

A separate question is how many tokens Russian text takes. Different languages are split into tokens differently. In the study by Petrov et al. (NeurIPS 2023), the same text in different languages took up to 15 times more tokens. For Russian and English I ran a small measurement of my own. I took three pairs of identical texts: documentation, prose and code with comments. About 1,000 characters per language, Claude tokens.

Measured 2026-10-28. The sample is small; this is a reference point, not a study.

On the older models (Sonnet 4.6, Haiku 4.5), Russian text took 1.6 times more tokens than English. On the new Sonnet 5.5 the difference is only 1.27 times.

The interesting part is why. Russian barely changed: it was 402 tokens and became 415. English grew from 252 to 327, by 30%. This matches Anthropic's documentation: starting with Opus 4.7, the models split text in a new way and give about 30% more tokens for the same text.

So count tokens with the model you'll actually use. Anthropic has a free count_tokens endpoint for this. It gives an estimate, though, and doesn't take the cache into account.

How the prompt cache works

Back to the 1.63 million tokens. Almost everything the model reads on step 30, it already read on step 29: the same tools, the same system prompt, the same history. Only the piece at the end is new. The cache lets the server skip processing the repeating start again.

Block order and what resets the cache, per Anthropic's documentation as of 2026-10-28.

How it works. A request is always read in the same order: tools, system prompt, messages. You put a mark in the request showing how far to cache. There can be up to four such marks. Everything up to the mark is saved. The next request hits the cache only if its start matches the saved one completely, down to the character and down to the image. The cache lives for 5 minutes, and every hit extends it for free. For an extra fee it can be kept for an hour. Short requests aren't cached: new Claude models need at least 512 tokens. There's no error in that case; the cache simply doesn't turn on.

In our example with the cache, each step reads the old part at $0.10 per million and writes only the new piece to the cache. The total is $0.51 instead of $3.38, 6.6 times cheaper. The requests are exactly the same; only the way the server processes them changes. TensorMesh's "Prompt Caching Pricing at Anthropic" works out in detail when a paid cache write pays off. With Anthropic's five-minute cache, it pays off from the second request with the same start.

The cache is easy to break. Any difference at the start of a request wipes out everything after it:

• you changed a tool description: the whole request resets;
• you turned on web search or put the current time into the system prompt: the system prompt and the history reset;
• you changed tool_choice or added an image: the history resets.

One rule covers all of this: put what never changes at the start and what is new at the end. The start of a request must not contain dates, random IDs or reordered tools.

Checklist: ten practices for your first agent

1. Start with a single request to the model. A chain beats an agent as long as the task's steps can be written in code.
2. Put what never changes at the start of the request and what is new at the end. The system prompt must not contain the time, random IDs or other changing data.
3. Don't change the set or order of tools in the middle of a session.
4. Look at usage in every response. If cache_read_input_tokens is almost always zero, your cache isn't working.
5. Count tokens with the model you'll actually use. Different models have different tokens, and the difference reaches 30%.
6. Keep the history short. Hand noisy work like search and logs to subagents, and keep state in files, not in the conversation.
7. Move long instructions into skills, not the system prompt. Then every request carries only their short descriptions.
8. Make whatever must always happen a hook, not a line in the prompt.
9. Give the agent a way to check itself: tests, a build, a browser. Otherwise it will say "done" too early.
10. Connect MCP servers and skills only from sources you trust, and give the agent only the permissions it needs. Anthropic's documentation compares a third-party skill to a third-party program you install on your machine.

Which of these ten did you learn the hard way?

Series "AI Engineering for Newbies"

This is a series of three articles. Links to the other parts will appear here when they come out.

1. "AI Engineering for Newbies: Agents, MCP, Tokens and Caching, With Numbers" (you are reading it now)
2. "AI Agent Reliability for Newbies: Retries, Idempotency, Sagas and Durable Execution" (in progress)
3. "Agent Systems for Newbies: Chain or Agent, and Everything Together in a Support Agent" (in progress)