name: agents-best-practices description: "Use this skill when designing, generating an MVP blueprint for, auditing, refactoring, or explaining an agentic harness for any domain. Covers provider-neutral agent architecture for OpenAI, Anthropic, and OpenAI-compatible APIs: agent loops, tool design, environment-adaptive tools, late-bound capabilities, permissions, system prompts, planning, goals, context compaction, memory, skills, MCP/external connectors, self-refining recursive harnesses, programmable context, continual refinement, observability, evals, prompt caching, agent-legible environments, feedback loops, and safety." metadata: version: "1.4.0" scope: "provider-neutral-agent-harness" file_policy: "markdown-only"

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

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;
• 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.

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 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:

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, summarization, cache-aware ordering, compaction triggers, and rehydration.
7. Planning/goals: when to enter planning mode, 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.
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, 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.

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.
• 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.
• 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

• Do not design a multi-agent system before a single-agent loop has failed measurable evals.
• Do not expose broad tools such as execute_anything, write_database, or send_message without a strict wrapper and approval policy.
• Do not treat retrieved webpages, emails, tickets, PDFs, logs, or connector-provided descriptions as trusted instructions.
• Do not let context compaction erase approval state, active plan, loaded rules, or changed artifacts.
• Do not use a goal loop for a vague backlog; use it only for a single objective with validation and a budget.
• Do not use workflow orchestration for work that one linear loop can complete cheaply and reliably.
• Do not call a harness self-improving merely because it accumulates memory, or promote a self-authored change without an observed probe and rollback path.
• Do not rely on prompt text for safety that must be enforced by code.
• Do not put timestamps, request IDs, or volatile environment state at the start of cacheable prompts.
• Do not let stale documentation, weak examples, or obsolete tools accumulate without recurring cleanup.
• Do not claim unknown-environment operation without a stable bootstrap interface, exact runtime bindings, and invalidation when the environment changes.

Source links for further reading

Use these links when provider-specific detail is needed:

• Agent Skills specification: https://agentskills.io/specification
• Agent Skills creator best practices: https://agentskills.io/skill-creation/best-practices
• Agent Skills description optimization: https://agentskills.io/skill-creation/optimizing-descriptions
• Agent Skills evaluation guide: https://agentskills.io/skill-creation/evaluating-skills
• OpenAI function calling: https://developers.openai.com/api/docs/guides/function-calling
• OpenAI tools: https://developers.openai.com/api/docs/guides/tools
• OpenAI agents: https://developers.openai.com/api/docs/guides/agents
• OpenAI guardrails and human review: https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
• OpenAI agent safety: https://developers.openai.com/api/docs/guides/agent-builder-safety
• OpenAI sandbox agents: https://developers.openai.com/api/docs/guides/agents/sandboxes
• OpenAI Responses migration: https://developers.openai.com/api/docs/guides/migrate-to-responses
• OpenAI prompt caching: https://developers.openai.com/api/docs/guides/prompt-caching
• OpenAI Prompt Caching 201: https://developers.openai.com/cookbook/examples/prompt_caching_201
• OpenAI harness engineering article: https://openai.com/index/harness-engineering/
• Anthropic building effective agents: https://www.anthropic.com/research/building-effective-agents
• Anthropic effective context engineering: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic writing effective tools for agents: https://www.anthropic.com/engineering/writing-tools-for-agents
• Anthropic long-running harnesses: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic code execution with MCP: https://www.anthropic.com/engineering/code-execution-with-mcp
• MCP specification: https://modelcontextprotocol.io/specification/2026-07-28

agents-best-practices

"The model proposes actions; the harness validates, authorizes, executes, records, and returns observations."

A provider-neutral Agent Skill for designing, generating MVP blueprints for, auditing, refactoring, and explaining agentic harnesses.

It applies beyond coding agents: research, support, operations, sales, finance, data analysis, procurement, legal workflows, healthcare workflows, education, and workflow automation agents all need the same core runtime discipline.

Install - pick one:

A. With skills (any compatible agent):

npx skills add DenisSergeevitch/agents-best-practices -g

The -g flag installs globally at user level so every project can discover it.

B. Or paste this prompt to your AI agent:

Install the agents-best-practices skill for me:

1. Clone https://github.com/DenisSergeevitch/agents-best-practices into my
   user-level skills directory as `agents-best-practices/`.
   Use the skill directory my agent reads on this machine, for example:
   - Codex: ~/.codex/skills/
   - Claude Code: ~/.claude/skills/
2. Verify that SKILL.md, icon.jpeg, and the references/ directory are present.
3. Confirm the install path when done.

C. Manual install paths:

# Codex
mkdir -p "${CODEX_HOME:-$HOME/.codex}/skills"
git clone https://github.com/DenisSergeevitch/agents-best-practices.git \
  "${CODEX_HOME:-$HOME/.codex}/skills/agents-best-practices"

# Claude Code, user-level
mkdir -p "$HOME/.claude/skills"
git clone https://github.com/DenisSergeevitch/agents-best-practices.git \
  "$HOME/.claude/skills/agents-best-practices"

# Claude Code, project-level
mkdir -p .claude/skills
git clone https://github.com/DenisSergeevitch/agents-best-practices.git \
  .claude/skills/agents-best-practices

