Skip to content

How the factory works

Business intent in.Production software out.

Between those two sentences: three loops, nine documents, one line of accountability. One sentence starts the interview. Watch it make the trip.

What happens between those two sentences is the product.

The intent

“Build the relationship system our commercial work runs on, with the data-protection obligations that come with it.”

The example is real: XRM, an internal Taiga system, built and run through the factory. The screenshots on this page are from that project.

Book a demoSee the existing-codebase path

The intent · entering LearnOne sentence, and the interview it starts.

01 · Learn

One sentence becomes nine documents.

Intake agents interview your stakeholders and read what already exists: process docs, the current system, your policies. The Discovery Pipeline runs three phases: Understand, Design, Secure. It produces the full document set, each piece reviewable, editable, versioned, and exportable. You approve every one. Nothing is built from an artifact you have not seen.

There is a third input: your own reference documents. Upload them and the agents ground their work in what you already know. Knowledge that lives in files nobody opens becomes context the factory uses.

The nine-document set

  1. Specification
  2. User flows
  3. Architecture
  4. Technology decisions
  5. Data flow
  6. Threat model
  7. DPIA
  8. Risk register
  9. Service blueprint
Fig. 01 · Discovery pipelineThe Learn loop live: Understand, Design, and Secure complete, with the DPIA, threat model, and risk register versioned before anything is built.

Sample pack

A redacted document set from a real factory run.

Specification, threat model, DPIA. Leave your work email and a person sends the pack. No autoresponder, no sequence.

Also in Learn

Start from an existing codebase

Point Taiga at a repository you already run, GitHub cloud or enterprise, through an App you install and can revoke. It analyzes the code and generates the same nine-document set for the application as actually built, specification to threat model to DPIA. It proposes a backlog of the work that brings the system in line with your policies and standards.

The documents describe the system as built, not as remembered. Software that never had paperwork gets an audit trail.

Fig. 02 · The document setAll nine documents in one table, specification through service blueprint, each versioned. The codebase snapshot sits beside them: the paperwork, generated.

The intent · entering DeliverNine documents, reviewed and approved by you.

02 · Deliver

Nine documents become a pull request.

A council of models must agree on the plan before work proceeds; disagreement sends it back for revision. The coding agent builds against it, runs security hardening, fixes its own CI failures, and opens a pull request for your team to review.

Planning turns the approved specification into a backlog of initiatives, plans, and ordered steps. Every build runs static analysis, secret detection, and dependency and infrastructure checks before the pull request opens. The output is traceable, line by line, back to the goal that ordered it.

Deliver also sets up where the software runs. Connect your own cloud account or use a Taiga-managed one, and define the environments the work deploys into. The environment is part of the delivery.

Fig. 03 · Agents workingAn initiative mid-build: agents work the implementation plan step by step, progress on the record, Stop one click away.
Fig. 04 · Inside the runThe run as it happens: ordered steps with their dependencies, and every decision the agent makes written to the log.

A green build is not a fixed vulnerability.

The intent · entering OperateMerged code, running in production.

03 · Operate

Verified fixed, not just build passed.

Every connected repository is swept on each push and at least daily. Findings become reviewable pull requests, dependency-aware down to transitive dependencies, no downgrades.

What the sweeps find rolls up into a single health view: vulnerable and outdated dependencies, judged against your supply-chain policy. Your policy sets the bar for what is flagged and fixed.

And before a finding closes, Taiga independently re-scans the fix. If the vulnerability is still there, the finding stays open, even after the pull request merged. No silent false-resolutions.

The security posture behind the sweeps is on the trust page.

Fig. 05 · The health viewOpen findings judged against your supply-chain policy, the fixing pull request one click away, the sweep that re-verifies it on demand.

Coordination

One inbox for every decision.

When agents do the production work, the question is no longer who is doing the task. It is who needs to decide, and when.

Anything blocked on a human lands in a single Action Required inbox across all projects: spec reviews, plan approvals, pull requests, credentials. Items appear the moment work is blocked on a person and clear when handled. Every initiative shows whose turn it is: agents working, waiting on you, in review, done. Nothing waits in a channel nobody is watching.

