AI Workflow With OpenAI: Define Steps, State, and Review

An AI workflow built on OpenAI models is a sequence of steps where each step calls a model, a tool, or both, and the result of one step feeds the next. The workflow produces something a person can use: a draft, a decision recommendation, a structured output.

The design challenge is making each step explicit: what goes in, what comes out, and when a person must review before the next step runs. Tools like fenbs hold the approved plan and the record of what was decided, so the workflow has a durable backing beyond the current run. AI workflows for education, research, advertising, and SEO are covered on their own pages.

Define steps before you build them

Write out the workflow as a numbered list before writing any code. Each entry names the step, its input type, its output type, and whether a person must approve the output before the next step begins.

This forces early decisions that save later debugging. Steps with ambiguous outputs — "the model returns a summary" — become specific: "the model returns a JSON object with title, body, and confidence fields." Steps with implicit approval boundaries become explicit: "a person must confirm the extracted entities before the workflow continues."

A written step list also makes testing straightforward. Each step is a function with a defined input and expected output schema. You can test each function in isolation before wiring the whole workflow together.

Explicit state between steps

State is what the workflow passes from one step to the next. Implicit state — values passed through shared variables or left in conversation history — is the fastest path to debugging problems that are hard to reproduce.

Use a typed state schema. Each step receives a state object and returns an updated state object. The schema lists every field, its type, and whether it is required. When a field is missing or the wrong type, the workflow stops at the boundary rather than propagating an error silently.

• Input state: the fields this step needs to run. Validate before calling the model.
• Output state: the fields this step produces. Validate before passing to the next step.
• Audit fields: who ran this step, when, and what model version was used.

Approval boundaries

An approval boundary is a point in the workflow where a person must review the current state before the next step runs. Not every step needs one, but every workflow needs at least one — usually before an irreversible action.

Implement an approval boundary as a state field: a boolean or an enum that starts as "pending" and changes to "approved" or "rejected" when a person acts. The next step checks this field and refuses to run if it is still pending.

Record approvals in a durable store, not in the workflow's in-memory state. An approval that lives only in memory is lost if the workflow restarts. See the AI agent approval workflow guide for a detailed pattern.

Testing a multi-step workflow

Test each step in isolation first. Give it a fixed input, run it, check that the output matches the schema and that the state update is correct. Isolation tests catch schema mismatches before they become integration problems.

Then test the transitions. A transition test runs two adjacent steps and checks that the output of the first is a valid input for the second. These tests catch the mismatch between what one step produces and what the next one expects.

Finally, run end-to-end tests with fixed inputs and expected outputs. Use them to detect regressions when you change a step or update a model version. The what is an AI brain guide explains why keeping test decisions and results outside the model matters for reproducibility.

Keeping a handoff record

When a workflow run ends — whether successfully or not — the result should go into a durable record. Specifically: which steps completed, which decisions were made, what the final output was, and where a person needs to act next.

This record has two uses. First, it is what a reviewer reads to understand the run without replaying it. Second, it is what the next run starts from when this one was interrupted or produced a partial result.

How to do this with fenbs

1. Create a free account and add your OpenAI workflow as a project in fenbs. List each step as a task with its input schema, output schema, and approval requirement.
2. Write the approval rules in Decisions and rules: which steps need human review, what the model is authorized to do, what the retry policy is. Connect your AI assistant from Integrations so it reads these before each run.
3. After each run, update the relevant tasks with what happened: which steps completed, which approvals were given, and where the workflow stopped.
4. Record any human decisions made during approval in fenbs. The next run reads the approved decisions and follows the same path.
5. Use lessons learned in fenbs to capture what a run revealed: schema gaps, unexpected outputs, or steps that needed more context than anticipated.

fenbs does not replace OpenAI's own tooling for function calling, structured outputs, or model configuration. It holds the human decisions and task record that give the workflow a durable backing, separate from the model and the API.