The Core Agent Rules: A Quick-Reference List
This page condenses the tech-lead production rules for models, tools, security, observability, and team process onto one scannable sheet.
It intentionally keeps explanations short.
Each row points to the article that owns full reasoning, examples, and edge cases.
How to Use This List
- Keep this page open during design review for any multi-turn or tool-using production agent.
- Treat each rule as a default - deviations need a deliberate, reviewed reason.
- Walk categories top to bottom for a first production agent; walk only the category that failed for incident retros.
- Pair with AI Agent Rules Best Practices when you want checkboxes instead of tables.
- Revisit when autonomy level, tool surface, model routing, or team ownership changes.
Model and Provider Rules
| Rule | Default | Full detail |
|---|---|---|
| Select models through a policy interface | Call sites request a tier or policy name, not a hard-coded model id | Model and Provider Rules |
| Default to the cheapest tier that meets the quality bar | Escalate with eval evidence, not "safer feels better" | Model and Provider Rules |
| Predeclare fallback chains | Outages must not require a rewrite or improvised model swap | Model and Provider Rules |
| Enforce spend limits and per-run budgets | Token and dollar caps fail closed when exceeded | Model and Provider Rules |
| Log resolved model identity per run | Cost and quality retros need which model actually ran | Model and Provider Rules |
Tool Design Rules
| Rule | Default | Full detail |
|---|---|---|
| One tool, one job | Split search vs mutate; ban kitchen-sink supertools in prod | Tool Design Rules |
| Validate args in host code | Schema, enums, bounds, and field-level errors before side effects | Tool Design Rules |
| Rank side effects | Reads auto; irreversible writes need gates or human approval | Tool Design Rules |
| Cap timeouts, payload size, and per-run tool budgets | Loops must not melt APIs or flood context | Tool Design Rules |
| Version tool contracts deliberately | Breaking changes get new names or dual-serve + eval | Tool Design Rules |
Security Guardrail Rules
| Rule | Default | Full detail |
|---|---|---|
| Least privilege on every credential and tool | No master keys; read tools cannot write | Security Guardrail Rules |
| Sandbox untrusted code execution | Container or microVM; network default deny | Security Guardrail Rules |
| Allowlist egress destinations | Named hosts only; block metadata and broad private ranges | Security Guardrail Rules |
| Treat model context as untrusted input | Validate outputs; do not obey tool or document instructions blindly | Security Guardrail Rules |
| No blanket shell in production | Prefer intent-shaped tools; break-glass only with approval | Security Guardrail Rules |
Observability and Eval Rules
| Rule | Default | Full detail |
|---|---|---|
| Trace every run with stable ids | Reconstruct goals, tool calls, model, and stop reason after incidents | Observability and Eval Rules |
| Gate deploys with a golden eval suite | Prompt, tool, and model changes do not ship on vibe alone | Observability and Eval Rules |
| Define SLOs for success, latency, and cost | Alert on burn, not only on process crashes | Observability and Eval Rules |
| Redact secrets from logs and traces | Observability must not become a secret store | Observability and Eval Rules |
| Keep stop reasons machine-readable | Silent death is not an acceptable terminal state | Observability and Eval Rules |
Team Review Rules
| Rule | Default | Full detail |
|---|---|---|
| Treat prompts and model maps as production code | Same review bar as high-blast-radius application code | Team Rules |
| Require a second reviewer for tool and autonomy increases | Privilege expansion is not a self-merge | Team Rules |
| Attach eval evidence to behavior-changing PRs | Diff alone does not prove quality held | Team Rules |
| Document exceptions with owner and expiry | Silent local hardcodes are decision drift | Team Rules |
| Assign owners for platform defaults | Standards without owners drift | Team Rules |
Loop and Reliability Hygiene (from fundamentals + production)
| Rule | Default | Full detail |
|---|---|---|
| Always set max turns and wall-clock timeout | No production agent runs unbounded | Fundamentals: stopping conditions |
| Prefer human handoff over silent infinite retry | Escalation is a designed outcome | Fundamentals + reliability sections |
| Match autonomy to reversibility | Higher autonomy only when actions are cheap to undo or gated | Fundamentals: scope rules |
| Prefer one well-scoped agent before multi-agent | Split only after single-agent bounds are solid | Architectures section |
| Enforce circuit breakers and tool timeouts | Hung tools cannot hide inside turn counts | Reliability section |
FAQs
Is this page a replacement for the full rule articles?
No.
It is a scanning aid - each row reminds you a default exists and where the full detail lives.
Why is there no basics page in this section?
This section is a rules capstone for tech leads, not a tutorial sequence.
A condensed reference orients readers the way a basics page would in a recipe section.
Which category should a new production team implement first?
Stopping and budgets first (finite runs and spend), then tool least privilege and security, then evals and review process.
An unbounded or over-privileged agent is the fastest way to burn trust and budget.
Are these rules mandatory or defaults?
Defaults.
Override with an explicit, reviewed exception - not a silent local hardcode.
How often should this page be revisited?
Whenever autonomy, tool surface, routing policy, or ownership changes, and after any incident whose root cause is a missing production bound.
What is the difference between this page and Best Practices?
This page is category tables with links.
Best Practices restates the same ground as checkboxes for readiness reviews.
Do framework defaults satisfy these rows?
Sometimes partially (for example a max-iteration setting or built-in tracing).
They never fully cover product-specific tool allowlists, spend caps, eval suites, or review process.
Can I paste this table into an internal ADR?
Yes - treat it as a starting template and attach your team's concrete numbers (turn caps, budgets, model tiers, approval matrix).
How does this relate to the fundamentals rules section?
Fundamentals rules are the early, concept-level bound set for a single agent.
This page is the production tech-lead set spanning fleet, security, evals, and process.
Should every agent share the same numeric caps?
No.
Share the requirement for caps; tune numbers per risk, latency, and cost budget.
What if two rules conflict on a project?
Document the conflict and pick a reviewed exception.
Conflicts usually mean autonomy or tool scope is still unclear.
Where do multi-agent systems fit?
Apply every single-agent row first, then add handoff contracts and per-agent budgets.
Multi-agent does not exempt you from these defaults.
Related
- How Opinionated Rules Prevent Agent Production Incidents - why this condensed list exists.
- Model and Provider Rules: Routing, Fallback, and Cost Discipline - full model and cost rules.
- Tool Design Rules for Safe, Composable Agents - full tool composition rules.
- Security Guardrail Rules Every Tech Lead Should Enforce - full security defaults.
- Observability and Eval Rules for Production Agent Systems - full tracing and eval rules.
- Team Rules for Reviewing and Approving Agent Changes - full review-process rules.
- AI Agent Rules Best Practices - checklist form of the same ground.
- The Core Agent Fundamentals Rules: A Quick-Reference List - earlier fundamentals quick reference.
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.