Agent Runtime Patterns

---
name: agent-runtime-patterns
description: Use when optimizing agent runtime loops, card packs, MCP session lifecycle, tool-call count, or multi-agent orchestration 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`