Open agent harnesses · AI-native delivery

AI made everyone faster. Keeping the work together still falls on you.

Each role gets a harness for its part of the work. Shared requirements, work packages, and reviewable evidence help the next person continue without reconstructing the decisions from chat.

Explore the harnessesTalk to us
One harness can strengthen the role you hold today.Connected harnesses make the whole team move as one.A solo founder can move between roles without losing the work.Quality Harness reviews work. The private Platform is being built for project history and drift.

Your situation

Start with the work that is stuck now.

Code appears before you can say what must be ready.

Turn intent into a requirement, a design decision, and a small verified increment.

Intent → requirement → design decision → verified increment

First step: Start where the product decision needs to become clear.

Read the BA guide

Every request reopens decisions that were never made visible.

A change request traces the impact before implementation begins.

Change request → impact links → updated decision → evidence

First step: Start with the change that keeps falling through context gaps.

See traceable change

Everyone has agents, rules, and shortcuts. You still connect the results by hand.

A versioned output from one role becomes the next role’s input.

Role output → named handoff → human gate → next input

First step: Run one real package through the connected chain.

See the connected method

Your role

Start with the responsibility carrying the cost.

Changing roles means reopening your own decisions.

Artifacts survive the session and the role change.

Intent → decision → role change → retained artifact

First step: Choose the responsibility you hold today.

Choose your first harness

The meaning of the requirement breaks apart on the way to engineering.

Intent, rules, acceptance, and evidence remain traceable.

Intent → requirement → acceptance → evidence

First step: Start with the requirement handoff.

See the requirement handoff

Individual demos speed up while review, integration, and rework still land on you.

Shared standards and gates turn personal practices into delivery.

Standard → handoff → gate → evidence

First step: Map one delivery flow with the team.

Map one delivery flow

Shared product repository

BA and Architect work together here.

Business Analyst hands scope to Architect in the same product repositoryBusiness Analyst creates the canon work package. Architect preserves its ID and adds technical decisions in design. Each person uses their own harness.Business AnalystBA harnessArchitectArchitect harnessOne canon WP ID · technical design

Vision, requirements and the initial WP live in the canon. Architect prepares design/<WP> with the decisions, contracts and implementation scope.

Prepared WPChoose how the developer reads or receives it.Evidence and rework

Separate code repository

Developer implements. Quality reviews.

Developer produces implementation evidence for Quality HarnessDeveloper opens prepared requirements and design, implements scoped work in the code repository, and supplies evidence for review. Findings can return work. Publication requires its own approval.DeveloperDeveloper harnessQualityQuality harnessImplementation · evidence · review

The code stays in its own repository. A completed implementation, an applied quality outcome and Git publication are separate steps.

Each person installs the harness for their role. The shared artifacts connect their work. This is a team setup with an explicit handoff between repositories.
How the two repositories connect

Source Developer tools can use --design-dir for the product checkout and --product for the code checkout. They can write reports back under the design directory. Current Runtime uses one repo for local package discovery and checks: prepare the required inputs there explicitly. It does not automatically import or synchronize a sibling repository.

Follow the team delivery guide →

Generation is quick. Reconstructing decisions and acceptance is not.

A bounded package arrives with decisions and leaves with evidence.

Package → plan → change → evidence

First step: Start with the package you receive.

Read the Developer setup

AI code grows faster than your visibility into quality and security drift.

Review one result with Quality Harness; discuss private multi-project history separately.

Harness review → approved application; planned Platform → history per project

First step: Talk to us about private Quality Platform access.

Talk to us about private access

The coordination tax

Speed inside each role does not make the team move together.

A conceptual view of the same team using individual agents or connected harnesses. Your selected workflow determines the steps and approvals.

Focus a role
Quality gate
The same four roles before and after PraxisIndividual agents create many direct communication paths, uneven progress, and dropped context. Connected harnesses create a sequence of versioned artifacts, human gates, and controlled returns.BABusiness AnalystARArchitectDEVDeveloperQAQuality Harness
Everyone is faster in their own window.Every role must still ask every other role what changed. Work arrives early, late, or without the decision that shaped it.
Each role opens a named package.Requirements, decisions, evidence, and returns move through one sequence. Scope review, quality application and publication remain explicit decisions.

Business Analyst turns product intent into accepted scope and an initial canon work package. Architect adds technical decisions for that same scope.

Without a connected harness

Roles exchange status directly, reconstruct decisions, and wait on missing acceptance. Individual speed increases the number of coordination paths.

With connected harnesses

Each role receives a named, versioned artifact. Review can advance or return the work while its requirement and decision remain inspectable.
Input
The named package a role opens.
Artifact
The versioned work that role produces.
Gate
A review or approval required by the selected operation.
Next owner
The role that opens the accepted package, or receives a controlled return.

Connected delivery

Four roles. One connected delivery flow.

BA prepares the scope. Architect adds technical decisions. Developer implements it. Quality Harness reviews the result. Each person works with their own harness and shared artifacts.

praxis / connected delivery
  1. 01Open harnessBusiness Analyst
  2. 02Open harnessArchitect
  3. 03Open harnessDeveloper
  4. 04Role harnessQuality Harness
  1. 01
    Business Analyst
    → Architect

    Accepted scope and initial work package

    Review scope before applying it to the canon

  2. 02
    Architect
    → Developer

    Technical decisions, contracts and boundaries

    Review the selected implementation scope

  3. 03
    Developer
    → Quality Harness

    Implementation record and reviewable evidence

    Inspect completed, failed and skipped checks

Quality review, approved application of its outcome and Git publication are separate operations. Merge remains a review decision. See the Quality Harness workflow →

Use it alone. Multiply it together.

A harness helps one role. The chain keeps work connected between roles.

One harness

One harness — make your role stronger

Start with the job that is carrying the most uncertainty today.

Full chain

Full chain — make the team move as one

Each output enters the next role with decisions, boundaries, and human ownership intact.

Quality Platform · planned private product

See how quality changes across your projects.

Quality Harness reviews a particular work result. Quality Platform is being built to retain the history of each project and bring multiple projects into one view.

Before merge

Planned: review history before a change is merged.

Bring review findings and implementation evidence into a project’s quality record.

After merge

Planned: recurring quality and security evaluations.

Compare observations on the default branch over time to investigate quality drift.

Baseline signalIllustrative
riskexample observations
Quality signalSecurity signal

Illustrative planned view, not live telemetry. Comparable observations help a team investigate changes in quality and security over time.

Private access

Multiple projects. A history for each one.

The Platform is a separate private product. Talk with us to define access and integration for your team.

Talk to usRequest private access

Proof

Observable evidence, before promises.

  • Named artifactsRequirements, decisions, contracts, and implementation records have named artifacts.
  • Reviewable checksInspect what ran, what failed, what was skipped and what needs follow-up.
  • Open documentationRole guides make the method visible before a team chooses a starting point.

Documentation

Read the method, role guides, and handoff contracts.

The same documentation used by the open harnesses, published under Praxis.

Read the documentation

Choose a starting point

Bring one stalled delivery flow into focus.

Explore the harnessesTalk to us about Quality Platform