The Core Agent Fundamentals Rules: A Quick-Reference List
This page condenses the fundamentals rules for scope, stopping, context, and model choice 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 agent.
- Treat each rule as a default - deviations need a deliberate, reviewed reason.
- Walk categories top to bottom for a first agent; walk only the category that failed for incident retros.
- Pair with AI Agent Fundamentals Rules Best Practices when you want checkboxes instead of tables.
- Revisit when autonomy level, tool surface, or model routing policy changes.
Scope Rules
| Rule | Default | Full detail |
|---|---|---|
| Prefer a script or fixed workflow when the path is known | Use an agent only when branching, tool choice, or mid-run observation is essential | Scope Rules |
| Require a written goal and out-of-scope list | If you cannot state done and not-done, do not grant a loop | Scope Rules |
| Match autonomy to reversibility | Higher autonomy only when actions are cheap to undo or human-gated | Scope Rules |
| Refuse agent scope for pure one-shot transforms | Single-shot LLM or code wins for format conversion without tools | Scope Rules |
Stopping-Condition Rules
| Rule | Default | Full detail |
|---|---|---|
| Always set max turns | No production agent runs without a hard iteration ceiling | Stopping-Condition Rules |
| Always set a wall-clock timeout | Turns alone miss slow tools and hung network calls | Stopping-Condition Rules |
| Define success and failure exits explicitly | Success is a goal check; failure is retry budget exhausted or hard error class | Stopping-Condition Rules |
| Detect no-progress loops | Identical tool calls or oscillating plans must abort or escalate | Stopping-Condition Rules |
| Prefer human handoff over silent infinite retry | Escalation is a valid stop, not a product failure | Stopping-Condition Rules |
Context Discipline Rules
| Rule | Default | Full detail |
|---|---|---|
| Structure stable instructions into named sections | Role, goal, constraints, tools, output format stay scannable | Context Discipline |
| Trim or summarize stale tool results | Keep recent, goal-relevant observations; mark omissions | Context Discipline |
| Separate stable system policy from volatile turn state | Dynamic data belongs in the user/turn payload, not growing system text | Context Discipline |
| Cap tool-result size before re-injection | Huge dumps get truncated or summarized at the tool boundary | Context Discipline |
| Refresh goal summary each major phase | Long runs restate current objective so older plans do not dominate | Context Discipline |
Model-Swapping Rules
| Rule | Default | Full detail |
|---|---|---|
| Select models through a policy interface, not scattered strings | Call sites request a tier or policy name, not a hard-coded model ID | Model-Swapping Rules |
| Start at the cheapest tier that meets quality | Escalate with evidence, not "safer feels better" | Model-Swapping Rules |
| Keep tool schemas and prompts provider-portable where practical | Avoid baking one vendor's proprietary request shape into core logic | Model-Swapping Rules |
| Support runtime override and fallback | Outages and cost shocks should not require a full rewrite | Model-Swapping Rules |
| Log model identity per run | Cost and quality retros need which model actually ran | Model-Swapping Rules |
Architecture and Loop Hygiene (from the fundamentals group)
| Rule | Default | Full detail |
|---|---|---|
| Pick architecture to task shape | ReAct for interactive tool use; plan-and-execute for longer multi-step work; multi-agent only with clear handoffs | See Architectures section |
| Bound every loop before adding tools | Tools multiply blast radius when stops are missing | Why Fundamentals Rules |
| Log each perceive-reason-act cycle | Unobservable loops are undebuggable loops | Loops section |
| Prefer one well-scoped agent before multi-agent | Split only after single-agent bounds are solid | Architectures 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, not a tutorial sequence.
A condensed reference orients readers the way a basics page would in a recipe section.
Which category should a new team implement first?
Stopping conditions first (finite runs), then scope, then context, then model policy.
An unbounded loop 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, or routing policy changes, and after any incident whose root cause is a missing 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).
They never fully cover product-specific goal checks, scope, or model policy.
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, timeouts, model tiers).
Why list architecture here if this section is about fundamentals rules?
Architecture choice is a fundamentals decision that interacts with stopping and scope.
Deep comparison lives in the Architectures section; this row only records the rule-level default.
How does this relate to tech-lead production rules later on the site?
This section is the early, concept-level bound set.
Tech-lead rules go deeper on security, evals, and team process for production systems.
Should every agent share the same numeric caps?
No.
Share the requirement for caps; tune numbers per risk and latency budget.
What if two rules conflict on a project?
Document the conflict and pick a reviewed exception.
Conflicts usually mean scope or autonomy is still unclear.
Related
- Why Fundamentals Rules Prevent Early Agent Project Failures - why this condensed list exists.
- Scope Rules: When a Problem Actually Needs an Agent - full scope criteria.
- Stopping-Condition Rules Every Agent Must Implement - full stop-condition enforcement.
- Context Discipline Rules for Predictable Agent Behavior - full context rules.
- Model-Swapping Rules for Cost and Capability Flexibility - full model-policy rules.
- AI Agent Fundamentals Rules Best Practices - checklist form of the same ground.
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.