A reliable agent workflow has a narrow goal, known states, limited tools, explicit transition and stop rules, validated outputs, and a recovery owner. Let the model decide only where language or incomplete information requires judgment. Keep permissions, business rules, durable state, and consequential actions in application-controlled boundaries.
Who this is for: Engineers, automation leads, and process owners turning a multi-step business task into an operable agent workflow.
- Model the workflow states and failure exits before writing the agent instruction.
- Use model judgment inside bounded decisions while code enforces invariants and authority.
- Define completion from verified external state rather than from a confident final message.
Define the outcome and boundaries
Begin with one observable outcome, such as producing a sourced supplier comparison for a buyer. State what is outside scope, including contacting suppliers or changing purchase records. A broad command like handle procurement combines research, negotiation, approval, and spending authority into a goal that cannot be tested or safely permissioned.
Name the actor accountable for the result and the conditions that make the task complete. Completion might require three eligible suppliers, evidence for each required criterion, and a reviewer decision. The agent saying done is not evidence. Application code should inspect the saved artifact and approval state before marking the workflow complete.
Map states and transitions
Draw the states the work can occupy: intake incomplete, ready to research, gathering evidence, blocked, awaiting approval, approved, and closed. For each state, list permitted actions and the evidence required to move forward. This map prevents the model from skipping an approval because the final answer appears plausible.
Transitions can be deterministic or model-assisted. Code can verify that required fields exist; a model can judge whether a source addresses a nuanced criterion. Store the current state outside the conversation so retries and restarts do not depend on reconstructed chat history. Use stable identifiers for tasks, calls, evidence, and approvals.
Constrain decisions and loops
Give each model decision the smallest useful choice set. A research step might choose search again, record evidence, or declare a named gap. Set maximum iterations, elapsed time, and tool budget. Repetition without new evidence should trigger a stop, not another rephrased search. A blocked state should explain what input a person must provide.
Separate planning from execution when actions matter. A plan can be reviewed for inappropriate steps before tools run. For lower-risk reads, the system may execute directly while still validating every argument. Writes should use narrow operations, previews, idempotency controls, and approval where consequences warrant it. Never assume model memory supplies these safeguards.
Design recovery and measurement
Expect partial failure. A search provider may time out after useful evidence has already been saved, or an approval may arrive after a process restarts. Make steps resumable and avoid repeating successful side effects. Record attempts and error categories so operators can distinguish infrastructure problems from poor tool selection or bad reasoning.
Measure workflow outcomes such as completion with valid evidence, unnecessary calls, blocked-action rate, reviewer corrections, and recovery time. Review traces for representative failures rather than optimizing only a final-answer score. Platform APIs evolve, so check current official guidance each quarter while preserving tests for your own state and permission contracts.
Design a contract-intake workflow
A legal operations team wants assistance collecting contract facts before a lawyer reviews the agreement.
- Define completion as a saved intake containing named parties, dates, governing law, renewal terms, missing fields, and source locations, without legal conclusions.
- Create states for document missing, extraction ready, facts extracted, discrepancies found, and awaiting lawyer review.
- Allow document reading and structured extraction, but prohibit sending messages, editing the agreement, or marking legal approval.
- Validate required fields and source references in code, route conflicts to the discrepancy state, and stop after a bounded correction attempt.
- Track lawyer corrections by field and add recurring errors to the evaluation set before changing the workflow.
Agent state-map worksheet
Use one row per state to expose missing controls before implementation.
- State: current work condition and the durable data that proves it.
- Allowed actions: tools and decisions permitted from this state only.
- Transition evidence: validated condition required for each next state.
- Limits: attempts, time, budget, and repeated-observation stop rule.
- Recovery: operator, resumable checkpoint, user message, and escalation path.
Common mistakes
- Writing a long system prompt before identifying states, completion evidence, and recovery ownership.
- Allowing the agent to infer that a real-world action succeeded from its own generated narration.
- Retrying an entire workflow after one tool error and duplicating side effects that already completed.
Try one
Sketch a reliable workflow for collecting three approved quotes and preparing a purchase recommendation, without placing an order.
The answer should define intake, evidence collection, eligibility validation, comparison, and approval states. It must separate missing quotes from completed comparison, cite each price and term to source data, cap search attempts, and route unresolved requirements to a buyer. A strong design explicitly excludes ordering tools and treats a buyer's approval as the final state rather than letting the model approve its own recommendation.
Sources
- OpenAI agents guideOfficial guidance for building agent workflows with current OpenAI platform capabilities.
- OpenAI evaluation best practicesOfficial methods for defining evaluation criteria and testing model behavior.