Habr AI: How Pipeline Triad Builds an AI Agent Pipeline in Place of a Development Team

The idea of a single universal AI developer is gradually giving way to a more practical scheme: instead of a "super-agent," a pipeline of specialized triads, where one agent produces a result, a second hunts for errors and a third makes the call. That is how the Pipeline Triad Pattern works. It is a development model built not for demos but for typical enterprise tasks, where requirements, standards and rules are already documented, and humans keep control at a few of the most expensive points in the process.

The scheme rests on three roles: Creator, Critic and Arbiter. The first generates an artifact, the second checks logic, quality and risks, and the third decides whether to pass the result on or send it back for rework. The approach rests on a simple idea: language models are poor at fixing their own mistakes without outside checking, so it is more reliable not to keep strengthening a single agent indefinitely but to build an independent triad with distinct functions. The pattern's author carries the familiar enterprise maker-checker-approver principle over to agent-based development and stretches it across the whole SDLC.

Pipeline Triad is not proposed as a replacement for CI/CD. Automated pipelines still build, test and ship code, but a further layer appears above them: agent delegation, where decisions are made not by a rigid script but with context, regulations and business rules in mind.

The full scheme has 14 steps, from task definition to production. Seven of them are agent stages: analysis, development, code review, testing, regression, security and preparation of release artifacts. Four more checkpoints stay with humans: requirements validation, readiness approval, deployment confirmation and a final check before production.

At each stage the triad must deliver not just a text answer but a formalized package: the artifact itself, PASS or FAIL criteria, the Critic's log of remarks, and the Arbiter's decision to pass, return or partially pass the work. This turns the pipeline from a set of prompts into a reproducible process with decision tracing. The next stage does not start until it receives valid input, which makes it possible to build audits, measure quality and analyze errors after the fact.

The pattern's practical value shows best on a typical task. As an example, the author takes a banking endpoint for freezing an account. First the triad clarifies requirements and edge cases. Then separate triads write the code, check access rights, add tests for race conditions, and run regression and security checks. After that, a human merely confirms a few key decisions. In this scenario, human involvement is estimated at about one hour in total, versus two to three weeks in a classic enterprise process.

On cost, the author estimates a full run through the API at roughly 42–84 model calls, 1–2 million input tokens and 200–400 thousand output tokens, which gives a benchmark of about $6–12 per task. For pilots and personal setups a subscription may be cheaper, but a stable production flow will still require accounting for limits, budget and actual token consumption.

The model has hard limits, though. It suits change requests, bugfixes, CRUD and API tasks, integrations and infrastructure changes, where the domain is formalized and the result can be verified with tests and artifacts. Pipeline Triad works worst where uncertainty is high: discovery, greenfield architecture without mature standards, R&D and large cross-team refactorings.

The risks are fairly down to earth too. An agent may invent a nonexistent business rule, a poorly tuned Critic will either let errors through or reject everything, and parallel work on several tasks will quickly run into conflicts over context, migrations and branches.

Pipeline security is a separate matter. If agents get access to the repository, secrets and deployment without strict limits, the new process becomes an additional attack surface. The author therefore insists on least privilege, separate role permissions, a full audit log, a policy engine for tool use, and filtering of sensitive data before it reaches the model's context.

What this means in practice: the idea of a "team of agents" stops being a fantasy about a universal AI employee and becomes a more down-to-earth engineering model, in which speedup comes from specialization, formalized inputs and control at the expensive steps. But the material also honestly shows the approach's limits: it does not remove organizational approvals, does not solve the problem of poorly framed tasks and does not lift responsibility from senior people who must validate the result. If such pipelines become a working standard, they will do so first in predictable enterprise domains, where the cost of error is high and the rules can already be turned into a verifiable process.