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

Your role

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.

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.

Where you are · Founder / Solo

Changing roles means reopening your own decisions.

Intent → decision → role change → retained artifact

Where you are · Head of Product

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

Intent → requirement → acceptance → evidence

Where you are · Engineering Director

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

Standard → handoff → gate → evidence

Where you are · Developer

Generation is quick. Reconstructing decisions and acceptance is not.

Package → plan → change → evidence

Where you are · Quality Lead

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

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

praxis / connected delivery
  1. 01Open harnessBusiness AnalystGitHub
  2. 02Open harnessArchitectGitHub
  3. 03Open harnessDeveloperGitHub
  4. 04Role harnessQuality HarnessGitHub
  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 →

What you unlock

Start with the responsibility carrying the cost.

Founder / Solo

Artifacts survive the session and the role change.

  • Continuity

    Pick up tomorrow where you stopped: scope, the work package and evidence reopen from your repository, not from a chat.

  • Speed

    Switch from product to architecture to code without rebuilding reasoning that was clear a few hours ago.

  • A process a team can join

    When you hire, the next person inherits the same artifacts and handoffs instead of your chat history.

First step: Choose the responsibility you hold today.

Choose your first harness

Product decisions

You as BA, then as Architect.

You take the Business Analyst role, then the Architect role, on the same work packageAs BA you approve scope and create the canonical work package. Returning as Architect, you enrich the same package with technical choices.Business AnalystYouArchitectYouOne canon WP ID · technical choices

As BA, clarify and approve scope and create the initial canonical WP. Return as Architect to enrich that same package with technical choices.

The same WPReopened in the next session, not rebuilt from chat.Evidence and findings

Build and review

You as Developer. Quality Harness when needed.

You implement as Developer and review the result with Quality HarnessIn a Developer session you check that the prepared package and its files are available, implement, and record evidence. Quality Harness can review the result.DeveloperYouQualityYouImplementation · evidence · review

In a Developer session, verify that the prepared package and referenced files are available in the chosen code workspace before implementation. Quality Harness can review the result when needed.

One person, one harness per role. Accepted versionable artifacts can be reopened from the repository you maintain; local Runtime journals, uncommitted changes and credentials do not follow you automatically.
What you can reopen tomorrow

Open the accepted scope, stable WP identity, technical handoff, implementation evidence and any Quality findings. Check their revisions before resuming so a stale package does not silently become the current one.

Read the founder path →

Head of Product

Intent, rules, acceptance, and evidence remain traceable.

  • Transparency

    See the original ask, the accepted requirement and the evidence side by side, not a status report's reading of them.

  • Control over change

    When a business rule changes, linked stories and designs show what needs a decision before code moves.

  • Acceptance you can check

    Compare the result with the acceptance criteria you approved, not with someone's paraphrase of the brief.

First step: Start with the requirement handoff.

See the requirement handoff

Product repository

You approve the scope BA proposes.

Head of Product approves the requirement and acceptance proposed by Business AnalystBusiness Analyst captures the original ask, proposes the requirement and its acceptance, and returns them to you for approval.Head of ProductYouBusiness AnalystBA harnessOriginal ask · requirement · acceptance

BA captures the original ask, reviews the affected business rule and acceptance, and shows the proposed change for your approval. That acceptance gives Architect a defined scope to design.

Accepted scopeA defined scope for Architect to design.Evidence at the end

Engineering

Architect designs. Developer builds.

Architect enriches the same work package, Developer implements itArchitect adds technical decisions to the same work package ID. Developer implements the selected scope and records evidence that Quality Harness can review.ArchitectArchitect harnessDeveloperDeveloper harnessOne WP ID · design · evidence

Architect enriches the same WP ID with technical decisions. At the end, inspect what the Developer actually checked and what Quality Harness found before separate application and Git delivery decisions.

The original ask, the accepted requirement and the evidence at the end stay linked, so Product can compare the result with what was scoped.

Engineering Director

Shared standards and gates turn personal practices into delivery.

  • Coordination

    One delivery flow for the whole team, instead of every engineer's agent working to its own idea of done.

  • An audit trail

    Every change carries its requirement, decision and evidence, with a person approving each irreversible step.

  • Less integration by hand

    Handoffs travel as versioned packages, so review, integration and rework stop landing on you.

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 →

Developer

A bounded package arrives with decisions and leaves with evidence.

  • Speed

    Start coding with decisions attached instead of reconstructing them from transcripts and tickets.

  • A clear scope

    Know which work package is current, what the Architect decided and which repository is in scope.

  • Trust in your work

    Show what ran, what failed and what was skipped, so review discusses evidence, not impressions.

First step: Start with the package you receive.

Read the Developer setup

Product repository

BA and Architect prepare your package.

Business Analyst and Architect prepare the work package the developer receivesBusiness Analyst accepts the scope and creates the work package. Architect adds decisions, contracts and constraints to the same package.Business AnalystBA harnessArchitectArchitect harnessOne canon WP ID · technical design

Accepted scope, selected decisions, contracts and constraints arrive as a work package rather than a bare ticket.

Prepared WPCheck its referenced files are in your checkout.Evidence and rework

Your code checkout

You implement. Quality reviews.

The developer implements the package and Quality Harness reviews the evidenceYou plan and implement the bounded change and record the commands and results that ran. Quality Harness reviews the result; findings can return work.DeveloperYouQualityQuality harnessPlan · change · evidence

Plan the bounded change, implement it, then record the commands and results that actually ran. Applying the review and publishing with Git are separate decisions.

The package arrives with its decisions and leaves with evidence. Neither a ticket link nor a handoff file alone makes the referenced files available: prepare them in the chosen checkout.

Quality Lead

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

  • Visibility

    See what each review actually checked, including failures and skipped checks, before an outcome is applied.

  • Quality metrics over time

    Comparable observations per project, so drift is a trend and not a hunch. Planned in the private Quality Platform.

  • Findings with an owner

    A drift signal comes with the findings behind it and an owner to act, not just a score.

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

Talk to us about private access

Each change, before merge

You review one result with Quality Harness.

Quality Harness reviews the developer result and its evidenceDeveloper supplies the implementation and evidence. Quality Harness reports findings and previews application; findings can return work.DeveloperDeveloper harnessQuality HarnessYouEvidence · findings · approved apply

Quality Harness reviews a particular implementation and its evidence, reports findings and previews application. A verdict, an applied status, Git publication and merge are distinct events.

ObservationsPlanned: comparable records per project.

Across projects · planned

A private Quality Platform keeps the history.

The planned private Quality Platform keeps quality history per project and across projectsPlanned private product: each project keeps a comparable quality history, and an overview spans multiple projects. It is not live telemetry today.Each projectQuality historyAll projectsYou · overviewPlanned: drift against a chosen baseline

Quality Platform is a separate private product direction, planned to retain each project’s quality history and provide oversight across multiple projects. Access is arranged with the team.

Two levels: the delivered Quality Harness reviews one result; the planned private Quality Platform is for history across projects.

Your situation

Start with the work that is stuck now.

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.

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.

Cases

Built with the lifecycle, running in production.

These cases describe product contexts, the method used there, and a result with the source of its number. They do not imply today’s Runtime or private Platform was used historically.

  • Case study
    Digital Winery
    Digital Winery moved development to Praxis in March 2026. The group’s VP of Engineering reports the team went from 18 people to 10 on the same volume of work.
    Read the case
  • Case study
    WatchLink
    A luxury-watch community moved from a Facebook group of 4,000+ members to web, iOS, and Android apps of its own. Product analytics counted 2,041 registered accounts in the first month.
    Read the case

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