The core loop

Strip the marketing away and an agent is: give a model a goal, give it tools, let it choose one, feed the result back, repeat until done or out of budget. The patterns below are variations on where the thinking happens and who is allowed to stop it.

Start with the simplest thing. A single model call with good context beats a multi-agent system for most tasks, costs a fraction, and fails in ways you can diagnose. Add autonomy only where a fixed pipeline genuinely cannot express the work.

Tool use, with honest schemas

The model picks a tool by reading its name, description and parameter schema. Those descriptions are prompt text, not documentation — vague ones produce wrong calls, and the failure looks like the model being stupid rather than the schema being unclear.

Keep the tool surface small. Twenty overlapping tools produce worse selection than six well-separated ones, and every tool definition costs context on every single call.

Use it when the task needs current data or a side effect the model cannot produce from its weights.
The reason-act loop

The model alternates between reasoning about what to do and acting. Each observation goes back into context, so the loop is self-correcting when a tool returns something unexpected.

It needs a hard stop: maximum iterations, a wall-clock budget, or both. Without one, a model that cannot make progress will keep trying variations of the same failing call until you notice the bill.

Use it when the number of steps is not known in advance.
Planner and executor

Split the work: one call produces a plan, then cheaper calls or plain code execute the steps. The plan is inspectable before anything happens, which matters when the steps have consequences.

It also lets you use an expensive model for planning and a cheap one for execution, which is usually where the cost saving is.

Use it when steps have side effects, or someone needs to approve the approach before it runs.
Reflection, bounded

Have the model critique its own output and revise. It genuinely improves quality on writing, code and structured extraction.

Bound it to one or two rounds. Beyond that, quality plateaus and the model starts making changes for the sake of having something to say.

Use it when output quality matters more than latency and the task has a judgeable result.

Giving it the right context

Most agent failures are context failures. The model did not have the fact, had too much irrelevant text around it, or was given something stale.

Retrieval, and the chunking that decides its quality

Retrieval-augmented generation fetches relevant material and puts it in context. Its ceiling is set by chunking and ranking, not by the model.

Chunk on document structure — headings, sections, clauses — rather than a fixed character count that cuts a table in half. Combine keyword and vector search: pure vector search reliably misses exact identifiers, error codes and part numbers, which is exactly what people search for.

Use it when answers must come from a specific corpus rather than general knowledge.
Memory, deliberately scoped

Separate what persists. Working memory is the current task's context. Episodic memory is what happened in past sessions. Semantic memory is durable facts about the user or domain.

Persisting everything makes retrieval worse, not better, and turns a chat log into a personal-data store with a retention obligation nobody wrote down.

Use it when the agent should recall across sessions — and only then.

Control and safety

The question is not whether the agent will do something wrong. It is what it can reach when it does.

Approval gates on anything irreversible

Reads can be automatic. Writes that leave your system — sending an email, moving money, deleting a record, publishing — should pause for a human, showing exactly what is about to happen.

Make the approval specific. “Allow this agent to send emails” is not consent; “send this email, to this address, with this body” is.

Use it when an action is irreversible, outward-facing, or expensive.
Least privilege for tools

Give the agent a scoped credential, not yours. Read-only where reads suffice. Scope the database user to the tables it needs.

Prompt injection is a live threat, not a theoretical one: content the agent retrieves can contain instructions. Assume anything the model reads may be adversarial, and let the permission boundary — not the prompt — decide what is reachable.

Use it when always, and especially when the agent processes content from outside your organisation.
Evaluate, or you are guessing

Build a set of representative cases with known-good outcomes and run them on every prompt or model change. Without it, “the new prompt seems better” is vibes, and regressions ship silently.

Mix automated checks (did it call the right tool? is the JSON valid? does the number match?) with a small human-judged set for the qualities you cannot assert.

Use it when before the second prompt change, not after the first production incident.
Budget cost and latency explicitly

Agentic loops multiply token spend: every iteration resends the accumulated context. A task that costs cents as one call can cost dollars as a fifteen-step loop.

Cap iterations, cache what is stable, use small models for classification and routing, and measure cost per completed task rather than per call — that is the number that decides whether the feature is viable.

Use it when before launch. Cost surprises arrive at scale, not in testing.

Where to read more