The parallel

In March I published two posts about DAGent — a deterministic agentic pipeline that routes specialized AI agents through a fixed topology, produces tested pull requests from a spec, and spends zero tokens on orchestration decisions. On May 14, Jason Robert — Principal Software Engineer in Microsoft's Azure Core CTO office — shipped Conductor: Deterministic orchestration for multi-agent AI workflows, Jinja2-template routing, isolated agent sessions with explicit context flow.

He shipped a framework. I'd built a learning prototype that validated the idea inside one ecom project and one sample Azure app. Those aren't the same achievements, and I'm not going to pretend they are. But the underlying read on the category was the same — a Principal Engineer at Microsoft and an ecommerce solution architect on nights-and-weekends landed on the same architectural intuition from completely different vantage points. That's a category signal, not a coincidence.

What was right

The core insight behind DAGent was simple: most useful multi-agent workflows have known structure. A code-review pipeline is always plan → implement → test → review. A feature delivery pipeline is always spec → dev → unit-test → e2e → PR. You know the topology before anything runs.

If the topology is known, the orchestrator shouldn't be an LLM making routing decisions at runtime. It should be a state machine. Routing consumes zero tokens. You get deterministic execution, reproducible failures, and cost you can predict before you press enter.

DAGent was never a shipped product. It was tightly coupled to one ecommerce project and one sample Azure app — never extracted into a standalone tool anyone else could install. What I was building was a prototype to test whether the deterministic-DAG idea actually worked in practice — and it did.

Concretely, the demo branch (demo/single-file-pipeline) — the stripped-down version I eventually published — encoded this as a 6-node linear pipeline with index-jump failure routing and a try/catch/finally finalizer:

Each node has its own tool allowlist (RBAC), write-path restrictions, timeout budget, and retry policy. The e2e-debug agent could patch both application code and test code; the e2e-author couldn't read the application source at all. Bounded agents with explicit capabilities. No shared conversation state bleeding between nodes.

This was the right category to build in. Conductor's announcement post opens with the same pain: "We kept building multi-agent workflows—code review pipelines, design document generation, research assistants—and writing the same glue code every time." Same problem. Same answer.

What broke

I scaled before I stabilized. That's the short version.

The long version: in late April I introduced Temporal for orchestration. The project/temporal-migration branch carried a Temporal worker, a DAG kernel, an APM compiler (Microsoft solution), telemetry, a triage LLM, lifecycle hooks, an archive subsystem, and an admin CLI. Roughly 20× the surface area of the demo pipeline. I wanted a production-grade distributed system because the architecture docs in my head said "production-grade distributed system."

The problem is I never shipped a clean, stable core first. There was no finalized plug-and-play interface for external users. The Temporal integration introduced real bugs — workflow replay compatibility, signal handling edge cases, state serialization issues — and I was debugging infrastructure instead of demonstrating the thesis.

I know the theory here. I've given feedback on roadmaps and scope creep in delivery planning for years. Ship the smallest thing that proves the idea, get feedback, then add infrastructure. I broke every one of those rules on my own project.

Eventually I pulled back. The demo/single-file-pipeline branch stripped everything to ~1,200 lines of TypeScript: six nodes, JSON state on disk, index-jump failure routing, and a finalizer that always runs. No Temporal, no DAG kernel, no distributed system. It worked. It demonstrated the thesis. It should have been the first thing I built.

The specific product-mindset failures:

• Built for scale before proving value. Temporal is the right tool for a production multi-tenant pipeline. It's the wrong tool for a weekend project that needs to convince people the category exists.

• Confused architecture ambition with shipping. A well-scoped architecture doc is not progress.

• Let complexity debt accumulate on nights-and-weekends time. When you have 8 hours a week, every line of infrastructure you add is a line you'll debug later at 11pm. I added thousands.

• Built an LLM-powered triage router I didn't need. One node used RAG search plus an LLM call to classify failure types and dynamically reroute the pipeline — a semi-deterministic classifier that decided whether a test failure was a code bug, a test bug, or a platform flake, then jumped to the appropriate recovery node. It was clever. It was also spending tokens on orchestration decisions, which was the exact problem deterministic routing was supposed to eliminate. The demo branch replaced it with a static onFailureRoutes map keyed by fault domain strings that the failing agent self-reports. Zero tokens. Same outcomes.

This was a side project built on nights and weekends, which makes the product-discipline failure worse, not better. Limited time demands ruthless scope control. I did the opposite.

What Conductor showed me about the framework layer

