Tack

Introduction

One objective in. Reviewed, tested, merged code out.

Tack turns a natural-language objective into a reviewed, tested, merged pull request. You describe what you want built. Tack handles the rest: planning, parallel execution, quality gates, recovery, merge, and PR creation.

$ tack plan "Add pagination to all list endpoints and a PATCH /expenses/:id endpoint"

Created objective fb68742b. Planner agent will decompose.

$ tack approve e2b12fee

Plan approved. Execution will begin.
  Stream 1: PATCH expenses endpoint        ██████████ merged
  Stream 2: Pagination for list endpoints   ██████████ merged

Objective completed. PR created: github.com/you/project/pull/42

Quick Start

tack setup
tack daemon install
tack daemon start
cd your-project
tack init
tack doctor
tack plan "Add a health check endpoint at GET /health"

See the getting started guide for the full walkthrough.

How It Works

Isolated stream execution needs changes Objective Discovery dossier Planner creates stream plan Human approval Dispatch parallel streams Merge queue Pull request Builder agents Quality gates Reviewer agents Recovery loop
  1. You submit an objective
  2. Tack explores your codebase and produces a context summary
  3. A planner decomposes the objective into parallel work streams
  4. You review and approve the plan
  5. Agents build, test, and review each stream in isolated worktrees
  6. Tack merges everything and creates a PR

Each step is either deterministic (quality gates, merge, scheduling) or agentic (discovery, planning, building, reviewing). Blueprints (YAML workflow definitions) control which is which.

See How It Works for the full pipeline diagram.

Why Tack

The harness matters more than the model. Everything in Tack that isn't an LLM decision is deterministic infrastructure you control: blueprints, quality gates, scoped rules, file scope enforcement, merge ordering, recovery policy. The LLM is the worker. Tack is the harness.

Tack solves six real problems:

  • Objectives are underspecified — Tack explores your codebase before planning
  • Planning is serial — Tack decomposes into parallel streams automatically
  • Execution is uncoordinated — agents run in isolated worktrees with scoped file access
  • You must be presenttack daemon runs in the background; you review results
  • Failures stall progress — quality-gate and review failures trigger automatic recovery
  • Merging is manual — Tack integrates branches with tiered conflict resolution

What Tack Is Not

  • Not an agent framework. Pi does the thinking. Tack shapes the workflow around the runtime.
  • Not a sandbox provider. Local worktrees, Daytona, Docker provide isolation. Tack manages their lifecycle.
  • Not an IDE. Agents edit code. You review their work.
  • Not a CI system. Tack runs quality gates locally in sandboxes. CI is your existing pipeline.
  • Not locked to any model. Choose your runtime, provider, and model.

On this page