Retrieval, tools, workflows, or agents?

Match the pattern to the uncertainty

Long context is not a retrieval strategy

Putting every document into one prompt can work for a small, stable collection. It becomes harder to control as the corpus grows: irrelevant material competes for attention, access boundaries blur, cost rises, and updating one source may require rebuilding the entire request.

Retrieval creates a selection step. That makes freshness and citation possible, but also introduces a second system to evaluate. Measure whether the correct passages were retrieved before judging the final prose. Preserve document identity, version, and permissions alongside each chunk.

Tools make capability explicit

A tool should have a narrow, typed purpose: look up an order, calculate a total, create a draft, or fetch an approved document. Validate the tool’s arguments and response outside the model. Separate read tools from write tools. For changes that send, publish, purchase, delete, or alter permissions, require confirmation and an auditable event record.

The Model Context Protocol specification defines a protocol for exchanging context and capabilities between clients and servers. A protocol can standardize connection; it does not decide whether a tool is trustworthy, appropriately scoped, or safe for a particular user. Those remain application responsibilities.

A workflow makes the path inspectable

Use a fixed workflow when the stages are known. For example, an editorial pipeline can ingest sources, extract a claim ledger, flag unsupported claims, create a draft, run deterministic checks, request human approval, and only then publish. Each stage should have an input contract, output contract, failure state, and retry policy.

Make jobs idempotent: processing the same event twice should not create two publications or send two emails. Preserve durable state, stable event identifiers, and a recovery path. A timeout is not proof that an external action failed; reconcile against the external system before retrying.

Reserve agents for variable paths

An agent is useful when the next step cannot be fully enumerated in advance—for example, investigating an unfamiliar codebase or researching a question across heterogeneous sources. Even then, bound the objective, tools, time, cost, destinations, and stopping conditions. Use read-only access by default and split planning from consequential execution.

If the job is “take these fields, call this API, validate the result, and store it,” ordinary code is usually clearer. Agentic flexibility is not a quality badge; it is additional behavior to test.

Controls that travel with every pattern

• Least-privilege credentials and tenant-aware permissions.
• Input and output validation at trust boundaries.
• Explicit budgets for calls, retries, latency, and output size.
• Logging of source, model/version, prompt revision, tools, approvals, and outcome.
• Representative evaluations, including missing data and adversarial content.
• Rollback or compensating action for writes.
• A visible unavailable state when a dependency cannot be confirmed.

Use retrieval when the evidence is external, tools when the work touches systems, agents only when the path is genuinely variable, and human judgment when consequences exceed verified reliability.