I mapped DAGent's pipeline to Conductor's YAML format the week it launched. The exercise made visible what a real framework looks like when someone with the right specialty actually builds one.

1. The CLI as distribution surface

DAGent's Temporal branch already had YAML-defined workflows and a CLI — you ran dagent run workflows.yml and it executed the pipeline. An 11-node DAG in workflows.yml, a node pool in apm.yml, agents in separate folders. The topology was declarative and the invocation was terminal-native. What I never solved was extraction: the CLI, the runtime, and the workflow definitions all lived inside the project repo. You couldn't install DAGent separately and point it at a different codebase. Conductor ships as curl | sh, runs against any workflow file in any directory, and requires zero knowledge of the underlying project. That's the difference between having a CLI and having a distributable product.

2. Context modes as first-class primitives

DAGent always accumulated — every agent saw all prior outputs. Conductor ships three modes: accumulate, last_only, and explicit (only named dependencies). Their blog post notes: "Being deliberate about what each agent sees turned out to matter more than we expected."

I hit this problem in practice. The e2e-debug agent received all prior node outputs including the full dev context, which inflated token consumption and occasionally confused the model. I worked around it with prompt engineering. Conductor solved it at the framework level.

3. Pub/sub event system

DAGent bolted on a live-logger.ts that printed to stdout. Conductor built a pub/sub event bus from day one — the terminal renderer, web dashboard, and any future consumer subscribed independently. Adding their web dashboard required zero changes to the workflow engine.

This is the kind of upfront investment I skipped because "I'll add observability later." Later never comes on a side project.

4. Parallel execution

DAGent was strictly linear. Conductor supports static parallel groups with configurable failure modes (fail_fast, continue_on_error, all_or_nothing) and dynamic for_each groups that process arrays in parallel with batched concurrency.

For my 6-node pipeline, linear was fine. For production workflows with independent research or validation steps, parallel execution is table stakes.

5. Human gates and plugin registries

DAGent's admin interface was — quoting my own README — "Ctrl+C." That's not entirely fair to past-me though. On the main branch, when the pipeline produced infrastructure-as-code changes, I needed a human approval step before deploying to a live environment. My solution: the pipeline posted a GitHub comment with a deployment command, a human reviewed the IaC diff and triggered a GitHub Actions workflow via comment, then you ran a CLI command in your terminal to restore the agent session — it would check whether the deployment succeeded, pull back the artifact status, and resume the pipeline from where it left off.

It worked. It was also a duct-tape integration across three surfaces (GitHub comments, Actions workflows, a CLI restore command) that I knew at the time was a temporary fix. The "long-aimed decision" was always to make approval gates a first-class node type in the graph itself. I just never got there.

Conductor ships exactly that: human gate steps that pause execution, present options with Markdown-rendered prompts, route on the response, and resume — all within the workflow graph. No external surfaces, no session restore commands.

The ecommerce thesis

Here's the part I think matters most for the people I work with every day.

Ecommerce is constraint-oriented development. Every platform — Salesforce Commerce Cloud, Shopify, Adobe Commerce, commercetools, SAP Hybris — ships with a framework, a set of operating rules, and a solution kit that defines what's buildable. You don't start from scratch. You extend within boundaries. The platform's architecture decisions are your architecture decisions whether you agreed to them or not.

I spent years inside this constraint space. Migrating a server-rendered storefront to a PWA architecture inside Salesforce's framework. Writing session-alignment logic across two REST APIs with different auth models. Building extension mechanisms that don't fork the base layer. The work is always: how do you ship features inside someone else's constraints?

Here's the strong opinion: the next move for these platforms is to ship their own curated pool of deterministic pipelines. Not "AI features." Not chatbots bolted onto checkout. Deterministic agentic workflows that encode the platform's own conventions, APIs, and architectural rules.

What this looks like in practice:

• A Salesforce pipeline that knows PWA Kit architecture, SCAPI/OCAPI patterns, and the Page Designer content model. You give it a spec; it produces a PR that follows your platform's rules.

• A Shopify pipeline that understands theme architecture, Liquid templates, and the Storefront API. It authors extensions within Shopify's boundaries, not around them.

• A commercetools pipeline that speaks its API-first model, knows the projection/event pattern, and builds integrations that fit the platform's extension points.

The underlying orchestrator — whether it's Conductor, a DAGent descendant, or something else — is the execution layer. But the value is in the platform-aware pipeline library: curated workflows that encode domain constraints so the agents operate within the same rules a human architect would enforce.

