anastasiyaw/codex-claude-code-config/agents-best-practices

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.

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

Completion and reconciliation

For an action request, treat a discovered problem as a state transition, not a terminal report. Before calling the request complete, reconcile every required item using the contract in completion-reconciliation.md. Diagnosis-only internal gaps re-enter owned work; final prose is never a completion signal.

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 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;
• 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;
• attach Agent Skills, reusable workflows, MCP servers, external connectors, or tool search;
• audit an existing agent for reliability, cost, prompt-cache hit rate, safety, latency, or observability;
• 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.

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.

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.
• 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 completion-reconciliation.md when a request, rollout, bug fix, review finding, migration, or operational gap must advance from observed state to evidence-bound completion.
• 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, risk classes, 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, scoped memory, retrieval, auto-compaction, and handoff summaries.
• 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 for planning mode, 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 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, MCP, external connectors, tool search, and attachment strategy.
• 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, launch safety gates, and incident response.
• Read evals.md for evaluation strategy, adversarial test cases, trace grading, regression evals, and eval-driven 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 guidance, produce a concrete architecture, not generic principles: