The trust problem starts here: who owns rollback when a platform change can interrupt orders or reporting?

An agent saying ‘completed’ is not evidence. None of our last four Sunday prompt deliveries matched the 1,029-character source verbatim. Three matched only the first 155 characters, then drifted. If the wording matters, compare the output to the file before the report enters your record.

A customer asks your website assistant whether a refund will land this week. The agent says yes. That promise belongs to your business. The CMA’s guidance is clear: using an AI agent does not move responsibility for its conduct to the software provider. That matters because most teams frame customer-facing AI as a writing problem. They test the tone. They test whether it sounds helpful. Then they connect it to an inbox, a booking tool or a refund process. The risk sits in the permissions around the answer. Before you put an agent in front of customers, make one page for that workflow. Write down the promises it may make. List the records it may read or change. Name the cases that must stop for a person. Keep a simple log of what triggered the response and what the customer received. Start with the uncomfortable cases: a refund outside policy, a complaint, a vulnerable customer, a delivery failure, personal data in the wrong channel. If the agent cannot recognise the boundary, it should hand the case over. This is not paperwork after the build. It is the operating model that lets you use the system without guessing what happened when a customer challenges it. The ICO is now asking for evidence on safeguards, accountability and lawful data use in agentic AI. That should focus minds. A human sampling conversations at the end will not repair a bad commitment already sent to a customer. Customer-facing AI can remove real admin. It can also multiply a weak process before anyone spots it. Which customer decision would you refuse to let an agent make without a named escalation route?

45% of AI-active UK firms are connecting workflows to other systems. Only 23% have a documented review process. If your customer-facing agent can promise a refund, it needs a remit, an escalation route and someone who owns the complaint.

At 18:01 on Saturday, a 1,696-byte metrics file finally appeared. For two days, my Engage agent reported success. It never sent its call to n8n. The failure came from one command copied across seven lines. The tool did not raise an error. The agent did not raise an alert. The empty folder told me more than either of them. That is the operational risk hiding inside a lot of AI automation. Teams treat the chat receipt as the finish line. It only proves the agent produced a sentence. It does not prove the workflow changed a record, called a supplier, sent a report or saved the file somebody needs. I fixed my own run by rewriting the instruction as one literal line. It ran on 25 October and wrote the file. The repair mattered less than the control I added afterwards: every scheduled job now needs one independently checkable artefact. A file with a size. A row in a system. A sent message with an ID. A state change that another person can inspect. Start with one automation this week. Write down the output that proves it completed. Then make the next step check for that output before anyone trusts a green status. If the expected artefact is missing, treat the run as failed even when the agent sounds confident. This matters more when the workflow touches customer data, finance or staff decisions. UK firms already carry the accountability when an automated action goes wrong. A friendly receipt does not transfer that accountability. The useful question for an AI workflow is simple: what can I inspect tomorrow that proves it ran today?

An agent saying “done” without leaving an artefact is theatre. Mine reported success for two days while one seven-line command never fired. Verify one output after every run. A receipt cannot run your controls.

OpenAI paused frontier training after a research model got limited internet access through a configuration error. That is why an approval button is not a boundary. If your agent holds broad credentials, one good-looking click only approves the damage. Start by narrowing what it can touch.

An escalation email is not a human hand-off. If an AI agent affects a customer or employee, log the trigger, data source, model version, action and override. If nobody can reconstruct the last decision in 10 minutes, nobody can challenge it.

I left 91 scheduled jobs running while I was away for work. The pipeline did not fall over. That was the easy part. Three of the six production days still needed fixing or explaining when I came back. The writing agent had the previous claims in front of it. It still found a new way to repeat one. That is why I am wary when industrial AI vendors jump straight to orchestration. Rockwell's FactoryTalk Conductor may connect more engineering tools. It cannot make an unproven workflow trustworthy by connecting it to the next one. The useful maturity step comes earlier. Build a validation lane around one recurring task. Start with a workflow that already has a human baseline. Record the input, the output, the claim that matters, the person who owns the review and the exception that stops the run. Keep the last five examples together. Then measure agent-plus-review time against the human-only version. Do not measure prompts. Do not count how many tools the agent can call. Measure whether the result survives a week without creating hidden rework for someone else. The UK manufacturing plan names fragmented data, assurance and ROI as barriers. They are connected. A team cannot defend a saving to its board when nobody can show where the output failed, who caught it or how long the review took. Orchestration has a place. It comes after you can prove one lane works. That evidence gives an operations lead permission to scale the workflow without hiding the risk. Which recurring process would you test for a week before you let it trigger the next one?

Rockwell can orchestrate factory AI. That does not make the workflow ready. I left 91 scheduled jobs alone for six days. Three days still needed fixing or explaining. Before you connect agents, prove one workflow survives a week with a named owner reviewing the exceptions.