So why hasn't this happened yet? Three reasons.

First, the mainstream bet is on a different architecture: the silver-bullet agent plus MCP servers. Platforms are shipping MCP servers that bolt platform capabilities onto Copilot, Cursor, and other popular AI tools — one agent, better context, ship it. That's the dominant mental model right now, and it doesn't produce pipeline infrastructure because it doesn't think in pipelines.

Second, the pipeline idea comes from a different lineage. I arrived at DAGent through two principles that aren't mainstream AI-product thinking: (1) no matter how well you configure a single agent with MCP and prompts, you're still manually testing its output — that's frustrating and doesn't scale, I wanted at least an 80%-working feature before a human touches it; and (2) DevOps. If you've ever worked with a Jenkins setup you know it's a workflow pipeline with nodes and artifacts — one builds the project, another runs unit tests, another analyzes code quality, the next deploys and runs integration tests, and through the pipeline you get notified on failure. All the pieces are on the table. You just need to connect them for AI agents the same way CI/CD connected them for builds.

Third, until May there was no Enterprise ready orchestrator on the market. Which meant every company that wanted this had to ship both — the orchestrator and the platform-aware pipeline on top of it. That's two hard problems for the price of one, and nobody's going to invest in a pipeline library if they also have to invent the execution engine. But now we have Conductor. It's a genuinely promising product, and it removes the harder half of the problem.

Whoever first ships a platform-aware pipeline library backed by a deterministic orchestrator wins the next chapter of ecommerce extensibility. The platforms that move slowest will watch their SI partners build it anyway — with worse integration points.

What's next

DAGent is done. I don't see a future for it as a standalone project — and that's fine. It was a great learning exercise. I learned how to scope agent boundaries, how context flow between nodes matters more than individual agent quality, how deterministic routing eliminates an entire class of cost and reliability problems, and how badly I need to apply product discipline to my own side projects. It validated the thesis. That was always the point.

My next goal is applying Conductor to ecommerce. The conductor-workflow.yaml in this repo is the starting point — a functional mapping of DAGent's pipeline to Conductor's format, targeting a Salesforce PWA Kit storefront. From here I'm building the platform-aware pipeline library I described above: curated workflows that encode ecommerce framework constraints so the agents operate within the same rules a human architect would enforce.

If I hit gaps — missing features, edge cases, things that don't work cleanly in constraint-heavy delivery — I'll contribute upstream. Conductor is early enough that contributions from people running real workloads against it will shape the product.

Jason — thank you for shipping Conductor. Seeing a Principal-level engineer converge on the same architecture from the infrastructure side told me the category is real. Your implementation made the orchestration layer credible to people who would never have looked at my weekend project.

If you're an engineer who's been stitching together agent pipelines with glue code inside platform-constrained delivery: Conductor is worth your afternoon. And if you're at Salesforce, Shopify, or Adobe thinking about what "AI-native extensibility" actually means — the platform-aware deterministic pipeline pool is the answer nobody's shipping yet.

The pipeline is the product. The orchestrator is infrastructure.

DAGent repo · Conductor repo · First post · Second post

Three of four failure cycles in my agentic pipeline were the same bug class: the backend agent wrote correct Azure Functions code, CI deployed it, integration tests hit 404, the triage engine routed the failure back to backend-dev, and the agent re-read its own code, found nothing wrong, added defensive checks, pushed again. Another 404. Same error, different attempt, zero progress.

The circuit breaker caught it after 50 minutes and 3 wasted cycles. The root cause wasn't a code bug. The APIM route hadn't been provisioned. The Function App setting didn't exist. The infrastructure wasn't there.

The pipeline was working as designed. The design was wrong.

This post covers how I restructured the pipeline from a 12-item, 4-phase single-wave DAG to an 18-item, 6-phase two-wave architecture with a human-approved infrastructure gate — and why that gate eliminated an entire category of failure. Repo is open. First blog post for context.

The Failure Pattern, Precisely

Here's the v1 timeline from the first post:

00:37 — schema-dev           ✅  (4m)
00:41 —┬— backend-dev        ✅  (7m)     ← writes Terraform + Azure Functions
       └— frontend-dev       ✅  (11m)
00:52 —┬— backend-unit-test  ✅  (2m)
       └— frontend-unit-test ✅  (1m)
00:54 — push-code            ❌  (15m TIMEOUT — agent went rogue)
01:09 — push-code            ✅  (2s, deterministic retry)
01:09 — poll-ci              ✅  (10m)
01:19 — integration-test     ❌  → redev cycle 1   ← "404 on /api/generate"
       ... 3 more cycles ...                         ← same 404, same root cause
