How to build an AI agent workflow: start with the problem

Start a useful AI agent workflow with an operational problem: something that should move from an uncertain starting state to a useful, verifiable outcome. Models, prompt libraries, and agent diagrams come later.

That distinction changes the design. A chain of prompts describes what the model should say next. An operational contract describes what the system is allowed to do, what state it must preserve, how progress is evaluated, and when the job is finished.

This is also what separates a workflow from adjacent concepts. An agent, workflow, and orchestrator can all involve model reasoning, but they carry different responsibilities. The workflow defines the operating boundary. The orchestrator decides how to advance within it. Agents perform bounded work.

Why prompt chains become fragile

Prompt chains often look convincing in a prototype. One prompt gathers information, another drafts, and a third reviews. Each stage passes text to the next.

The fragility appears when the input is incomplete, a tool fails, a reviewer finds a real defect, or the work resumes after interruption. The chain has no reliable answer to questions such as:

• Which facts were verified, and where did they come from?
• Is a review comment a blocker, a repair, or an unsupported preference?
• Can a failed step be retried without repeating side effects?
• What remains unfinished?
• Has the requested outcome already been reached?
• Which instructions still apply after several rounds of generated text?

Prompting alone does not create durable state or explicit control flow for these questions. A larger context window can hide that gap without closing it.

A prompt chain also tends to mix reasoning, state, and control flow. The model is expected to remember prior decisions, infer the current phase, choose tools, preserve constraints, and decide whether to stop. Small ambiguities accumulate. Later steps inherit summaries of summaries rather than a stable account of the job.

Representing those responsibilities explicitly makes an agentic workflow easier to inspect when something changes.

Define the job before defining the agents

Start with four descriptions: the problem, the useful outcome, the operator path, and the agent path.

The problem describes the operational gap. “We need a five-agent research system” is an implementation preference. “An editor cannot tell which claims in a draft are supported by the supplied sources” is a problem.

The useful outcome is the state in which that problem has been resolved. It should be inspectable. For the example above, the outcome might be a publishable draft whose material claims are linked to evidence, with unresolved claims clearly identified.

The operator path describes what a person initiating or supervising the workflow must do. What do they provide? Which choices can only they make? What can they inspect or revise? If the operator must repeatedly reconstruct hidden workflow state from chat history, the contract is incomplete.

The agent path describes how the system turns the initial inputs into the outcome. It names the required stages, dependencies, tools, state transitions, and recovery behavior. It should not assume that the agent will infer the intended route from a vague goal.

The two paths should meet at explicit interaction points, but they do not need a mandatory approval after every step. Some workflows can proceed automatically within a narrow boundary. Others need a decision when evidence conflicts, scope changes, or an external side effect is about to occur. The contract should reflect the actual risk rather than adding ceremonial checkpoints.

Work backward from a terminal condition

A workflow needs a definition of done that can survive imperfect execution.

“Produce a good article” is not a terminal condition. Neither is “continue until the reviewer is satisfied.” Both delegate completion to an unbounded judgment.

A stronger terminal condition combines observable state with acceptance criteria. For example:

The draft exists, required sections are present, material claims have supporting evidence or an explicit unresolved status, blocking review findings are repaired, and the output passes the sanitization checks.

This gives the orchestrator something concrete to evaluate. It also prevents the workflow from looping because a reviewer can always imagine another improvement.

Terminal conditions should distinguish failure from incompleteness. Missing credentials, unavailable evidence, and contradictory operator requirements may prevent completion. Those states should produce structured recovery information: what failed, what was preserved, and what action could unblock the run.

Keep durable state outside the conversation

Conversation context is useful working memory. It is a poor system of record.

Durable workflow state should capture the facts needed to resume or audit the job: inputs, source references, decisions, step status, outputs, findings, retries, and unresolved issues. Generated prose can be part of that state, but it should not be the only place where the workflow records what happened.

While building StackOS, we have treated this separation as an authoring constraint. The workflow contracts we are refining represent run state, step boundaries, grants, findings, and outputs independently from an agent’s conversational context. That is implementation experience, not proof that every workflow needs the same storage model. The useful principle is narrower: state required for correct continuation should not depend on a model reconstructing it from dialogue.

