N Agentic Harnesses

Problem

Most AI products do not break because the model is too weak. They break at the harness layer: unclear tool boundaries, missing approval policy, brittle state, sloppy context assembly, no evaluation loop, and weak operator visibility. This skill turns those vague issues into concrete primitives, boundaries, phases, and checks.

Trigger Conditions

• The user is designing or rebuilding an agent, assistant, copilot, or AI workflow
• The request mentions harness architecture, tool-use architecture, tool registries, permission layers, approval gates, workflow state, session persistence, retries, resumability, memory, evals, observability, or multi-agent design
• The user wants to evaluate an existing harness for risks, missing primitives, UX gaps, or operational weakness
• The symptoms point to harness problems even if the word "harness" never appears:
  • tools fire without clear permission
  • sessions fail on crash or long waits
  • context gets stale or bloated
  • operators cannot see what happened or why
  • costs, retries, or handoffs are drifting out of control

Default Posture

• Bias toward lean, solo-maintainable architecture.
• Start with a single-agent design unless clear constraints justify more.
• Require an evaluation plan even for greenfield builds.
• Prefer explicit system boundaries, permission policy, and workflow state over prompt cleverness.
• Translate ideas into implementation phases, success criteria, and failure tests.

Step 0: Gather Context

Before routing, make sure you have enough to work with.

For design work, confirm:

• what product or system the harness serves
• what actions the agent will take
• who the users are
• any known constraints such as solo maintenance, existing stack, or timeline

For evaluation work, inspect the harness itself: