Agent runtime patterns

Agent Runtime Patterns

When to use

• Optimizing a slow or over-spending agent loop (too many tool calls, high token use).
• Designing multi-agent orchestration topology for a new workflow.
• Managing MCP session lifecycle for experimental data-layer sessions.
• Reducing redundant search or file-read loops.

Core Patterns

Pattern	Use when	Avoid when
Direct execution	Single agent, clear scope, no subagent benefits	Task genuinely requires parallel sub-agents or specialized routing
Routing	Input type determines which specialized agent to invoke	Agents share context and can't be isolated
Chaining	Output of A is strict input of B	Agents need to share partial context
Orchestrator-worker	Parallel independent subtasks with a coordinator	Tasks are tightly coupled or sequential
Agents-as-tools	Callable child agent inside a parent's tool loop	The child needs user interaction

Knowledge Cards

A card is a compact, high-signal instruction block — typically 3–10 lines — for a specific operation. Cards are preferable to loading full documentation into context.

Good card: step sequence + key constraint + example invocation. Bad card: copied README sections, multiple unrelated topics in one block.

Pack cards for the current task only. Swap cards between phases rather than accumulating them.

Workflow

1. Identify the bottleneck — measure before optimizing: count tool calls, token usage, and latency. Name the specific slow or expensive step.
2. Choose the right pattern — use the table above. Default to direct execution; add orchestration only when simpler approaches are insufficient.
3. Pack knowledge as cards — replace large prompt docs with targeted 5–10 line cards per operation.
4. Bound search loops — cap retries (e.g., max 3 search attempts), normalize query construction, prefer a dedicated search subagent over inline ad-hoc loops.
5. Model MCP sessions explicitly — for experimental sessions: track create/delete lifecycle, request _meta session IDs, handle missing-session errors without silent retries.
6. Measure after — compare latency, tool-call count, token use, and task success rate before/after.

Safety Constraints

• Sandbox experimental runtime changes; do not deploy to production flows without verified before/after comparison.
• Do not add orchestration layers to compensate for unclear requirements — clarify the task first.
• Do not persist session state containing secrets without an explicit storage policy.
• Do not retry failed sessions silently; surface the error.

Validation / Done Criteria

• Measurable before/after evidence: fewer tool calls, lower latency, lower token use, or higher task success.
• Chosen orchestration pattern is named and justified.
• Session lifecycle and cleanup behavior are documented if MCP sessions were introduced.

References

• references/runtime-patterns.md