Here is an agent, complete. The model picks a tool. The tool runs. The model reads the result and decides what to do next. Repeat until done.
That sounds too simple until you try to name the missing piece. Planning is deciding the next tool call with a longer prompt. Memory is text you put back in on the next pass. Multi-agent is one loop calling another and reading its output. There is nothing else underneath.
Holding the simple version changes how you debug. When an agent misbehaves there are only four places to look: the tool description was unclear, the tool returned something useless, the result got mangled on the way back, or the loop never ends. I have fixed far more agent bugs by reading what a tool actually returned than by rewriting a system prompt.
It also shows you where the real work is, and it is not the orchestration. It is the tools. A vague description gets called at the wrong moment. A wall of JSON burns the context the next decision needs. A tool that fails quietly teaches the model it succeeded.
Good agents are mostly a side effect of good tools. And tool design is ordinary API design: clear names, honest errors, small responses.
Frameworks are not useless. Retries, tracing and streaming are tedious to write. But they sit around the loop, they are not what makes it work.
Write the loop by hand once. It takes about forty lines. After that every framework is readable, because you can see which of your forty lines it replaced.