02:20 — integration-test     ✅
02:47 — create-pr            ✅

140 minutes total. 53 of those minutes — 38% of the run — were spent in post-deploy reroute cycles caused by the same problem: application code deployed before its infrastructure existed.

The v1 architecture treated Terraform as a backend-dev concern. The agent wrote .tf files and Azure Functions code in the same session, committed both with the same scope, and the deploy pipeline handled them as one unit. When the feature required a new APIM operation or Function App setting, the infrastructure changes and the code that depended on them raced through CI together.

Sometimes infra landed first. Sometimes it didn't. When it didn't: 404.

Why Better Triage Doesn't Fix This

The immediate instinct is: make the triage engine smarter. Teach it to recognize "infrastructure not provisioned" as a distinct fault domain. Route to infra-architect instead of backend-dev.

I actually tried this. The problem is deeper — it's temporal, not taxonomic. The triage engine can correctly classify fault_domain: "infra" and route to the right agent. But in a single-wave pipeline, re-running the infra agent means re-running the deploy, re-running CI, and re-running the integration test. Each cycle burns 10–20 minutes. And if the fix requires a terraform apply that needs elevated permissions, the loop is infinite.

Triage tells you what broke. It can't fix the fact that the ordering was wrong from the start.

Infrastructure and Application Code Are Different Trust Domains

This is the table that changed how I think about the pipeline:

"Yeah, but couldn't you just run terraform apply automatically?"

For greenfield resources in a dev environment, sure. But the moment you touch IAM role assignments, OIDC federation, network security groups, or APIM policies — the blast radius is environment-wide. A wrong terraform apply can lock out your own CI pipeline (ask me how I know). The enterprise answer is: plan automatically, apply with approval.

The fix isn't better error classification. It's never letting application agents run until infrastructure is proven to exist.

The Two-Wave DAG

18 items. 6 phases. The two waves never overlap.

The key dependency edges — and this is worth staring at — are:

// pipeline-state.mjs — the actual dependency map
export const ITEM_DEPENDENCIES = {
  // Wave 1
  "schema-dev":           [],
  "infra-architect":      ["schema-dev"],
  "push-infra":           ["infra-architect"],
  "create-draft-pr":      ["push-infra"],
  "poll-infra-plan":      ["create-draft-pr"],
  "await-infra-approval": ["poll-infra-plan"],
  "infra-handoff":        ["await-infra-approval"],

  // Wave 2 — gated behind infra-handoff
  "backend-dev":          ["schema-dev", "infra-handoff"],  // ← the gate
  "frontend-dev":         ["schema-dev", "infra-handoff"],  // ← the gate
  "backend-unit-test":    ["backend-dev"],
  "frontend-unit-test":   ["frontend-dev"],
  "push-app":             ["backend-unit-test", "frontend-unit-test"],
  "poll-app-ci":          ["push-app"],
  "integration-test":     ["poll-app-ci"],
  "live-ui":              ["poll-app-ci", "integration-test"],
  "code-cleanup":         ["integration-test", "live-ui"],
  "docs-archived":        ["code-cleanup"],
  "publish-pr":           ["docs-archived"],
};

backend-dev and frontend-dev both depend on infra-handoff. That's the structural guarantee. No amount of prompt engineering or triage logic can bypass it — the DAG scheduler won't make the item available until infra-handoff is done.

Six new items vs. v1. push-code split into push-infra + push-app. poll-ci split into poll-infra-plan + poll-app-ci. Not naming gymnastics — each triggers different CI workflows with different permissions and different failure modes.

The infra-architect Agent: Validate Before You Commit

Most agent systems trust CI to catch errors. The infra-architect agent runs terraform validate + terraform plan locally before anything leaves the session. The hard constraint: don't mark complete until terraform plan succeeds.

Why validate locally instead of trusting CI? Terraform plan is slow in CI (~2 min), plan failures cascade (a missing variable blocks everything), and the plan itself is an artifact — it gets posted to the Draft PR for human review. Catching errors in 10-second local cycles beats 10-minute push → CI → poll cycles.

The agent never runs terraform apply. Apply is irreversible and environment-scoped — a wrong apply can delete resources, corrupt state, or create security holes. The agent writes and validates; CI generates the plan; a human approves; an elevated workflow applies.

The Approval Gate: agent: null

