Spec-driven agent orchestration

Turn intent intoworking software.

Conduit turns approved feature specs into bounded, parallel work for coding-agent teams—then keeps every decision, run, and result visible.

The product, in motion

One deliberate path from story to software.

Conduit keeps every stage visible. Refine the intent, ground it in the repository, approve the packet, and watch bounded agents deliver it.

01 / REFINE

Start with the problem, not a prompt.

Capture the audience, desired outcome, constraints, QA scenarios, and implementation guidance in a structured refinement form.

Refinement fields

▸ Problem / user story * · 147

  User or audience * · 10

  Desired outcome and acceptance criteria * · 420

  Constraints and non-goals · 0

  QA test cases and regressions * · 640

  Implementation guidance · 67

Refinement Form

Complete each required field, then press Ctrl+Enter to review your draft.

Field 1 of 6: Problem / user story

Describe the problem or user story this feature addresses.

Problem / user story *

As an operator, I need each payment attempt to expose its lifecycle so I can diagnose failures without reading raw logs.

Tip: Make the gap observable and describe the expected outcome.

02 / RESEARCH

Ground the story in the repository.

A researcher inspects the existing architecture, tests, and domain boundaries. You can follow its runner activity before the architect receives that context.

Conduit · Research preflight · 014-1783867884368

←/→ or Tab switch roles · ↑/↓ navigate · j/k scroll · Ctrl+C cancel · Esc/q exit

[researcher]

▸ Roles

› researcher · working

┌┤
└┤
researcherresearcher: agent started

Activity (5 events)

researcher: agent starting

researcher: agent started

runner stderr → Reading additional input from stdin...

runner stderr → OpenAI Codex

workdir: ~/projects/acme-store

Changed files

No worktree changes detected

03 / ARCHITECT

Turn evidence into an implementation contract.

The architect combines the approved brief with repository research, exposes its activity, and writes the files that will bound every downstream agent.

┌┤
└┤
architectrunner pendingRefining feature 014

Architect is refining the packet. Activity appears as its transcript is captured.

↑/↓ select a changed file · Enter open/close its diff · Esc close · q exit

Changed files: 4 | Events: 12

Changed files

▶ specs/014/spec.md

specs/014/plan.md

specs/014/tasks.md

specs/014/test-cases.md

Activity

activity Refining feature specification

tool-call rg --files src/domains/payments

tool-call read contracts and QA cases

file-change wrote specs/014/spec.md

activity Defining bounded task ownership

04 / APPROVE

Review the story before agents act.

Read the generated Markdown, adjust research and architect settings, and approve only when the story, acceptance criteria, and delivery detail are right.

Refinement fields

▸ Problem / user story * · 147

  User or audience * · 10

  Desired outcome and acceptance criteria * · 420

  QA test cases and regressions * · 640

Markdown Preview

a approve · Ctrl+R edit · q quit · t architect · s research

# Story

## Problem / user story

As an operator, I need each payment attempt to expose its lifecycle so failures can be diagnosed without reading raw logs.

## Desired outcome and acceptance criteria

– Every attempt publishes observable lifecycle events.

– Operators can inspect failures from the TUI.

Research [s]: ON (preflight)

Architect [t]: ON

Detail [l]: implementation-blueprint

Approve: research preflight, then architect

05 / ORCHESTRATE

Watch bounded agents deliver in parallel.

Switch between roles, inspect normalized runner events, and review changed files without losing sight of who owns what or which agents are waiting.

Conduit · Worker Monitor · 014-1783867884368

←/→ or Tab switch roles · ↑/↓ navigate · j/k scroll · Ctrl+C cancel · q exit

frontendreviewerdocumentation[qa]

▸ Roles

frontend · completed

reviewer · waiting

documentation · waiting

› qa · working

┌┤
└┤
qaqa: agent started

Activity (15 events)

qa: agent starting

qa: agent started

runner stderr → Reading additional input from stdin...

runner stderr → codex

runner → Running focused test suite

Changed files

tests/payment-events.test.ts

Why I built it

Frontier intelligence. Affordable execution. One terminal.

I wanted an easy way to use both my ChatGPT and OpenCode Go subscriptions without running several CLIs or constantly switching context.

Frontier models are excellent at the work where judgment matters most: understanding a repository, refining requirements, designing the plan, and reviewing the result. Open-source models are much cheaper and work well when the task is focused, bounded, and backed by a clear contract.

The idea behind Conduit is simple: use GPT models for the brains and affordable open-source models for the muscle. Conduit turns that mix into one visible workflow, so I can coordinate the whole delivery without leaving my terminal tab.

The brains

Research · Architect · Review

Frontier models handle ambiguity, system-level reasoning, and quality gates.

ChatGPT / Codex
The muscle

Implement · Test · Document

Affordable models execute clearly scoped work inside explicit ownership boundaries.

OpenCode Go / open models

CLI friendly

The full workflow, without leaving your shell.

Conduit’s compact commands are stable fallbacks for scripts, automation, CI, and terminals that cannot run the interactive TUI.

conduit — zsh~/acme-store

$ conduit feature "Add payment observability"

✓ Created feature 014-payment-observability

$ conduit refine 014 --architect --compact

architect  Refining feature specification

✓ Approved packet written to specs/014-payment-observability

$ conduit run 014 --roles frontend,backend,qa --compact

frontend  working   backend  working   ○ qa  waiting

✓ Run complete · 8 files changed · ready for review

$

Embedded Turso persistence

Local state, deliberately contained.

Conduit now persists runtime state through domain repositories backed by Kysely and embedded Turso—without exposing the database to coding agents or committing intermediate work.

project/.conduit/state.dbmigration · running
EVENT0001 system → 0006 source · checksums verified

The blocking migration screen completes global migrations, project migrations, and legacy import before the application can query state.

01Project and global databases stay separate.

02Credentials never enter database rows or backups.

03Approved packets remain ordinary Git-visible files.

Installation

Bring Conduit into your next repository.

Use the standalone binary for the simplest setup, or add the development package with pnpm.

Recommended

Standalone binary

Download the platform binary from GitHub Releases, verify it, and place it on your PATH.

$ chmod +x conduit-linux-x64
$ install -m 755 conduit-linux-x64 ~/.local/bin/conduit
$ conduit init .
View latest release
Development package

Install with pnpm

Add the publishable package to an existing project and initialize Conduit in place.

$ pnpm add -D conduit-orchestrator
$ pnpm exec conduit init .
$ pnpm exec conduit
Read the documentation

Feature sources

Start with specs. Expand from there.

Today, Conduit works with repository-backed feature packets stored as spec files. Future integrations are planned for Jira, Asana, Linear, and other story sources, all feeding the same refinement and orchestration workflow.