Research into practice
Making AI finish the commercial workflow
A revised proposal, an old attachment and the difference between successful tool calls and a useful business outcome.
Published: Updated:
In this article
In this illustrative scenario, a sales agent has updated the proposal, generated a PDF and sent the client a message saying the new price is attached. Every tool returned a response. The client opens the attachment and sees yesterday’s price.
The failure is commercially ordinary: the system completed several actions without establishing that they added up to the intended outcome. This matters because useful business automation rarely ends with a sentence. It ends with something being different in another system.
What a tool response actually tells you
MobilePA-Bench, version 1 posted on 24 August 2026, evaluates agents inside a stateful mobile sandbox. It distinguishes tool calls, changes in application state and agent behaviour, and exposes problems involving ordering, permissions and runtime errors. Its mobile results are not a forecast of business-software reliability. The useful research question is whether an action produced the intended state.
In a business workflow, those layers might be a successful request to a document service, a newly generated proposal and a message actually carrying that proposal. These are related facts, but one does not establish the next. A document identifier may refer to a saved draft. A successful email operation may refer to a message queued for sending. The application’s own response determines what is known.
A proposal that passes every step and still goes wrong
Consider an illustrative software business preparing an annual proposal for 20 seats at £100 per seat per month: £24,000 for the year. A previously authorised 10% annual discount changes the proposal to £21,600. These are example prices, not results from my own business.
The agent updates the pricing record to version three. It asks for a PDF export, but the export service returns the most recently generated file: version two. The sending tool then attaches that file correctly. The CRM note records “revised proposal sent”.
No arithmetic is wrong. The wrong relationship is between the accepted price, the generated file and the outgoing message. Looking only at tool success would miss the problem. Asking another model whether the message sounds professional would miss it too.
| Transition | A useful confirmation | What it does not establish |
|---|---|---|
| Price updated | Proposal ID and version three contain £21,600 | A new PDF exists |
| PDF generated | File refers to that proposal version and price | The client received that file |
| Message sent | Outgoing record identifies the intended recipient and file | The client opened or accepted it |
The product opportunity is substantial. An agent could prepare many personalised proposals in parallel, combine product configuration with approved commercial terms and keep follow-ups connected to the right document. The condition is that it carries those relationships through the workflow, rather than treating “generated a file” as interchangeable with “completed the proposal”.
Make uncertainty a state the workflow can use
I would represent this task as a few meaningful states: pricing confirmed, file generated for that version, message submitted, sending outcome confirmed. They need not become a large dashboard. They need to be available to whatever process continues the work.
Suppose the sending request times out. A timeout says the agent did not obtain a response. It does not say the message was never sent. Retrying immediately could produce a duplicate proposal. Declaring success would be equally unsupported.
My next step would be to inspect the sending system’s record using the proposal or operation identifier. If the record confirms the correct message, continue. If it confirms rejection, repair the cause and retry. If the state remains unknown, preserve that uncertainty instead of converting it into a confident client-facing update.
Some services provide a mechanism for this. Stripe’s idempotency documentation describes keys that identify repeated requests. In API v1, a repeated key returns the first stored result after execution begins, including a stored error. That is a specific API contract, not a promise that every tool can safely be retried. The workflow must use the behaviour of the service it actually calls.
Parallelise preparation; connect the consequential steps
Most of the valuable work can still happen concurrently. One agent can assemble the client’s requirements, another check product availability, and another prepare an explanation of the commercial offer. Independent proposals can also progress in parallel. There is no reason to put every customer through one serial queue.
The dependency appears when the outgoing document needs a particular agreed price and scope. That is where the process should bind the components to one proposal version. The boundary follows the data dependency, not a general preference for slower automation.
If terms are already authorised, routine preparation and sending can proceed within that authority. A new discount or an unapproved scope change is a different decision. Keeping the distinction explicit lets the system do more work autonomously without asking the owner to approve every ordinary step.
When the check costs more than the mistake
I would not inspect every draft sentence through a separate agent and then read back the draft three times. Reversible preparation needs proportionate checks. A low-cost deterministic comparison of proposal ID, version and total can be more useful than a lengthy general review.
For an internal draft that nobody has received, regeneration may be cheaper than investigation. For an already submitted message, investigating the existing operation can be cheaper than creating another one. The same technical uncertainty has different economic consequences at different points.
I would start with one recurring commercial workflow and identify its final state before adding more tools. Then I would test a normal run, an old attachment and a timeout after submission. The question is practical: can the system finish the work, recognise uncertainty and continue from the right place?