From AI output to work your team can own.

Start with an item of work.

Imagine an instruction to increase a product's price by 5%. A model can interpret the request. Completing the business task also requires identifying the product, checking the current price, establishing who may approve the change and recording what actually happened.

The example below is an illustrative design, not a record of a customer deployment. It shows how a request can become work that a team can own, review and follow through.

Provider tooling already offers useful controls. The OpenAI Agents SDK supports approval and pause/resume flows; the Claude Agent SDK provides permission rules and callbacks. OpenAI Frontier also addresses enterprise context, governance and implementation. The practical question is how a chosen foundation fits your organisation's records, responsibilities and everyday work.

Give the request an owner and a state.

Our example begins as a work item with its own reference, an owner in commercial operations and a status such as “Preparing”. It retains the original request and the records used to prepare the proposal.

Its state should reflect the business process: preparing, awaiting review, approved, applied or needing attention. “The model finished” is an execution event; the price change remains open until its business outcome is confirmed.

A shared queue lets colleagues see what needs attention. Define how work is assigned, when it is due, who covers an absent owner and how an overdue item escalates. These decisions connect the workflow to the team's responsibilities.

Put the evidence beside the proposal.

The reviewer needs to see the matched product identifier, the current amount and currency, the proposed amount and the request that supports the change. Retain the source-system reference and when the value was read. For a document, the equivalent might be a page and the relevant passage.

Evidence links help someone inspect a proposal's basis. They do not prove that a source is current or that an interpretation is correct. Make missing, conflicting or uncertain information visible, and give the reviewer a way to correct it.

Keep that context with the work item so the next person can understand the decision without reconstructing a conversation.

Make the rules inspectable.

Define the conditions under which this particular change may proceed. In this example, they could include a unique product match, a known currency, a fresh source value and approval by the assigned commercial role.

A declarative workflow expresses inputs, required fields, states, rules and permitted transitions as definitions that can be inspected and changed. For example: when the required evidence is present, move the proposal to review; when it is incomplete, assign a clarification task. The implementation still needs to enforce those definitions.

Agree which rules are configurable, who can change them and how changes are checked. Retaining the applicable rule version alongside the decision helps explain why an item took a particular route.

Make human review a real handoff.

The designated reviewer receives the exact proposed change with its evidence and any exceptions. Define whether they may approve, reject, correct or return it for clarification, and what each decision means for the item's next state.

Approval should identify the version of the proposal being approved. If the underlying price changes before execution, the workflow needs a defined response, such as preparing a new proposal for review. An earlier approval should not silently authorize a different change.

After an approved update, record the destination system's response. If it fails or the result is uncertain, route the item for attention. Define recovery so a retry does not accidentally repeat a change that already succeeded.

Keep model output and execution rules distinct.

Use AI where interpretation is useful: understanding the request, extracting information or preparing an explanation. Use explicit logic for known calculations, validations, permissions and state transitions. A 5% increase can be calculated directly once the correct starting value and rounding rule are established.

Deterministic control means defined rules govern the allowed action for a given validated input and state. It does not mean the model will always produce the same interpretation or that an external system cannot fail. Those possibilities require checks and exception paths.

Place the flow where the team works.

A work queue can live inside an existing application, appear through an embedded review interface or form part of a dedicated workspace. Choose the location by following the people who handle the process. Consider how they receive work, find context and take over from colleagues.

The useful design is the one they can operate day to day. Include the process owner and intended reviewers when evaluating it, alongside the people responsible for the connected systems.

Reuse the foundation; define the business process.

ECH02 brings an existing flow engine, canonical data approach, archetype-based nodes and a composer. These provide a starting point for representing shared information and assembling the steps that act on it. Integrations connect those steps to the systems involved.

The business definitions, queue behavior, evidence requirements, roles and exception routes still need to be established for the implementation. We identify which components can be reused and where new configuration, mapping or development is needed.

That work can result in a connected workflow, a document process or a dedicated application. The common goal is work the team can see, understand and take responsibility for.

Test the operational outcome.

Try representative requests, including a missing reference, conflicting source data, a rejected proposal and a failed update. Confirm who receives each exception and whether they have enough information to resolve it.

Then measure what matters to the process: completed items, correction effort, time waiting for review and unresolved exceptions. A successful model response is one observation. The useful outcome is a completed piece of work with a clear record of how it reached that state.