This is the simplest and most important piece of code in the pipeline:

// pipeline-state.mjs
{ key: "await-infra-approval", agent: null, phase: "approval" }

// watchdog.ts — the orchestrator loop
const approvalGateItems = available.filter((i) => i.agent === null);
if (approvalGateItems.length > 0 && available.every((i) => i.agent === null)) {
  console.log("  ⏸  Awaiting human approval — comment /dagent approve-infra");
  break;  // clean exit — ChatOps re-triggers on approval
}

agent: null means no LLM session gets created. Zero tokens. The orchestrator logs a message, exits cleanly, and waits. A GitHub Actions ChatOps workflow (dagent-chatops.yml) watches for PR comments:

• /dagent approve-infra — Triggers elevated-infra-deploy.yml, which runs terraform apply with OIDC credentials scoped to a secops-elevated GitHub Environment (requires reviewer approval). On success, calls pipeline:complete for await-infra-approval, then re-triggers the orchestrator.

• /dagent hold — Cancels all running agentic + elevated workflows. Full stop.

• /dagent apply-elevated -target=azurerm_resource.x — Targeted apply for when you need to apply specific resources with elevated permissions.

The approval gate costs ~0 seconds of compute and ~0 tokens. The human review typically takes 2–5 minutes. The 50 minutes of wasted agent cycles it eliminates make it the best ROI of any change in the pipeline.

The Infra-Handoff Contract

After approval and apply, infra-handoff bridges the two waves. It reads terraform output -json from the applied infrastructure and writes a structured contract (with sensitive values masked):

# Infrastructure Interfaces — my-feature

## Endpoints
- Function App: https://func-tb-dev.azurewebsites.net
- APIM Gateway: https://apim-tb-dev.azure-api.net
- Static Web App: https://swa-tb-dev.azurestaticapps.net

## API Routes
- POST /api/auth/login → fn-demo-login
- GET  /api/hello → fn-hello

## Auth Config
- CORS Origins: ["https://swa-tb-dev.azurestaticapps.net"]

When backend-dev and frontend-dev start their sessions, they read this file. They know every endpoint, every URL, every resource name. They don't guess. They don't assume. They read a contract that was generated from real terraform output against applied infrastructure.

This is why application development time dropped 22% — agents spend less time exploring and more time implementing, because the infrastructure contract removes an entire class of unknowns.

Graceful Degradation: Knowing When to Stop

Not every infrastructure error is retryable. The triage engine maintains a list of signals that no agent can fix:

// triage.ts
const UNFIXABLE_SIGNALS = [
  "authorization_requestdenied",       // Azure AD
  "aadsts700016", "aadsts7000215",     // Entra ID
  "insufficient privileges",
  "does not have authorization",
  "subscription not found",
  "error acquiring the state lock",    // Terraform
  "resource already exists",
  "state blob is already locked",
] as const;

When one of these appears, triageFailure() returns an empty array — "blocked, don't retry." The pipeline doesn't halt. It preserves all valid work, marks untestable items as n/a, skips to documentation and PR creation, and opens a Draft PR with the error documented.

"Why not just halt and throw an error?"

Because partial work has value. If schema-dev, infra-architect, and backend-dev all completed successfully but integration-test hit an IAM denial — that's 80% of a feature. Throwing it away because of an environment config issue is wasteful. Ship the draft, let the human fix the IAM binding, re-run the pipeline from where it stopped.

Before/After: The Numbers

Same feature (full-stack deployment with new APIM routes), v1 vs. two-wave:

The 79% reduction in post-deploy time is the headline. Those 4 reroute cycles were structurally impossible in v2 — the DAG dependency on infra-handoff prevents the failure class from occurring.

The 22% app-dev speedup is an unexpected bonus: agents producing fewer exploratory commands because the infra contract removes guesswork about which endpoints exist.

The total now includes ~3 minutes of human Terraform plan review. That's a net trade of 3 minutes of human attention for 50 minutes of wasted compute. I'd take that tradeoff every time.

The Mental Model: Your DAG Is Your Trust Model

Every dependency edge in a DAG is a trust statement.

backend-dev → backend-unit-test means: "I trust backend-dev's output enough to run tests against it."

infra-architect → push-infra → poll-infra-plan → await-infra-approval → infra-handoff → backend-dev means: "I don't trust infrastructure changes until CI validates the plan, a human reviews it, an elevated workflow applies it, and the outputs are captured into a contract."

That's 5 edges encoding a trust policy. The old pipeline had 0.

