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.
//
Search across all documentation pages
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.
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
No.
It is a scanning aid - each row reminds you a default exists and where the full detail lives.
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.
Stopping conditions first (finite runs), then scope, then context, then model policy.
An unbounded loop is the fastest way to burn trust and budget.
Defaults.
Override with an explicit, reviewed exception - not a silent local hardcode.
Whenever autonomy, tool surface, or routing policy changes, and after any incident whose root cause is a missing bound.
This page is category tables with links.
Best Practices restates the same ground as checkboxes for readiness reviews.
Sometimes partially (for example a max-iteration setting).
They never fully cover product-specific goal checks, scope, or model policy.
Yes - treat it as a starting template and attach your team's concrete numbers (turn caps, timeouts, model tiers).
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.
This section is the early, concept-level bound set.
Tech-lead rules go deeper on security, evals, and team process for production systems.
No.
Share the requirement for caps; tune numbers per risk and latency budget.
Document the conflict and pick a reviewed exception.
Conflicts usually mean scope or autonomy is still unclear.
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.
Reviewed by Chris St. John·Last updated Jul 16, 2026