Durable state changes the agent experience. An agent entering halfway through a run can inspect the current state instead of performing archaeology on a transcript.

Make every step an explicit packet

A step should arrive as a bounded packet of work. A role name followed by the entire project history leaves the agent to reconstruct the real assignment.

A useful step packet contains:

• Purpose: why the step exists and what downstream decision it supports.
• Inputs: the artifacts, references, and state the step may rely on.
• Bounded context: the relevant constraints without unrelated run history.
• Exact tools: the operations available for this step, including their scope.
• Expected outputs: the artifact or state change the step must produce.
• Criteria: the checks that determine whether the output is acceptable.
• Recovery: how to report missing inputs, tool failures, ambiguity, or partial work.

Consider a claim-review step. Its purpose is not to “improve the draft.” It is to identify material claims, compare them with allowed evidence, and emit structured findings. Its tools might permit reading sources and recording findings but not rewriting the article. Its output distinguishes supported claims, unsupported claims, and cases where the available evidence is inconclusive.

That packet gives the reviewer enough freedom to reason without giving it ownership of the whole delivery. It also makes failures local. If evidence is missing, the workflow can repair that dependency rather than restart content production.

Exact tools matter because capability is part of the contract. An instruction such as “do not publish” is weaker than a step that has no publishing operation available. Tool boundaries turn behavioral expectations into operating constraints.

Give one orchestrator ownership of progression

A practical default is one reasoning orchestrator that owns progression: inspecting state, selecting the next eligible step, evaluating outputs, and checking the terminal condition. Add a specialist when the task needs a distinct context, tool boundary, or evaluation discipline—not simply because the brief contains several kinds of work.

In a content-production workflow we have been authoring for StackOS, one orchestrator coordinates bounded evidence, writing, claim, voice, and sanitization specialists. Each specialist has a different job and output contract. None independently decides that the entire article is complete.

The orchestrator also acts as the feedback gatekeeper. Review findings are classified before they affect delivery. A supported blocker can reopen an earlier step. A specific, valid repair can become bounded follow-up work. An unsupported preference or a finding outside the agreed scope does not silently expand the job.

This classification is designed to prevent a familiar multi-agent failure mode: every reviewer becomes a new source of authority. Without classification, one agent’s stylistic suggestion can override the original brief, trigger unnecessary rewrites, and create another review cycle. Feedback should change delivery only when the workflow contract says that kind of finding matters.

This is not a universal claim that every system needs exactly one orchestrator. It is a practical default for workflows where several bounded tasks contribute to one outcome. Additional reasoning authorities should have a clear ownership boundary, not merely a different persona.

Verify the cold start

A workflow that succeeds only when its designer supplies unstated context is not finished.

Cold-start verification gives a fresh agent the kind of vague request an actual operator might provide and observes what happens. Does the agent locate the workflow? Does it inspect state and requirements? Does it ask for a genuinely missing choice? Or does it guess the project, invent inputs, and begin producing output?

While refining our StackOS workflow guidance, we use fresh-agent scenarios to expose these gaps. We are testing whether the operating contract leads an unfamiliar agent toward the intended path, not whether the model can improvise a plausible response.

A good cold start should make the safe next action easier than guessing.

A compact workflow design test

Before adding another prompt or specialist, test the workflow with a short sequence of questions:

1. What operational problem is being resolved?
2. What observable state counts as a useful outcome?
3. What does the operator provide, decide, and receive?
4. What path may the agent take, and which actions are outside its boundary?
5. Where does durable state live?
6. Does each step have explicit inputs, tools, outputs, criteria, and recovery?
7. Who evaluates findings and decides whether they change the run?
8. Can a fresh agent find the path without private context?
9. Can the workflow stop deterministically?

If the answers are vague, a more elaborate agent topology can make the ambiguity harder to see. Start with the problem, define the contract, and let the agents occupy only the boundaries the work actually requires.