It is easy to turn an agent architecture into a row of boxes: retrieve, analyze, plan, write, review. Once a box has a name, it begins to look like a necessary component.
But a capability and a physical module are different things. A task may require access to historical evidence without requiring a separate retrieval agent. Another may need several rounds of search. A third may legitimately use only the current material.
My design preference is to make responsibilities and boundaries explicit while allowing the execution shape to vary. This is an engineering position, not a claim that flexible topology is always faster or more reliable.
A boundary can outlive a workflow
Suppose two tasks share information about the same person. One writes a short family update. The other prepares a private work briefing.
They may share requirements: use only permitted sources, do not look into the future, preserve the subject of a statement, and report failures honestly. They need not share the same sequence of reasoning steps or the same amount of context.
The family update may benefit from careful recipient context. The briefing may need repeated retrieval and comparison. Making both pass through an identical series of agents can add overhead without solving either task's hardest problem.
The reusable object may be an evidence-access interface or a permission check, rather than an entire reasoning pipeline.
What I would make explicit
| Shared responsibility | Task-dependent choice |
|---|---|
| Which sources may be accessed | Which permitted source to inspect next |
| The decision's time boundary | Whether more evidence is worth seeking |
| The allowed actions and budget | How to compare eligible candidates |
| Evidence and output records | How much context to use |
| Truthful completion and failure reporting | Whether to express an optional observation |
This division is a starting point. Some tasks need stricter constraints on sequence, and some judgments cannot be reliably delegated. The point is to justify those constraints by the task rather than by the name of a box.
Begin with one real task
I would start by giving an agent the tools, evidence, and boundaries needed to attempt a concrete task. Then inspect the earliest actual failure.
If it cannot access a needed source, fix access. If it misinterprets a sentence, a new orchestration layer may not help. If it repeatedly forgets a mechanical constraint, deterministic enforcement may be appropriate. Those are different repairs.
A behavior appearing once is not a reason to build a permanent module around it. First ask whether removing or replacing that behavior changes the result. Then ask whether its contribution survives a different date, task, or user.
There is a cost to waiting: duplicated local solutions and less tidy diagrams. There is also a cost to extracting too early: every future task inherits assumptions that were never tested outside the first one.
A reusable capability needs more than a name
Before treating a capability as reusable, I want to know its inputs, permissions, observed contribution, known failures, resource needs, and conditions under which skipping it is reasonable.
“Personal understanding” is too broad to be a useful contract. “Can retrieve source passages for a disputed relationship claim under the current user's permission boundary” is more concrete. Whether it should be a tool, an inlined operation, or a separate agent remains an implementation choice.
Repeated use does not establish independent value either. A component can appear in every successful run because every run was forced to include it.
Keep the thin layer honest
A small shared runtime can still become a hidden product designer. It happens when seemingly mechanical checks begin deciding what counts as an interesting life event or the right emotional tone for everyone.
Those judgments deserve visibility. A validator can check whether a source exists. It cannot infer from that fact alone whether a person wants a message about it.
I want the common layer to make task decisions inspectable and enforce boundaries we actually understand. I do not want its tidy interfaces to disguise untested judgments as universal rules.
A useful architecture diagram shows who is responsible for what. It should not become a script that every future agent is required to perform.