A generated answer is an artifact. A workflow is a set of transitions that determines what the artifact can do next. If those concepts are mixed together, a plausible draft can acquire the same authority as an approved decision. Drawing the states first makes that mistake easier to see.
The workflow explanations on Relay App are a useful starting point for this exercise. The homepage places AI extraction, classification, and summarization beside triggers and human review. The independently operated site attributes some illustrations to the original Relay.app archive. This article uses those explanations as design examples; it does not claim that I ran an automation or verified a current integration there.
Represent the pause explicitly
Consider a process that prepares a response to a customer question. A minimal design has received, drafting, awaiting review, approved, and delivered states. Rejected and needs information are useful outcomes too. The review boundary sits between drafting and approval, rather than between delivery and a later apology.
The state record should identify the request and the draft version. Approval of version one should not silently authorize version two after the model rewrites it. An implementation can bind the approval to a version identifier or a content digest. That is a proposed engineering technique, not a feature claim about the site.
A transition table helps make the design reviewable. Received can become drafting when input validation passes. Drafting becomes awaiting review when an artifact exists. Awaiting review becomes approved only through the designated human action. Delivered should mean that the external operation was confirmed, not merely that a task attempted it.
Define what each state owns
Relay App's building blocks separate app data, AI actions, and requests for approval or more information. That distinction maps well to a state machine. An extraction action owns a proposed set of fields. A validation step owns the decision that those fields satisfy the contract. A reviewer owns the release decision.
For example, a draft response might carry the source question, proposed text, missing details, and reviewer identifier. An empty proposed response is not ready for review. A response with an unresolved account reference may need information first. These conditions should be evaluated before a state change, rather than hidden inside the wording of an AI prompt.
Keep permissions aligned with the states. A process that only needs to draft a message should not need permission to send it during that step. Where the eventual service permits separate credentials or tools, that separation can reduce accidental external actions. Check its actual permission model before depending on the design.
Plan retries around external effects
A webhook can arrive more than once. A send operation can succeed while the worker misses its acknowledgement. Both cases challenge a simple chain of actions. A state machine does not solve them automatically, but it gives the implementation a place to record uncertainty.
Use a stable event identifier where one is available. Record an action identifier before attempting an operation, then retain the provider's result when it returns. A repeated request can consult that record instead of blindly performing the action again. If the result is ambiguous, investigate the external system before choosing a retry.
The homepage describes webhooks, HTTP requests, and waiting for an external response. Treat those as categories to investigate in your chosen implementation. A public explanation does not establish delivery guarantees, retry policy, or idempotency support for a connector.
Test the boundary, not just the happy path
A small test set can include a valid request, missing input, reviewer rejection, a changed draft after approval, and a repeated event. For each case, specify the allowed final state and whether an external message should exist. Checking only that a draft was generated misses the important boundary.
Inspect the actual run history and external destination when testing a service. The page's examples help with process planning, while execution behavior must be demonstrated separately. Keep that distinction in the test notes.
A workflow becomes easier to maintain when its transitions can be explained without reading the prompt. Start with the states, assign the decision at each boundary, and then choose the AI action that belongs inside that structure.
Top comments (0)