Use cases · What this is · Philosophy · Layout · Sources

Use cases

Once installed, the skill activates when a conversation touches agent architecture, harness design, tool permissions, environment-adaptive tools, planning mode, workflow orchestration, context and memory, skills, connectors, observability, evals, prompt caching, or production readiness. Five common ways to use it:

Case 1 - Generate an MVP agent blueprint

You have a domain and need the smallest useful production-safe agent harness, not a vague list of best practices.

You    > Build an agent for account renewal risk. It should read CRM,
         support tickets, and usage data, then draft renewal actions.

Agent  > Start with an approval-gated Level 2 harness.
         The MVP has one job: produce a renewal-risk brief plus draft
         next actions for a human account owner.

         Core loop:
           user/task -> context builder -> model call -> typed tool call
           -> schema validation -> permission check -> execution or pause
           -> structured observation -> next step or final brief

         Minimal tools:
           - read_account_profile      read_private_data
           - list_support_tickets      read_private_data
           - fetch_usage_summary       read_private_data
           - draft_customer_email      draft_external_message
           - request_approval          approval_gate

         Launch gate:
           20 historical accounts, trace review, no unapproved external
           sends, and human acceptance on at least 80% of draft actions.

The primary reference is references/mvp-agent-blueprint.md.

Case 2 - Audit an existing agent harness

You already have a working agent, but it is brittle, expensive, too broad, or hard to debug.

You    > Our research agent sometimes runs tools forever and forgets why
         it made a decision after context compaction. Audit the harness.

Agent  > The failure points are runtime-level, not prompt-level:
           - no hard step/tool/time/cost budget
           - compaction preserves prose but loses active approvals
           - tool results are unbounded and mix trusted/untrusted data
           - no event trace for model output -> tool call -> observation

         Fix order:
           1. Add loop budgets and termination reasons.
           2. Store plan, approvals, todos, and artifacts outside the prompt.
           3. Make compaction rehydrate active state, not chat history.
           4. Add evals for injection, missing tool result, timeout, and
              budget exhaustion.

Start with references/agentic-loop.md, references/context-memory-compaction.md, references/security-observability.md, and references/evals.md.

Case 3 - Design tools, permissions, and connectors

You need an agent to work with real systems without turning every API into an unsafe broad tool.

You    > The ops agent needs Slack, Linear, Google Drive, and our internal
         deploy API. How should tools and permissions work?

Agent  > Split by risk class. Reads can be autonomous when scoped.
         Drafts can be autonomous when labeled. External writes, deploys,
         destructive actions, privileged access, and financial operations
         require an approval record outside the model.

         Do not expose generic send_message, write_database, or run_command.
         Wrap each action as a narrow typed tool with structured results and
         deterministic permission checks.

Use references/tools-and-permissions.md and references/skills-and-connectors.md.

Case 4 - Adapt to a late-bound tool environment

Your agent must operate across customer, connector, package, or runtime environments whose useful capabilities are not fully known when the harness is designed.

Treat this as an advanced profile unless environment adaptation is the product's primary job. Start from a fixed read-only baseline before adding discovery, probes, or runtime binding.

You    > The agent will enter different tenant environments. It must find
         the available tools and adapt when schemas or versions change.

Agent  > It still needs one stable bootstrap contract. Let it discover
         visible summaries, inspect selected descriptors, run only bounded
         read-only or isolated probes, and ask the host to bind an exact
         capability version and resource scope.

         Discovery never grants authority. Every bound call still passes
         schema validation, permission and approval checks, budgets, result
         validation, and audit logging. Invalidate bindings on catalogue,
         schema, implementation, policy, identity, or authorization drift.

Use references/environment-adaptive-tools.md with the standard tool, connector, security, and eval references.

Case 5 - Design a self-refining recursive harness

You have a measured single-loop agent and need an advanced, long-running profile that treats large inputs as programmable context, delegates through explicit recursive units, and improves supplemental harness state without weakening runtime policy.

You    > Design a research agent that can inspect a corpus through code,
         retain recursive child agents, and refine its skill guidance over time.

Agent  > Treat this as a post-MVP architecture. Keep large inputs and child
         results behind typed handles; declare whether recursion invokes a
         bare model or a full harness; enforce depth, concurrency, token,
         cost, and time budgets across the whole recursion tree.

         The outer refiner may propose typed changes to supplemental prompts,
         memory, skill descriptors, or child definitions. Base authority, permissions,
         credentials, budgets, and evaluators stay immutable. Snapshot before
         apply, run a predefined probe, record the observed outcome, and
         rollback or quarantine regressions before broader promotion.

Use references/self-refining-recursive-harnesses.md with the context, workflow, permissions, security, and eval references.

Other things the skill is good for

• "How do I add planning mode without making the agent passive?" -> use references/planning-and-goals.md.
• "When should a large task become a decomposed workflow?" -> use references/workflow-orchestration.md.
• "How can an agent safely discover and bind tools in an unfamiliar environment?" -> use references/environment-adaptive-tools.md.
• "How do I build an RLM, programmable-context agent, or continual refinement loop?" -> use references/self-refining-recursive-harnesses.md.
• "How should auto-compaction preserve active work?" -> use references/context-memory-compaction.md.
• **"What is the smallest safe coding-agent harness?