Agentic Architecture & Orchestration

An agent is an LLM given a goal, a set of tools, and the ability to run in a loop: observe the current state, decide on an action, execute it (usually via a tool call), and repeat until the goal is met or a stop condition is hit. This is different from a single-shot prompt-response call, where the model produces one output with no ability to act on the world or revise its plan based on results.

The defining architectural property is the loop — an agent's own tool outputs become part of its next input, letting it course-correct. A chatbot with function-calling that stops after one tool call is not yet agentic in the full sense; a system that keeps calling tools and reasoning over results until done is.

• Narrow, well-named tools beat broad ones — a tool called search_orders is easier for a model to use correctly than a generic run_query that accepts arbitrary SQL.
• Tool descriptions are prompts — the model chooses and calls tools based on the description text, so ambiguous or incomplete descriptions cause wrong tool selection more often than model reasoning failures do.
• Return structured, bounded output — a tool that dumps an entire database table back to the model wastes context and increases the chance of the model losing track of the actual goal.
• Fail loudly and specifically — a tool that returns a vague error forces the agent to guess at a fix; a specific error ("order_id not found", not "error") lets the agent self-correct.

A single agent handles the whole task in one continuous context — simplest to reason about, but its context window fills up with every intermediate tool result, which can crowd out the original goal on long tasks.

A multi-agent (orchestrator/sub-agent) architecture splits work: an orchestrator agent breaks a large goal into sub-tasks and dispatches each to a fresh sub-agent with its own clean context. Sub-agents return a summary, not their full transcript, back to the orchestrator. This trades added coordination complexity for context isolation — each sub-agent stays focused and the orchestrator's context doesn't balloon with implementation detail it doesn't need.

Exam-style signal: if a scenario describes context getting "crowded" or a task naturally decomposing into independent parallel pieces, multi-agent orchestration is the architecturally correct answer over one large single-agent loop.

For any non-trivial multi-step task, an agent that plans explicitly before executing tends to outperform one that acts step-by-step with no upfront plan — the plan gives the agent (and a human reviewer) a checkpoint to catch a flawed approach before tool calls start mutating real state.

This is why many production agent architectures separate a planning phase (produce a task list, optionally get human approval) from an execution phase (work through the list, one item at a time, updating status as it goes) — rather than interleaving reasoning and irreversible actions from the first turn.

• Reversibility awareness — an agent should be able to distinguish an action it can freely retry (reading a file) from one it can't easily undo (deleting a record, sending an email) and treat the latter with more caution or require confirmation.
• Scoped permissions — tools should expose only what the task needs; a code-review agent does not need write access to production databases.
• Bounded loops — every agent loop needs a maximum iteration count or clear stop condition, or a stuck agent can burn tool calls indefinitely without making progress.
• Human-in-the-loop checkpoints — for high-stakes or hard-to-reverse actions, the architecturally correct pattern is a pause for explicit approval, not an autonomous action.

Every tool result, every sub-agent summary, and every turn of conversation consumes context window — the model's finite working memory for the current task. Good agentic architecture treats context as a budget to be spent deliberately: summarizing instead of passing raw data forward, discarding intermediate detail once its conclusion is captured, and isolating unrelated sub-tasks into their own contexts (via sub-agents) rather than letting one context accumulate everything.

A system that appears to "forget" earlier instructions on a long task is usually not a reasoning failure — it is a context-management failure, where important information was pushed out or diluted by less important accumulated detail.