"Agentic" has been applied to enough products by now that it has almost stopped meaning anything. Some of what gets the label is a chatbot with a nicer input box. Some of it is a scheduled script with a language model in the middle.
We are going to use the word a lot at this chapter, so it is worth saying plainly what we mean by it.
Answering versus acting
A chatbot answers. You send text, it sends text back, and whatever happens next is your job. If it tells you the wrong thing, you have read something wrong.
An agent acts. It is given a goal instead of a question, and it has real capabilities: it can read a file, call an API, run a query, open a pull request, send a message. If it gets something wrong, something in the world is now wrong.
That is the whole distinction, and everything difficult follows from it.
The loop
Underneath, an agent is a loop that is easier to describe than to run well:
- Look at the goal and at what has happened so far.
- Decide the next action.
- Take it, using a tool.
- Read what came back.
- Decide whether the goal is met. If not, go to step 1.
Nothing there is exotic. What makes it hard is that step 3 is real, step 4 is often ambiguous, and step 5 is a judgement call made by something that cannot reliably tell you how confident it is.
A single wrong answer from a chatbot costs a retry. A wrong action at step 3 on iteration four, in a loop that then runs eleven more iterations on top of it, costs an investigation.
The hard part is not the model
This is the thing we most want to get across, because it is where people are surprised.
Teams generally get a demo working in a week. The demo is genuinely impressive. Then they try to run it for real, and every problem that shows up is an infrastructure problem:
- Identity. The agent needs access to a database. Whose access? Yours, delegated to it? Its own service account? For how long, and how do you revoke it at three in the morning?
- Observability. It failed. Which of the nineteen steps failed, what did it see at that point, and what did it decide because of it? Application logs will not tell you this, because the interesting state is a conversation.
- Cost. A loop that reconsiders too much costs real money, and the bill arrives at the end of the month rather than at the moment of the mistake.
- Determinism. Your test suite assumes the same input produces the same output. It does not.
- Blast radius. What is the worst thing this can do if it misreads a response? If you do not know, you have not finished building it.
None of these get better when the model gets better. They are the reason the AAIF working groups are named after reliability, identity, observability and security rather than after capability.
Why standards arrived so quickly
The first wave of agent tooling wired everything by hand. Every agent had its own way of describing a tool, so an integration written for one was worth nothing to another. With four agents and six tools that is twenty-four bespoke connections, all of which break separately.
The Model Context Protocol exists to make that a one-sided problem. Describe your tool once, in a standard way, and any client that speaks the protocol can use it. It is the same trade that made Language Server Protocol worth adopting: agree on the interface, and the number of things you have to build stops multiplying.
AGENTS.md does the same thing pointed the other way. Instead of describing a tool to an agent, it describes a repository: how to build it, how to test it, what not to touch. One file, in a predictable place, that every coding agent can read.
The pattern in both is worth noticing. Neither is clever. Both are agreements.
If you are starting from zero
You do not need a research background for any of this. Two things carry most of the way:
Build something small that actually acts. Not a chatbot. Give it one real capability, on data you own, where the worst case is embarrassing rather than expensive. You will learn more from one agent that can genuinely break something than from ten that only talk.
Then read what came back. Log every step, every tool call, every result, and go through the trace of a run that failed. That habit is most of the difference between people who ship agents and people who demo them.
Bring what you find to a meetup. The failure modes are the interesting part, and nobody has seen all of them yet.