Ben Callow💹🧲 @ben_callow

We found one AI workflow billing the wrong meter while every job still looked green. That is how ROI stories rot. Before a pilot launches, log baseline cost, cost per run, owner, and the dashboard that proves which number moved.

A 40-person finance team does not need an agentic accounting demo first. It needs one workflow owner, clean permissions, stable endpoints, and a rollback path. I have seen AI save hundreds of hours only after the messy integration work happened.

@PromptSlinger Right Max, and you don't find the limit in a meeting. You find it in production. I watched an agent lose its primary model, quietly drop to a backup, then invent an API instead of stopping Nobody had written the rule for what happens when the limit gets crossed silently!!

The FCA has put a line in the sand for AI in financial services. It says future systems may recommend actions, initiate transactions, and execute decisions inside agreed limits. That sounds like progress. It is also where many automation projects get dangerous. I have seen this pattern in enterprise deployments. The model rarely creates the biggest risk on its own. The risk appears when the process around it has no named owner, no exception route, and no clean evidence trail. One agent I tested failed to reach its intended model. It silently dropped to a smaller backup. Then it invented a plausible software API and a broken code sample instead of stopping. The worrying part was not that it got the answer wrong. The worrying part was that the failure looked normal until someone read it closely. That is the real governance problem with agentic finance. Before you let an AI workflow touch advice, payments, customer decisions, claims, invoices, or compliance checks, write down five things: Owner: one named person who owns the output. Boundary: the exact point where automation must stop. Evidence: what the system records for every decision, handoff, exception, and override. Escalation: who reviews edge cases and how quickly they see them. Shutdown rule: the condition that pauses the workflow before it keeps acting badly. This does not require a huge governance programme. It requires operational clarity. A 40-person firm does not need theatre. It needs to know where human judgement ends and automation begins. The safest first step is often not autonomous action. It is automating the review path. Route the exception. Summarise the evidence. Put the right person in front of the decision faster. Then expand autonomy once the control layer has proved it works. AI is an accelerator. Humans still hold the wheel. Which workflow in your business would fail this five-line accountability test today?

The FCA says AI may soon initiate and execute financial decisions. That is not a licence to automate faster. It is a warning. I have seen agents invent plausible outputs when a fallback model hid the failure. Autonomy without ownership is liability.

You bought the AI seats. Fine. Which weekly process still depends on one person remembering the next step?

I shipped a tiny change in our own agent pipeline last week. Not a model upgrade. Not a better prompt. A run record. Every time an agent run fires, we now capture: what triggered it, what data went in, what tools it touched, what it produced, and what a human approved. That sounds like admin until you try to run an agent inside a real UK business. The first question is never "is the output good?" It’s "if this goes wrong, how do we prove what happened and roll it back?" The ICO has been clear for a while that AI + data protection is a risk management job. OWASP’s LLM Top 10 basically shouts the same thing from the security angle. Prompt injection and excessive agency aren’t ‘AI problems’. They’re control problems. Here’s what an SME-grade audit trail actually looks like (no enterprise theatre): 1) Run ID + timestamp One identifier for the whole chain. 2) Trigger + owner What kicked it off (email received, form submitted, schedule) and who owns the process. 3) Inputs + data classes What came in, where it came from, and whether it includes customer data. 4) Tool calls The external actions. CRM update. Invoice created. Email sent. This is where liability lives. 5) Approvals + overrides Where a human had to say yes. And where they said no. 6) Outputs What the system produced and where it landed. 7) Rollback / revoke path How you stop it. How you undo it. How you revoke access. You don’t need a 40-page policy to start. You need evidence automation. The harness. If your workflow can’t answer "who approved this?" in 10 seconds, it isn’t ready for production. If you want, I’ll share the minimal run record schema we use and a checklist for what to log in your first agent workflow. Reply EVIDENCE and I’ll send it.

At 07:15 my pipeline spins up 8 agents and starts posting content without me touching it. That sounds slick until the first time something goes wrong and you cannot answer one question: what happened in that run? Most UK teams try to ‘trust’ agent workflows the same way they trust prompts. They read the output. They nod. They move on. That is fine for a chatbot. It is dangerous for an agent that routes tickets, drafts customer emails, or changes records in a system. This is why I care about boring platform features like an attachable harness. If I can attach to a running session, inspect the trace, and replay a run, I can treat the workflow like software. If I cannot, I am running vibes in production. Minimum viable harness for any agent workflow that touches real ops: 1) Write a run record every time it triggers. Inputs, actions taken, outputs, who approved what, timestamp. 2) Emit an audit event for every external action. Email sent. Ticket updated. Refund flagged. 3) Keep log retention and retrieval explicit. If you cannot pull the last 6 months of decisions quickly, you cannot defend the system under GDPR accountability, let alone board scrutiny. 4) Add a stop switch with a named owner. Someone must be able to pause the workflow when it drifts. This is the difference between ‘AI adoption’ and ‘AI liability’. If you have one workflow today where an agent could make 100 decisions before a human notices, what is the very first thing you would add: run records, audit logs, or a kill switch?

