Agent architectures

«Agent» is not an architecture but a family. Four patterns cover most of it:

The pattern	How	Suits	The cost
ReAct	one loop: think → act → observe	open tasks, few steps	low
Planner/executor	one model makes a plan, another (often cheaper) carries out the steps	tasks with a clear structure	medium
Reflexion	the agent criticises its own result and tries again	code, text that has to hold a quality	high (2–3×)
Multi-agent	specialised roles passing work between them	broad tasks with different competences	the highest

The rule that saves the most money: start with the simplest thing that could work. A single well-formulated LLM call beats an agent on most tasks. A ReAct loop beats multi-agent on most of the rest.

Planner/executor in detail: the planner produces a list of subgoals with dependencies (a small DAG), the executor solves one subgoal at a time with a limited set of tools, and a control loop decides whether the plan needs revising. The advantage is that the plan can be reviewed and stopped before anything is run — decisive when the steps have side effects.

Multi-agent is more expensive than it looks: every agent has its own context, and the information between them passes through natural language, which loses precision at every handover. The research shows mixed results — the gains usually come from the task having been split up, not from several models «collaborating».

Choosing in practice, three questions:

1. Can the task be solved with one call plus retrieval? → do that.
2. Are the steps known in advance? → write an ordinary pipeline in code, not an agent. Code is cheaper, faster and deterministic.
3. Are the steps unknown and dependent on intermediate results? → then, and only then, an agent.

The most common mistake in production is to use an agent where a pipeline is enough.