Most teams don't start by building a workflow. They start by building an agent. A single prompt. A single screen. A single "wow." Then reality shows up.
Someone asks for a compliance check. Someone wants the message rewritten for tone. Someone wants the output packaged into something shareable. Someone wants an audit trail. Someone wants to see which step caused the wrong wording.
This is the moment your agent quietly becomes something it was never designed to be: the conductor of a business process.
And when your agent becomes the conductor, you don't just get unpredictability rather you get unexplainability. The system still produces outputs, but you can't confidently describe how it got there, why it said something, or how to fix it without "trying different prompts."
That's not an LLM problem. That's an orchestration problem.
The distinction that stops the chaos
Here's the simplest line that keeps systems sane:
An agent is an actor. A workflow is a director.
Agents are incredible at reasoning within a bounded responsibility. They can interpret messy text, produce drafts, critique language and apply style. Whereas, workflows are responsible for the part engineers care about most: the shape of execution. The ordering. The branching. The stop conditions. The boundaries. The traceability. The ability to resume. The ability to prove what happened.
Microsoft Agent Framework Workflows exists to make that shape explicit rather than accidental, including built-in orchestrations (Sequential, Concurrent, Group Chat, Handoff and Magentic) that represent different coordination strategies.
If you hand "system shape" to an agent, you get a brilliant actor who improvises forever. If you separate the responsibilities, you get a system you can ship.
Check out this mental model:
The workflow tells the agent what the step is. The agent returns output. The workflow decides what happens next.
That loop is the foundation for every orchestration pattern we'll cover.
Why "type safety" matters in orchestration
When people hear "type-safe workflows," they sometimes assume it's marketing. It isn't.
In real multi-step systems, the most common bugs aren't "the model hallucinated." The common bugs are:
- Step outputs don't match what the next step expects
- Someone silently changes a prompt and breaks downstream parsing
- A "review" step starts rewriting instead of reviewing
- The system loses context and nobody knows where
- You can't resume because you didn't store enough state
Workflows exist to formalise those boundaries. Even if your demo starts with strings and JSON, the discipline is the point, each step has a contract and orchestration is the enforcement mechanism. I get philosophical at times.
Which orchestration pattern should you start with?
You'll see a lot of patterns in this series and I covered all of them high-level in our previous post. But the first one we ship is Sequential, for a simple reason, sequential forces discipline.
It is the pattern that makes you think like an engineer again. And it gives you the clearest answer to the question that kills most multi-agent demos:
Who's in control right now?
In Sequential orchestration, the answer is always the workflow. Control moves forward step-by-step. No debate. No routing. No committee meetings. That constraint is not limiting, it's stabilising.
Not "agents in a line" but a pipeline with responsibilities
Sequential orchestration is the orchestration pattern that matches how business execution naturally works: draft first, then refine, then validate, then publish.
It's not trying to be clever. It's trying to be boring in the best way: predictable, traceable, repeatable.
That final box of Audit Trail is not optional. It's the feature that makes the system usable in real teams. Because when someone asks "why did it say that?", you don't answer with vibes, you point to Step 4.
Introducing PolicyPack Builder (a workflow people actually need)
PolicyPack Builder demonstrates a six-step deterministic pipeline that transforms chaotic input into compliant, structured HTML with each step has a bounded responsibility and creates a transparent audit trail.
PolicyPack Builder in action: six-step sequential workflow
Implementation: the anatomy of a step executor
Each step is implemented as a dedicated executor class implementing IStepExecutor. Here's the extraction step from our codebase:
public sealed class ExtractFactsExecutor : IStepExecutor
{
private readonly ILlmClient _llmClient;
public string StepName => WorkflowSteps.ExtractFacts;
public async Task<WorkflowContext> ExecuteAsync(
WorkflowContext context,
CancellationToken cancellationToken = default)
{
string systemMessage = """
You are a document analysis expert. Extract structured information.
Output STRICT JSON only with this exact schema:
{
"entities": [...],
"key_points": [...],
"risks": [...],
"required_disclaimers": [...]
}
""";
string prompt = $"""
Analyze the following text:
---
{context.NormalizedInput}
---
Remember: Output only valid JSON matching the specified schema.
""";
string response = await _llmClient.InvokeForJsonAsync(
prompt,
systemMessage,
cancellationToken
);
context.ExtractedFactsJson = response;
return context;
}
}
Notice what's not happening:
- The step doesn't decide what happens next
- The step doesn't route to other steps
- The step doesn't know about the workflow shape
It receives context. It performs one job. It returns updated context. The workflow orchestrator owns everything else.
The workflow step catalog
All six steps are defined as constants in a single place:
public static class WorkflowSteps
{
public const string IntakeNormalize = "IntakeNormalize";
public const string ExtractFacts = "ExtractFacts";
public const string DraftSummary = "DraftSummary";
public const string ComplianceCheck = "ComplianceCheck";
public const string BrandToneRewrite = "BrandToneRewrite";
public const string FinalPackage = "FinalPackage";
public static readonly string[] AllSteps =
[
IntakeNormalize,
ExtractFacts,
DraftSummary,
ComplianceCheck,
BrandToneRewrite,
FinalPackage
];
}
This is where the shape lives. Change the order here and the entire workflow changes. No prompt engineering required.
A decision guide
The Strategy pattern enables us to define a family of step executors where each implements the same interface but encapsulates a distinct algorithm. This allows the workflow orchestrator to treat all steps uniformly while maintaining flexibility to add, remove, or modify individual steps without affecting the overall coordination logic.
Demo Design
We're building this as a production-style demo, but we're not trying to sneak advanced durability patterns into the first real build.
Re-run from step is implemented using SQLite-persisted step outputs and immutable run history. It is not durable checkpointing. The official checkpoint approach comes later in the series when it's actually worth the complexity.
Likewise, we'll start with a simple agent invocation approach and keep a clean abstraction so we can upgrade to persistent agents later when we need long-running, multi-session behavior.
Architecture
PolicyPack Builder follows Clean Architecture principles:
Each layer has a single responsibility. The orchestration logic lives in the Application layer. The infrastructure details (how we talk to Microsoft Foundry, how we store runs) are pluggable.
This is how you prevent "the LLM is the architecture."
Now to conclude, Sequential is not the end. It's the foundation. In our next post, we'll break the "one step at a time" constraint and introduce Concurrent orchestration, the pattern for when order doesn't matter but speed does.
We'll also talk about when parallelism becomes a liability and why aggregation strategies are harder than they look.
Until next time.