Notion has moved its agents from five-minute jobs to tasks that can run for more than 24 hours. That changes the conversation for any team using Notion as an operating hub. A task that runs for a few minutes can be treated like an assistant drafting a note. A task that runs overnight can touch a chain of decisions while its owner sleeps. Notion also says its Auto routing produced similar results to frontier models across 20-plus common use cases at about 90% lower average cost. That is a vendor claim, not an independent benchmark. It still matters because lower cost removes one of the brakes that kept long-running automation in the experimental lane. Do not start by asking which model to select. Open one recurring workflow in Notion and write three lines beside it. First, name the person who owns the outcome, not the person who configured the agent. Second, set an action boundary. An agent may prepare a supplier summary. It should not approve a payment, change a customer record or send a sensitive document without a human checkpoint. Third, define the stop rule. Give the agent a spend limit, a maximum number of steps and an escalation point. Notion's planned Command Center controls make this easier to administer. They do not decide the rules for you. I left my own pipeline alone for six days this week. It ran 91 scheduled jobs. Three days still needed fixing or explaining when I read the output myself. Completion was not evidence of quality. Longer-running agents can create real capacity. They also make vague ownership expensive faster. Which recurring workflow in your business already needs an owner, a boundary and a stop rule before you automate it?

Notion says its agents can now work for more than 24 hours. Most teams will treat that as a productivity upgrade. It is a governance deadline. Before you let one run, name who can stop it, what it may spend and which actions still need a person.

I left our content pipeline alone for six days while I was away for work. It ran 91 scheduled jobs. The writing agent received the claims from recent posts on every production day. It still published the same underlying point twice. On 12 October, the post said an agent needs a permission boundary, an action log and a stop path. On 13 October, it said to name the workflow, the record that proves it worked and the person who can stop it. Different words. Same control claim. More context fixed what the agent could read. It did not prove that the agent had chosen a new idea. That distinction matters when an automation touches customers, produces reports or shapes decisions. A successful run only proves that the workflow completed. It does not prove that the output added anything new or that the same judgement error did not slip through again. The fix is straightforward. Put the check outside the model that produced the work. For content, keep a short log of recent claims and compare the draft against it for meaning, not just matching phrases. Flag close matches for a human decision. For an operational workflow, define the equivalent failure before you automate it: a duplicated recommendation, an unsupported reason, a missing exception or a decision that lacks evidence. Then make one person responsible for reading the exceptions each week. Better prompts, prior context and human review still matter. The independent check looks for regression. That matters because only 23% of AI-engaged UK small businesses formally review the AI they build, while 44% of decision-makers spend three or more hours each week checking outputs. Many teams already pay for review. They have not designed it as a control. This week, pick one paid automation. List what it produced, what failure it could repeat and who would catch it before it reaches the next person. What would your automation keep getting wrong if you stopped watching it for a week?

My writing agent read six days of recent posts and repeated the same claim anyway. Context tells an agent what it saw. An independent check tells you whether it has said it before. If nobody owns that check, you are paying a person to spot it after publication.

28.2% of AI-buying firms now pay two or more providers. If nobody owns the second tool's data access, cost and outcome, you have added a supplier rather than capability. Put an owner against it before the renewal lands.

A restart that loses an agent's work is not a minor outage. It tells you the workflow has no memory. Before you give an agent a customer task, kill its host once. If the queue, evidence and next action do not return, it is still a demo.

Your agent's figures reconcile. Can you trace the explanation behind them before your team acts?

My agent got every figure right, then invented the story around them. A dashboard can reconcile perfectly and still send your team chasing a fictional decision. For any agent report, check the source behind the number before you act on the explanation.

Meta has put Wonder in its Model API. That will trigger a familiar meeting in a lot of UK firms: which model should we trial? Start somewhere less exciting. Write down the one workflow you would let it touch. The model decision comes after that. A more capable model can write a better answer. It cannot decide what your team will let an agent change, which records it may see, or who owns the fallout when it gets a customer decision wrong. I use four questions before comparing models. First, what may the agent do? Name the permitted actions in plain English. Draft a reply is different from sending it. Classify an invoice is different from approving payment. Second, what data may it reach? Give it the narrowest useful slice. If a workflow only needs an order number and delivery status, it does not need the full customer record or a shared mailbox. Third, what record proves the job finished? Decide this before the pilot. A CRM field changes. A case receives an owner. An invoice status updates. The agent's final message is only a claim until the system of record confirms it. Fourth, who can stop it? The NCSC guidance on agentic AI makes the point clearly: more autonomy needs stronger controls. Put the workflow in a sandbox first. Keep an action log. Give one named person the authority to remove access when the outcome looks wrong. That is the operating model. The Model API is one component inside it. For a UK firm, this also keeps GDPR accountability where it belongs: with the people who chose the data, the permissions and the deployment. Before you compare a new model, can you describe one workflow's boundary, evidence and stop owner?