tx

Headless, Local Infra for AI Agents. Primitives, not frameworks.

The Problem

You open a new session and context is gone. Two agents pick the same task. A key decision disappears into chat history. You end up rebuilding the same infrastructure every project.

The Solution

tx handles persistence, dependencies, and memory primitives so you can stay focused on your orchestration logic.

Why Primitives?

The orchestration flow is where you create value. It encodes your domain knowledge:

• How your codebase works
• What your agents are good at
• Where humans need to intervene
• How you handle failures

If we dictate the flow, we're not a tool. We're a competitor. We don't know your domain, your constraints, or whether you need 3 agents or 30.

TanStack won by saying: "Here's headless table logic. Style it yourself."

tx says: "Here's headless agent infrastructure. Orchestrate it yourself."

Your Journey

Follow the docs in this order:

1. Task Management: start with Getting Started, then the task primitives.
2. Spec-Driven Development: add docs, specs, and closure after the task loop works.
3. Memory & Context: add durable knowledge and prompt context once the basics are stable.
4. Bounded Autonomy: add limits, verification, and gates when agents have more freedom.
5. Coordination: add worker coordination and messaging when multiple actors are involved.
6. Observability: add traces, health views, and dashboards once you need operational visibility.

Only add the Watchdog Runbook later if you need detached, long-running supervision.

Recommended Start

If you are evaluating tx, keep the first pass small:

1. tx init
2. tx add
3. tx ready
4. tx show
5. tx done
6. tx sync export

After that, follow the same maturity ladder:

1. Task Management
2. Spec-Driven Development
3. Memory & Context
4. Bounded Autonomy
5. Coordination
6. Observability

The Layers

• Task Management: tx ready, tx done, tx block, tx sync
• Spec-Driven Development: tx doc, tx spec, tx decision
• Memory & Context: tx memory, tx pin
• Bounded Autonomy: tx label, tx guard, tx verify, tx reflect, tx gate
• Coordination: tx claim, tx inbox, task-group context
• Observability: tx trace, tx spec health, dashboard

Quick CLI Examples

tx pin set coding-standards --file ./standards.md
tx memory search "auth flow" --semantic
tx memory add "Retry 429s with backoff" -t learning
tx memory context tx-abc123
tx verify set tx-abc123 "bun test"
tx verify run tx-abc123

Structured Requirements (EARS)

tx enforces EARS (Easy Approach to Requirements Syntax) as the standard requirement format for PRDs. When a PRD contains requirements, it must also define ears_requirements.

EARS requirements are:

• clearer and less ambiguous than plain bullets,
• machine-validated before implementation (tx spec lint),
• easier to map to tests in DD traceability matrices.

Start in tx doc for syntax and examples.

Spec-Driven Development

Spec-driven development is not a one-way equation. It is a feedback loop. Implementing code generates decisions that must feed back into specs and tests. tx keeps the loop in sync: tasks define what to build, memory and decisions capture what changed during implementation, and tx done closes the loop.

The answer to AI coding's volume problem is not more orchestration. It is lightweight process that keeps intent, code, and tests aligned at speed. Use tx spec status and tx spec fci for scoped closure, and tx spec health as the repo-level rollup.

Your First Step

Start with Getting Started, then continue through Primitives and Headful Experience. Add Watchdog only if you later need detached supervision.

Design Principles

As you build, these principles keep you in control:

• No opinions on orchestration. Serial, parallel, swarm, human-in-loop. Your call.
• Powerful defaults. tx ready just works. So does dependency resolution.
• Escape hatches everywhere. Raw SQL access, stream event logs, custom scoring.
• Framework agnostic. CLI, MCP, REST API, TypeScript SDK. Use what fits.
• Local-first. SQLite + git. No server required. Works offline.

Interfaces

Choose the interface that fits how you want to operate:

For REST task update and completion requests, tx defaults to the agent path. Send x-tx-actor: human when a human operator is updating or completing work, especially for gate-linked tasks where agent completion can be blocked by default.

License

MIT