A prompt box is a good beginning and a weak destination.
It lets a user express intent and accepts messy input, which makes the first interaction feel easy. But real work rarely finishes in one prompt. It has steps, intermediate state, review, revision, and a definition of done. Prompt-first design tends to assume the next best step is always another prompt, and that assumption breaks the moment the task is something a person wants to finish rather than explore.
Where prompt-only design breaks down
Open-ended chat is good for thinking out loud. It struggles with work that repeats and has structure:
- prepare a report from several sources;
- triage a backlog;
- compare vendors and pick one;
- generate, review, and approve a campaign;
- review a set of code changes;
- produce a customer follow-up that someone signs off on.
These tasks share a shape. There is a goal that stays fixed while the artifacts around it change. There are points where a human has to look and decide. There is a result that needs to exist somewhere other than message 47 of a transcript.
A pure prompt loop handles this badly because the only memory it has is the conversation itself. To change one thing you send another message, the context grows, and the real state of the work, what is done, what is pending, what was approved, ends up buried in scrollback that you and the model both have to re-read.
What a workflow adds
A workflow gives the system memory outside the transcript. The shift is from a linear chat to a stateful loop with a stable goal.
flowchart LR P["Prompt"] --> G["Generate"] G --> R["Review"] R -->|"approve"| D["Done"] R -->|"revise"| G R -->|"add context"| P
This is the same idea behind agent loops like ReAct, where a model alternates between reasoning and acting and feeds results back in. The difference a workflow makes is that the loop’s state is explicit and durable, not just implied by message history. A workflow can track:
- the current goal;
- required inputs;
- completed steps;
- open decisions;
- generated artifacts;
- pending approvals;
- final outputs.
With that state, a user can leave and come back without rebuilding context from chat history. The model resumes from where the work is, not from where the conversation happened to stop.
Interface shape: three zones
A workflow-oriented AI interface usually separates three things.
flowchart LR A["Conversation"] --> B["Workspace"] B --> C["Status"] C -->|"guides next step"| A
- conversation for intent and clarification;
- workspace for generated artifacts and structured results;
- status for progress, pending decisions, and next actions.
The layout does not have to be heavy. The point is that the product’s state is visible somewhere other than the message stream, so the user can answer “where am I in this” at a glance. This is why coding assistants increasingly show a task list, changed files, and a run status next to the chat, rather than narrating every step as a reply.
A small state model
type WorkflowState = {
goal: string;
phase: "collecting_context" | "generating" | "reviewing" | "ready";
checkpoints: Array<{
label: string;
status: "pending" | "active" | "done";
}>;
artifacts: Array<{
id: string;
title: string;
status: "draft" | "approved";
}>;
};This gives the frontend something concrete to render and gives the user a stable sense of place. It also connects back to the earlier posts. Each artifact carries a draft or approved status, which is the trust boundary made into state, and the whole object is a structured output rendered as a real interface rather than prose.
Product implication
The best AI products will not feel like one long conversation. They will feel like adaptive software: conversational when intent is unclear, structured when the task is known, and explicit when the user has to decide or approve.
The prompt box does not go away. It becomes one control inside a larger system, the place you state or adjust intent, while the workspace and status carry the work itself.
What to watch next
The open question is where workflow state lives. State held only in the browser disappears when the tab closes, but useful workflows need to survive a refresh, a handoff to a colleague, or a week away.
This is pushing teams toward durable execution: workflow state kept on the backend, with the frontend as one view onto it. Durable workflow engines and the newer agent frameworks are converging on the same idea, a run you can pause, resume, and inspect. Once the state outlives the session, the same workflow can be picked up from chat, a dashboard, or a notification, and the prompt box is one entry point among several rather than the whole door.
That closes the loop for this series. A working model is not a working product. The product is the interface around it: a conversation to capture intent, structured surfaces to make output inspectable, trust boundaries to keep people in control, and durable workflows to carry real work to done.