Workflow Automation

An agent that answers a question and an agentic workflow that runs a business process are built from the same parts, but they are not the same system. The agent described in AI Agents is invoked by a person, holds a conversation, and returns an answer. A workflow is invoked by an event, runs to completion whether or not anyone is watching, writes its output somewhere durable, and has to be operable at 3am by someone who did not build it.

The reasoning loop is identical. What changes is everything around it: how the run starts, how work is decomposed across agents, what happens when a step fails halfway through, and who is accountable for the output. Most of the engineering effort in a production agentic workflow goes into that surrounding structure, not into the agents.

The pattern below is a trigger layer with two entry paths, a workflow that decomposes into nested units of work, and three cross-cutting concerns that wrap the whole thing rather than sitting inside it. It is designed so new building blocks can be added to the workflow without redesigning the scaffolding around it.

The Trigger Model

Every run starts from one of two entry paths, and the choice determines most of the operational design.

• Scheduled Event produces Automated Runs. Monthly sampling, recurring batch review. The workflow starts on a cadence, processes a known window of work, and nobody is waiting for it.
• Unscheduled Event produces One-Off Runs. Ad-hoc review, escalations. The workflow starts because something happened, the arrival rate is unpredictable, and a human is usually waiting on the result.

Teams often build one path and retrofit the other. That fails because the two differ on the concerns that are hardest to bolt on later.

A single run identity covers both paths and makes retries converge instead of fanning out:

def run_key(workflow: str, trigger: dict) -> str:
    """Stable identity for a run, so retries and re-triggers converge."""
    if trigger["type"] == "scheduled":
        return f"{workflow}:{trigger['window_start']}:{trigger['window_end']}"
    return f"{workflow}:{trigger['business_key']}"


def start_run(workflow, trigger, store):
    key = run_key(workflow, trigger)
    existing = store.get(key)
    if existing and existing.status in ("running", "succeeded"):
        return existing  # already handled - do not start a duplicate
    return store.create(key, trigger)

How Work Decomposes

Inside the workflow, work nests through four levels: Event, Task, Action or Sub-Task, and Data or Tool Inputs.

• Event - one execution of the workflow, created by the trigger. It carries the run key, the parameters (which window, which case), and the identity the run executes as. Everything below inherits that context. The event is the unit you retry, cancel, audit, and bill.
• Task - a bounded unit of work with a single owner, usually one agent. "Screen the file", "score the file". A task has a defined input contract and a defined output contract, which is what lets you replace the agent behind it without touching the rest of the workflow.
• Action / Sub-Task - one step the agent takes inside a task: a tool call, a retrieval, a model call, a validation. This is the Reason-Act-Observe cycle from AI Agents. Actions are where iteration limits, token budgets, and output validation apply.
• Data / Tool Inputs - the concrete resources an action touches: a document set, a search index, an API, a memory store. This is the only level that reaches anything real, which makes it the level where access control has to be enforced.

The nesting has an operational consequence worth designing around: the deeper the level, the shorter it lives and the more often it repeats. Actions retry in seconds inside the agent loop, tasks retry in minutes under the orchestrator, and events are re-run in hours or days by a human or a backfill. Putting a retry at the wrong level either hides a real failure or replays expensive work needlessly.

The Cross-Cutting Scaffolding

Three concerns wrap the entire workflow rather than appearing as steps within it: version control and CI/CD, orchestration, and security and monitoring. They are drawn as a wrapper because none of them belongs to a step. A version-control step in the middle of a pipeline is meaningless, and a monitoring step only monitors itself. Each applies to every event, task, and action in the workflow, and together they are most of what separates a demo from something that runs unattended.

Version control and CI/CD

Team collaboration and automated release. For an agentic workflow this covers considerably more than application code.

• Prompts and agent definitions are source. System prompts, tool schemas, agent roles, and routing rules belong in the repository and ship through the same pipeline as the code. A prompt edited directly in a portal is an undeployable change and an unexplainable behaviour shift.
• Model and retrieval configuration are pinned. Model deployment name, temperature, embedding model, index schema, and chunking parameters all change the output. Treat a chunking change with the same seriousness as a schema migration.
• Evaluation gates release. The pipeline runs the workflow against a fixed evaluation set and blocks the release on a threshold. Without that gate, a one-word prompt edit reaches production with no evidence it improved anything.

Orchestration

