harn-agent

Harn agents

Use this skill for agent_loop, agent sessions, workers, supervisors, tools, completion, and lifecycle controls.

Pair it with [[harn-orchestration]] for workflows, [[harn-testing]] for deterministic evidence, and [[harn-product-quality]] for user-facing behavior.

Ownership

• Harn owns loop, lifecycle, transcript, replay, lineage, and audit semantics.
• Hosts expose concrete capabilities and native approval UX.
• Keep semantic policy in the runtime or harness, not duplicated in host prose.
• Give each behavior one owner and project its state to every client.
• Prefer a deep agent module with a small typed interface.
• Do not infer lifecycle state by parsing assistant text.

Session identity

• Give durable work a stable session id.
• Preserve parent/child lineage for delegated work.
• Carry workspace anchors and capability scope explicitly.
• Resume from durable state rather than reconstructing from UI messages.
• Treat transcript compaction as a state transition with continuity evidence.
• Keep secrets and provider credentials out of transcripts.
• Record the initiator and reason for lifecycle transitions.

Capabilities and approval

• Grant only the capabilities required for the task.
• Child policy intersects the parent ceiling; delegation must not widen it.
• Let agents act autonomously inside approved, reversible scope.
• Request approval for genuine ambiguity, destructive action, production impact, exceptional spend, or new authority.
• Do not request approval for every ordinary tool call.
• Make a rejected or expired approval a typed terminal or waiting state.
• Route mutations through host-owned capabilities so undo and audit remain native to the product.

Loop design

• Use agent_loop as the one public agent entry point. Use harness.llm.call or harness.llm.completion when the work is one model request, and keep interactive input and editor state in the host.
• Build the flat AgentSpec with agent_options or agent_preset. Use its named model, execution, capability, lifecycle, context, and observability component records at narrower boundaries.
• Bound iterations, tool duration, concurrency, tokens, and cost.
• Use adaptive iteration budgets only when progress signals justify extension.
• Register typed tools with closed input and result shapes.
• Feed dispatch errors back as structured observations.
• Use stop_after_successful_tools for terminal tools.
• Prefer lifecycle events and progress records over recurring prose nudges.
• Keep model routing and fallback policy explicit.
• Built-in presets use named catalog ladders. Override routing with one owner (provider + model, inline models, or ladder) rather than splicing a caller route into the preset's catalog route.
• Use a completion judge only for a claim it can actually evaluate.