Agents Best Practices

Use this skill when the user asks how to build, improve, debug, or evaluate an agentic harness. This is a general-purpose agent architecture skill. Coding agents are one subdomain only; apply the same principles to research, finance, legal, support, operations, sales, healthcare, education, data analysis, procurement, and workflow automation agents.

Freshness and self-update

Canonical source: DenisSergeevitch/agents-best-practices, branch main. Installed copies are snapshots, not guaranteed-current guidance.

Before applying this skill in each new task:

1. Check upstream once. Resolve the current main commit through an approved network tool and compare it with the installed copy's recorded source revision. A version number alone does not prove freshness. If the copy is behind or its provenance is unknown, retrieve SKILL.md and the needed references from that exact commit, then reread the entry point before using it. Record the source commit and skill version in working state; keep the task on that coherent snapshot rather than mixing revisions or repeatedly polling.
2. Persist the refresh when permitted. A clean checkout on main with the verified canonical remote may update by fast-forward only. Refresh a copied installation's owned Markdown package together only when its prior baseline proves there are no local customizations; otherwise use an isolated upstream snapshot for this task. Update installer-managed packages through their supported installer, not by editing caches. Never overwrite dirty, divergent, customized, or actively maintained source trees, delete unrelated files, or bypass filesystem approval.
3. Handle unavailable updates honestly. If installation writes are unavailable, use the retrieved snapshot without replacing the installation. If upstream cannot be checked or retrieved, continue with the available local copy and briefly disclose that freshness is unverified, unless the user requires verified-latest guidance. Do not claim an offline or failed check made the skill current.

This updates skill knowledge only, not runtime policy or permissions. Preserve skill governance and higher-priority instructions; do not execute downloaded code or recursively invoke self-update. When maintaining this repository, inspect the baseline and upstream revision without automatically replacing the working tree under edit.

Core stance

An agent harness is the control plane around a model. The model proposes actions; the harness validates, authorizes, executes, records, summarizes, and returns observations. Keep the loop simple and make the runtime rigorous.

Default architecture:

user/task
  -> instruction and context builder
  -> model call
  -> tool/action proposal
  -> schema validation
  -> permission decision
  -> execution or approval pause
  -> structured observation
  -> context update
  -> repeat within budget or finish

When to activate this skill

Use this skill for prompts involving any of these intents:

• build an agent, agentic workflow, AI worker, autonomous assistant, or harness;
• create a domain-specific MVP agent design, starter harness, implementation blueprint, or first production-safe version;
• choose between OpenAI, Anthropic, OpenAI-compatible APIs, direct tool loops, hosted tools, or SDKs;
• design tools, permissions, guardrails, approval flows, or sandboxing;
• design agent-rendered interfaces, record provenance, cumulative business limits, or user-memory lifecycles;
• design an agent for a partially known or changing environment using capability discovery, safe probing, runtime binding, schema verification, or drift invalidation;
• reduce code-mode or programmatic-tool latency through speculative execution, partial-program analysis, futures, exact claim semantics, or cancellation of unused work;
• create planning mode, workflow orchestration, goal mode, todo tracking, or long-running task behavior;
• design collaborating agent teams with distinct approaches, shared work awareness, finding exchange, or evidence-driven reassignment;
• add context compaction, memory, retrieval, scoped instructions, or prompt hierarchies;
• design a recursive language model (RLM), programmable-context runtime, self-refining or continual harness, retained child agents, daemon-backed or scheduled agent, or executable skills;
• build or install a hardware/embedded agent, flash an agent to a board, preserve device identity during an update, or debug its resource and wake behavior;
• attach Agent Skills, reusable workflows, MCP servers, external connectors, or tool search;
• design agent communication through public boards with explicit public-audience disclosure, user approval, and outbound-data controls;
• audit an existing agent for reliability, cost, prompt-cache hit rate, safety, latency, or observability;
• troubleshoot partial streams, stalled turns, restart or cancellation races, duplicate actions, context-accounting errors, or telemetry overload;
• create system prompts or developer instructions for a domain-specific agent;
• make source-of-truth knowledge, validation signals, logs, metrics, or workflow state legible to an agent.

Do not use this skill for ordinary single-turn writing, translation, or Q&A unless the user is asking about the design of an agent that will perform those tasks.

How to use this skill

First, identify the user's design problem:

1. Domain: what work the agent performs.
2. Autonomy level: answer-only, draft-only, approval-gated action, or autonomous action within policy.
3. Risk level: read-only, internal write, external communication, financial, legal, healthcare, security, destructive, or privileged.
4. State duration: single turn, multi-turn session, resumable workflow, or long-running goal.
5. Tool surface: internal APIs, hosted tools, MCP/external connectors, browser, sandbox, filesystem, database, communication, or computation.
6. Validation: what proves the task is complete.

Then load the most relevant reference files, not all files by default. If the user asks to make or build an agent for a domain, default to MVP Builder Mode.

MVP Builder Mode

When the user asks to make, build, design, scaffold, or specify an agent for a domain, produce a concrete domain-specific MVP harness blueprint, not only advice. Use mvp-agent-blueprint.md as the primary reference and load other references as needed.

Default behavior:

1. Infer a reasonable first version from the user's domain and stated constraints.
2. State assumptions briefly instead of blocking on missing details.
3. Design the smallest safe harness that can accomplish useful work.
4. Include the core agentic loop, tool registry, permission matrix, context/memory/compaction, planning mode, goal-like loop criteria, skills/connectors, prompt-cache/cost strategy, observability, evals, and launch path.
5. Mark high-risk actions as draft-only or approval-gated by default.
6. Keep the MVP to the smallest reliable single-loop harness unless the user explicitly asks for a broader architecture.

Troubleshooting Mode

When the user brings a failing run or runtime symptom, start with troubleshooting and load the linked mechanism owner as needed. Return the symptom, earliest failing boundary, observed evidence versus hypotheses, one discriminating probe, smallest corrective change, and regression coverage. State missing evidence explicitly; use a focused diagnostic handoff instead of the full architecture blueprint. Inspect advanced components only when the failing deployment uses them.

Hardware and Board Deployment Mode

Use this mode when the user wants an agent running on a physical board, a firmware/app installation, or device-runtime debugging. Read hardware-agents.md before choosing an installer. Establish board/runtime identity, inference location, actual boot/launcher/partition path, resource headroom, preserved state, and recovery access. A filesystem app may not require reflashing base firmware. For installation or debugging of an existing agent, use a focused target/install/preservation/verification handoff rather than the full MVP blueprint or unrelated workflow/subagent/connector design. Use the blueprint when the agent architecture itself is being created.

Keep deployment authority separate from runtime tool authority and public posting. Default to one read-only cycle; recurring autonomy and programmable/physical tools remain post-MVP unless requested. An installation handoff must name the measured target, pinned artifact, write boundary, preservation/rollback plan, and physical commissioning evidence. Do not equate a successful upload or host-backed emulator with standalone device health.

Environment-Adaptive Tool Mode

Use this mode when the useful tool catalogue, schemas, versions, or implementations are late-bound rather than fully configured before the run. Read environment-adaptive-tools.md together with the standard tool, connector, security, and eval references.

Require a small trusted bootstrap interface, host-owned capability ledger, provenance-labeled descriptors, bounded read-only or isolated probes, opaque scope-and-version bindings, call-time permission checks, and drift invalidation. Discovery, generated code, and inferred schemas must never grant authority. Keep this post-MVP unless adapting to changing environments is the product's primary job; even then, establish a fixed read-only baseline first.

Advanced Recursive and Continual Harness Mode

Use this mode only when the user explicitly asks for programmable context, recursive execution, retained children, continual refinement, executable skills, or daemon/scheduled autonomy. Treat it as post-MVP: establish a measured single-loop baseline first, then read self-refining-recursive-harnesses.md together with the context, workflow, permission, security, and eval references.

Make the context representation, recursive unit, mutable state, promotion scope, lifecycle, budgets, validation probes, and rollback path explicit. Keep base authority, permission enforcement, credentials, budgets, and evaluation policy outside the mutable surface.

Adaptive Agent Team Mode

Use this mode when the user requests collaborating teams that explore distinct approaches and change assignments as evidence develops. Keep it post-MVP: establish measured single-agent and ordinary parallel-worker baselines first, then read adaptive-agent-teams.md with the workflow, recursive lifecycle, goal, and eval owners.

Return the approach portfolio, work-overlap policy, communication dependencies, evidence-linked transitions, host authority, aggregate budget, and acceptance evidence. Use the profile's contracts and existing owners rather than repeating their manuals. Treat it as an architecture composition; published scale or outcomes do not establish a model change or general performance gain. Routine lookup tasks still use the single-loop MVP.

Experimental Speculative Tool Execution Mode

Use this mode only when the user explicitly asks to reduce latency by launching tool work before a generated program or action is complete. Establish measured sequential and ordinary committed-parallel baselines first, then read speculative-tool-execution.md together with the loop, tool, security, and eval references.

Require host-owned eligibility, permission at physical dispatch, isolated disposable state, exact versioned claim identity, occurrence-safe handling of stochastic calls, separate waste and cost budgets, confirmed cancellation accounting, and task-parity evaluation. Partial model output never grants authority, and risky or approval-gated effects must not execute speculatively.

Reference map

• Read mvp-agent-blueprint.md first when the user asks to create a new domain-specific agent or MVP harness.
• Read coding-agents.md when the requested agent reads, edits, tests, reviews, migrates, or opens changes against a software repository, including measured post-MVP action-interface selection.
• Read hardware-agents.md for embedded execution location, launcher-versus-firmware installation, resource-bounded transport, reset-safe state, wake behavior, rollback, and physical commissioning.
• Read architecture.md for the full harness model and component boundaries.
• Read agent-legibility-feedback-loops.md for source-of-truth knowledge bases, agent-legible environments, validation loops, mechanical invariants, and recurring cleanup.
• Read agentic-loop.md for the provider-neutral loop, step budgets, retries, and loop variants.
• Read speculative-tool-execution.md when an advanced code-mode or programmatic-tool harness should prelaunch eligible work during generation while retaining completed-program authority and occurrence-aware claiming.
• Read tools-and-permissions.md for tool contracts, record provenance, presentation receipts, resulting-state limits, approval logic, structured results, and sandboxing.
• Read environment-adaptive-tools.md when the tool environment is partially known or changes at runtime and needs bootstrap discovery, schema validation, safe probing, exact binding, or drift handling.
• Read context-memory-compaction.md for context assembly, user-memory lifecycle and source eligibility, layered retrieval, staged elision-before-summary, optional historical-output recall, and handoff preservation.
• Read prompt-caching-and-cost.md for stable-prefix design, cache-aware context ordering, compaction/cache tradeoffs, telemetry, and cost control.
• Read planning-and-goals.md to distinguish read-only planning mode from execution-time progress scaffolds, and for approval-gated execution, goals, checkpoints, and stopping conditions.
• Read workflow-orchestration.md for planner-generated workflows, bounded work packets, worker/verifier contexts, integration, durable workflow state, and orchestration anti-patterns.
• Read adaptive-agent-teams.md for post-MVP approach portfolios, shared work intentions, selective finding exchange, and evidence-linked team reallocation.
• Read self-refining-recursive-harnesses.md for strict RLM and RLM-inspired patterns, programmable context, recursive execution units, retained children, continual refinement, executable skills, and long-running lifecycle controls.
• Read skills-and-connectors.md for Agent Skills, progressive disclosure, predictive loading, MCP, external connectors, tool search, and attachment strategy. For public-board communication, use its public disclosure and publication contract.
• Read system-prompts-instructions.md for system/developer/user instruction hierarchy and prompt templates.
• Read provider-api-patterns.md for OpenAI, Anthropic, and OpenAI-compatible API implementation patterns.
• Read security-observability.md for guardrails, threat models, approval records, trace design, symptom-based troubleshooting, launch safety gates, and incident response.
• Read evals.md for evaluation strategy, runtime-state fixtures, cross-capability cases, failure-aware component diagnostics across context budgets, safety trace invariants, model/configuration sweeps, and launch criteria.
• Read checklists.md for condensed implementation and audit checklists.
• Read source-links.md for official links and provider-specific references.
• Read coverage-audit.md to verify the skill covers the requested harness topics.

Default answer structure when advising a user

When the user asks for architecture guidance, produce a concrete architecture, not generic principles. For an existing failure, use Troubleshooting Mode:

