Building Agent Tasks

“Building an agent” sounds like one decision. In practice it’s several separable ones, made independently and revisited on different schedules: how a tool is described to the model calling it, how the agent decides what to do next, how multiple agents divide a task between them if more than one is involved, and what gets remembered afterwards. Treating these as one decision is where agent projects tend to lose time, in the same way treating RAG as one architecture rather than four components does.

Tool schema: what a tool call needs to specify

A tool is only as reliable as the description the model is given of it. A schema that under-specifies what a parameter means invites the model to guess, and a model guessing at a parameter’s meaning fails silently rather than raising an error, since it has no way to know its guess was wrong. The description needs to state not just the type of each parameter but what values are valid and what happens at the boundary: a date field needs a stated format, not just “date”; a search tool needs a stated maximum result count, not an implicit assumption the model has to infer from context it wasn’t given.

The failure mode worth naming directly is a tool that does two things depending on how it’s called, a single “update” tool that creates a new record if the ID is missing and edits an existing one if it’s present. This kind of implicit branching is exactly the sort of ambiguity a fixed pipeline handles safely with an explicit conditional and an agent handles by guessing which behaviour it wanted, which is a good reason to keep tools narrow and single-purpose rather than saving on schema count.

Planning strategy: how the next step gets decided

The static-versus-dynamic question from the first article in this series applies again here, at a finer grain, inside a single agent’s own execution rather than at the level of choosing whether to build an agent at all.

ReAct, reason then act then observe then repeat, is the simplest version: the model states its reasoning, picks one action, sees the result, and decides the next action fresh each time. It’s straightforward to implement and to debug, since each step is visible and self-contained, and it pays for that simplicity in redundant reasoning: the model re-derives context on every loop that a system with an actual plan would only compute once.

Plan-and-execute separates the two: the model produces a full plan up front, then executes it step by step, replanning only if a step fails or the plan turns out to be wrong partway through. This is closer to the static end of the spectrum from piece one, applied within a single agent’s run, and it earns its keep on tasks where the overall shape of the work is knowable even if the specific details of each step aren’t, since committing to a plan avoids re-deriving the same reasoning at every step that ReAct pays for repeatedly.

Neither is a strict upgrade over the other. ReAct suits tasks where each step’s outcome genuinely changes what the sensible next step is; plan-and-execute suits tasks where the overall shape is known even if the details of each step aren’t.

Orchestration: how multiple agents divide the work

Once a task involves more than one agent, a further decision appears: how work moves between them.

Supervisor-delegate puts one agent in charge of breaking a task into subtasks and routing each to a specialised child agent, then assembling the results. This gives the cleanest separation of concerns, each child agent has a narrow, well-defined role, but the supervisor becomes a bottleneck and a single point of failure: if it misjudges how to break down the task, every downstream agent inherits that mistake.

Sequential handoff passes the task down a fixed chain, each agent doing its part and passing the result to the next, with no central coordinator. This is simpler to reason about than a supervisor pattern and easier to debug, since the flow of work is linear, but it has no mechanism for a later agent to send work back upstream if it discovers the earlier stage got something wrong.

Shared-thread dispenses with explicit handoffs entirely and lets multiple agents read and contribute to one continuous conversation. This is the pattern behind the finding in Agent Alloys or Persona Leakage?: agents sharing a single thread inherit each other’s reasoning and framing as though they’d produced it themselves, which reads as a bug from a separation-of-concerns standpoint and turned out, in the XBOW team’s exploratory security research, to be closer to a feature: the blending of approaches across models produced results neither model alone would have reached. Worth being precise about where that finding applies. It’s a reasonable trade for exploratory, generative work where diversity of approach is the point. It’s a poor fit for a task that needs an auditable record of which agent decided what, since a shared thread makes that attribution genuinely ambiguous after the fact, which is exactly the property governance in the previous article depends on.

Memory: which timescale the task actually needs

The fourth decision is which of the memory types covered in Memory in Agentic AI the task requires, at which timescale, and that piece is detailed enough to stand on its own rather than repeat here. The point worth restating in this context: memory is a separate decision from planning strategy and orchestration pattern, not a property that falls out of choosing one. A supervisor-delegate system and a ReAct loop can each be built with or without session memory, long-term memory, or episodic memory, and the choice should be driven by what the task actually needs to recall, not by whichever framework’s defaults happened to include a memory module.

The pattern across all four

Each of these four decisions can be changed independently of the other three. A team that gets the tool schema wrong doesn’t need to redesign the orchestration pattern to fix it; a team that picks the wrong planning strategy doesn’t need to rebuild memory. Debugging an agent that isn’t working starts with identifying which of the four is actually responsible, which is a more tractable question than asking whether “the agent” is good enough, since it points at a specific, replaceable part rather than the system as a whole.

(If you’re working through tool design, planning strategy, or orchestration for a specific agent build, get in touch.)