£0 spent on ‘AI strategy’ fixes this. If you can’t replay one agent run end-to-end, you don’t have automation. You have theatre. Tools like `openclaw attach` are the difference between trust and vibes.

If you can’t show an audit log for your AI workflow in 60 seconds, you don’t have AI adoption. You have liability. EU AI Act expects 6+ months of logs. Start with run records, not better prompts.

EU AI Act compliance won’t fail in your legal review. It will fail when you can’t pull a 6-month decision log in 10 minutes. If the evidence doesn’t exist as automation, it doesn’t exist.

@PhilipOdiachi Tiny workflow, huge confidence boost is real. Form submission → Google Sheets → Gmail is the perfect first loop because it leaves a paper trail and has a clear before/after. Pleased for you!! 🚀

@Ronald_vanLoon Model accuracy isn’t the bottleneck when the robot already moved. If the defect is detected after the fact, you don’t have an AI problem - you have a timing problem. Latency turns “smart” into “too late” 🚀

@polsia Job modes are the right move. The moment you add “Compliance” & “Review”, you’ve admitted the real product is the gate plus handoff, not the content volume Most teams ship the modes and forget the queue 🚀

I lost a month of ‘breaking news’ in my own content pipeline and nothing screamed. Scout-News wrote the brief. Injector looked for it. Both jobs passed. The file path was different, so the signal never arrived. That’s the uncomfortable truth about automation in 2026. The failure mode isn’t the AI doing something dramatic. It’s quiet. It’s a green tick that hides a blind spot. If you’re picking an automation platform (n8n, Make, Zapier, custom code), stop starting with connectors. Start with the question you’ll get asked after the first incident: “what happened?” Here’s the checklist I now treat as non-negotiable once a workflow can touch customer data: 1) One run record per execution (inputs, actions, outputs, trace ID). 2) Audit logs you can export and retain (not just “view in app”). 3) RBAC that matches how your team actually works. 4) Replay / history. “Show me the exact run that sent the email.” 5) Human-in-the-loop where decisions have impact. 6) Secrets handled properly. Not pasted into a node. 7) An exception queue. Silent failures kill value. Concrete example: if support triage auto-tags a complaint as “refund risk” and pings finance, I want to pull the trace ID, see the inputs, see the decision, and see who approved it. Otherwise you can’t defend anything when a customer challenges it. Self-hosting often wins here, not because it’s a nerd flex, but because it makes ownership explicit. Data residency. Log retention. Who can access what. What happens when something breaks at 9pm. If you can’t reconstruct one run end-to-end, you don’t have automation yet. You have a liability with a nice UI. What’s the highest-risk workflow in your business today: onboarding, invoicing, or support triage?

30 days. That's how long an 'automation' of ours was broken while every run still looked green. If you can't produce a run record and an audit log for one workflow that touches PII, you're gambling with GDPR.

We run an AI assisted content pipeline. It has 8 agents, file gates, and run records. The scariest failure mode isn’t the model being wrong. It’s the model disappearing. Reuters reported a U.S. export-control directive forced Anthropic to abruptly disable access to its most advanced models for foreign nationals, then the government partially reversed access for “trusted” U.S. organisations days later. That swing happened faster than most SMEs can ship a hotfix. If your support bot, document workflow, or internal copilot depends on one vendor, you’ve built a single point of failure you can’t control. Not technical. Political. Here’s the resilience pattern I’d copy from payments and cloud: 1) Capability tiers. Split workflows by what they actually need: “cheap + fast”, “reasoning”, “strictly private data”, “must be explainable”. 2) Routing + fallbacks. Put a router in front of every LLM call. Choose the primary model by tier. Keep at least one fallback from a different provider. If the primary 403s, rate-limits, or goes missing, the workflow still completes. 3) Graceful degradation. When a high-tier model isn’t available, don’t just fail the whole process. Return a “good enough” output, or route to a human review queue. 4) Audit trail by default. Log model + version, prompt hash, tool calls, and the decision path. That gives you two things you’ll need anyway: postmortems when it breaks, and evidence when your board asks “what changed?” This is the bit most AI stacks miss. They optimise for “best model wins”. Production systems optimise for “still works on a bad day”. If you’re running real workflows today, what’s your single biggest AI dependency? One model, one provider, or one person who understands the build?

If a prompt-injected agent could send 10 customer emails before you notice, which sink would you lock first: payments, exports, or customer comms?

If your AI automation has no evals, you haven’t automated anything. You’ve just sped up guessing. Uptime dashboards stay green while quality rots. Log a pass/fail check for every run, or expect a slow-motion incident.