Technical overview / 01

Coordination is a system.
Not a pile of sessions.

Brigata is a governed software-delivery operating environment. It keeps human intent, architecture, parallel agent work, external effects, evidence, and acceptance inside one recoverable control loop.

Authority stackSystem model
  1. 01
    Human intentapproves direction and acceptance
    AUTHORITATIVE
  2. 02
    Coordinator stateplans, contracts, policy, evidence
    DURABLE
  3. 03
    Worker effectscode, tools, builds, tests
    BOUNDED
Workers report evidence.They do not declare acceptance.
Authority flows downward. Evidence returns upward.

Implemented operator surfaces

The architecture already has a place to operate it.

Brigata currently ships a browser control-room surface and an Ink terminal operator preview. Both are clients of the coordinator model; neither is a worker terminal with permission to bypass policy.

Browser control roomDeterministic product fixture
Brigata control room displaying run state, planner packets, review gates, artifacts, and fail-closed conditions.
Actual shipped interface rendered from the repository's deterministic fixture state. The labels and controls are real product code; the displayed project is not customer data.

Browser control room

Inspect the delivery state visually.

Projects, planner packets, runs, approvals, artifacts, evidence, and closeouts share one inspectable surface with explicit blocked and failure states.

Terminal operator console

Supervise without leaving the shell.

The Ink TUI uses the same coordinator view-model boundary for run selection, attention queues, approvals, evidence, and safe pause, resume, or kill controls.

corepack pnpm tui

The operating model

Three planes separate intent, truth, and effects.

This separation lets Brigata use capable coding agents without granting any individual session authority over the delivery as a whole.

D

Human-approved intent

Direction plane

Turns a desired product outcome into bounded work, explicit acceptance criteria, and an architecture proposal a human can inspect and approve.

  • intent
  • scope
  • acceptance criteria
  • architecture
E

Bounded worker effects

Execution plane

Adapts coding agents and tools into governed work: isolated scopes, controlled context, explicit permissions, and terminal receipts.

  • workers
  • worktrees
  • builds
  • tests
  1. A human approves intent.
  2. The coordination kernel compiles bounded work and policy.
  3. Worker adapters perform customer-side effects.
  4. Evidence returns to authoritative gates and verdicts.
  5. A human accepts the result or directs another governed revision.
The coordinator is the sole delivery authority. Workers perform bounded effects and return evidence into the loop.

The delivery protocol

Autonomy advances through evidence gates.

“The agent finished” is an observation, not a product verdict. Each stage must leave the state required to admit the next one.

  1. 01

    Approve intent

    A human accepts the outcome, boundaries, and definition of done.

  2. 02

    Shape architecture

    Architecture and design-security roles define the system and challenge risky assumptions.

  3. 03

    Freeze contracts

    Interfaces, ownership, dependencies, and acceptance obligations become explicit before parallel work.

  4. 04

    Dispatch scopes

    Builders receive bounded context, isolated workspaces, and only the authority required for their scope.

  5. 05

    Reconcile evidence

    Terminal receipts, contract realization, and dependency evidence determine what may advance.

  6. 06

    Integrate

    Admissible work is assembled against the accepted aggregate rather than merged by optimism.

  7. 07

    Verify

    Security, tests, functional review, and product gates produce authoritative verdicts.

  8. 08

    Accept and close

    A human accepts the evidenced result; decisions, artifacts, and residual risk remain durable.

Durable coordination state

Shared truth survives the chat window.

Brigata represents the delivery explicitly so humans, agents, and restarted processes can recover the same authoritative state.

01

Approved intent

Defines the outcome and the boundaries autonomous work may not silently rewrite.

What are we actually building?
02

Frozen contracts

Give parallel scopes stable interfaces, ownership, and obligations before implementation starts.

Where may each worker change the system?
03

Claims and dependencies

Prevent overlapping ownership and release work only when its required evidence exists.

What may run now, and against which truth?
04

Durable effects

Record attempted external work so completion, retry, adoption, or uncertainty can be reconciled after interruption.

What happened outside the coordinator?
05

Typed events and failures

Preserve causal history without collapsing distinct faults into a generic pipeline error.

Why did the system advance or stop?
06

Evidence and verdicts

Separate worker success from governed acceptance through tests, reviews, receipts, and explicit gates.

What proves this result is admissible?

Operational projection

Status is a projection, not a survey.

Each work item occupies exactly one governed state, derived from claims, dependency evidence, gate verdicts, and durable effects. Status surfaces are read models over the same event journal that admits dispatch—so a report cannot drift from delivery truth, and uncertainty stays visible instead of rounding up to green.