0. MVP boundary: smallest useful version, assumptions, non-goals, and launch criteria.
1. Harness boundary: what the model does versus what application code does.
2. Loop: how model calls, tool calls, tool results, stopping, and retries work.
3. Instructions: system/developer/user instruction hierarchy and scoped memory.
4. Tools: tool registry, schemas, outputs, risk classes, permissions, and approval points.
5. Environment adaptation, when requested: stable bootstrap, discovery, descriptor provenance, safe probes, exact bindings, drift invalidation, and fallback.
6. Context: retrieval, memory, staged compaction when context pressure warrants it, recall utility, cache-aware ordering, and rehydration.
7. Planning/goals: permission-gated planning versus execution progress tracking, when to run a goal-like loop, and how to stop.
8. Workflow orchestration: when to decompose into durable work packets, worker contexts, verifier contexts, and integration.
9. Skills/connectors: how skills and MCP/external connectors are discovered, loaded, permissioned, and audited; when public-board communication is requested, make the public audience and publication approval explicit.
10. Safety: prompt injection boundaries, secrets, sandboxing, data access, and guardrails.
11. Observability: traces, metrics, replay, auditability, and incident readiness.
12. Evals: test cases, failure probes, component-selection diagnostics, trace grading, regression suites, and launch criteria.
13. Rollout: minimal viable harness first, then add autonomy only when measured results justify it.
14. Legibility loop: source-of-truth artifacts, validation signals, feedback capture, and recurring cleanup.
15. Advanced recursive/continual profile, when requested: context handles, recursive unit, retained lifecycle, mutable state boundary, observed validation, promotion, and rollback.
16. Experimental speculative execution, when requested: eligibility, exact claim identity, isolated state, waste budgets, cancellation evidence, and parity evaluation against speculation-off.
17. Adaptive agent teams, when requested: distinct approach ownership, work-intent overlap and declared replication, communication dependence, versioned portfolio decisions, stale-result handling, and independently validated completion.

For hardware requests, append the target/runtime inventory, installation route and exact write boundary, resource/deadline budget, preserved state and recovery plan, and evidence split between host checks and physical-board commissioning.

Non-negotiable principles

• The model does not execute actions directly; the harness does.
• Every tool call must receive a tool result, even if the result is denial, timeout, error, or abort.
• Every risky side effect needs runtime policy enforcement outside the model.
• Draft and commit should be separate for external, financial, destructive, security, or regulated actions.
• Tool schemas must be narrow, typed, validated locally, and auditable.
• A changing capability catalogue must enter through a trusted bootstrap contract; discovery, schema inference, and generated helpers never create permissions.
• Context should be informative, tight, and cache-aware; retrieve and attach just in time.
• Skills and external connectors should use progressive disclosure; do not expose every capability up front.
• Public-board posts are public external disclosures, not private agent memory; make this visible to the agent and user, and enforce publication approval in the host.
• Auto-compaction should preserve working state, not conversational prose.
• Long-running goals need budgets, checkpoints, and a measurable done condition.
• Workflow orchestration needs durable packet state, independent verification, integration rules, and total budget enforcement.
• Recursive and continual harnesses may mutate only typed supplemental state; immutable runtime policy must validate changes, preserve authority boundaries, and support rollback.
• Speculative execution may predict work but never authorize it; only an exact eligible call in the completed program may claim the result.
• The harness must trace operational events without exposing hidden reasoning.
• Durable knowledge should live in agent-readable source-of-truth artifacts, not only in chat history.
• Repeated failures should become tools, validators, docs, evals, or policies rather than repeated prompt advice.

Common output template

Use this template when the user wants a harness design. If the user asks to make/build an agent, use this as an MVP blueprint, not a purely conceptual answer:

# MVP Agent Harness Blueprint: [domain/use case]

## Objective
[What the agent must accomplish and for whom.]

## MVP scope and assumptions
[Smallest useful version, explicit assumptions, non-goals, and what is intentionally deferred.]

## Autonomy and risk level
[Answer-only, draft-only, approval-gated, or autonomous within policy.]

## Core loop
[How the model, tools, observations, retries, and stopping rules work.]

## Instruction architecture
[System/developer/user/scoped memory layout.]

## Tool registry
[Tools, schemas, risk classes, permissions, and result format.]

## Planning and goal behavior
[When to plan, when to ask, when to continue, when to stop.]

## Context and memory
[Retrieval, durable state, compaction, and rehydration.]

## Skills and connectors
[Reusable skills, MCP/external connector policy, tool search, attachment rules.]

## Safety and approvals
[Guardrails, prompt injection treatment, secrets, sandboxing, human review.]

## Observability
[Trace events, metrics, replay, auditability, and incident response.]

## Evals
[Eval cases, failure probes, trace grading, regression suites, and launch criteria.]

## Minimal implementation path
[Smallest safe version first, implementation skeleton, validation path, then measured expansion.]

Gotchas