AI Agent Fundamentals Rules Best Practices
This page distills every rule list in the Agent Fundamentals Rules section into one standalone checklist - positive, enforceable practices for scope, stopping, context, and model policy.
It is meant for design reviews, production-readiness gates, and periodic audits - not as a one-time read.
How to Use This Checklist
- Work by category (A-F); new teams usually start with A and B before deep model routing.
- Require evidence for each checked item - a config value, code path, ADR, or eval - not a vibe.
- Use as a gate before any multi-turn agent reaches real users, real budget, or write tools.
- Revisit after incidents and whenever autonomy or tool surface expands.
A - Scope Fitness
- Confirm the problem needs mid-run branching or tool choice. Fixed paths stay scripts or workflows, not open loops.
- Write a pass/fail goal and an out-of-scope list before coding the loop. Done and not-done are reviewable artifacts.
- Match autonomy to reversibility and blast radius. Read-only or human-gated modes come before unsupervised writes.
- Cap the tool inventory to the stated goal. Extra tools require an explicit scope change.
- Refuse multi-agent splits until a single agent is bounded and measured. Complexity waits for fundamentals.
B - Stopping Conditions
- Enforce a hard max-turn ceiling in runtime code. Prompts alone do not stop loops.
- Enforce a wall-clock timeout for the whole run and for tools. Hung I/O cannot hide inside turn counts.
- Define success with a checkable predicate or oracle when possible. Free-text "done" is not enough for executable goals.
- Detect no-progress (repeated tool signatures or empty deltas) and stop or escalate. Polite infinite loops count as failure.
- Expose machine-readable stop reasons to logs and UX. Silent death is not an acceptable terminal state.
C - Context Discipline
- Structure stable policy into labeled sections with owners for changes. Unreviewed accretion is forbidden by default.
- Keep volatile facts out of the stable system policy blob. Dynamic data lives in turn state.
- Trim or summarize stale tool results on an explicit policy. Markers note omissions; dumps do not grow forever.
- Truncate or summarize oversized tool payloads at the adapter boundary. The model never receives unbounded raw responses by default.
- Restate the active goal at major phase boundaries on long runs. Local tool subgoals do not replace the product goal.
D - Model Policy and Cost
- Resolve models through logical policies or tiers, not scattered raw ids. Call sites request capability, not a hard-coded string.
- Default to the cheapest tier that meets the quality bar. Escalation requires sample evidence.
- Support fallback and runtime override without rewriting business logic. Outages and experiments stay config-level.
- Log resolved model id, policy name, and token usage per run. Cost and quality retros need facts.
- Re-eval tool-calling quality whenever the model map changes. Tiers are not interchangeable without proof.
E - Reliability Hygiene
- Classify tool errors before retrying. Not every failure deserves another turn.
- Prefer human handoff over silent infinite retry on high-stakes paths. Escalation is a designed outcome.
- Keep a minimal golden eval set for each agent. Even small oracles beat vibe-only shipping.
- Trace each perceive-reason-act cycle for failing runs. Unobservable loops are undebuggable.
- Environment-gate any "debug unbounded" modes. Production always remains bounded.
F - Team and Governance
- Assign an owner for fundamentals defaults (stops, scope template, model policy). Standards without owners drift.
- Turn each incident class into a rule or checklist item. One-off patches are not enough.
- Review fundamentals when autonomy, tools, or routing change - not only after outages. Cadence prevents surprise.
- Require documented exceptions for any rule override. Silent local hardcodes are decision drift.
- Keep the rule set small enough to remember and enforce. A manifesto nobody checks is not a control.
FAQs
How is this different from the Core Fundamentals quick-reference?
The quick-reference uses category tables with links.
This page restates the same ground as checkboxes for readiness reviews.
Do we need every checkbox before a prototype?
No.
You need them before real users, real budget, or write side effects.
Prototypes should still avoid unbounded production deploys.
Which category should we implement first?
Stopping conditions (B) and scope (A), then context (C), then model policy (D).
How do we prove a checkbox honestly?
Point to code, config, or a linked ADR - for example the module that enforces max_turns, or the policy map file.
Can framework defaults satisfy these items?
They can satisfy pieces (iteration limits).
Product-specific goal checks, scope, and model policy still need your team.
What if a checkbox conflicts with a stakeholder demo deadline?
Ship a narrow, bounded demo path; do not disable stops on the shared production worker to save a day.
How often should the checklist be re-run?
Before first production traffic, after material tool or autonomy changes, and on a fixed quarterly (or similar) cadence.
Is ten practices enough for the whole fundamentals group?
The title promises distilled practices; the lettered groups expand them into enforceable checkboxes covering the full section.
Should personal agents use the same list?
Yes, especially for shell or account access - blast radius is personal but real.
How does this page relate to later tech-lead production rules?
This is the early fundamentals gate.
Tech-lead sections add security, eval ops, and team process depth for mature systems.
What do we do with unchecked items?
Track them as explicit debt with owners and dates - not as quiet failures to ignore.
Can we fork this checklist for our company?
Yes.
Keep the categories; replace numbers (turn caps, tiers) with your standards and link internal runbooks.
Related
- Why Fundamentals Rules Prevent Early Agent Project Failures - why these checkboxes exist.
- The Core Agent Fundamentals Rules: A Quick-Reference List - table form with deep links.
- Scope Rules: When a Problem Actually Needs an Agent - detail behind category A.
- Stopping-Condition Rules Every Agent Must Implement - detail behind category B.
- Context Discipline Rules for Predictable Agent Behavior - detail behind category C.
- Model-Swapping Rules for Cost and Capability Flexibility - detail behind category D.
- Common Fundamentals Mistakes New Agent Builders Make - negative patterns these practices prevent.
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.