Should guides for building AI agents be organized as a step-by-step timeline, or as a map of things you can tweak?
How do agent design frameworks differ in organizing guidance by phase versus customization type?
This explores two ways of structuring advice for building AI agents: ordering it by stage (what to do first, next, later) or sorting it by kind of change (instructions, knowledge, tools, oversight). The corpus has no paper that compares the two directly, but it has good examples of each.
This explores whether agent design guidance works better as a timeline (stages to move through) or as a map of layers (kinds of things you can change). No note in the collection puts the two side by side. Still, the corpus splits fairly cleanly between them, and the split shows what each approach is good at.
The 'customization type' approach is the more common one. Its basic move is to sort changes by where they live. Fin's Blueprint Team, a group at the customer-service AI company Fin, offers the simplest version: facts go in a retrievable knowledge base, and tone and behavior rules go in the agent's instructions Should factual content and behavior rules live separately?. Dubberly stacks capabilities from a basic chatbot up through system prompts and RAG on one axis, and from monitoring agents up through supervisors on another How should agent capabilities be organized into functional layers?. A survey of self-improving agents divides changes by update mechanism. The slow route changes the model's weights. The fast route changes prompts, memory, and tools, and that is where most recent progress has been, because it is cheaper and easy to undo Do self-improving agents really split into two distinct loops?. Another line of work says reliability comes from moving memory, skills, and interaction protocols out of the model and into a surrounding layer of support code (a 'harness') Where does agent reliability actually come from?. All of these are sorted by type. They tell you *where* a fix belongs, not *when* to make it.
The idea is older than LLMs. MOISE+, a 2002 framework for organizing teams of software agents, split a design into three parts: structure (roles and groups), function (shared plans), and rules (permissions and obligations) Can separating structure and function improve multiagent organization design?. Its argument for keeping these apart is still useful. If you mix them, agents end up without guidance, or a plan that was already checked gets lost when the structure changes.
The 'phase' approach is rarer, but it makes a claim the type-based frameworks can't: some things have to come before others. Humberd and Latham argue that monitoring must be in place *before* you try to align an agent's incentives, because you can't reward behavior you can't yet see or define Must AI monitoring precede incentive alignment as agents evolve?. Deloitte argues for redesigning the whole business process first, rather than adding agents onto existing workflows Does agentic AI succeed through process redesign or workflow layering?. Cocoa adds a twist. It treats planning and doing as alternating steps rather than fixed stages, so users can reassign or revise steps while the work is running Can users steer AI agents better by revising plans mid-execution?. That suggests phases are better seen as loops than as a one-way sequence.
The point that's easy to miss: type-based frameworks quietly assume the layers can be adjusted independently, and some evidence says they can't. In one study, labeling which agent is accountable for a result only changed outcomes when the workflow actually passed the deliverable through that agent Does accountability placement actually shape multi-agent outcomes?. A setting in one layer (who owns the result) only took effect through another (the order of steps). Cognition's Walden Yan makes a similar point about parallel subagents. Each one makes unstated assumptions that the others never see, so they drift into conflicting decisions Why do parallel subagents produce conflicting design decisions?. Splitting work by type without coordinating it over time creates the very problem the split was supposed to prevent. So a mature framework probably needs both: types to decide where a change goes, and phases to decide what has to be in place before that change will work.
Sources 10 notes
Fin's Blueprint Team recommends routing factual content to retrievable knowledge bases while keeping only tone and behavioral directives in agent instructions. This split aligns with instruction-tuning research showing models follow what-to-do rules better than what-to-ignore constraints.
Dubberly proposes a two-axis stack model: a capability axis (chatbot → system prompt → RAG) adding inputs that extend what LLMs can act on, and a scale axis (monitoring agents → supervisors → orchestrator) aggregating oversight. He cautions that ubiquitous agent hierarchies raise design risks alongside capability gains.
A survey framework organizes self-improving agents into two update mechanisms: slow parametric loops updating foundation model weights, and fast non-parametric loops updating prompts, memory, and tools. Recent progress concentrates in the fast loop because scaffold updates are cheaper and reversible than weight updates.
Research shows reliable LLM agents externalize three cognitive burdens—memory (state persistence), skills (procedural components), and protocols (structured interaction)—into a harness layer rather than relying on model scale alone. The harness unifies these externalities and eliminates the need for the model to solve the same problems repeatedly.
Hübner, Sichman, and Boissier's 2002 model splits organizational specification into structural (roles and groups), functional (global plans), and deontic (permissions and obligations) dimensions. This separation avoids failures where agents lack guidance or lose validated plans.
Show all 10 sources
Humberd and Latham argue that as AI becomes more autonomous, monitoring mechanisms must be established first as prerequisites to incentive alignment, because defining desirable AI behaviors is harder than for humans and AI decision-making becomes increasingly incomprehensible over time.
Deloitte argues many agentic AI implementations fail because organizations layer agents onto old workflows rather than redesigning operations. Success requires agent-compatible data architectures, robust orchestration, and new management models; HPE and Toyota illustrate this approach.
Cocoa's system, which lets users assign plan steps to themselves or an agent and revise plans mid-execution, afforded greater steerability than chat-baseline interaction in a lab study (n=16) while maintaining ease of use, with field users valuing explicit work delegation.
Ablation studies show RACI accountability tags change outcomes only when the collaboration protocol's control flow passes the deliverable through the accountable agent. The best placement varies by model family, requiring per-model validation rather than universal design.
Walden Yan argues multi-agent parallelism is fundamentally fragile: subagents embed unwritten assumptions in every action, so agents working independently converge on conflicting choices. The fix is reverting to single-threaded linear agents where context remains continuous.
Papers this line draws on 8
The research behind the notes this line reads — ranked by how closely each paper relates.
- Institutional AI: Governing LLM Collusion in Multi-Agent Cournot Markets via Public Governance Graphs
- Explaining AI Agents Through Execution Traces
- HumanAgencyBench: Scalable Evaluation of Human Agency Support in AI Assistants
- Comparing Human Oversight Strategies for Computer-Use Agents
- Drop the Hierarchy and Roles: How Self-Organizing LLM Agents Outperform Designed Structures
- Toward an Organizational Science of Multi-Agent LLM Systems: Decoupling Who, How, and Which Algorithm
- LatentSkill: From In-Context Textual Skills to In-Weight Latent Skills for LLM Agents
- Towards a Science of AI Agent Reliability