When you add a new agent to any pipeline, the question isn't just "what does it depend on?" It's: "what am I trusting when I let this agent run?" If the answer includes "infrastructure that hasn't been validated" or "permissions that haven't been approved" — add a gate.

Trust Taxonomy for AI Agents

Based on running this pipeline across multiple features, here's where I've landed:

Trust the agent to:

• Reason about code. Write functions, debug type errors, design APIs. This is what LLMs are genuinely good at.

• Diagnose failures. Parse error logs, emit structured {"fault_domain": "backend", "diagnostic_trace": "..."} JSON. Agents are surprisingly reliable at classification.

• Follow bounded workflows. Numbered steps with clear completion criteria. The key word is bounded.

Don't trust the agent to:

• Orchestrate itself. (The v1 push-code agent ran 63 shell commands in 15 minutes, including git reset --hard. Deterministic orchestration is non-negotiable.)

• Judge blast radius. (An agent doesn't distinguish "this affects one endpoint" from "this affects the entire network layer." The DAG must encode this.)

• Know when to stop. (Without circuit breakers, agents retry until timeout with decreasing output quality.)

• Approve infrastructure. Not because they'd get it wrong — the infra-architect agent writes correct Terraform. But the consequence of a wrong apply is categorically different from a wrong endpoint, and the organization needs a human audit trail.

Updated Stripe Comparison

The first post mapped my v1 against Stripe's Minions. The biggest delta in v2: infrastructure handling. Stripe likely doesn't have this problem — their infra is managed by a dedicated platform team, not by the same agents that write application code. For everyone else building on cloud primitives, the infrastructure trust boundary needs to be explicit in the execution graph.

Trade-Offs and Open Questions

This architecture isn't free. Honest accounting:

Added latency. Wave 1 is strictly sequential: schema-dev → infra-architect → push-infra → create-draft-pr → poll-infra-plan → await-infra-approval → infra-handoff. That's 7 items in series before any application code runs. For features with no infrastructure changes, this is pure overhead. The pipeline mitigates this with workflow types — Backend and Frontend workflow types still skip infra items via N/A marking — but Full-Stack features pay the full serial cost.

Human dependency. The approval gate blocks on a human. If no one reviews the Terraform plan for 2 hours, the pipeline sits idle for 2 hours. In practice: we use Slack notifications on Draft PR creation. Average review time is 3 minutes. But this is a process dependency, not a technical one, and it doesn't self-heal.

State complexity. 18 items × 6 phases × 4 workflow types = a combinatorial state space. Each workflow type has an N/A map that marks irrelevant items — get one entry wrong and an item either runs when it shouldn't (wasted tokens) or gets skipped when it shouldn't (missing validation). Tests cover this (apm-parity.test.ts), but the surface area is real.

Concurrent Terraform state. Two feature branches can't run terraform plan against the same state backend simultaneously without state locking conflicts. The pipeline currently handles this by detecting "error acquiring the state lock" as an unfixable signal (graceful degradation), but the correct solution is either a queueing mechanism or environment-per-branch isolation. Neither is implemented.

The Principle

Separate concerns by trust level, not by technology.

The v1 pipeline separated by phase: pre-deploy, deploy, post-deploy, finalize. The v2 pipeline separates by trust boundary: infrastructure (human-approved) vs. application (auto-verified). The phases still exist within each wave — but the trust model governs the top-level architecture.

This applies beyond AI pipelines. Any system where autonomous agents interact with infrastructure should encode trust boundaries in its execution graph, not in its prompts. Prompts can be ignored. DAG edges can't.

What's Next

The full pipeline is open source — orchestrator, APM compiler, triage engine, ChatOps workflows, and the two-wave DAG. If you're adapting this to your own stack, the files to start with are .apm/instructions/ (your project's rules) and the workflow type configs in pipeline-state.mjs.

I'm most interested in feedback on:

• The approval gate pattern — is /dagent approve-infra via ChatOps the right UX, or should this be a GitHub Environment protection rule?

• Graceful degradation — shipping a Draft PR with partial work vs. halting entirely. Which would your team trust?

• Terraform state contention — environment-per-branch isolation vs. a queue. What's worked for you?

If you're building deterministic agent pipelines or figuring out where human gates belong in AI-assisted workflows, I'd genuinely like to hear what you've learned. The repo is open and actively developed. The first post covers the v1 architecture and the Stripe convergence. I'm Roman Kaliupin — I build agentic developer tooling and always enjoy connecting with people working on similar problems.