The intent loop: business intent to specification to code to a running system, feeding back into intent.
The loop every initiative travels.
Fig. 06 · Action RequiredThe inbox itself: setup tasks phased so the right thing comes first, shared across the team, done when it says done.

Your organization's structure, mirrored.

Work is organized the way you are: organization, teams, projects. Policies, standards, and business goals published at the organization flow into every project automatically, and teams carry shared context of their own, so nobody re-briefs the agents.

Fig. 07 · Team dashboardOne team live: projects, members, the team playbook, and every agent action in a single activity feed.

Access scoped, visibility shared.

Members are invited by email, with roles scoped to the organization, a team, or a single project. Organization and project dashboards show teams, projects, running agent work, and recent activity in real time: one view for a team lead, a portfolio view for the organization.

The intent · deliveredA relationship system, running in production, with its papers.

The implementation package

What a factory run delivers.

Application code
Done means reviewed, tested, and traceable line by line to the specification.
Infrastructure as code
Done means the environment is reproducible from the repository, not from someone's memory.
CI/CD pipelines
Done means the path to production is versioned, tested, and part of the delivery.
Security checks in every build
Done means static analysis, secret detection, and dependency and infrastructure checks ran before the pull request opened.
Audit trail
Done means every decision and change is on the record from the first prompt, end to end, readable by your auditors.
As-built documentation
Done means the document set is updated after every merge, so the docs match what actually shipped.

Code is the smallest part.

The rest is governance

Roadmap

Not built yet. We say so first.

  • SSO/SCIMnot built

    Enterprise identity: SAML and OIDC single sign-on, including Microsoft Entra ID, SCIM provisioning, custom roles.

  • Verified auto-merge remediationnot built

    Policy-gated automatic remediation that merges only fixes Taiga has independently verified.

  • Insightsnot built

    Signals from production monitoring and user feedback, collected and fed to the planner.

  • Test generationnot built

    Automated test generation and quality gates in the Deliver loop.

  • Deployment orchestrationnot built

    Push-button deployments to your environments with approval gates and release orchestration.

  • Continuous readiness viewnot built

    One live 22-check view per project, assembled from the evidence the factory produces. Today that assembly is manual.

  • Observability and incident responsenot built

    Delivered systems wired for observability, plus incident runbooks, SLOs, and error budgets drafted for your sign-off.

  • Threat detection in productionnot built

    Threat detection wired into delivered systems, with findings routed into the audit trail.

Why the bar is set where it is: the incident filegovernance debtwhat an AI software factory isone spec, six systems

Questions an evaluation asks here

What does an engagement cost?
Taiga is a subscription, priced on the outcomes delivered rather than seats or hours. There is no rate card. Bring a project to the demo and you leave with a scoped outcome, an indicative price, and a timeline.
Can Taiga start from our existing codebase?
Yes. Point it at a repository through a read-only GitHub App you install and can revoke the same day. It generates the nine-document set for the system as built and proposes a backlog that brings it in line with your policies.
What does the Learn loop ask of our team?
Interviews with your stakeholders at the start, then reviews: each of the nine documents is approved by a person on your side before anything is built from it.
Where do our code and data live?
Your code stays in your GitHub behind an App you install and can revoke. Customer data at rest stays in AWS Frankfurt. The full specifics, subprocessors included, are on the trust page.
What happens if we stop?
Your repositories, documents, pipelines, and infrastructure code already live in your GitHub and your cloud, so the delivery survives the subscription. Account data is deleted on termination under the Data Processing Agreement; the audit archive follows its seven-year rule.

How pricing works

A subscription, priced on outcomes.

Consulting sells hours and delivers the software as a by-product. Taiga is a subscription: not seats, not hours. There is no rate card to publish; the price follows the outcome being delivered. Bring a project to the demo and you leave with a scoped outcome, an indicative price, and a timeline.

Bring the project you would give a team next quarter.

Book a demoRequest the sample pack

In production since May 13, 2026. References are part of the demo process.