Workflow orchestration native to the platform, with job scheduling attached - AWS Glue job scheduling in one variant of the pattern, Azure Pipeline job scheduling in another. The orchestrator owns scheduling, retry with backoff, checkpointing between tasks, state hand-off, concurrency limits, and run history.

Keep the boundary between the two orchestration layers clean. The agent framework orchestrates actions inside a task. The platform orchestrator orchestrates tasks inside an event. An LLM should never be the component deciding whether to retry a failed job or how to sequence a pipeline that has a fixed order - that is deterministic control flow, and it belongs in the orchestrator. Where the sequence genuinely is dynamic, the coordination patterns in Multi-Agent Systems apply.

Security and monitoring

Observability, security, and access control across the whole run.

• Run identity. The workflow executes as a service principal with least privilege at the Data / Tool Inputs level, not as whoever triggered it. If it must act on a user's behalf, pass that identity explicitly and check it at the tool boundary.
• Tracing at all three levels. Event, task, and action traces correlated by the run key. Reconstructing what an agent did from its final output alone is not possible, and in a scheduled run there is no user to describe what went wrong.
• Untrusted input. Documents entering the workflow are untrusted content, and a scheduled run has nobody watching when injected instructions are followed. Content filtering and prompt injection defence are covered in Guardrails & Safety.
• Cost and drift. Track token spend and evaluation scores per run over time. Quality degrades gradually as inputs shift, and only a trend line catches it.

Worked Example: File Checking on Azure

To accelerate a manual file checking process, the workflow deploys two agents in sequence on the Azure stack, built with the Microsoft Agent Framework and LangChain. Files arrive either on a schedule (monthly sampling) or one-off (an escalated case), and both paths enter the same pipeline.

Agent #1 - File Screening is a retrieval task. Documents are embedded and indexed into Azure AI Search, a Python script handles querying and prompt engineering against that index, and an Azure AI Foundry LLM produces the screening result. The retrieval mechanics - chunking, re-ranking, and evaluation of retrieval quality - are covered in RAG. A Memory Tool holds temporary memory for the duration of the run: intermediate findings the agent needs across several actions but which should not persist once the event completes.

Agent #2 - Rating / Scoring consumes Agent #1's output and produces a rating with a rationale, backed by its own temporary memory.

Splitting screening and scoring across two agents rather than one is deliberate. The two have different objectives - screening optimises for recall, scoring for precision and consistency - so they need different prompts, different evaluation sets, and different failure thresholds. With a task contract between them, either agent can be replaced or re-tuned without regression testing the other.

Three quality mechanisms wrap the pipeline:

• Evaluation Agents score the output against a rubric automatically on every run, or on a sample when volume makes that uneconomic. This is the only quality signal available on an unattended scheduled run.
• Human-in-loop review sits at the scoring output, where the consequential decision is made. The approval gate and escalation patterns in Autonomous AI determine which cases route to a reviewer: low confidence, high value, or novel situations rather than every case.
• Feedback-based learning turns reviewer decisions into labelled examples that improve prompts and few-shot content. Route those improvements through the CI/CD pipeline with an evaluation gate. An agent that rewrites its own prompt at runtime drifts silently and cannot be rolled back.

Read the diagram as a reference decomposition, not as a mandated shape. Screening independent files is embarrassingly parallel and should fan out. Where scoring finds a gap that screening could resolve with a second retrieval pass, a fixed one-way pipeline is the wrong topology and the handoff or group chat patterns fit better. The trigger model, the four levels of decomposition, and the three cross-cutting concerns hold regardless of the topology inside.

Key Takeaways

• A chat agent and an agentic workflow differ in their scaffolding, not their reasoning. The trigger, orchestration, versioning, and monitoring layers are the actual work.
• Scheduled and unscheduled triggers need different designs for idempotency, concurrency, backfill, and alerting. Build both paths deliberately rather than retrofitting one onto the other.
• Match retry to the level: actions retry in seconds inside the agent loop, tasks in minutes under the orchestrator, events in hours through a backfill. Retrying at the wrong level hides failures or replays expensive work.
• Prompts, agent definitions, and retrieval configuration are source code. If a behaviour change can happen without a commit and an evaluation run, the workflow is not under version control.
• Keep deterministic control flow in the platform orchestrator and reserve agent reasoning for the decisions that genuinely need judgement. Asking an LLM to sequence a fixed pipeline adds cost and failure modes for nothing.