The 80/20 Insight

We have incredible AI coding tools — Copilot, Cursor, Claude Code. They're transformative for the 20% of work that requires judgment, creativity, and architectural thinking.

But what about the other 80%? The work where every step is well-understood, the patterns exist in your codebase, the rules are documented, and the tests define success. This work doesn't need a human co-pilot. It needs a factory.

So I built one. Then I found out Stripe built the same thing — and ships 1,300+ PRs per week with it.

The Architecture: Deterministic Control + LLM Execution

The core insight — and one that Stripe arrived at independently — is this: LLMs are great reasoners but unreliable orchestrators. Give them a focused task with clear boundaries, and they excel. Ask them to coordinate a 12-step pipeline with failure recovery and CI/CD integration, and they hallucinate steps, skip phases, and burn tokens in loops.

The system separates two concerns that most agentic tools conflate:

• Control plane (deterministic) — A TypeScript while loop reads a DAG state machine, resolves dependencies, and spawns agent sessions. No LLM decides what happens next. The state machine does.

• Execution plane (LLM) — Each specialist agent receives a bounded context (rules, MCP tools, skills) and reasons about its domain. Backend-dev writes backend services. Frontend-dev writes React components. Live-ui runs Playwright against the deployed app. Each agent is trusted to think, but not to orchestrate.

The Stripe Convergence

After reading Stripe's Minions blog post, I mapped my design decisions against theirs:

Deterministic orchestration wrapping LLM execution, configured per project, with bounded failure recovery and CI/CD as a first-class pipeline phase. Two teams, working independently, arrived at the same pattern.

The Pipeline DAG

12 items across 4 phases, scheduled by an explicit dependency graph — not inferred by an LLM at runtime. Items within a batch run in parallel:

The dashed arrows show self-healing reroutes with compound fault domains — a CORS failure resets only frontend-dev, not the entire pipeline. Test agents write new tests for the code that dev agents just created. The deploy phase (push-code, poll-ci) runs as deterministic bypasses — no LLM session, no tokens spent on mechanical operations. Four workflow types (Backend, Frontend, Full-Stack, Infra) prune irrelevant items at init.

What Makes It Work

1. APM: Agent Package Manager

Context pollution kills agent quality silently. When you stuff a single system prompt with every rule for your entire project, the agent's attention degrades. Microsoft's APM solves this — you declare agents, their instruction includes, MCP servers, and skills in a single apm.yml manifest:

# apm.yml — each agent declares exactly which rules it needs
agents:
  backend-dev:
    instructions: [always, backend, infra, tooling/roam-tool-rules.md, tooling/roam-efficiency.md]
    mcp: [roam-code]
    skills: [test-backend-unit]
  frontend-dev:
    instructions: [always, frontend, tooling/roam-tool-rules.md, tooling/roam-efficiency.md]
    mcp: [roam-code]
    skills: [test-frontend-unit, build-frontend]
  poll-ci:
    instructions: [always]    # minimal context — this agent just watches CI
    mcp: []
    skills: []

If any agent's assembled rules exceed the token budget, compilation fails — the same way type systems prevent runtime errors by failing at compile time.

2. Self-Healing Recovery with Live Browser Testing

When post-deploy tests fail, the pipeline doesn't retry blindly. The failing agent emits a structured diagnostic:

{ "fault_domain": "frontend+infra", "diagnostic_trace": "CORS 403 on /api/generate — APIM not routing to backend origin" }

The triage engine maps the fault domain to the correct development agents, resets them to pending, injects the error context into their next prompt, and re-enters the loop. Circuit breakers prevent infinite loops: 5 redevelopment cycles, 10 retries per item, hard session timeouts.

The live-ui agent doesn't execute a pre-written test suite — it creates Playwright E2E scenarios tailored to the feature it just built, runs them against the deployed app with headless Chromium. It authenticates through the real auth flow, validates CORS headers, routing, and rendered DOM state — all against production-like infrastructure, not mocked endpoints.

3. Structural Code Intelligence (Roam-Code)

Roam-code pre-indexes the codebase into a semantic AST graph using tree-sitter (27 languages, 102 MCP tools). Instead of text search, agents ask structural questions:

Agents are forbidden from using grep for code exploration. Before any agent can mark its work done, it must pass roam_check_rules — a deterministic governance gate, not a prompt-based suggestion.

4. Agents Never Touch Git or State

Every side-effect goes through deterministic wrappers that provide the same auditability enterprises expect from their human CI/CD pipelines. Trust the LLM to reason, but don't trust it to operate.

