TAKT—TAKT Agent Koordination Topology—is an open-source orchestration CLI for running coding agents through explicit, versioned workflows. Rather than asking one agent to decide when planning, implementation and review are complete, a YAML workflow defines steps, personas, permissions, transitions and terminal states. Current provider surfaces include Claude, Codex, OpenCode, Cursor, GitHub Copilot CLI and Kiro, with configuration varying between SDK/API-key and external-CLI integrations.
TAKT’s value is process repeatability, not extra model intelligence. It can make review loops visible, isolate tasks in Git worktrees and preserve run records, but it cannot guarantee that an agent’s status judgment is true or that a passing test proves correct software. Teams still own specifications, tool permissions, independent validation, secrets, merge controls and the operational cost of multiple model calls.


From chat request to governed change
user / issue
|
v
TALK: refine scope
|
QUEUE: immutable task record
|
RUN in isolated worktree
|
.----+---------+----------.
v v v
plan ------> implement --> review
^ | |
| v +--> COMPLETE
'----------- fix loop +--> ABORT
|
v
independent tests + human merge
The project describes a Talk–Queue–Run pattern. Interactive chat refines a task; queueing records it; execution runs the configured workflow in an isolated shared-clone worktree. Direct, issue and pipeline modes shorten this path. Skipping refinement is sensible only when the input already has machine-checkable acceptance criteria.
Core concepts without the music metaphor
| TAKT concept | Engineering meaning | Control question |
|---|---|---|
| Workflow (formerly “piece” in older material) | YAML state machine | Can every path terminate safely? |
| Step / movement | Bounded unit of agent work | What files and tools may it use? |
| Persona | Role-specific prompt facet | Does it change authority or only perspective? |
| Policy / knowledge / instruction | Composable context facets | Which source wins when instructions conflict? |
| Rule | Status-conditioned transition | Is the condition independently observable? |
| Provider routing | Map step, tag or persona to a model/provider | Are cost, data and capability acceptable? |
| Finding contract | Structured review-finding lifecycle | Can findings be silently dropped or self-closed? |
Documentation and releases have evolved from “piece/movement” to “workflow/step” terminology. Pin the installed npm version and read its matching docs instead of copying an older YAML example. As reviewed, npm reported version 0.52.0 and Node requirements of ^20.20.0 or >=22.22.0; confirm the live package before installation.
A minimal workflow is a graph, not a checklist
name: plan-implement-review
initial_step: plan
max_steps: 10
steps:
- name: plan
persona: planner
edit: false
rules:
- condition: Planning complete
next: implement
- name: implement
persona: coder
edit: true
rules:
- condition: Implementation complete
next: review
- name: review
persona: reviewer
edit: false
rules:
- condition: Approved
next: COMPLETE
- condition: Needs fix
next: implement
This illustrative pattern needs failure edges, iteration limits and deterministic checks. “Planning complete” and “Approved” are model interpretations unless backed by a schema, tests or a human decision. Add explicit ABORT behavior for invalid status, provider failure, budget exhaustion and scope violation. Run the official workflow validation/doctor command supported by your installed version.
Design transitions around evidence
| Transition | Weak condition | Stronger evidence |
|---|---|---|
| Plan → implement | Agent says plan is good | Required acceptance, files, risks and test fields validate |
| Implement → review | Agent says coding finished | Diff exists, changed paths allowed, build/test commands ran |
| Review → fix | Free-form criticism | Finding has ID, severity, file/line, evidence and status |
| Review → complete | No issues mentioned | Ledger has no open blocking findings and gates pass |
| Any → abort | Model decides to give up | Budget, safety, invalid state or repeated-failure policy fires |
| Complete → merge | Automatic PR merge | Protected branch checks and accountable human approval |
Permissions must follow the step, not the provider brand
A planner normally needs read/search access, not edits. An implementer may edit a bounded worktree and run repository checks. A reviewer should be read-only so it cannot “fix” evidence before approving it. A release step needs an explicit human gate and narrow repository token. Model sophistication does not justify broad authority.
| Capability | Default stance | Control |
|---|---|---|
| Filesystem edit | Only implementation/fix steps | Allowed roots and post-step diff inspection |
| Shell | Sandbox/worktree only | Command policy, timeout, CPU/disk limit |
| Network | Deny or allowlist | Block metadata/internal hosts and log destinations |
| Git push/PR | Task branch and draft PR | Scoped app token and protected main |
| Secrets | Injected only when required | Per-step short-lived credentials and redaction |
| Package install | Lockfile-constrained | Approved registries, integrity and dependency scanning |
| Deployment | Outside coding workflow initially | Independent release system and human approval |
Worktree isolation: useful but incomplete
TAKT’s isolated Git worktree/shared clone protects the developer’s active files and makes task branches easier to inspect. It does not isolate processes, network, credentials, user home files or external accounts. An agent with shell access may still read environment variables, contact arbitrary hosts or invoke globally authenticated CLIs.
For untrusted issues or repositories, run the whole task in a disposable container or VM with a clean home directory, restricted egress and resource quotas. Mount only the task repository. Use a dedicated GitHub/GitLab app token. Destroy the environment after exporting the diff, logs and required evidence.
Provider routing creates cost and policy routing
Routing a planner to one model and implementation/review to others can improve specialization and avoid a single-model monoculture. It also means source code and prompts may reach several providers under different retention, region and account terms. Maintain an allowlist by repository data class and record the resolved provider/model for every step.
| Routing goal | Reasonable experiment | Guardrail |
|---|---|---|
| Lower planning cost | Small model on structured low-risk plans | Escalate ambiguity/security work |
| Strong implementation | Code-focused model with edit tools | Token, file and command limits |
| Independent review | Different provider/model family | Read-only and finding schema |
| Data residency | Approved provider for sensitive repo | Block fallback to unapproved provider |
| Availability | Fallback model on transient outage | Revalidate behavior, never silently broaden data sharing |
Review loops need hard stopping rules
Agent review can oscillate: one pass changes an API, another restores it; one model adds tests, another removes them. Set maximum steps, retries, wall time, model spend, changed files and diff size. Hash findings and patches to detect repeated states. Escalate to a human when the same finding reopens, no test improves or scope expands.
- Never let the implementer mark its own security finding resolved without reviewer evidence.
- Do not close a finding merely because the line moved.
- Keep severity changes and waivers attributable to a person or policy.
- Require a final clean checkout validation, not only commands inside a modified agent session.
Prompt and workflow supply-chain risk
TAKT can use built-in or ejected workflows/facets and can install repertoire packages from GitHub. These files influence agent behavior and tools; treat them like executable dependencies. Pin commits, review diffs, avoid floating main references in CI and scan packages before activation.
Repository files, issues, compiler output and fetched web pages are untrusted prompt content. A malicious issue can ask the agent to print keys or modify workflows. System policy and permission enforcement must sit outside that text. Do not let a task edit the quality gate that judges the same task without separate review.
CI/CD deployment
TAKT documents pipeline mode and a GitHub Action. Begin with read-only analysis or draft PR creation. GitHub Actions triggered by forks can be dangerous when secrets and writable tokens are available; follow GitHub’s event-specific security guidance. Pin third-party actions by immutable commit SHA and use minimal permissions.
| CI element | Safe initial setting | Reason |
|---|---|---|
| Trigger | Manual dispatch or trusted label | Prevents any issue author from spending/acting |
| Repository token | Contents read; PR write only if needed | Limits compromise |
| Provider secrets | Environment-scoped and masked | Reduces fork/log exposure |
| Output | Draft PR plus evidence artifact | Keeps merge accountable |
| Concurrency | Per-repo and per-task caps | Controls conflicting branches and spend |
| Timeout | Finite job and workflow budget | Stops loops and hung CLIs |
What to measure in a pilot
Select 20 representative, bounded tasks and a comparable human/single-agent control group. Track accepted task rate, first independent CI pass, reviewer minutes, reopened defects, security findings, lead time, model cost and workflow failures. Lines changed and number of agent steps are activity, not value.
Also measure orchestration overhead: YAML maintenance, provider setup, false review findings, conflict cleanup and time diagnosing transitions. A structured workflow is justified when it increases accepted quality or predictability enough to exceed that overhead.
When TAKT is a good fit
| Situation | Fit | Why |
|---|---|---|
| Repeated maintenance with clear tests | Strong pilot | Reusable workflow and objective gates |
| Multi-model plan/build/review | Good | Provider routing and explicit roles |
| Ambiguous greenfield product design | Conditional | Human decisions dominate early work |
| One tiny deterministic edit | Weak | Direct script or one supervised agent is simpler |
| Production incident response | Poor autonomous start | Live authority and time pressure magnify errors |
| Untrusted repository with broad secrets | Unsafe without sandboxing | Worktree alone is not a security boundary |
Alternatives
| Option | Best fit | Tradeoff versus TAKT |
|---|---|---|
| TAKT | Local/CI multi-provider coding workflow in YAML | New orchestration language and project maturity |
| Direct Codex/Claude Code | One developer supervising one task | Less repeatable multi-stage routing |
| GitHub Agentic Workflows | GitHub-native repository automation | Platform-specific execution/governance |
| Open SWE | Internal async issue/chat-to-PR platform | Heavier service and sandbox integration |
| LangGraph | Custom programmatic stateful agent applications | More code and generality, less coding-workflow packaging |
| Ordinary CI scripts | Known deterministic transformations | Less flexible reasoning, often safer and cheaper |
Frequently asked questions
Is TAKT a coding model?
No. It orchestrates supported coding-agent providers and workflows.
Is it open source?
The current repository and npm package identify an MIT license. Verify the installed version and bundled dependencies.
Does it isolate agent execution?
It uses isolated Git task worktrees/clones, which protect working-tree state. Strong process, network and secret isolation require a container or VM.
Can it run in CI?
Yes, through pipeline mode and documented action integration. Start with minimal permissions and draft PRs.
Does YAML guarantee quality?
No. It makes process explicit. Quality requires evidence-backed transitions, independent gates and accountable review.
Which providers are supported?
Current materials list Claude, Codex, OpenCode, Cursor, GitHub Copilot CLI and Kiro. Support and authentication change by release.
When should a workflow stop?
On success backed by required gates, explicit abort, or hard budgets for steps, time, spend and repeated findings.
Primary sources
- Official TAKT repository and README
- Official npm package metadata
- Official CLI reference
- Official configuration guide
- Official workflow guide
- Official changelog
- Official GitHub Action repository
- GitHub Actions security hardening
- OWASP prompt-injection guidance
Last reviewed July 25, 2026. TAKT is releasing quickly; pin the npm package, workflow schema and provider versions, then rerun security and behavior tests after upgrades.



