ModelRefs / Canonical Agent Patterns — Library
Canonical Agent Patterns — Library
The canonical agent-pattern registry: planning, tool-use, memory, multi-agent, reflection, safety, observability, and deployment patterns with components, control-flow, failure modes, and model compatibility.
What this reference supports
Canonical Agent Patterns — Library: This hub organizes related ModelRefs references into a crawlable starting point. Use it to narrow the problem, identify relevant profiles or guides, and continue into detailed evidence and implementation material.
Canonical Agent Patterns — Library: Items are connected across models, providers, benchmarks, workflows, tools, and guides. Those relationships explain where an option fits, what it depends on, and which adjacent decisions still need validation.
Canonical Agent Patterns — Library: Catalogue presence is not an endorsement or universal ranking. Compare candidates against your own requirements and review each page's sources, freshness notes, limitations, and coverage gaps.
All agent patterns (16)
Every published agent pattern.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Canonical Agent Patterns — Library.
Frequently asked questions
What is a canonical agent pattern?
A canonical agent pattern is a reusable architecture for an autonomous LLM-powered system — documenting its components, control-flow, failure modes, observability hooks, and safety controls.
What is the ReAct pattern?
ReAct (Reasoning + Acting) interleaves chain-of-thought reasoning with tool calls in a single generation pass. It is the most widely deployed agentic pattern for tool-using LLMs.
When should I use a multi-agent pattern?
Use multi-agent patterns when a single agent can't reliably complete a task end-to-end — complex decomposition, parallelism, or specialized sub-tasks that benefit from separate context windows and tool sets.
How do I choose an agent memory pattern?
Short-task agents need only working memory (context window). Long-running agents need episodic memory (vector store + summarization). Cross-session persistence requires structured external memory.
What observability does a production agent need?
At minimum: trace IDs per run, tool call logs with latency, token usage, error rates, and a replay mechanism. Add evals and LLM-as-judge scoring for quality monitoring.