What 140 Minutes and 4 Failure Cycles Taught Me

Architecture diagrams are easy to draw. Running them against real infrastructure is where the learning happens. I ran the pipeline on a full-stack deployment feature — provisioning Azure infra, deploying backend Functions + frontend SWA, wiring APIM, and validating end-to-end with Playwright. Here's what actually happened:

00:37 — schema-dev (4m)
00:41 —┬— backend-dev (7m)        ←── parallel
       └— frontend-dev (11m)      ←── parallel
00:52 —┬— backend-unit-test (2m)  ←── parallel
       └— frontend-unit-test (1m) ←── parallel
00:54 — push-code ❌ (15m TIMEOUT — agent went rogue)
01:09 — push-code ✅ (2s, deterministic retry)
01:09 — poll-ci ✅ (10m)
01:19 — integration-test ❌ → redev cycle 1
       ... 3 more cycles on the same bug ...
02:20 — integration-test ✅ (all 7 tests pass)
02:25 — live-ui ✅ (8 Playwright tests)
02:47 — create-pr ✅ (PR #2)

Final result: 140m 30s, 33 steps (28 pass / 5 fail), 4 redevelopment cycles. The pipeline shipped a working PR.

What went right: The happy-path pre-deploy phase completed in 15 minutes with full DAG parallelism. The backend agent independently identified that tsc doesn't bundle dependencies and migrated to esbuild. The CI agent proactively fixed a workflow bug. The finalize phase removed 56 lines of dead code using roam-code's analysis.

What went wrong — and what I learned:

The first push-code agent went rogue. It was supposed to do one thing: push the branch. Instead it executed 63 shell commands in 15 minutes — including git reset --hard, cherry-pick operations, and pipeline:complete calls on items owned by other agents. It timed out. The deterministic fallback (just git push) worked in 2 seconds. Lesson: mechanical operations should never get an LLM session.

The bigger bug: agent-commit.sh scopes commits by agent domain — backend scope only stages files under backend/. The backend-dev agent correctly identified a CI workflow fix and applied it to the working tree, but the commit script wouldn't stage .github/workflows/deploy-backend.yml. The fix existed in the working tree for 3 cycles but was never committed. The pipeline burned ~50 minutes on the identical unfixed bug because the agent could edit the file but not commit it through the sanctioned path.

The triage diagnostics from cycle 3 onward explicitly reported: "A working-tree fix exists but was NEVER COMMITTED." The system saw the problem clearly — it just couldn't act on it.

What I fixed after: Added a cicd commit scope for cross-cutting workflow files. Added duplicate-error detection to the circuit breaker — if an agent fails with the same error and no code has changed, the pipeline halts immediately instead of burning tokens. Made push-code always deterministic.

This is the feedback loop that makes deterministic pipelines valuable: every failure is observable, triageable, and fixable. The audit trail is the training data.

Try It

The entire pipeline is open source. It includes the orchestrator, the APM system, 6 CI/CD workflows, and comprehensive documentation. Every run produces a deterministic audit trail — state files, transition logs, per-step metrics, and Playwright logs.

It's a Blueprint — Not a Finished Product

The orchestration engine is generic — the watchdog, state machine, APM compiler, triage engine, and DAG scheduler don't know anything about Azure. But the sample app's instruction fragments and CI workflows are Azure-specific. Adapting this to your stack means rewriting the files in .apm/instructions/ and .github/workflows/ — exactly the files designed to be swapped per project.

Quick Start

# 1. Clone and open in DevContainer (VS Code / Codespaces)

# 2. Create a feature spec
mkdir -p apps/sample-app/in-progress
vim apps/sample-app/in-progress/my-feature_SPEC.md

# 3. Initialize pipeline state
export APP_ROOT=apps/sample-app
npm run pipeline:init my-feature Full-Stack

# 4. Run the orchestrator
npm run agent:run -- --app apps/sample-app my-feature

# 5. Review the PR when the pipeline completes

Prerequisites: GitHub CLI auth (gh auth status), Azure CLI auth (for live deploy/test), DevContainer with --shm-size=2gb, and an apm.yml config.

I'd love technical feedback — especially on gaps in the architecture or if you've tried similar approaches.

If you're building deterministic agent orchestration or evaluating this pattern for your org, I'd love to compare notes. The repo is open and I'm actively developing it. I'm Roman Kaliupin — I build agentic developer tooling and always enjoy connecting with people working on similar problems.