Route work with ak:agentkit

Use ak:agentkit when a task spans several steps or domains and you need the shortest defensible route through the capabilities that are actually installed. The Skill classifies the work, selects one owner per step, adds verification for the risk, and reports gaps instead of inventing unavailable tools or Agents.

Choose ak:agentkit for routing decisions

Use ak:agentkit when

• The task is ambiguous, multi-step, multi-domain, or high risk.
• Several installed Skills could apply and their order matters.
• You need to decide whether a fresh-context Agent adds useful specialization, isolation, or parallelism.
• You want a visible route and verification contract before execution begins.

Choose another workflow when

• You named the Skill you want. Invoke that Skill directly.
• One installed Skill obviously owns a small, single-step task.
• You only need conversation, an opinion, or a factual answer.
• Work must run headlessly across CLIs or worktrees. Use ak:orchestrate.
• You need multiple coordinated sessions. Use ak:team.
• A missing capability must be discovered or installed. Use ak:find-skills.

Prepare the task and runtime

Complete Onboarding and install the Kit in the scope where you will work. Give the router an outcome, constraints, relevant domains, and any authority boundary around files, Git, services, money, or publication. It inventories the live runtime; names mentioned in examples are not proof that a capability is installed.

See Runtime adapters before assuming the same delegation or automation surface across providers.

Run the Skill

The Skill accepts the task to route. It defines no mode flags.

/ak:agentkit "Add subscription billing and a settings page; require tests and stop before deployment"

/ak:agentkit "Add subscription billing and a settings page; require tests and stop before deployment"

$ak:agentkit "Add subscription billing and a settings page; require tests and stop before deployment"

The first observable result should be a route record with workflow class, size, risk, and domain count. A trivial or obvious request should collapse directly to its owner instead of producing a long chain.

Understand the routing stages

1. Apply the proportionality gate. Direct requests and obvious single-Skill tasks bypass orchestration.
2. Classify the work. The router selects the final-deliverable class and grades size, highest-link risk, and number of domains.
3. Inventory installed capabilities. It checks the current runtime rather than routing from memory.
4. Build the shortest chain. Links follow an understand, decide, execute, verify, and deliver shape, but links collapse when they add no artifact or required evidence.
5. Delegate only at a trigger. Large investigations, disjoint implementation phases, completed implementations, high-risk delivery, or repeated failures may justify a specialist Agent.
6. Verify by risk. Low-risk work uses owner checks; elevated work adds verification and self-review; high-risk work adds independent review and a user decision before the irreversible step.

Long chains should pass durable artifacts by path. Each link needs named entry criteria, a verifiable exit, and one owner.

Keep authority with the user

The router itself is a decision layer. External effects come from the Skills, Agents, providers, and commands it activates. Delegation can add model runtime and cost; parallel work can also create conflicts unless file ownership is disjoint. High-risk actions remain blocked on explicit confirmation.

Verify the route and result

A useful run produces:

• The route classification and a concise ordered chain.
• Confirmed owners from the installed inventory, with missing capabilities named.
• Entry and exit evidence for each link that ran.
• Any Agents used, their bounded responsibility, and their findings.
• Verification matched to risk and a final outcome-first report.
• Remaining gaps, blockers, or actions still awaiting authorization.

Do not accept a route that assigns two owners to one link, assumes an uninstalled capability, skips required verification, or continues past the same failed link without new evidence.

Troubleshoot and limits

The router does not execute headless cross-runtime jobs, manage multi-session teams, or install capabilities by itself. Runtime projection is capability-specific, and Agent names are resolved from the live installation. The two release snapshots used for this page contain the same router workflow.

Continue with the Engineer Kit overview or review Installing kits.