SDTK-AGENT
SDTK-AGENT is the cross-cutting orchestration layer above sdtk-code agent-team. It doesn't own one SDLC phase — it chains multiple steps, adapters, and human approval gates into one resumable run, driven entirely by a file ledger.
> A DAG CONTROLLER, NOT A CHATBOT MEMORY
A single agent-team run is great for one focused task. SDTK-AGENT sits above it: a stateless-CLI-over-file-ledger controller that chains several steps into one durable run, with human approval gates wherever a decision needs a person, and can resume from a completely different process because every command reads and writes the same on-disk state.
Without SDTK-AGENT
With SDTK-AGENT
Validates the workflow + runtime map, freezes both into a new run ledger. Does not execute anything yet.
run_id printed — the handle for every subsequent command.
Dispatches every ready task through its mapped adapter (manual / shell / sdtk-cli / Hermes Kanban dry-run), applies the state-machine reducer, and stops at the first block, wait, or completion.
state.json updated on disk — safe to stop and resume from a different process.
A human reviews a `human_gate` stage and writes an approval decision — approved, rejected, or needs_changes with notes.
approvals/<gate_id>.json — downstream tasks stay blocked until this exists.
Reads state.json + all evidence files and renders a final Markdown report of the whole run.
reports/final_report.md — a durable record, not a chat transcript.
When a solo founder reaches for this
You're evaluating an auto self-improvement workflow for a bot team: search the wiki, maybe do external research, synthesize a recommendation, get it approved, draft a spec and plan, get that approved too, implement, verify, get ops sign-off, then report. That's nine steps and three human checkpoints — too much for one chat session to hold reliably. sdtk-agent run start creates the ledger, run continue drives it forward one ready task at a time, and gate approve unblocks each checkpoint. Come back tomorrow, run continue again — it picks up exactly where it left off.
Product truth
These cards summarize the current shipped or internal surface exactly as it exists in the local source tree.
The shipped public package is sdtk-agent-kit with the sdtk-agent CLI: init, workflow validate, run start/continue/status/report, gate approve/reject, and adapter hermes-kanban plan. Zero new npm dependency — Node.js stdlib only.
Every command reads and writes the run ledger at .sdtk/agent-runtime/runs/<run_id>/ before it exits. There is no in-memory session — a run can be inspected, resumed, or driven forward from a completely different process at any time.
manual (human supplies evidence), shell (allowlisted binaries only), sdtk-cli (dispatches to other SDTK CLIs and normalizes their output), and hermes-kanban (pure dry-run card-plan compiler — no live gateway). The state machine evaluates skip_when, gates, and retries the same way regardless of adapter.
Core commands
Human gates
Hermes Kanban (dry-run only)
| Runtime | Project | User | Notes |
|---|---|---|---|
| Claude | n/a | n/a | Not runtime-aware — sdtk-agent installs no skills for either runtime. sdtk init still runs its (skill-free) init as part of the unified suite setup. |
| Codex | n/a | n/a | Identical behavior to Claude — the CLI and ledger are runtime-independent by design. |
Toolkit usage guide
products/sdtk-agent/governance/SDTKAGENT_TOOLKIT_USAGE_GUIDE.md
Full command reference, adapter details, workflow/runtime-map/evidence JSON schemas, ledger layout, safety model.
Package landing page
products/sdtk-agent/distribution/sdtk-agent-kit/README.md
npm-facing package truth for sdtk-agent-kit, including install/uninstall and quick start.
Runtime controller spec
governance/ai/reviews/shared/SDTK_AGENT_RUNTIME_CONTROLLER_SPEC_R1_20260630.md
The invariants (I-1..I-9), ledger schema, state machine, and adapter contracts this controller implements.
Position in the SDTK control plane
SDTK-AGENT is the orchestration layer that wraps every owner. It does not own one phase — it chains multi-step workflows across any of them, dispatching work through agent-team, shell commands, other SDTK CLIs, or a Hermes Kanban dry-run plan, with human approval gates wherever an owner needs to sign off.
Highlighted owners actively use SDTK-AGENT as their execution pack.
Family links
These product pages map the current suite boundaries so users can move from specification to coding to operations deliberately.
SDTK-AGENT delegates execution to sdtk-code's agent-team — it drives multi-step agent-team runs, it doesn't replace them.
Open page ->Paired capabilityThe other cross-cutting capability: SDTK-WIKI is the memory layer every workflow can read from; SDTK-AGENT is the orchestration layer that drives the workflow itself.
Open page ->Optional upstreamUse SDTK-SPEC first when the workflow you're orchestrating starts from a formal spec or handoff — SDTK-AGENT can dispatch to any SDTK CLI, including sdtk-spec.
Open page ->