Microsoft Just Shipped Conductor. I Built a Side Project With the Same Idea. Here's the Gap.

Third in a series. Previously: the vision post and the infrastructure post, both from March 2026.

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