planned

The scope is admitted to the work graph with frozen contracts, and no claim is held yet.

approved intent · contract set
active

A worker holds the scope's claim and produces effects inside an isolated worktree.

claim record · dispatch policy
blocked

A dependency's required evidence does not exist yet, so the coordinator refuses release.

dependency edge · missing verdict
awaiting review

A terminal receipt has returned and security, test, or functional gates have not yet decided.

worker receipt · queued gates
verified

The scope's gates signed their verdicts against recorded runs.

signed verdicts · test artifacts
failed / indeterminate

A gate refused the result, or an interrupted effect cannot prove its outcome. The item holds fail-closed.

typed failure · preserved uncertainty
awaiting acceptance

Assembled evidence is ready for the human who owns the outcome.

delivery receipt
READ

Authority boundary

Reading state moves nothing.

A projection grants no authority: it cannot dispatch work, approve gates, or mutate coordination state. Standups and PMO reviews consume the same view the operator surfaces read, and keep the work that needs humans—decisions, priorities, and risk.

Interruption is normal

Recovery begins with what can be proven.

Processes restart. Networks break. A worker can finish after its caller disappears. Brigata treats those conditions as governed lifecycle states rather than excuses to guess.

  1. R1

    Observe

    A worker, command, or coordinator is interrupted while work may still exist.

  2. R2

    Reconstruct

    The event journal and durable effect records restore the last authoritative state.

  3. R3

    Reconcile

    Receipts and external evidence determine whether work completed, can be adopted, or remains unknowable.

  4. R4

    Decide

    Brigata advances, retries within policy, requests intervention, or fails closed. It does not invent success.

HOLD

Fail-closed by design

Unknown is not another spelling of success.

When Brigata cannot establish an authoritative result, it preserves the uncertainty and stops or intervenes according to policy.

Customer-controlled execution

The control boundary stays explicit.

Brigata coordinates the delivery. Customer code, credentials, workers, builds, and tests remain on infrastructure the customer controls.

Customer environment

Code and execution

  • Source repositories and worktrees
  • Cline, Claude Code CLI, and future governed adapters
  • Provider authentication and local secrets
  • Builds, tests, previews, and artifacts
policy →typed events ↔← evidence

Brigata authority

Coordination and governance

  • Plans, contracts, dependencies, and claims
  • Dispatch, budgets, retries, and cancellation
  • Security, test, integration, and product gates
  • Verdicts, audit history, and closeout

Model-flexible by architecture

Use the right engine for each governed role.

Worker engines are adapters beneath Brigata’s authority. The current governed runtime is built around Cline, with Claude Code CLI available as an optional adapter; future engines must prove their execution, audit, and recovery contracts before adoption.

Operating patterns

The same coordination model scales from one builder outward.

Scale changes the number of people, repositories, and delivery streams. It does not change the authority model: humans approve direction, Brigata coordinates, workers execute, and evidence earns acceptance.

01

Solo operating pattern

One human.
A governed agent team.

One developer can supervise specialized architecture, implementation, security, and verification roles without carrying the entire delivery state in memory or chat history.

Human authority
one product owner
Worker topology
several bounded roles
Primary relief
session orchestration
02

Team operating pattern

Many humans.
One delivery truth.

Founders, engineers, reviewers, and agent workers share the same architecture, ownership, dependency, policy, and evidence model across parallel work.

Human authority
explicit participants
Worker topology
parallel scoped teams
Primary relief
organizational drift
Invariant

Approved intent → durable coordination → bounded effects → authoritative evidence → human acceptance

Category boundary

Brigata governs agents. It is not another agent.

Brigata is01
  • A delivery authority around specialized agent teams
  • A durable coordination and recovery system
  • An evidence-backed path from intent to acceptance
  • A customer-controlled execution architecture
Brigata is not02
  • A chat interface that asks one model to do everything
  • A launcher for unrelated coding sessions
  • A replacement for human product authority
  • A cloud worker that takes custody of customer code
Technical founding customer programNow forming

Pressure-test the system

Bring us the delivery boundary your agents keep crossing.

Whether you are one developer supervising an agent team or an engineering organization operating them across products, bring us a real delivery problem and we will compare it honestly with Brigata's current capabilities.

  • Hands-on technical onboarding
  • Customer-controlled execution
  • Direct influence on early priorities
Discuss your environment
Brigata / Turtleback ResearchOPEN