agents-best-practices

Files (30)

• LICENSE
• README.md
• SKILL.md
• 01-use-cases.jpg · assets/agents-best-practices-illustrations/
• 02-workflow-orchestration-schema.svg · assets/agents-best-practices-illustrations/
• icon.jpeg
• adaptive-agent-teams.md · references/
• agent-legibility-feedback-loops.md · references/
• agentic-loop.md · references/
• always-on-agents.md · references/
• architecture.md · references/
• checklists.md · references/
• coding-agents.md · references/
• context-memory-compaction.md · references/
• coverage-audit.md · references/
• environment-adaptive-tools.md · references/
• evals.md · references/
• hardware-agents.md · references/
• mvp-agent-blueprint.md · references/
• planning-and-goals.md · references/
• prompt-caching-and-cost.md · references/
• provider-api-patterns.md · references/
• security-observability.md · references/
• self-refining-recursive-harnesses.md · references/
• skills-and-connectors.md · references/
• source-links.md · references/
• speculative-tool-execution.md · references/
• system-prompts-instructions.md · references/
• tools-and-permissions.md · references/
• workflow-orchestration.md · references/

SKILL.md (first lines)

# 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](https://github.com/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](references/skills-and-connectors.md#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:

```text
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;
- route model requests within a session, replay instruction/tool configuration changes, or evaluate paid cache warming;
- integrate or evaluate a backend whose generation state includes nontext latent positions and cannot be reconstructed from a text transcript alone;
- 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;
- build an always-on agent service or durable session with accepted-input receipts, task ownership, application state, restart recovery, reconnecting observers, or recurring source collection and delivery bookkeeping;
- 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, task-local harness search, retained child agents, 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;
- design or debug voice agents, speech pipelines, realtime turn taking, interruptions, playback, or corrections during tool work;
- 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;
- improve measured harness or application performance using validated benchmark proxies, production acceptance, and regression ratchets;
- 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](references/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](references/security-observability.md#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](references/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](references/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.

## Realtime Voice Agent Mode

For spoken interaction, read [realtime-voice-agents.md](references/realtime-voice-agents.md) with the tool and eval owners. Use it alongside MVP Builder Mode for a new voice agent or Troubleshooting Mode for an existing audio failure. Voice can be an MVP; independent backend orchestration and durable recovery are optional unless the selected architecture requires them.

Return the media topology, interaction/turn policy, execution placement, input and playback evidence, interruption repair, correction/result freshness, and audible-versus-task acceptance criteria. Reuse existing authority and task contracts; do not assume speech interruption cancels work or audio capability implies weaker reasoning.

## Always-on Agent and Durable Runtime Mode

Use this mode when the user requests an always-on service, recoverable sessions, accepted inputs during active work, durable task/application state, or observer reconnection. Read [always-on-agents.md](references/always-on-agents.md) with the loop, tool, context, security, and eval owners. Keep this post-MVP: measure a simpler request-scoped or resumable baseline first. Availability, persistence, inference activity, and authority are separate choices; ordinary always-on operation does not require recursion or self-refinement.

Return the acceptance and commit boundary, input/control lanes, owned task lifecycle, document scope and fork policy, observation/reconnection contract, resident ownership, recovery, and aggregate limits. Reuse the existing goals, permissions, compaction, and child protocols; a durable submission receipt or idle generation is not proof of completed work.

From SyntaxAsSpiral/ConSensus, MIT.

More from SyntaxAsSpiral/ConSensus