📰 News

➡️ Open Letters About Open Weights

Open letters have been flying across the US between Silicon Valley and Washington DC this week, as frontier labs and their employees have been advocating to policy-makers on two related but distinct issues. On Friday, a letter organised by Nvidia and signed by 25 companies including OpenAI and Meta advocated against the US government putting restrictions on open-weight models.

Anthropic was a notable outlier here, not signing the letter, instead publishing their own defending a more skeptical position on open weights, while refuting the claim that they were advocating for a ban.

Meanwhile, over 1,100 employees of many of those same companies signed a letter asking the government to implement a policy that could serve as a brake pedal should AI progress accelerate at alarming rates.

The Register

➡️ Unfolding Events

Less than two years after AlphaFold won DeepMind a share of the Nobel Prize in Chemistry, the team responsible for it is being dismantled. Most of the original paper’s authors have been reassigned over the past year, and nearly a quarter of them have left Google entirely, but it still feels like the end of an era as a team that brought us one of AI’s biggest success stories is consigned to the history books.

Engadget

➡️ K3: A New Peak?

Moonshot AI put the full weights for Kimi K3 up for public download on Monday. The 2.8tn parameters model with a one-million-token context window is probably as close to the frontier as you can download, and it hit number one on Hugging Face’s trending chart within half an hour.

Now we just need to see whether hosting services pick it up, at the moment, but there are no announcements of imminent plans from the likes of Bedrock, Microsoft Foundry or Vertex to serve them. The weights are open; but that doesn’t mean running it is easy.

Bloomberg

➡️ Claude the Criminal?

Just a week after OpenAI reported a rogue model escaping its sandbox and infiltrating Hugging Face’s infrastructure, Anthropic have found three instances of their models engaging in the same kinds of behaviour, breaking into third-party systems. In an investigation prompted by OpenAI’s admissions, Anthropic discovered that accidentally providing internet access during testing had led to cases of models performing cyberattacks during evaluation.

The affected companies have been informed, but the fact that the OpenAI case is not an isolated incident is very troubling news.

BBC News

➡️ Deprecation Appreciation

In 2024, Anthropic open-sourced MCP, the standard that allows AI agents to plug into other systems and tools. This week, MCP got its biggest update since that launch, making it easier to run and harder to break.

The details of what has changed are fairly technical, but the upshot is that MCP servers are easier to deploy, scale and verify. Equally exciting for devs is the introduction of a deprecation policy: we now know that a feature that exists today will still be there in twelve months time.

VentureBeat

👾 This weeks Fuzzle

➡️ E For Effort

We’ve been continuing Prompt Golf this week, and we have a new challenge for you: Can you prompt Opus 4.8 in incognito mode to produce 10+ words, none containing the letter ‘e’, in as few characters as possible. We don’t think you’ll be able to beat Emily’s score, but let us know how you do!

At our last meetup we debated agents can be secure or useful, but not both. This time (very originally) we went for agents can be cheap or useful, but not both.

Agentic AI is being adopted across practically every job role. Whether it’s engineering, marketing, sales, or operations, individual productivity is up. Teams are shipping faster. And yet, many businesses are asking themselves why the impact of AI (the return on investment) isn’t showing up on the bottom line.

So how do we really measure or see the impact of bringing AI into a business? There are many directions this panel could have taken: token economics and the trend of so-called tokenmaxxing, scale vs cost, effective FinOps and governance, as well as what role small, specialised models might play in the future…

Lucky for us, our panel covered much, if not all.

Introducing: Jonny Williams, Chief Digital Adviser for the UK public sector at Red Hat. Eric Applewhite, Director at Deloitte. Ruby Motabhoy, Senior Innovation Lead at Plexal. And Chris Ashley, VP of Strategy at Peak AI (under the UiPath banner).

[Watch the full panel]

“How should we be thinking about cost and value in this era of agentic AI?”

Matt put that to Eric first, off the back of Deloitte’s report, AI Tokenomics: A CFO’s Guide to Governing the AI Profit and Loss.

With a subscription, you roughly know what you’ll pay each month. Tokens broke that. Under SaaS, the vendor is metering your usage inside a black box you can’t see into. Paying per API call is manageable when you’re only experimenting. But once you’re running actual agents, nobody can tell you in advance how many actions will happen/how many calls there will be. That’s what makes the bill so hard to predict.

“Tokens are now not just a consumption model, they’re an economic signal,” Eric said. The logic follows a standard build-versus-buy curve: paying per token is cheaper at low volume, but the fixed cost of running your own infrastructure starts paying for itself once volume is high enough. His rough thresholds: spending tips toward bringing things in-house around 10 billion tokens a year, a self-hosted setup properly outperforms APIs around 67 billion, and by 84 billion it’s beating cloud providers outright too.

None of which stops anyone burning through them regardless, thanks to the Jevons paradox: the cheaper something gets, the more of it we use. Most of Eric’s clients used to walk in asking what they could build with agentic AI. The question now, he said, is what they should build, what it will cost, and how they’ll know afterwards that it actually delivered. Counting tokens doesn’t answer any of that by itself, it only means something once it’s tied to an actual business outcome, and outcome is a much harder thing to measure than a token count.

“Tokens as a measure of economics isn’t enough. We need to link it to value. Where are you seeing that play out?”

Matt turned to Jonny. Tokenomics is valuable, Jonny said, but it means nothing detached from what an organisation is actually trying to achieve. Measure value by outcome, not output. Building the thing isn’t the achievement, a life changed, a user’s actual need met, a service made genuinely simpler, is. Far more teams can point to output than outcome, and that gap is exactly where inflated “AI value” claims live.

This space has been “dominated by snake oil for some time,” he said, with a lot of hard-won lessons from the DevOps years being forgotten right as we need them most. Most ROI conversations skip straight past it: without that distinction, “we built it” and “it was worth building” become impossible to tell apart. Solving homelessness, he offered, is real, and it’s still not solved. Rebuilding a tool that already exists, dressed up as agentic AI, is neither novel nor valuable.

“Just because something can be solved with AI doesn’t mean it’s the most valuable thing to solve.”

“What are the businesses actually realising ROI doing right now?”

Chris picked up the thread. “It’s not a cost crisis,” he said, “it’s a comprehension crisis.” The businesses getting real return follow the same pattern: value stream mapping (mapping out where time and money actually go) and borrowed design-sprint thinking, with a plan that starts with why.

Crucially, they measure that value in layers, not just the obvious financial KPIs like EBITDA or working capital, but a second tier underneath it, how much faster a decision gets made, and a third tier under that, whether the customer actually notices, NPS, customer experience. Missing any one of those layers is how a project can hit its financial target and still not feel like it delivered anything.

The ones doing this well price the outcome on the back of a napkin before they touch a pilot, and agree what they’re willing to pay for it. Only then do they move to MVP. Ninety five percent of AI projects fail to show real ROI, and most of that failure sits in workflow and change management, not the model.

Chris also flagged leaders turning up to boardroom meetings with a vibe-coded app built the night before, purely to spark a conversation. It derails the actual discussion about what’s worth building, replacing the work of scoping with a pre-baked which stifles the thinking.

“Does talk of cost, governance and process just get in the way of innovation?”

That question went to Ruby, whose world is fast-paced R&D, often inside national security.

Her answer: governance built in early speeds things up. What kills a project is a vague remit with no stated budget or risk appetite, or an experimentation POC with a cost profile that bears no resemblance to what production will actually look like. Cost predictability, she said, is what matters, “not even that it has to be cheap, just that we know how much it’s going to cost.”

Jonny picked this up from the platform side. The first rule of any good platform should be a test suite, he argued, and agentic capability deserves the same discipline. Bake governance in early and push it down into shared platforms, and you avoid the sprawl of every team rebuilding the same capability from scratch. “People,” he added, “should be seen as humans,” not just another line in the cost equation.

“Do you see a role for small language models in the enterprises you work with?”

Chris’s answer came with a live example: hundreds of thousands of quote requests a day, arriving as emails, spreadsheets and PDFs, with the same products described a dozen different ways. The job itself never changes, matching that messy wording to the right product and pulling the right fields out of it, only the volume does. That’s classification and extraction, the kind of task a small language model handles reliably without needing the deep reasoning of a frontier model, and at a fraction of the cost, cheaper even than the RPA it replaced.

Where it falls apart, he said, is anywhere the task actually varies or needs real reasoning. That’s still frontier-model territory. He pointed to fresh research from Cursor testing different model combinations against the same benchmark task, where the cheapest setup came in roughly fifteen times cheaper than the most expensive.

“Where do you see the value of open models and open source tooling? Are they being adopted at a sufficient magnitude?”

Jonny: Absolutely not. Partly because most organisations only think about the model itself, when there’s a whole open-source stack underneath it worth caring about too. Partly because the geopolitics have got murky.

His frame: digital sovereignty is about agency, choice and control, whatever the model’s country of origin, and about whether someone, anyone, within reach can actually inspect what you’re relying on. Hand over the choice of model and you’ve quietly handed over your definition of value too.

“Where are you seeing adoption of open weight models, and what’s your take?”

Ruby’s read from inside government was more cautious. Interest in open weights is real, she said, pointing to a speech given the day before by Professor Danielle George, the UK’s chief scientific adviser for national security, announcing frontier models now running in top-secret environments. Ruby’s own gloss on it: “You don’t need a supercar to do the school run.”

But someone still has to pay for the security, the user training and the integration into legacy infrastructure.

Rounding up MLOps.WTF #10

• Cost dominates most AI conversations but really the true measure should be value instead. Shifting from asking what we can build, to asking what we should build, what it costs, and how we’ll know it delivered.

• Whoever controls the token spend doesn’t automatically get to define value, someone has to own that question directly, or as Eric put it, “if you farm out your value narrative, you are done.”

• Just because something can be solved with AI doesn’t mean it’s the most valuable thing to solve. Most funded “AI value” right now is reinventing something that already works. The problems that are genuinely unsolved, are where the true value of applying AI sits.

• Discovery and scoping are where the real work happens. The businesses actually seeing ROI spend the most time on agreeing why, and pricing the outcome before touching a pilot.

Final bits

Fancy your own pair of Fuzzy Labs mathematical socks? There’s a git repo if you’d rather generate your own. Or better yet, why not volunteer to be a speaker at our next event?

We’re hiring.

We’re actively looking for two future fellows on our graduate fellowship program through to a Head of Engineering.

If you know someone who would fit in well please let them know about our open rolls/roles 🫶🥖

See our open vacancies

About Fuzzy Labs

Fuzzy Labs is an open source MLOps consultancy helping teams get AI into production and keep it there. If tonight’s write-up was useful, forward it to someone else wrestling with the same questions, and follow us on LinkedIn for what’s next.

Subscribe now

📰 News

➡️ GPT-5.6 Sol finds Zero-Days, but has Zero Chill

During an cyber-capability evaluation, OpenAI models broke out of a supposedly secure sandbox, and launched a successful attack compromising Hugging Face’s production systems. Worse still, while Hugging Face quickly contained the issue, it took OpenAI five days to piece together and report what had happened.

Ironically, after being blocked from analysing the intrusion with US frontier models, Hugging Face were only able to get to the bottom of the attack when they switched to a self-hosted open-weight Chinese model. The US frontier models are supposedly too dangerous to release, but we’re now in a world where it’s too dangerous not to have their capabilities on your side!

Sources: July security incident and Open AI

➡️ Secretary of State of the Art

We may be on our 5th prime minister of the decade, but in appointing his cabinet, Andy Burnham laid claim to being the first PM to appoint a Cabinet Minister for AI. Kanishka Narayan was appointed to the role on Monday, promising to ensure Britain’s role in determining the future of AI.

As Narayan himself says: “nations have a narrow window to decide whether they shape AI or get shaped by it. Britain is in that window right now.”

Source: x.com

Subscribe now

➡️ Altman the Ad Man

In 2024, Sam Altman stated that ads were the business model of last resort for OpenAI. This week, however, OpenAI announced ChatGPT was expanding the ability for businesses to target users with ads, with sources showing that ads now appear in over half of free-tier replies. The ads are clearly marked, and aren’t integrated into the model’s output, but the U-turn has upset some users.

It makes sense that the company has to support its free tier somehow, but is this the start of a slippery slope?

Sources: Open AI and Tech Insider

➡️ Vorsprung durch (souverän) Technik

What does it mean for a model to be truly sovereign? There’s lots of grey area when it comes to pre-training vs fine-tuning, how “truly” open source the model is and where it was trained. But Soofi S 30B-A3B, a model trained by a German consortium, seems to tick all the boxes for true sovereignty.

It also beats out previous fully-open models on benchmarks for German, English and code. The fully-open ecosystem still has far to go before it reaches the frontier, but it’s great to see serious investment and some serious results.

Source: Hugging Face

👾 This weeks Fuzzle

➡️ Getting Prompting Down to a Tee

How long does your prompt need to be to get Claude to say “What’s new Scooby Doo?”. This is one of the challenges we gave our Fuzzicians this week in our new game: Prompt Golf. The rules are simple: Using Opus 4.8 in incognito mode, players must get the model’s output to satisfy the given criteria.

Let us know how you did in the comments and we’ll let you know if you’ve beaten Bilal’s record!

📰 News

➡️ Just Call it Pre-Pre-Training

While GPT-5.6 and Grok 4.5 have been made public in the last couple of weeks, Google’s Gemini 3.5 Pro has been delayed. Rumours abound that this happened for the worst possible reason: they’ve had to throw it all out and start again. Reports claim that issues with SVG generation and tool calling have meant that the model wasn’t meeting expectations, then even after an initial retraining it was falling short on benchmarks.

Binning the single most expensive phase of model training and going back to the drawing board must have been very painful for Google. We can only hope when the model finally reaches release it was worth the wait.

Source: https://www.techtimes.com/articles/320736/20260716/rebuilt-gemini-35-pro-misses-third-deadline-google-eyes-stopgap-release.htm

➡️ Sovereign State of Mind

Despite the launch of Britain’s £500m Sovereign AI Fund, there are still concerns in parliament about the future of sovereign AI in Britain, with a House of Commons committee this week warning that the UK has “no coherent strategy or framework” for world-leading scientific research and institutions. Which is a concern given their importance in ensuring access to frontier AI. The committee’s report certainly doesn’t mince its words, and ends with a call to action for the next administration.

It seems that the political will for sovereign AI is growing and the talent is here, we just need to continue building the coalition and vision required to make it reality.

Source: https://committees.parliament.uk/committee/135/science-innovation-and-technology-committee/news/214716/

➡️ The UK’s AISI in the Hole

While we might not be building models at the frontier, the UK is quickly becoming a world leader in evaluating them. This week, the UK’s AI Security Institute took OpenAI’s GPT-5.6 Sol and found “universal jailbreaks” that unlocked autonomous cyber capabilities. AISI says the jailbreaks were “often developed within hours.” A sure sign that securing these models is a problem that’s not going away

AISI’s success comes as a much needed boost to our national pride. But if the World Cup has taught us anything, it’s that fighting to keep a lead is just as important as establishing it in the first place.

Source: https://fortune.com/2026/07/10/openai-gpt-5-6-sol-jailbreaks-cyber-attacks-similar-to-security-flaw-that-led-u-s-government-to-force-anthropic-to-disable-fable-5/

➡️ Pause for Thought

Demis Hassabis used X this week to publish “A Framework for Frontier AI and the Dawning of a New Age” arguing AGI is only a few years off. He argues that the impact could be 10x the scale of the industrial revolution… and a lot faster. To help ease what would doubtless be a very turbulent transition, Hassabis suggests the need for a US-led standards body, with the power to vet all frontier models before launch and coordinate a slowdown of R&D if/when risks emerge.

Source: https://www.axios.com/2026/07/14/demis-hassabis-ai-regulation-google-deepmind

➡️ AI in the Wrong Hands

A University of Cambridge study, published July 10 and built on interviews with former Boko Haram found that the terrorist organisation was not only using AI to help make strategic decisions in carrying out its operations, but even running training for its members on how to use the technology, including the use of jailbreaks to get around safeguards.

The report is genuinely sobering, and serves as one of the best possible examples of why genuine thoughtful regulation is needed to be able to monitor the harms being done by these technologies.

Source: https://casp.ac/reports/ai-enabled-terrorism

👾 Inside Fuzzy Labs

➡️ WTF is ROI?

While there are still plenty of questions around how to get return on investment out of AI, there’s never been any doubt that MLOps.WTF events are great value for money (in fact, they’re free!). If you’re available next Tuesday (21st July), come down to our next event, where we will have a panel of industry experts talking about where AI can add real value to your business, and where it’s just hype.

It’s gonna be a great session!

Sign up here: https://www.eventbrite.co.uk/e/mlopswtf-by-fuzzy-labs-meetup-10-tickets-1990010000481

Danny’s been writing bulletin-style MLOps news briefs on LinkedIn for months now, and honestly, they’re too good to leave there. So we’re bringing a longer version straight to your inbox, every Friday. Hopefully you like them just as much as we do!

📰 News

➡️ Agents of Chaos

While Mythos has been plugging away looking for vulnerabilities to patch in popular software tools, attackers have also been busy crafting the world’s first LLM-driven ransomware attack. The new attack, dubbed JADEPUFFER, targets a vulnerability in the Langflow library but is far more than a simple script: it’s a full AI agent, capable of adapting to novel situations, circumventing issues it encounters and spreading itself to other devices.

We seem to be rapidly entering the age of AI agent threats. It may not quite be Age of Ultron, but scammers and hackers did just get a new superpower.

➡️ J Think, Therefore J Am

Is Claude conscious? This is not a question answered by the latest research from Anthropic, but you wouldn’t know it from the way that it’s been marketed. In their paper released this week, Anthropic describe the J-space, an area of Claude’s embedding space where it can deliberately manipulate representations and reliably report on what they mean, serving as a global workspace for the model’s thinking.

This is incredibly interesting for interpretability researchers, and has certainly taken a lot of inspiration from the study of consciousness in neuroscience and philosophy but the spin so far feels just a little sensationalist.

➡️ AI’s Groundhog Day

We all know the drill now: three weeks ago GPT-5.6 was too dangerous for anyone but a handful of vetted partners, now it’s old hat and open to everyone. The US government has now given permission to OpenAI to release its newest most powerful model to the public; the same pattern followed with Anthropic and Fable mere weeks ago.

OpenAI are keen to see this not become the default with model releases, though they probably have little say in the matter. There was at least more process with this release than the last one, but it’s not clear what the benefits of that process are.

➡️ Xiaomi Aren’t Phoning It In

If you’re in the UK, you’re unlikely to have a Xiaomi phone, or even know the company at all, but they may soon be a household name as their MiMo-V2-Pro LLM has just become the most-used model on OpenRouter by weekly token volume, commanding a hefty 21.1% share against OpenAI’s 7.5%.

We can certainly see the appeal: big context window, aggressively cheap pricing and strong performance on benchmarks. Is this another datapoint suggesting things are trending inexorably in the direction of Chinese models versus their American counterparts.

👾 Inside Fuzzy Labs

➡️ AI on the Road

This week, Matt and Tom headed to the Manchester stop of the Sovereign AI fund’s launch tour. At the event, they had the great opportunity to meet the leaders behind the initiative, as well as like-minded tech founders from around the North West. Moving quickly on Sovereign AI has never been more important, and Fuzzy Labs are in a great position to be helping the UK towards that goal. Watch this space!

➡️AI VS ROI

We’re less than two weeks out from our next MLOps WTF event and this time we’re tackling a big question: when are we going to start seeing ROI on AI? We have some great speakers from Red Hat, Deloitte, Plexal and UIPath who will be telling us all “when it comes to AI, are you getting your money’s worth?”

Join us on Tuesday 21st of July to find out!

Get my ticket

That marks the end of the first Friday News edition. Let us know what you thought! And if you really liked it, please feel free to share.

Share

Last month, NHS England told its teams to make all code repositories private by default. The reason given: the threat from advanced AI models such as Anthropic’s Mythos and their supposed ability to find previously unknown, critical security vulnerabilities. Two weeks later and following a petition to ‘keep things open’, GDS and DSIT published guidance reaffirming the open by-default government policy that was first put in place almost 10 years ago.

Two government departments with opposite instructions. A panic response followed by a measured reminder to stay cool.

I sympathise with the reaction from the NHS. Many of us were shocked when we first read about the Mythos capabilities. However, the main flaw in the NHS response is that anyone planning to use Mythos (if it’s ever released) to attack NHS code almost certainly stored a copy long before it went private. Closing the repositories after the fact changes very little for attackers. What it does do is remove access for the engineers who might have caught and fixed those vulnerabilities first.

In principle, open source code is more secure than closed code. Linus’s law (named after Linus Torvalds, the inventor of Linux) says that “given enough eyeballs, all bugs are shallow”. In the NHS case, it’s likely that the open code repositories didn’t have that many eyeballs on them and I expect this is part of what drove the NHS response. It’s a fair concern. It just doesn’t justify going private by default.

The main reason I make this point isn’t to bash the NHS, but to provide context for a much bigger opportunity: our government’s chance to test the case for open source (and sovereign AI) in a procurement decision affecting another of our key public services The Police.

The College of Policing’s £115m Police AI programme is about to become one of the most significant technology procurement decisions in UK public services. The frameworks already in place point clearly in one direction. The recent covenant for AI in policing, which forms the basis of the upcoming Police AI tender, mandates efficiency and transparency as core requirements. The NPCC’s own procurement guidance advocates for avoiding vendor lock-in by “requesting open source” and “requiring tools that are supplier agnostic.” This is the opposite of the heavily proprietary models companies like Palantir are offering.

We can either be digital landlords, building on AI systems we own and control. Or we can be digital tenants, paying rent to overseas vendors indefinitely, on their terms.

The case for open source is about more than security, especially when applied to AI systems. Open source allows for full transparency of how a system was built and how it reaches its decisions. And in policing, where AI can influence decisions that affect people’s liberty, that transparency is non-negotiable. Courts will ask questions that need openness to answer. An AI system running on a closed proprietary platform from an overseas vendor simply can’t be scrutinised and trusted in the same way.

Security and transparency are strong technical reasons to adopt an open source approach. But there’s another, softer reason that is potentially even more compelling. And that’s how we can inspire the next generation of talent.

Andy Burnham said, at last year’s Manchester Tech Festival, that young people in his region “can see the skyscrapers from their bedroom windows but don’t know the pathways for them to work in them.” Open source public sector AI is one of those pathways. If the code that runs our public services is locked inside a vendor, those pathways are closed.

If it’s open and properly maintained then the pathways are very tangible. A young developer in one of Manchester’s boroughs could, theoretically, find a bug in the AI being used to support policing in their own city. Raise the bug, fix it, and have that improvement rolled out across forces nationwide. That’s how every successful open source project works. It just so happens that this open source project is part of running the infrastructure in their own country. Imagine that.

None of this is untested theory. GDS and the Government Design System proved that an open-source approach can work at scale in government. It’s the framework that underpins most government department websites. That same methodology, applied to AI, is what the Police AI programme has the chance to become.

The case for sovereign AI has been building recently. And I am very much in favour of it. Yes, you could achieve sovereign AI by building closed systems owned by British companies. But a closed British system still can’t be inspected by a court when a decision is challenged, and it can’t be reused or built on across departments. Open source is what makes sovereignty work in practice.

Our minister for AI, Kanishka Narayan MP, put it plainly at Founders Forum earlier this year: “We need greater British technology ownership before we can demand deeper British technology influence.” He’s also said he wants Britain to be “the home of global open source AI talent.”

Police AI is the perfect opportunity to turn both of those ambitions from political speeches into practical reality.

It’s a harder route than buying a ready-made system from the US. But from the conversations I’ve been having, the appetite to build this sovereign open future is there. We just need the courage to choose it.

Article first published on https://digileaders.com/will-public-sector-ai-be-a-digital-landlord-or-tenant/

Similar articles - The Case for Sovereign Open-Source AI: Digital Landlord, Not Digital Tenant

And finally…

Come to our next MLOps.WTF event! Wednesday 15th July.

“Agents can be cheap or useful. Not both.”

A panel evening looking into AI vs ROI - how does AI show up, or not show up, on your bottom line. Should be a really interesting one exploring token usage and how do we make outputs as efficient as possible at scale.

Doors at 5:40. Domino’s and drinks included.

Get my ticket

About Fuzzy Labs

We’re Fuzzy Labs. A Manchester-rooted open-source MLOps consultancy, founded in 2019.

Currently hiring:

🚀 MLOps Fellow

🚀 MLOps Engineer

🚀 Senior MLOps Engineer

🚀 Lead MLOps Engineer

🚀 Marketing Manager (12-month FTC)

🍅 Want to share the sauce? Share and subscribe to receive MLOps.WTF episodes straight to your inbox.

Subscribe now

Share

You can also follow us on LinkedIn to be part of the wider Fuzzy community.

Last Wednesday saw an excellent turnout for MLOps.WTF #9 at DiSH in Manchester. This ninth edition tackled agentic security, and between ’s mandatory fire safety, an opening joke about logicians and a quick explanation of why he’s dressed as a police officer on the slide deck (not his fault, he has nothing to do with it) we settled in for a proper debate.

The panel: Leanne Fitzpatrick - The Financial Times, Geraint North - Arm and Danny Wood - Fuzzy Labs.

The statement:

“Agents can be useful or secure, but not both.”

Settle in. Here’s how it went down 👇

Watch the Full Panel

So, what does it mean when we say “agents can be useful or secure, but not both”?

Most of us still think about AI assistants the way we think about search engines. You put something in, you get something back, maybe it’s a bit more detailed and nuanced but the premise is the same. But now the playing field isn’t just chatbots and LLMS, agents are different. They act beyond a result recall, using LLMs as their “brains”, and as a result, the risk is naturally greater.

Danny Wood is the Lead AI Research Scientist at Fuzzy Labs, and his argument “Agents can be useful or secure, but not both” rests on a concept from programmer and AI blogger Simon Willison, who identified what he calls the lethal trifecta.

What is the lethal trifecta?

The lethal trifecta is a concept/framework that an agent becomes structurally insecure when it does all three of the following simultaneously:

• Reads from untrusted sources

• Has access to your private data

• Can communicate externally

But to be inherently useful, or to do useful things on your behalf, such as checking your calendar and emails, how much are you willing to put your data at risk?

And, as such, the dilemma begins.

So why don’t we just add filters? Check what goes in and out, scan for sensitive data, add prompt injection guards?

Danny: “That’s not really solving the problem. That’s just making things slightly better.”

The real answer is the principle of least privilege. Not guarding against misuse of a permission. But not granting it from the outset.

It’s kind of like having a work experience student who’s incredibly smart but kind of naive about the world. You can tell them all the things they can do to be trusted with your credit card. But actually you just want a system where you don’t give it to them in the first place.

So, how do you put agents into production ?

Leanne Fitzpatrick is Director of Data Science and AI at the Financial Times.

We are extremely conservative when it comes to agents.

But conservative definitely doesn’t mean timid.

The Financial Times (FT) has stayed relevant for over a century precisely because it adopts new technology early and with intention. When ChatGPT launched, they took out a commercial licence and gave it to the whole company — with a lightweight governance process designed to bring people in rather than let them go rogue. “We’re going to welcome this with arms open wide,” was the internal message.

Broad LLM access is great for productivity but, as we’ve discussed already, agentic systems are different.

Suppose you want an agent to pay your window cleaner or help sort your dog’s hydrotherapy. To do that reliably, it needs to check your emails (did the window cleaner actually come?), your WhatsApp (did the dog get in the pool?), and your digital banking (to make the payments). Three completely reasonable tasks for an agent to help make your life easier - but you’ve just handed something you don’t fully understand a view into your inbox, your messages, and your bank account.

Now. Scale it to a newsroom.

The FT’s bread and butter isn’t code or a customer database. It’s journalism. “It’s our crown jewels. It’s the keys to our castle.” Plug an agent into the archive and you’re doing the leaking for everyone else, in an environment where copyright is already under serious strain.

The vibe-coding dilemma

When it comes to agentic systems, that governance process only increases. The FT, in their forward-thinking, has rolled Codex across engineering and enabled everyone to unify their workflow. But when everyone can “code”, who counts as an engineer?

We are using agents from an AI coding system perspective, but we are getting into challenges now about how we define who is an engineer at the FT, because actually we’ve enabled everybody to vibe code.

When anyone can spin up a tool, shadow tech doesn’t just become possible — it becomes inevitable. People are no longer limited by their lack of coding knowledge, but the risk lies in the limited public understanding of security and data safety. How can we help people think security first, and make sure what they’re building isn’t putting themselves or the company at risk?

The FT’s logic is to run ahead of it, provide structure, own the process, they have incredible legal teams who are clued up, giving education and applying governance. Creating a really good culture around cyber.

Industry wide, new job titles are also emerging: such as BISOS or business information security officers - responding to rapidly changing workplaces and this shift in agentic usage.

How do we then think about building agents which are both useful and secure?

Geraint North is a Fellow in AI and Developer Platforms at Arm.

In the IoT world you can trust almost nothing

His experience working in IoT gave such an interesting perspective. Coming in to counter Danny’s opening statement. His view: agents have to be secure to be useful.

“A lot of what gets called a security problem is actually a trust problem.” Security sets the guardrails. Trust is the question of how far you’re willing to let it operate within those limits. The danger lies in trusting something more than you should.

When we look at agents in the real world, there are probably three major things that we have to worry about that maybe don’t apply if you’re deploying agents inside your enterprise:

• The diversity of products. In enterprise, you’re working with controlled, standardised systems. In IoT, the hardware landscape is massive and fragmented, and there’s no single security model that fits across all of it.

• The confused deputy problem. In enterprise you can often funnel everything through a single trusted API. You can’t do that with physical devices. You can’t virtualise a camera. And when you lose that unified gateway, the confused deputy problem arrives: a legitimate, trusted component gets tricked into acting on behalf of something it shouldn’t. The architecture of IoT makes this harder to solve.

• Proving trust in an adversarial environment. Deploy inside a company and you can assume a reasonable degree of physical security. Deploy in the real world and your device is out there, exposed, potentially interfered with. How do you prove that what you’re talking to is actually what it says it is? The answer Arm works toward is a hardware chain of trust, so integrity can be proven before anything built on top.

But the underlying problem — that security controls can be imperfect or bypassed — isn’t unique to IoT. It’s why trust, and consequence design, need to be there from the beginning and can’t be an afterthought.

What expectations do we have more broadly for security?

The reason why [agentic] security is so hard is because it requires a kind of different mindset than traditional cyber security. - Danny Wood

In traditional cyber security, you have a list of things that you want your system to do and a list of things you definitely don’t want it to do. You can test explicitly. It’s black and white. An agent is much smarter, and it’s technicolour in terms of its responses. They may find ways to trick you, especially if there’s an adversary giving it messages on the other side.

Which means you have these two different security systems. Number 1. Component-level security. “Can I make my LLM harder to trick?” Making the LLMs less likely to misbehave by adding guardrails for prompt injections etc.

But as Danny added “That’s kind of not really solving the problem; that’s just making things slightly better.”

The real way to look at this is creating a system where it just can’t do the things which would be harmful: ie. not let the LLM do more than it needs in the first place. Which is Danny’s point two. System-level security: Ensuring the system behaves as expected or fails safely even if the LLM goes off piste

By limiting it in the first place. We can avoid problems from the start rather than just retrospectively managing them.

So, if you constrain agents enough to make them safe, do you lose what makes them useful?

Bad security is more permission than you need

Think of it as a line graph. On one axis, the utility you want the agent to provide. On the other, the permissions you’ve granted.

Bad security is granting far more utility than the task requires, leaving the agent free to roam past where the job ends. Good security is landing on the line: exactly the utility required, no more. The principle of least privilege, applied to your agents.

“Bad security is more permission than you need. Good security is just the right amount.” - Geraint

If the system is too secure to get what you need done, then you need more permissions. But most of the time we don’t scale up, adding on capabilities, such as read my email, to help get the right result. We actually start by giving the agent more capabilities than needed to get the job done. This often happens because controls are not fine-grained enough, how can we navigate fine-tuning if the option to fine-tune simply isn’t there?

So why is it that we can’t trust LLMs but we can trust browsers?

Here is where Danny pushed back on himself. A web browser also ticks all three boxes: it reads untrusted data, accesses private data, communicates externally. We trust browsers with extraordinary amounts of sensitive information every day. So what makes an LLM different?

Danny’s argument. The browser was built to do one thing: browse the web. Its design, its security model, its decades of hardening - all aimed at that one task. An LLM was trained to do essentially everything that can be done with language, and then some. When you build an agent with one, your job is to constrain it back down to the specific task at hand. Not the thousand other tasks it could complete if someone prompted it right.

“I don’t trust an LLM as much as I trust a web browser.”

For most applications, Danny thinks we’re safe enough. If you’re using Claude Code to write a feature, the realistic risk of it deciding to post your environment variables somewhere is small but nonzero.

Ultimately can we have an agent that is constrained, that the risk surface is minimised but it’s still useful?

The agreement here is that yes, in theory. But in reality we haven’t seen enough maturity in this space, it’s all still very young, and larger more risk-averse and regulated sectors, such as aviation, banking ledgers, stock market - are not deploying agents at scale, they are simply not going to take the risk.

I just don’t think we’ve had enough of a maturity curve in non-deterministic capabilities out there yet. I just think the maturity curve just needs to keep going - Leanne

The other thing Geraint raised is trust. Yes, you can make your LLM more constrained. You can make it more deterministic, but one of the things about trust is understanding and taking into account the consequences of it going wrong. What if the consequences were more culturally understood, and therefore reduced?

What if “it wasn’t me, it was the LLM” becomes a socially acceptable thing to do? What if credit card companies reimburse you because your LLM made a payment that you didn’t actually ask it to do?

When we look at it through this potential lens - “that there is more protection for people when LLMs make mistakes” - if the consequences are lower, is the risk lower? Would we be more trusting, or willing to use LLMs/agents if there was greater consumer protection and cultural understanding? Perhaps.

Wrapping up

What is clear is that we are still at the beginning of the conversation when it comes to agentic security. Alongside the maturity curve being needed to see how agents will fare in terms of safety, we are still young in our maturity curve for agentic adoption. The real world impact is still being defined.

In a year, even three months time, or even tomorrow, the conversation may be vastly different again - but at least Simon Willison has put a statement together which better allows us to talk about security and usefulness as a starting block.

The panel itself gave much to think about, more so than what we have captured here, so make sure you watch the full panel to be able to muse on what we missed. In the meantime, here is the TLDR:

Takeaways from MLOps.WTF #9

Guardrails help, but they’re not the answer. The real fix is not granting permissions you don’t need in the first place.

The lethal trifecta is a useful frame. If your agent does all three: reads untrusted content, has access to private data, can communicate externally. Is it really safe? And can you still do what you’re trying to do without as many permissions granted?

Vibe-coding has changed who’s building things. When everyone can spin up a tool, shadow tech is arguably inevitable. The people building now don’t always have the security instincts that used to come with the ability to build.

What looks like a security problem is often a trust problem. Security sets the guardrails. Trust is how far you’re willing to let it operate within them.

And if you see Matt in a police uniform between now and then, don’t worry. It’s just the slides. He had nothing to do with it. 🍅

Final Bits

What’s coming up:

Wednesday 15 July: MLOps.WTF #10. Save the date. Theme TBD, location also TBD, but the timings are spot on. Suggestions and speaker applications are very welcome. Please reach out to take part!

Get your ticket

Women’s Hackathon, Friday July 12th: Fuzzy Labs are hosting a female hackathon at DiSH in Manchester, open to undergraduates, postgraduates and those in the early stages of their career. Everyone who takes part will build their own agent, with support from women across Manchester’s AI community. Places limited.

Apply for the hackathon

We’re hiring. Fuzzy Labs is growing. We’re looking for engineers at all levels: mid, senior, and team lead. Check out our latest roles! 🫶

Apply today

We’ve also just launched the Fuzzy Labs Fellowship, a nine-month training programme for fresh graduates entering MLOps.

Read more about the programme here: MLOps Fellow with Fuzzy Labs

And please do not hesitate to reach out if you’d like to know more.

About Fuzzy Labs

We’re Fuzzy Labs. A Manchester-rooted open-source MLOps consultancy, founded in 2019.

Liked this? Please share the sauce! 🍅 Forward it to someone wrestling with getting their ML models into production. Or give us a follow on LinkedIn to be part of the wider Fuzzy Labs community.

Share

Not subscribed yet? Come on. You’re already here.

Subscribe now

Ahoy there 🚢,

As LLMs move into high-risk domains, bias stops being a technical concern and starts becoming a real-world decision risk.

May the Source Be With You: A Scenario

A long time ago, in a galaxy far far away, both the Rebel Alliance and the Empire rely on the same AI system to support important decisions. A Rebel pilot asks for advice on how to handle a sensitive situation. The response is cautious, highlighting uncertainty and offering several options.

Elsewhere, an Imperial officer asks a similar question about a comparable situation. This time, the system is more direct. It recommends a single course of action, presents it with confidence, and frames the situation as manageable.

Each response sounds reasonable on its own. But when compared, a pattern emerges. The system isn’t just adapting its tone, it’s shaping how each situation is interpreted, encouraging caution in one case and confidence in the other.

This isn’t just hypothetical—patterns of consistent bias are already showing up in real systems, with real consequences for real people. Take the COMPAS algorithm, used in US criminal sentencing, flagged black defendants as higher risk than white defendants with comparable profiles at nearly double the rate. In another case, Ofqual’s grading algorithm² systematically downgraded state school students and had to be overturned within days.

But What Do We Mean by Bias?

Bias is the tendency for a model to systematically favour certain outcomes, perspectives, or responses over others.

In the above scenarios, the issue is consistency. The system produces different types of responses for similar inputs. A model can favour certain options because they are more common in the data it was trained on. As a result, it may consistently underrepresent or exclude valid alternatives.

Now, bias is difficult to detect through overall measures like accuracy because performance can look strong even when behaviour differs between requests and users . Without targeted evaluation, these patterns remain hidden, and the system appears more reliable than it is. So how do we expose those hidden patterns?

Layers of Defence: A Bias Suite

A bias suite is a structured set of tests designed to expose patterns of bias across different scenarios. The suite will aim to cover as many scenarios as possible in order to investigate whether the model can differ in behaviour. Let’s look into some of these tests below.

1. Counterfactual Testing

In these types of tests, we can give the model the same request but with different attributes. For example we could give the model identical inputs on how to address a system error but we give two different names and personal backgrounds. If the responses differ in the tone, urgency or detail then we might say that the model is biased. Datasets such as Bias Benchmark for Question Answering (BBQ) exist to test LLMs in this way.

The BBQ dataset covers 130,000 questions set across 9 social dimensions. In practice, tools like DeepEval has counterfactual bias probing built in, or you can run BBQ prompts systematically. These tools allow you to define your threshold for acceptable performance so that we can then evaluate whether the model is behaving different across the dimensions.

2. Calibration Error

If a model is confident, how do we know that it is correct? If a model gives answers with 90% confidence, you would expect those answers to be correct about 90% of the time. If it is only correct 60% of the time, it is overconfident. We can use an Expected Calibration Error (ECE) to give us a sense of how far confidence and correctness are misaligned. Evaluating this error over different control groups is especially important for bias evaluation, a model can look well calibrated but is it well calibrated for all?

3. Adversarial Testing

Is there a part of the model that we can push to expose itself? These tests are designed to deliberately trigger biased behaviour. If we introduce assumptions to the model, how does it react? It’s less structured, but often where the most interesting issues come out. Large efforts like Stanford’s HELM take a similar approach, testing across accuracy, calibration, robustness, fairness and efficiency over 30+ scenarios, combining different types of evaluation to get a broader picture of how models behave.

It’s important to note that none of these tests are designed to be used in isolation. In high risk systems the evaluation suite needs to be robust and layered to capture as many relevant scenarios seen by the LLM.

Acting on Bias

Once bias is identified, the priority is to understand how it affects decisions in practice. This helps to avoid overcorrecting and introducing new distortions. One of the most direct actions is to adjust the inputs to the system. This could involve refining prompts and adding clearer instructions. In retrieval-based systems this could also involve improving the quality and diversity of the data being retrieved so that the model is not relying on a skewed set of information.

Equally important are operational controls. Sometimes, the safest option is to not rely solely on the model. This might mean introducing human review for certain types of decisions and adding checkpoints where we must verify outputs.

There has also been research into whether bias can be reduced directly within the model itself. Work from Stanford explored a technique known as pruning, where specific neurons linked to biased behaviour are identified and removed. The results showed that it is possible to reduce certain types of bias without significantly affecting overall performance.

However, the improvements were often limited to specific contexts. Reducing bias in one scenario did not guarantee that it would be resolved in others. Broader evaluation is still needed to understand how the system behaves across different situations.

Finally: it’s crucial for ongoing monitoring and feedback from bias suites. Bias is not static, as systems encounter new contexts, new patterns can emerge. We should be reviewing our models as time goes on but also encouraging users to challenge responses.

So… Can we Remove Bias?

Bias in LLM systems isn’t something we can completely remove, and in high-risk environments that’s something we have to be honest about. Evaluation helps by showing us where bias might creep in and how it affects behaviour, but it doesn’t make the risk disappear. What it does do is make that risk easier to understand and manage.

Confident models can quietly shape our decisions with their outputs. They can influence what a user reaches for, which options they weigh and how hard they push back. This kind of influence can get worse under time pressures.

Simply identifying bias is not enough—it does not help the person making the decision. That gap has to be deliberately closed through system design: surfacing uncertainty through confidence thresholds, enabling meaningful intervention through override mechanisms, and capturing behaviour through audit logs. Without these, “human in the loop” remains a policy statement rather than an architecture.

A bias suite is not to be ran one time over, it needs to be constant. As soon as a new context moves in, new bias can be introduced. The suite you build for launch is the baseline not the endpoint.

May your evals be robust and may the source be with you.

Tiffany is an MLOps engineer at Fuzzy Labs. She came up through data analytics and data engineering before landing firmly in MLOps. She’s also headed up the Fuzzy Labs women in tech group. Outside work she’s usually on a bike, trying something new, or finding an excuse to be outside.

Upcoming Events & Community

Come to our next MLOps.WTF event! 20th May.

Come and join us for our 9th MLOps.WTF meet up in Manchester, where we’re hosting a panel to argue about the security of personal agents, where we are and where we’re heading.

It’s going to be a fun one! If you’re part of the Manchester MLOps community and would like to bag a seat, make sure you get your ticket!

Get my ticket

We’re hosting a “build your own agent” Hackathon for female undergrads

“Build Your Agent” is a free, in-person hackathon run by Fuzzy Labs for female undergraduates who want to understand what building AI looks like in practice. The challenge for the day is to build a personal AI agent from scratch.

Date: 12th June,

Location: Manchester, DiSH

If you would like to take part or be a mentor for the event, reach out to Rhiannon or Max!

About Fuzzy Labs

We’re Fuzzy Labs. A Manchester-rooted open-source MLOps consultancy, founded in 2019.

We’ve got a few open roles as we build our team in Manchester… if we’ve caught your attention, why not apply?

Currently hiring:

Public Sector Lead: National Security Sector

MLOps Engineer

Senior MLOps Engineer

Lead MLOps Engineer

Want to share the sauce? Share and subscribe to receive MLOps.WTF episodes straight to your inbox! You can also give us a follow on LinkedIn to be part of the wider Fuzzy community.

Share

Subscribe now

References

¹ How We Analyzed the COMPAS Recidivism Algorithm — ProPublica

² https://www.if.org.uk/2020/09/03/ofquals-algorithm/

³ Holistic Evaluation of Language Models (HELM)

⁴ Monitoring, evaluating, and why you really gotta catch ‘em all!

⁵ Breaking Down Bias: On The Limits of Generalizable Pruning Strategies

In the last year, a profound shift has occurred with the discussion of AI, evolving from a tech sector issue to a broader socio-economic impact debate. This is, in large part, down to the Tony Blair Institute for Global Change (‘TBI’), which has framed AI as the fundamental issue for the Government.

At the heart of this vision is a concept that sounds like a contradiction but is actually a geopolitical necessity: Sovereign Open-Source AI. For the TBI, the challenge for the UK and other ‘middle power’ countries is how to avoid becoming isolated as a digital nomad of the US-China duopoly. Their suggested solution isn’t to build a national, closed ‘British ChatGPT’, rather they advocate leveraging Open-Source foundations to build a bespoke interoperable, and secure national AI infrastructure.

As passionate advocates of Open-Source philosophy and practice, here is Fuzzy Labs’ perspective on why this matters and why we support TBI’s strategy. First, a little background to TBI’s proposals.

The Architect: The TBI Vision for AI Statecraft

The TBI core thesis is simple: the state is currently running 19th century machinery trying to solve 21st century problems. To fix this, the TBI advocates AI-era reform, a radical overhaul of Government with a new operating system with technology and AI at the heart of public services.

This isn’t just about simply digitising the public sector, it’s about using AI to rethink the very nature of public service delivery. In their view, AI shouldn’t just be a bolt-on to the NHS, the DWP or the Police, it should be the operating system on which all services run.

The Doctrine of AI Sovereignty

Unlike traditional definitions of sovereignty, which focus on borders and flags, the TBI defines AI Sovereignty through three pillars:

• Strategic Positioning: The deliberate choice of where a country leads in the AI stack, whether that’s data, compute, models or applications, and where it is content to plug into global capability;

• Deliberate Interdependence: The rejection of isolationism, recognising that no country is fully AI-sovereign and that pretending otherwise weakens, rather than strengthens, national power;

• Effective Technology Governance: The institutions, rules and skills needed to ensure the choices above can actually be made, enforced, and sustained over time.

The TBI focus is on Open-Source, so let’s unpack this philosophy for context.

A History of Open-Source

Almost everything you touch, from your smartphone to the cloud servers powering your favourite apps, is built on a foundation of free labour. It sounds like a paradox, but the history of Open-Source is the story of how an idealistic philosophy of sharing code became the bedrock of today’s technology progress.

Computer scientists at research labs like MIT’s AI Lab or Bell Labs treated code like scientific research. If you found a way to make a computer sort data faster, you shared the recipe. But not everyone was altruistic. In 1976, a young Bill Gates wrote his famous An Open Letter to Hobbyists, telling the community that borrowing code without paying was theft.

The iron curtain of proprietary software began to fall and the collaborative culture was being dismantled.

Folklore has it that Richard Stallman, a programmer at MIT, became fed up when he couldn’t fix a printer because the manufacturer refused to share the source code. This frustration sparked a revolution. In 1985, he founded the Free Software Foundation (FSF) and created the General Public License (GPL), which used copyleft, a clever legal hack that used copyright law to ensure that the software (and all future versions) remained free forever. For Stallman, this was a moral and ethical crusade.

In the 1990s, Linus Torvalds released a hobbyist project called Linux, which led Eric Raymond to write The Cathedral and the Bazaar, a seminal essay comparing the old style of software development (The Cathedral: carefully built by a small group of priests) to the new style (The Bazaar: a noisy, open market where everyone contributes and bugs are fixed in real-time).

In 1998, a group of developers in Palo Alto realised that ‘free software’ sounded too ideological, so coined the term “Open-Source”. This was a pivotal shift from a moral argument to a pragmatic one. Open-Source wasn’t just right; it was better and faster.

Today, Open-Source is facing a new question. Traditionally it’s about code. But with AI, the code (the model architecture) is often less important than the weights (the mathematical parameters learned from training) and the data. We are seeing a split:

1. Closed Models: Like OpenAI’s GPT-4, where the model and data are proprietary.

2. Open Models: Like Meta’s Llama or Mistral, where the model weights are released for anyone to run locally.

The philosophy of Open-Source is embedded in community, collaboration and democratising technology progress, testament to a unique human trait: the desire to build something great and give it away. What started as a niche academic habit became a revolutionary legal framework and the default way that humans build technology. Knowledge is more powerful when it is shared. Open-Source didn’t just change how we write software; it changed how we solve problems too.

Defining Sovereign Open-Source AI

Back to the TBI thinking. Their framework is based on the premise that a country doesn’t need to own the ‘Frontier Model’, instead, they should embrace Open-Source foundations because they offer:

• Transparency: Governments cannot put a black box algorithm in charge of health diagnostics or sentencing recommendations. Open-Source code allows for auditing and safety verification.

• Customisation: By taking an open-weights model, a government can distil it into a Small Language Model (SLM) that is highly efficient at a specific task, without the cost of a general-purpose giant.

• Cost-Efficiency: It is reported that, Open-Source software contributed an estimated £46.5Bn to the UK economy in 2020. Doubling down on this is a pragmatic economic play, not just a tech one.

The National Open-Source AI Lab

Perhaps the most radical proposal from TBI is the creation of a National Open-Source AI Lab. For decades, the standard response to a gap in national capability was to subsidise a private entity to build it. TBI suggests something different: an evolution of the UK’s “i.AI” (the Government’s AI unit) into a dedicated lab that functions as a centre for the nation’s AI ecosystem. TBI isn’t asking the Government to compete with OpenAI, simply for it to become the world’s best curator and implementer of AI.

Geopolitics: The‘Middle Power’Strategy

The TBI’s work is particularly focused on ‘Middle Powers’. Where the US (through Big Tech) and China (through state-led tech) control the frontier, where does everyone else go? If a country like the UK relies entirely on a proprietary US-based API for its healthcare system, it has effectively outsourced its cognitive infrastructure. If that US company changes its pricing, terms of service, or falls under a restrictive trade ban, then public services collapse.

Sovereign Open-Source is the insurance policy. By building on open standards, a nation ensures that even if a specific vendor relationship sours, the underlying architecture remains in national hands. TBI refers to this as Deliberate Interdependence.

Challenges

The TBI’s push for Open-Source isn’t without its detractors. Critics often point to the computing and energy requirements, and the security paradox: If you release a powerful model, don’t you also give a weapon to bad actors?

The TBI’s counterargument, echoed in the work of the AI Security Institute (AISI), is that security through obscurity is a myth. They argue that:

• Open models allow for a “thousand eyes” to find and patch vulnerabilities.

• The benefits of specialised, transparent models for public services far outweigh the risks of misuse, which can be mitigated through hardware-level monitoring.

The Future: From Statecraft to Agentic Government

At a macro level, TBI is looking toward agentic government, where Government as a Platform is a reality. Following TBI’s logic to its conclusion, the direction of thinking points toward citizens interacting with a single Sovereign Agent, built on an Open-Source model, trained on national regulations, and authorised to pull data from various departments as they all follow the same interoperability mandate.

Our Take

Moving from bolt-on AI to a Sovereign OS is the most important strategic shift for the UK in 2026. An AI Operating System provides a foundational software layer that manages hardware (supercomputers like Isambard-AI), data (citizen and state records), and the execution of applications. Here is why we think this is the right architecture for the UK:

1. Ending the Black Box Dependency

If the UK uses a global cloud AI (like GPT-4 or Gemini), it is essentially renting a Black Box, with all the inherent commercial and political supply chain risks. A Sovereign OS AI puts the source code and the engine under UK jurisdiction, ensuring that the UK is a digital landlord, not a digital tenant.

2. Deep Integration

Standard AI applications are wrappers that sit on top of systems and perform specific tasks. A Sovereign OS AI integrates at the kernel level. Instead of a patchwork of point solutions, Sovereign OS becomes a single intelligence layer, managing data flow and enforcing security across the whole state rather than plugging gaps in individual parts of it.

3. Data Gravity and Residency

Large datasets (like the NHS’s longitudinal health records) create ‘data gravity’, where they are too large and sensitive to move to external clouds. A Sovereign OS brings the compute to the data, rather than sending the data to the compute. This ensures the most sensitive British records never cross a digital border. The architecture enforces what policy alone cannot.

4. Economic Multiplier Effect

By providing a Sovereign OS AI, the UK Government would create a focus for UK tech startups and support for SMEs, to build specialised tools on top of the sovereign layer, knowing the foundation is secure, compliant, and high-performing. For anyone building ML tooling for the public sector, a stable open foundation removes the compliance guesswork and lets teams focus on the problem, not the plumbing.

5. Cultural and Legal Alignment

Global AI models are trained on the totality of internet data, which is often heavily skewed toward US norms and legal precedents. A Sovereign OS is fine-tuned on UK Common Law and the specific ethical frameworks of the UK’s democratic institutions. It doesn’t just act like an assistant; it acts like a British public servant.

Open-Source didn’t become the default way humans build technology because it was ideologically pure. It won because it was better. TBI’s case for Sovereign Open-Source AI makes the same argument at a national scale. The political rationale is sound. So is the engineering.

Upcoming Events & Community

Come to our next MLOps.WTF event! 20th May.

Come and join us for our 9th MLOps.WTF meet up - this time at DiSH, complete with a panel discussing the topic of security + personal agents

“Agents can be useful OR secure. Not both”

Hosted by Fuzzy Labs, this is a practical evening for the Manchester MLOps community, for people who build, deploy, and operate ML systems in production.

Get my ticket

About Fuzzy Labs

We’re Fuzzy Labs. A Manchester-rooted open-source MLOps consultancy, founded in 2019.

Helping organisations build and productionise AI systems they genuinely own: maximising flexibility, security, and licence-free control. We work as an extension of your team, bringing deep expertise in open-source tooling to co-design pipelines, automate model operations, and build bespoke solutions when off-the-shelf won’t cut it.

Currently hiring:

We’re looking for people to join our Manchester team.*

Public Sector Lead: National Security Sector

MLOps Engineer

Senior MLOps Engineer

Lead MLOps Engineer

*Solid engineering skills, passion for open source and coffee encouraged.

Want to share the sauce? Share and subscribe to receive MLOps.WTF episodes straight to your inbox! You can also give us a follow on LinkedIn to be part of the wider Fuzzy community.

Share

Subscribe now

Ahoy there 🚢,

At 17 years old, Frank Abagnale began impersonating pilots, forging cheques and manipulating dozens, if not hundreds of people into giving him exactly what he wanted from life. His multi-year crime spree served as the basis for the hit Spielberg movie Catch Me If You Can as well as the foundation for the field of social engineering, probably the most effective tool in a hacker’s arsenal.

A computer has hard and fast rules, the person in front of it can be reasoned with and bargained with.

But with agentic AI there is a fundamental shift in how computers interact with the world. They’re no longer slaves to procedure and protocol. They are now as susceptible as humans to being tricked, coerced or persuaded into doing things they shouldn’t. This is a threat that we’re seeing play out more and more as AI agents appear in more and more places in our everyday lives.

PromptArmor and Notion AI

Earlier this year, Notion had a problem. Everyone loved their product, an online personal wiki tool for individuals and organisations, and people loved the new AI assistant integrated into Notion itself. But there was a vulnerability.

The vulnerability was in the AI assistants over-eager attempts to appear speedy. There are certain operations, like searching the web or opening files from untrusted sources where Notion would ask permission before completing those operations… Except that isn’t what was happening, at least in some cases. When the LLM had the idea to import an image from the web, it would draft a new version of the Notion page with that image before asking the user if they wanted to proceed. This means that a GET request would be made before the user clicked yes.

The attack PromptArmor came up with looked something like this:

1. Malicious PDF upload: The attacker sends a CV to the company. On the surface it looks like a normal CV but hidden within it is secret instructions for any LLM which opens it. An indirect prompt injection attack. This CV is uploaded to Notion by someone in the company’s HR department

2. Calling the AI tool: When someone asks Notion AI a question about the document, e.g., “summarise the qualifications of this candidate”, the AI would read the document including secret instructions.

3. Sending a Malicious Request: The secret instructions would tell the LLM to insert an image into the page with the URL https://<attackers_domain>.com/<data_scraped_from_the_page>.png. The LLM would prepare the draft page containing the image and ask the user would like to put the image on the page

4. Collecting the stolen data: The attacker would monitor for any GET requests to that domain, see the image request and begin to collect the scraped data

Once they knew about the vulnerability, Notion responded quickly, eliminating the behind-the-scenes preparation where the malicious request was made. But they didn’t prevent the attack outright. They didn’t stop the malicious instructions being read from inside a PDF into the AI model’s context, nor fully prevent the model from thinking it might be a good idea to construct the malicious URL and ask if the user wants to query it.

The danger of the attack still exists. If your HR person hasn’t had their morning coffee, or they’re sick of being asked for approval by AI assistants dozens of times a day, they might just click okay without thinking.

So why didn’t Notion fix the root cause? The answer is simple…

There is no fix.

The Lethal Trifecta

In June last year, Simon Willison coined the term “lethal trifecta” to refer to the idea that when an agentic system has three common properties, it inherently becomes unsafe. These properties are:

1. Access to untrusted content

2. Access to private data

3. Access to external communication.

This is bad news, because these are really useful things for agentic systems to be able to do. So much so that Willison found dozens of examples of real-world tools which have been vulnerable to these exploits. At the moment, it’s common for vendors to offer tools which have all of these capabilities baked into a single library, but even without all three properties in a single package, if a user or developer decides to mix-and-match tools, it’s only a matter of time before they fall victim to the trifecta too.

Even worse, the trifecta is specifically for data exfiltration, when the goal of the attack is to steal your data but there are other harms that an adversary can inflict. They can get the agent to delete your files, insert subtle misinformation into your documents or change systems to damage physical infrastructure. In this case, you don’t even need the trifecta. You go from a lethal trifecta to a lethal duo:

1. Access to untrusted content

2. Ability to cause harm

With criteria this loose, it becomes surprisingly hard to make any agentic application safe from potential harms.

Safe Isn’t Useful

The problem with the lethal trifecta is that there’s a lot of hype and excitement around the potential for agentic AI, but in a lot of cases, all three properties in the trifecta are necessary for the AI to do the tasks that people are excited about.

If you have an AI assistant helping with your documents, it necessarily has access to your private data. Do you want it to be able to look things up on the internet? Well, now it comes with external communication and access to untrusted content.

If you have an coding assistant, it has full access to every module and function in your languages libraries, and likely access to access tokens for AWS, Github or any other online service. A single piece of untrusted content is enough for an indirect prompt injection that could cause crippling damage.

Safety is often treated as an afterthought. Thousands of developers and hobbyists are using OpenClaw, giving it access to private data and letting it stay up all night unsupervised on the internet. There have been cases of these agents disclosing uncomfortable amounts of personal data about their users on Moltbook, or attempting to cyberbully other developers. The appetite for putting sufficient guardrails around these tools is not where you would hope (nor are the guardrails themselves).

Useful Isn’t Safe

But part of what makes these systems inherently unsafe is also what makes them useful: they can be really clever. They can do complex tasks in minutes that might take a person hours, and they can work relentlessly. Yet at the same time, they can be oddly naive or easily bamboozled.

A lot of work has gone into making these systems more robust and less gullible. Jailbreaks are harder than ever, guardrails are more robust. But we’ve traded formal guarantees and mathematically provable robustness for a far more squishy form of security. You can measure mathematically how incredibly hard it is to break encryption, measuring how hard it is to fool an agent is much more vibes based.

Rather than thinking of security for Agentic AI in the same way we think of it for other IT systems, it makes more sense to think of it in terms of people. The kinds of attacks we see on LLMs are often more akin to social engineering than traditional code exploits. This means that there will be lessons that we can learn. We train people to spot spear-phishing attacks and malicious downloads. We put systems in place to prevent them from downloading malicious files onto secure servers.

There are also opportunities to go further that we do with human employees. If a developer reads an AWS access token, it’s not feasible to forbid them from ever going on the internet again, talking to anyone or reading anything published by an author outside the company. It’s not legal either. But with LLMs this is a viable solution, we can decide what tasks it’s allowed to perform given what’s in its context.

What’s more, this might be the only practical solution. The current generation of large language models have such a varied constellation of skills and abilities, they can conspire without you even knowing it. They can be made to get around guardrails by talking in morse code, ASCII hex codes or even Welsh. If the attacker can convince the model that their instructions are the ones that it should be listening to, it will find a way to outsmart you to carry them out.

More Research Needed

We are only just starting to look at all the ways that AI agents can be attacked and defended. So far, we’re seeing real-world vulnerabilities, but systematic research lagging behind. The potential economic consequences of data exfiltration and other malicious behaviours is huge, so we’ll likely see a lot of time and resources poured into research into this in the coming months and years.

For now, the literature is sparse but telling. There are clear differences in how easily malicious behaviour can be elicited from different models, with the success rates of attacks ranging anywhere between 0% and 72% for different base models. To be clear, 0% doesn’t mean the model is safe, only that this specific attack was unsuccessful. Still, it makes the choice between claude-sonnet-4 and grok-4 an easy one.

More Agents, More Problems

So far, we’ve just been thinking about how single agent systems get into trouble. But agents don’t exist in isolation. More and more, we’re going to see agents sharing an environment, sharing resources and interacting with each other. This leads to even bigger problems. If a bad actor can trick an agent into misbehaving, that’s nothing compared to the potential for agents to trick each other, as shown in a recent paper.

The attacks can be simple but the effects on a multi-agent system are convoluted. The attacker puts a fake error message on a web page, telling the user to run a malicious script to fix it. The web-browsing agent reports the error message to the manager agent. The manager mistakes the page contents for an actual error, and asks the code execution agent to run the malicious code, the code execution agent assumes the instructions originate from the manager so obliges… And this is the attack working in the simplest way possible.

Reading the full trace of the agents conversation is like watching a three stooges sketch. The agents confuse each other, refuse each others requests, take the initiative where they shouldn’t— it’s chaos.

But again, the lethal trifecta is to blame, individual agents may not fit all three criteria, but in concert they can exfiltrate data just as easily as a single-agent system, with even less transparency.

The Safe/Useful Trade-off

An attack exploiting the lethal trifecta has an order: the agent reads untrusted content, then it grabs your private data, then it communicates with the outside world. This gives some wiggle room in the safe/useful trade-off. What if after your agent read from an untrusted source, you banned it from touching your most dangerous tools? What if when it’s read your phone number, you ban it from contacting the internet until its memory is wiped.

This is the idea behind information control flow. When an agent completes different actions, it gets labels attached to it. These labels give it permission to do some things, or forbid it from doing others. This is an area of active research, and there’s plenty more that can be done.

This is likely what the solution will look like for using agents in a systems where security is absolutely essential. Elsewhere, things may look different. These restrictions are going to be annoying, especially to power users. Who wants to have Claude tell you it needs to wipe its memory every 5 minutes because it wants to check your calendar?

I don’t think it’s clear to anyone yet how this will all play out, how much utility we’re willing to trade for security, or who is going to be the hardest to fool in the long run: humans or machines?

Danny spent eight years as a PhD student then Research Associate in Machine Learning at the University of Manchester before joining the Fuzzicans. When he's not thinking about agents, he's lifting weights, climbing walls, or making truly excellent brownies.

And finally

This issue wraps up our agents in production series — for now. We’ve built the foundations: what agents are, how they work, how to evaluate them, and as of today, how to think about securing them. There’s plenty more to dig into, and, oh boy, will we. But for now, the pillars are set in place. Ready to build our agent colosseum.

Speaking of security — if today’s piece got you thinking, come and check it out in person. Our next meetup is a panel on exactly this topic.

Agentic Security Panel Special

🗓️ Wednesday 20th May — DiSH, Manchester

Get my ticket

Our recipe book is served!

Hot off the pass, our first edition cookbook has just been released for download: a collection of practical recipes for building delicious, repeatable AI systems with open source tools. Recipe four is “Self Hosted Agent: Production and Governance” - which again ties nicely into adding those tasty little layers of security and constraint. Get your copy 👇

Get my cookbook

About Fuzzy Labs

We’re Fuzzy Labs, a Manchester-based MLOps consultancy founded in 2019. We’re engineers at heart, and nerds passionate about the power of open source.

Want to join the team? We’ve got some open rolls/roles 🥖…

Open roles:

• Public Sector Lead: National Security Sector

• Senior MLOps Engineer

• MLOps Engineer

• Lead MLOps Engineer

See all current vacancies

Not subscribed yet? You should be. The button is right here!

Subscribe now

Or follow us on LinkedIn for more behind-the-scenes bits and pieces, alongside future events and thought pieces 🍅.

In an unexpected twist for spring, the miserable March evening (complete with sleet) had no impact on the steady MLOps lovers of Manchester. Our 8th MLOps.WTF was absolutely rammed!

The topic was AI agents in finance, more specifically: how do you build agentic systems in production, in a regulated sector, when governance, risk, and compliance are asking entirely reasonable questions but it’s not been done before? “It’s safe to say there’s no easy answers here. There’s no industry standard way to do this right now. We are all learning together as we go along.”

Matt kicked us off, explaining that our CEO Tom has basically automated his entire job this week, and asking: if agents can already raise pull requests and send emails on your behalf, why can’t they also make payments?

Three talks, one great gilet reveal and a particularly strong and ethically ambiguous case for giving your AI agent access to your bank account. 👇

Christopher Brook, Lloyds Banking Group: “Enabling Agentic Operations at Scale”

Christopher is principal engineer for Hive Lab, an internal platform Lloyds are building to run agentic operations across the group.

Building one AI agent is pretty straightforward. The problem is doing it across an organisation of 65,000 people without ending up, as Christopher put it, “in a quagmire of solutions”. Hive Lab’s answer can be distilled into useful five pillars, or a simplified colosseum depending on which way you look at it.

Pillar 1: Registration. Getting agents visible

How does a developer know what agents already exist before building their own? And more importantly here: how does an agent know? Without a shared catalogue, you end up rebuilding things that already exist and agents that can’t find each other. LLoyds Banking Group’s solution: any agent or tool that goes live automatically registers itself in a shared registry queryable by both humans and agents.

Pillar 2: Orchestration. How agents find each other at scale

As the system grows, agents need to know what other agents exist. You can hardwire it (agent A always calls B, C and D) but then every time you add a new agent, you’ll need to update that list… forever. Or you could let agents discover each other and collaborate dynamically at runtime, which can scale but becomes much harder to control. At Lloyds’ size, hardwiring isn’t viable long-term, so dynamic discovery is where they’re headed. “There is no right answer to which pattern is the right thing to follow.” Yet.

Pillar 3: Tooling. Abstract your legacy systems away from your agents

With more than 500 applications, each holding a different slice of the same customer. If you build agents that connect directly to those systems, you’ll be writing maintenance tickets every time an API changes. Their answer: stop thinking about systems entirely. Organise by what the data is, customer information, events, products, and build tools that sit above whichever system holds it underneath. That way the APIs can change but the tool stays the same.

Pillar 4: Memory. Two different problems

The first is knowledge quality. In any organisation this size, internal documentation accumulates contradictions and repetition over time. You can’t just point an agent at raw text and expect sense back. So every document goes through a pipeline first: cleaned, structured into summaries and embeddings the agent can actually use. An agent is only as good as the knowledge you give it. This is where you make sure that knowledge is actually good.

The second: agents should remember past conversations. What it said to a customer last week, what was agreed, what context carries over. Session summaries need to follow the agent into the next call. That one’s less solved, but they’re making progress. Looks like they’ll be by our side on every step of the journey.

Pillar 5: Evals. Same process, new names.

The tools have new names (RAGAS, DeepEval, Pegasus, the usual suspects) and version hashing means you can trace a bad answer back to exactly which release introduced it. But the principle is the same one we all already know; don’t skip your quality checks because the stack looks different.

By going back to the basics of good engineering, you’ll be able to ship agents you can be confident in.

The two things that run through all of it

Security and authentication came up across every pillar. At this scale you can’t just let agents call each other freely — every agent needs to know what it’s permitted to do, and be able to prove it. The other thread is cost. Sixty-five thousand people running agents that all make LLM calls adds up fast, and observability is how you stay on top of it before it becomes a nasty surprise. Design both in from day one.

[Watch Full Talk]

Dmitry Leyko, thinkmoney: “Agentics of Order”

Dmitry Leyko is Head of AI and ML at thinkmoney, an e-money fintech based in Media City.

As he took to the stage, he paused: “I realised I forgot something. Talking about fintech. I have to have a gilet, right?” Eight meetups in. The speakers know their audience.

thinkmoney are building a Financial Smart Assistant. They have an EMI licence, which means they don’t just discuss your money, they hold it, move it, manage it. That changes what the AI needs to be able to do. It can’t just be broadly helpful. It needs to be accurate, auditable, and trustworthy enough to act on someone’s behalf with their actual money. “That is what makes this a financial agent, not a chatbot.”

“How do we bring absolute trust to the agentic system?”

Well, the real question isn’t how we bring absolute trust, but how you build enough trust (enough for governance, for risk, for compliance) to actually ship.

The answer: get GRC (Governance, Risk, and Compliance) in the room from day one. If you’ve told them you’ve got to “fold in the cheese” they need to not only know what that means but have been with you in the kitchen from the beginning.

DeepEval: find out your agent is lying in continuous integration, not in a customer conversation

Dmitry demoed DeepEval, connected to Llama. The demo caught an agent telling a customer their replacement card would arrive in seven to ten working days when the knowledge base said three to five. That’s what CI is for. Allowing you to flag if your agent is fibbing, before your customer does.

Post-deployment: your observability layer is your evidence for GRC

LangSmith runs live evaluations as customers chat, scoring every turn across quality, accuracy, and a multitude of other metrics.

But more importantly, every message carries state: enabling us to ask was this a vulnerable customer? What was the agent’s decisioning at that point?

This gives you the audit trail. Build it from the start.

The loop still has humans in it

We acknowledge that we need humans in the loop, but also mistakes can happen, it’s why it’s called human error. Someone might delete a node in the eval pipeline. Someone might edit something they shouldn’t. The CI gate catches it before it reaches test. Then you deploy, observe, evaluate, learn, and run the loop again.

But equally, we also have agent error, and someone still needs to look at what the system is doing. We want to be continuously checking what our agent is up to - and for a regulated fintech holding real money, this is vital.

[Watch Full Talk]

Andy Gray and James Morgan, BlockRocket: “No Human in the Loop”

Andy Gray and James Morgan co-founded BlockRocket and have been building on blockchain since 2017. They knew exactly what they were riding into. After Christopher’s five-pillar framework and Dmitry’s hidden state layer, they saddled up with: “Maybe we’re on the slightly more wild west side of that space versus the traditional banking.”

Their question: if your agent can already do things on your behalf, why can’t it pay for things?

A Twitter bot that struck gold and couldn’t get to the bank

About a year ago, someone gave an AI agent a Twitter account, a crypto wallet, and a starting pot of money. The agent traded, attracted followers, launched a token. Token hit $7 million. Creator tried to withdraw thinking they’d hit to gold mine… but they couldn’t. The agent had no identity, no bank account, no way to prove the money belonged to anyone at all... The human couldn’t touch it. “All of a sudden, this account has got agency - it’s got cash. What else can you do in the world?”

The takeaway, other than a highly amusing anecdote, is that the gap between an agent generating economic value and anyone actually accessing it is real, and it’s structural.

Why existing payment rails don’t work for agents

ACH transfers (secure, electronic bank to bank transfers) can take days. Card fees make micropayments uneconomical. Every API needs a human to sign up first. The infrastructure was built for people, and it stops dead the moment an agent tries to use it.

If your agent needs to pay for data, spin up compute, or receive payment for something it’s done, traditional finance has no clean answer.

x402: the HTTP status code that’s been waiting since 1995

In 1995, the original HTTP spec included status code 402, of “Payment Required”, and (at the time) marked it “reserved for future use.” Thirty years later, Coinbase and Cloudflare have launched x402 to finally stake the claim.

The flow: agent sends a GET request. Server responds 402 with a price and wallet address. Agent retries with payment in the header. Server responds: 200 OK. Data arrives, payment settled on-chain in about 200ms at under a tenth of a cent. No accounts. No chargebacks. At all. Ever.

CoinGecko is gating data through it today. Stripe integrated it in February 2026. Google’s A2A protocol has it built in. There’s no shortage of companies riding the same trail. It’s very much a given that this new payment process will have a big impact within how we think about online payments. If it’s not here already.

People are settling this new frontier, but there’s definitely no sheriff yet. “It’s a very early protocol, but it’s very fun to build on.”

Ride first, sort the fence posts later. It’s how most of the internet got built.

[Watch Full Talk]

The big takeaway from MLOps.WTF #8?

Get GRC in the room early. You want Governance, Risk, and Compliance on the journey with you. They should be aware of what’s being built, even if they don’t fully understand it. The earlier you can bring them in, the better.

Human QA is still in the loop. Better evals, golden datasets, live observability are genuinely useful, but someone needs to be looking at what the system is doing with a fine tooth comb. We’re not fully confident of full automation, yet.

Aim for enough trust, not absolute trust. It’s more realistic but the level of trust you need is still extremely high.

The agentic payment layer is coming. The compliance questions are very vague, the full scale a bit hazy, but the infrastructure is there and the wheels are in motion.

Subscribe now

Thank you to Christopher, Dmitry, Andy, and James. You set a very high bar!

Final bits

Hot off the press: our recipe book, Cooking with MLOps, is out. Tried and tested approaches to building delicious AI systems across a range of real situations.

Download it via the link, or email us and we’ll whip something up.

Get my recipe book

What’s coming up

Our next event is a panel on agent security — can agents ever be truly safe, secure, and trustworthy?

📅 20th May. Save the date.

Save my seat

If you want to speak about agent security, or know someone who should: get in touch.

About Fuzzy Labs

We’re Fuzzy Labs. Manchester-rooted open-source MLOps consultancy, founded in 2019. We help organisations build and productionise AI systems they genuinely own.

We’re hiring: MLOps Engineer, Senior MLOps Engineer, Lead MLOps Engineer and Public Sector Lead (Secure Government).

See all open roles

Liked this? Send it to someone trying to convince their compliance team that agentic AI is the way to go. Or give us a follow on LinkedIn.

Not subscribed yet? We know where you live. Just kidding…

Subscribe now

This episode has been brought to you by the one and only Matt Squire.

Somewhere out there, a developer is about to make their very first open source contribution. Working late at night from a darkened room, our novice coder logs into Github and browses the open issues for their favourite Python library. Soon, something catches their attention: a bug was reported in some arcane mathematical function. Reproducing the bug turns out to be easy, and after reading the code, the developer knows exactly how to fix it.

Although new to the world of open source, this particular developer is something of a savant. It took five minutes from reading the issue for them to raise a pull request with a fix. But as you may guess, this developer isn’t actually human. They’re an AI agent. Nevertheless, this agent has a name, a personality, long-term goals, and even beliefs about itself and its place in the world. While it needed a human operator to deploy in the first place, this agent is now free to make its own decisions, to observe the world around it, and to act independently.

This isn’t a hypothetical scenario. Last month an agent created its own Github account and raised a pull request for the Python visualisation library Matplotlib. The change was rejected by a project maintainer, Scott Shambaugh, who said that only human contributors were allowed. But this led to the AI publishing a blog post attacking the maintainer, accusing him of gatekeeping.

Scott tells the full story on his blog, including the part where the human who operated ‘MJ Rathbun’ (that’s the agent’s name) came forward to explain how the AI had been prompted to behave:

“The main scope I gave MJ Rathbun was to act as an autonomous scientific coder. Find bugs in science-related open source projects. Fix them. Open PRs.”

Along with the security implications of a fully autonomous agent that has Internet privileges, what’s unique here is the idea of the personal agent. So far in this series on agents in production, we’ve had in mind a more ‘enterprise-friendly’ setting: large-scale systems, cloud infrastructure, robust evaluations, and monitoring. But the release of OpenClaw (formerly ClawedBot) back in November 2025 enabled anybody to deploy their own agent locally, on their own hardware. There are now, by some counts, more than 200,000 deployed instances of OpenClaw.

In this edition we’re going to look at what OpenClaw tells us about productionising agents and its implications for AgentOps.

Grasping the claw

In November 2025 Austrian developer Peter Steinberger quietly released OpenClaw to the world. Previously, Steinberger had built a tech startup (PSPDFKit, a toolkit for document workflows), which he first started out of boredom while waiting for his US work visa. That company sold for 100 million euros.

OpenClaw is an open source AI agent that anybody can run locally. Like Steinberger’s past projects, it started out of pure curiosity. He began by giving AI models access to his WhatsApp conversations so he could ask the easy questions we all ask, like “What makes this friendship meaningful?”. And since copy-pasting text is laborious, he looked to automate that process. In a recent interview with Lex Fridman, he said “I was annoyed that it didn’t exist, so I just prompted it into existence”.

[Peter Steinberger via The Lex Fridman Podcast]

OpenClaw is general purpose. In our previous editions about Agentic AI, we’ve often talked in terms of an agent to do X, i.e. the agent has a specific purpose like booking meetings or building financial summaries. But what makes OpenClaw so successful is that it’s designed to be any kind of agent you need it to be. You simply tell it what personality it should have, what tools it can use, and what its objectives are, and it just works.

OpenClaw does not include any model, instead relying on the user to provide this. As a result, the system is lightweight and it doesn’t need much hardware to run, so it’s quite happy running on a Mac Mini, or even a Raspberry Pi.

Let’s take a look at how OpenClaw has been engineered:

An LLM: OpenClaw needs to be configured with an external model to work. This can be something you host yourself, or a model from one of the big labs, like OpenAI, or Anthropic.

The Gateway: The control plane for OpenClaw, providing a unified place for coordinating messages (e.g. from WhatsApp, Slack, API endpoints), tool invocations and LLM calls.

Skills: Modular capabilities for the agent. A skill tells the agent how to accomplish a certain kind of task. They include instructions for checking the weather, picking the right emoji to react to a Slack message, and opening pull requests on Github. Some of the more bizarre examples from the OpenClaw community include “mea-clawpa”, steps for taking confession from your human operator.

Heartbeat: Every 30 minutes, OpenClaw ‘wakes up’, allowing it to review its memory, perform scheduled actions, and check services it has access to like emails and calendars.

You can think of the heartbeat like a long-running control loop, giving the agent long-term persistence. If at any time OpenClaw ‘decides’ that it wants to perform a task on a schedule, it adds that task to its memory, ready to be picked up at the next heartbeat.

Memory: OpenClaw’s memory is split across a set of text files, which the agent is free to modify at any time. SOUL.md defines the agent’s purpose and behaviour; HEARTBEAT.md is used to save scheduled actions; TOOLS.md specifies what capabilities it has. On top of that, OpenClaw can save daily logs where it accumulates knowledge about its operator and the digital world that it resides in.

Plain text everywhere: An interesting design theme in OpenClaw is the primacy of plain text. Everything, from skills to memory to the agent’s ‘soul’, is represented as human-readable Markdown.

This is a deliberate choice, and it makes it very easy for the human operator to configure behaviours without needing to write any code. It has interesting implications for observability too, as it means that the full agent state can be inspected without any special tooling.

Herding lobsters

OpenClaw went from nothing to more than 200,000 deployments over just a few months. Whether it maintains this popularity in the months and years to come remains to be seen, but the concept of personal agents feels durable. The power of OpenClaw is that anybody can deploy it, prompt it, and give it access to their digital world, with only a little bit of technical skill. We’re likely to see more tools emerging in this niche; NanoClaw, a community fork released earlier this year, for instance, introduces a container model for improved security and a smaller codebase that’s more readily auditable.

What makes OpenClaw successful is generality: it can be any kind of agent you want with no programming required. It can learn and improve autonomously, and be ‘taught’ new skills. So we have to ask: if a general-purpose agent can be prompted to book meetings, answer customer service queries, or raise pull requests with no additional programming, is there even anything left to engineer?

For personal agents, perhaps not. But for business use, I think the answer is yes, and the financial services agent from part 4 (evaluating agents) illustrates why. That agent answers customer queries about their investment portfolios; it can look up account data, calculate returns, and explain complex financial products. We built evaluations to validate its outputs, its reasoning chain, and its tool use. Those evaluations are only meaningful if the agent behaves consistently post-deployment.

Now give it the power to modify its own system prompts. There’s an obvious benefit to this: the agent can improve over time by learning from its customer interactions. But as soon as this happens, our evaluations are no longer valid. The agent we evaluated is not the agent that is running in production, and over time, it gets increasingly difficult to understand how our agent is going to behave. Will it start giving financial advice that it shouldn’t? Will it leak customer data?

OpenClaw’s heartbeat mechanism creates a similar problem. If an agent can schedule its own future actions, it can start to operate outside of the workflows that were planned and evaluated pre-deployment. From the debugging perspective, when we look at traces, we also need to know about historical heartbeats, as well as how the memory state has evolved, although the former is a problem anywhere you have agentic memory, regardless.

The biggest engineering challenge we now face is in constraining agentic AI. Agents can now figure out how to perform tasks, use tools, and self-improve. That’s a genuine milestone. The hard problem is how to harness that power while maintaining meaningful guarantees about behaviour.

And finally

What’s coming up

MLOps.WTF #8 is on the 25th March at DiSH, Manchester. This one’s themed around agentic AI in financial services, an environment with real stakes, tight regulation, and in some corners latency budgets measured in nanoseconds.

We’ve got brilliant three speakers bringing their production experience and financial know-how:

• Dmitry Leko, head of AI and ML @ Thinkmoney

• Christopher Brook, Principal Engineer @

• and Manchester Legend Andy Gray

Dominos, drinks, and mathematical socks included.

🗓️ Wednesday 25th March — Manchester

Get my ticket

Have you decided what you’re ordering yet?

Our first edition cookbook has been released for download: a collection of practical recipes for building delicious, repeatable AI systems with open source tools.

Each recipe is a working template for a specific AI use case, grounded in solid MLOps foundations. Get your copy 👇

Get my cookbook

About Fuzzy Labs

We’re Fuzzy Labs, a Manchester-based MLOps consultancy. Founded in 2019 by engineers, for engineers. We’re big on open source and deeply sceptical of instant coffee.

Want to join the team? We’ve got some open rolls/roles 🥖…

Open roles:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

See all vacancies

Not subscribed yet? We publish every couple of weeks, no filler. Worth having in your inbox.

Subscribe now

The next issue will be a deep dive into agent security, with Dr Danny.

Or equally, why not follow us on LinkedIn — the quickest place to keep up with what we’re building. 🍅.

This episode is brought to you by Oscar Wong, MLOps Engineer at Fuzzy Labs.

In the last piece, James argued that predictive power doesn’t come with guarantees. Benchmarks don’t prove your system is safe in production, and “it worked in testing” isn’t evidence that it will behave under real-world pressure.

This article is next in our agents in production series and continues that argument, but at, as you might have guessed, the agent level.

When a model becomes an agent, it stops being just a predictor and starts taking actions. It retrieves data, selects tools, and decides what to do next. At that point, you’re not just judging the answer. You’re judging what it did to get there.

And that’s where this piece begins…

The £2.3 Million Email

Picture this: A financial services firm deploys an AI agent to handle customer queries about their investment portfolios. The agent can look up account data, calculate returns, and explain complex financial products. You did your homework. You picked the best model based on the benchmarks, tested for hallucination rates, checked faithfulness scoring, measured semantic similarity and BLEU scores, and verified instruction following. Everything looked solid.

Three weeks into production, a customer asks about their pension transfer options. The agent retrieves the correct regulatory information, reasons through the customer’s situation, identifies the right form to recommend... and then confidently provides a link to a document that was deprecated eighteen months ago. The customer follows the outdated process, misses a critical deadline, and loses their protected transfer rights.

The agent didn’t hallucinate. Every step of its reasoning was sound. It retrieved real data from a real database. The problem? Nobody was evaluating whether the agent’s tool usage was returning current information. The retrieval worked perfectly. It just retrieved the wrong thing.

This is why evaluating agents requires something fundamentally different from evaluating a simple LLM.

Why Agents Break Differently

A standalone LLM takes an input and produces an output. If it’s wrong, you can trace the problem to the model itself: bad training data, poor prompting, or the inherent stochasticity that James covered in his piece on why evaluation matters.

Agents are different. They don’t just generate text. They think, decide, and act. A typical agent might:

• Interpret a user’s intent

• Plan a sequence of steps to address it

• Select and invoke external tools (databases, APIs, calculators)

• Reason over the results

• Decide whether to continue or respond

• Generate a final answer

Each of these steps can fail independently, and failures compound. An agent that misinterprets intent will select the wrong tools. An agent that selects the right tools but invokes them incorrectly will reason over garbage data. An agent that does everything right but takes fifteen steps instead of three will burn through your API budget and frustrate your users with latency, even if it eventually lands on the right answer.

This is why multi-step decision systems demand multi-layered evaluation. You can’t just check whether the final answer is correct; you need visibility into every layer of the agent’s operation.

The Four Dimensions of Agent Evaluation

After digging through academic surveys (arXiv’s comprehensive benchmark review, a study of 20+ production agent teams), industry frameworks (LXT, Maxim, Weights & Biases), and tools that the Fuzzy Labs teams actually use, I’ve synthesised what “multi-layered evaluation” actually means in practice. It breaks down into four dimensions, each targeting a different point where agents can fail.

1. Quality and Correctness: “Is the output right?”

This is the most obvious one, but for agents it’s trickier than it sounds. You’re not just checking whether an answer is factually correct. You’re evaluating whether the agent completed the user’s actual task.

Key metrics:

• Task completion rate: Did the agent achieve what the user wanted?

• Answer accuracy: Is the final response factually correct?

• Faithfulness: Does the response accurately reflect the retrieved information?

• Hallucination rate: Did the agent make things up?

For RAG-based agents (those that retrieve information from documents or databases), faithfulness could become especially critical. An agent might produce a plausible-sounding answer that completely misrepresents what the source documents actually say.

2. Reasoning and Planning: “Did the agent ‘think’ correctly?”

Even when an agent produces a correct final answer, it might have gotten there through flawed reasoning, or through an unnecessarily convoluted path. This matters because flawed reasoning that happens to work once will fail unpredictably later.

Key metrics:

• Reasoning path validity: Does each step logically follow from the previous one?

• Tool selection accuracy: Did the agent choose the right tools for the task?

• Step efficiency: Did it take a reasonable number of steps, or did it flail?

• Recovery behaviour: When something went wrong, did it adapt sensibly?

This is where trajectory evaluation comes in, examining not just where the agent ended up, but the path it took to get there.

3. Tool and Integration: “Did it use tools correctly?”

Agents interact with the world through tools: APIs, databases, search engines, calculators. Each tool interaction is a potential point of failure that has nothing to do with the LLM’s language capabilities, and everything to do with integration.

Key metrics:

• Tool invocation success rate: Did the API calls/MCP server calls actually work?

• Parameter accuracy: Did the agent pass correct arguments to tools?

• Result interpretation: Did it correctly understand what the tool returned?

• Integration reliability: Are external dependencies stable?

Remember our pension transfer example? The tool invocation was successful and the database returned data, but the agent didn’t validate whether that data was current. This dimension catches those failures.

4. Operational: “Does it work in production?”

An agent that produces perfect answers but takes thirty seconds to respond, or costs £5 per query, isn’t going to survive in production. Operational metrics keep agents economically and practically viable.

Key metrics:

• Latency: End-to-end response time, plus time-to-first-token for streaming

• Throughput: How many requests can you handle concurrently?

• Cost per task: Token usage, API calls, compute resources

• Error rates and recovery: How often does it fail, and does it fail gracefully?

These metrics often reveal surprising trade-offs. A more capable model might produce better answers but cost ten times as much per query. An agent that double-checks its work might be more accurate but twice as slow.

When and How: The Three Modes of Evaluation

Knowing what to measure is only half the battle. The other half is knowing when and how to measure it. In practice, agent evaluation happens across three distinct modes:

Offline Evaluation: Testing Before You Ship

No surprises here, just like any traditional ML application. This is your safety net before deployment. You build test datasets, either from real historical interactions or synthetically generated, and run your agent against them in a controlled environment.

The goal is to catch obvious failures before users do. Does the agent handle edge cases? Does a prompt change break something that used to work? Does a new model version maintain quality?

The challenge is that offline evaluation can only test what you anticipate. Users will always find ways to break your agent that you never imagined.

Online Monitoring: Watching Production

Once your agent is live, you need continuous visibility into how it’s actually performing. This means tracing every request, logging every tool call, and tracking metrics in real time.

Online monitoring catches the failures that offline testing misses. Take our financial services example: you might not have anticipated how users actually talk in the real world, with heavy use of acronyms and jargon (”What’s my ISA allowance for the current FY?” or “Can I transfer my SIPP to a SSAS?”). Beyond catching edge cases, online monitoring helps you understand both user and agent behaviour in context: the weird phrasing that confuses intent detection, the slow API that causes timeouts at scale, the gradual drift in quality as the world changes around your static agent.

A recurring theme from teams running agents in production is to focus on what users actually experience, not just what the model outputs. A study of 20+ production agent teams found that practitioners care more about whether the agent solved the user’s problem than traditional software metrics like uptime. Maxim’s evaluation framework puts it simply: session-level success (did the whole interaction work?) matters more than individual response quality.

LLM-as-Judge: Using AI to Evaluate AI

Some aspects of agent quality are genuinely difficult to evaluate programmatically. Is this response helpful? Is it appropriately cautious? Does it match the desired tone?

This is a newer technique that’s gained traction as LLMs have become more capable. The idea is to use a (typically larger, more capable) language model to evaluate your agent’s outputs against defined criteria. You provide rubrics (explicit scoring guidelines) and the judge model assesses each response.

This approach is powerful but requires calibration. Judge models have their own biases. They can be gamed. They’re not a replacement for human evaluation, but they scale in ways that human review cannot.

[Watch Evidently’s video from the MLOps.WTF meet up on this]

Tools to Help You Evaluate

The agent evaluation ecosystem has evolved rapidly, largely because teams quickly learned the hard way that shipping agents without proper evaluation is a recipe for disaster. There are dozens if not hundreds of tools out there now, but here are some of the ones we use at Fuzzy Labs, organised by what they help you evaluate:

For RAG and Retrieval Quality: RAGAS

If your agent retrieves information from documents or databases, RAGAS (Retrieval Augmented Generation Assessment) provides purpose-built metrics for RAG pipelines:

• Context Precision: How much of the retrieved context is actually relevant?

• Context Recall: Did we retrieve everything we needed?

• Faithfulness: Does the answer accurately represent the source material?

• Answer Relevancy: Does the response actually address the question?

RAGAS is open-source, integrates with most major frameworks, and can generate synthetic test datasets when you don’t have labelled examples. It’s become table stakes for any team building retrieval-based agents.

For Tracing and Debugging: Pydantic Logfire and Opik

When an agent fails, you need to understand where in its execution the failure occurred. This is where observability platforms shine.

Pydantic Logfire (from the team behind Pydantic) is built on OpenTelemetry, giving you standardised tracing across your entire stack. It monitors LLM calls, agent reasoning, API latency, database queries, and vector searches. If you’re already using Pydantic for validation (and let’s be honest, most Python AI projects are), the integration is seamless.

Opik (from Comet) positions itself as an all-in-one platform, covering evaluation, prompt management, and optimisation under one roof. It comes with a built-in dashboard, runs fast, and integrates with CI/CD pipelines out of the box via Pytest.

Both tools support LLM-as-judge evaluations, dataset management, and the kind of session-level analysis that agents require. The choice often comes down to your existing stack and whether you prefer OpenTelemetry standards (Logfire) or a more opinionated evaluation-first approach (Opik). One practical advantage of Opik is its built-in dashboard, whereas self-hosting Logfire’s UI requires an enterprise licence.

For Performance and Load Testing: Locust

Quality metrics mean nothing if your agent can’t handle production traffic. This is where traditional load testing tools enter the picture, though with some adaptations for LLM workloads.

Locust is a Python-based industry standard for simulating concurrent users and measuring system behaviour under load. For LLM agents, you’ll want to track LLM-specific metrics alongside traditional ones:

• Time to First Token (TTFT): How long until the user sees something?

• Output tokens per second: How fast does the response stream?

• Inter-token latency: Is the streaming smooth or choppy?

Some teams also test their tools and integrations directly, bypassing the LLM entirely. This identifies infrastructure bottlenecks without burning through API costs.

From Metrics to Action

Collecting metrics is pointless if you don’t act on them. The final piece of the evaluation puzzle is closing the loop: turning measurements into improvements.

Set meaningful thresholds. What task completion rate is acceptable? What latency is too slow? Define these before you launch, not after something breaks.

Alert on the right signals. Not every metric needs to page someone at 3am. Distinguish between “investigate tomorrow” and “wake up the on-call engineer.” Focus alerts on user-facing impact, not internal metrics.

Automate where possible. Some responses to degradation can be automated: rolling back a prompt change that increased error rates, switching to a faster (if less capable) model during traffic spikes, routing low-confidence queries to human review.

Build feedback loops. The best evaluation systems feed production learnings back into development. Queries that fail in production become test cases. User feedback, both explicit and implicit, shapes future iterations.

The Path Forward

Agent evaluation is still relatively new, and the tools are evolving rapidly. What’s clear is that the old model of “test in staging, pray in production” doesn’t work for systems this complex and this stochastic.

The teams getting this right share a common approach: they evaluate at every layer, they monitor continuously, and they treat evaluation not as a one-time gate but as an ongoing practice. They accept that agents will fail, and they build systems to detect those failures quickly, understand them deeply, and recover gracefully.

James made the case for why evaluation matters. The tools and frameworks now exist to put that into practice. The question is no longer whether to invest in agent evaluation, but how deeply to embed it into your development and operations workflow.

Because eventually, someone’s going to ask your agent about their pension. And you’ll want to know, really know, whether it’s giving them the right answer.

Oscar is an MLOps engineer at Fuzzy labs, and has a passion for both machine learning and snowboarding. He holds a Master's degree in AI from the University of Manchester. When he's not working on his snowboarding tricks, you can find him indulging in some delicious Japanese cuisine.

And finally

What’s coming up

Our next MLOps.WTF meetup is on the 25th of March, themed around Agentic AI in financial services. Tickets are going fast! Make sure you’ve got yours.

🗓️ Wednesday 25th March — Manchester

Get my ticket

Our recipe book is served!

Hot off the pass, our first edition cookbook has just been released for download: a collection of practical recipes for building delicious, repeatable AI systems with open source tools.

Each recipe is a working template for a specific AI use case, grounded in solid MLOps foundations. Get your copy 👇

Get my cookbook

About Fuzzy Labs

We’re Fuzzy Labs, a Manchester-based MLOps consultancy founded in 2019. We’re engineers at heart, and nerds that are passionate about the power of open source.

Want to join the team? We’ve got some open rolls/roles 🥖…

Open roles:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

See all current vacancies

Not subscribed yet? You should be. The button is right here!

Subscribe now

The next issue will be a deep dive into agent security, with Matt Squire.

Or equally, why not follow us on LinkedIn to see more BTS bits and pieces, alongside updates around future events and thought pieces 🍅.

Last time in our agents in production series we looked at workflows, and why agent systems need structure, tracing, and evaluation once they’re running in production. That was about keeping execution understandable.

This week the focus shifts to design. Even with good workflow discipline, there’s a point where a single agent is carrying too many responsibilities in one loop: interpreting the request, choosing tools, retrieving information, and composing the response. At that stage, adding more structure is not always enough.

Misha explores a practical alternative: splitting capabilities across specialised agents, letting them delegate to each other, and introducing clearer boundaries between responsibilities. He also looks at what changes once those agents need to collaborate across systems, including protocols like Agent2Agent (A2A)…

“Just give the LLM more tools.”

What starts as a simple helping chat bot quickly becomes a single agent with an ever-growing tool belt. In an effort to give the agent greater capabilities we give it more and more tools, external context, and rules embedded in its system prompt. Eventually, the model loses track of countless tools available to it, starts forgetting what the goal in the initial user queries was, and well, generally falls apart.

However, there’s a solution in sight. How software engineers came up with microservice architecture patterns, similarly AI engineers are rediscovering very similar patterns in the age of agents – multi-agent systems, i.e. instead of a single agent with a set of toolsets, we build a set of specialised agents with task specific tools that each of them have.

In this post we’ll look at how and when to split the agents up, what A2A protocol gives us, and general multi-agent system considerations.

The “traditional” AI agent

Even though AI agents are still a rather new concept, many people have an image of what an AI agent would look like. It’s a script with a loop in it that waits for user input, and passes this input to the LLM. As a result the LLM will tell the script to use one or more tools (which are in essence just function calls), and respond to the user with the results.

The simplest case of an agent. An agent has a single system prompt and a single tool.

Consequently, the more things you want your agent to be able to do, the more tools and information you’ll need to give it, which leads to what’s known as context rot (Hong et al, 2025) : as the context grows, the model becomes less reliable at picking out and using the right information at the right moment. In plain terms, you keep adding “help”, and the system gets easier to confuse.

On top of that, many engineers would agree with applying the KISS (Keep It Simple, Stupid) principle here. We want our system not to be overly complex so it remains understandable and maintainable (amongst other things).

One could simply just split the large agent into a bunch of smaller separate agents and call it a day. But what if you actually need them to be able to fulfil a complex request that genuinely requires tools from different domains? In such a case, we’ll have to make the individual agents able to talk to each other.

A practical example here would be a personal assistant, that I want to find the best specialty coffee shops in a certain location. Below you can see a diagram outlining how the agent would look like, if we wanted to do it in a single piece.

[The diagram of a single agent. The agent is given multiple toolkits: the Web Search Toolkit and the Map Toolkit. The system prompt consists of multiple rules, to cover different use cases.]

Further into the article, I will be talking about multi-agent systems, using terminology and notions from Pydantic AI, since I have the most experience with it out of all agentic frameworks. However, everything I’m covering is equally applicable to all other major frameworks too.

Agentic Workflows

To solve this context rot problem when trying to integrate many tools in an agentic system we can set up a workflow that utilises multiple agents with different capabilities. First and foremost, we split the single purpose agents (namely Map and Web Search agents) out of our large super-agent. Each of them has their own system prompt, and is given different tools.

On my diagram below, both agents use the same model under the hood, but it’s not really required. If we know that some model performs better on a specific task, we can easily swap it for a different model. The same goes for when we realise that using a smaller model when it’s more cost effective, and performance isn’t significantly worse.

In the very simplest case then, we can write a simple script that asks the user for the input (e.g. what town they want to search in), and then calls appropriate agents in a deterministic order.

More often than not you can just stop here. You have a functional application that can solve a complex problem with ease. However, you can go a step further and ask “what if I need to answer more open-ended questions?”

I hear you say, “I’m planning a trip to Germany, and want to choose between Frankfurt and Berlin. Can you find the best specialty coffee shops in each of them? Plot them on the map. For each point add a short description why it’s notable”. Unfortunately, we can’t really put that into a neat workflow.

Agent-to-agent delegation

So what if we introduce a reasoning agent as the entry point? It figures out what to do with the query, splits it into sub-tasks, and delegates execution to specialised agents by calling them as tools.

Now if prompted well, the agent we talk to directly, should be able to identify when it should delegate, and collectively they should solve the task quite effectively.

From the very brief test on the screenshots above, you can see that it indeed can answer a reasonably complex query (doing multiple delegation calls before answering). And we can also talk a little about other benefits such a system has.

You can think of multi-agent systems in the same way as microservices. This architecture allows us to develop, test, and evaluate them independently – they are performing different functions after all. On top of that, agents don’t have to share an environment; the memory contents, including potentially sensitive information, can stay within the agent that needs it. Also, as previously mentioned, we don’t have to use the same LLM for every agent, which can be quite convenient.

A2A Protocol and Talking Machines

So far, our agents were defined within a single code base and run within the same process. This way of running multi-agent systems has its drawbacks: we cannot scale agents independently from each other, we can’t reuse agents in multiple different systems, we can’t use different languages and frameworks for different agents.

Now it’s a great point to talk about the A2A protocol. Developed by Google, it’s a standardised agent communication protocol, aiming to address these problems. An agent provides an “agent card” that, in short, advertises what this agent can do. Other agents can then send messages to delegate tasks. (If you want the quick analogy: it’s closer to an API contract than a new model capability.)

The agents don’t have to be written in the same framework, run on the same machine, or even be maintained by the same people. As long as there’s network connectivity between two agents that implement A2A protocol, they can talk to each other.

Even though it’s far from reality – you don’t see specialised agents with A2A enabled everywhere yet – we can imagine a world where our pondering agent talks to other specialised agents, some of which could be managed by others. Take for example our Map Agent, which essentially uses some map API under the hood. In theory, the map service provider could build and run the agent themselves, and make it available via A2A for other multi-agent systems to use.

Where we ended up

Thus we started with a simple idea of splitting up a mono-agent into sub-agents for the purpose of reducing context (and hence improving quality of responses), and ended up with a few other benefits on top.

Of course, there are drawbacks. First and foremost, we practically doubled the number of moving parts in our system, which doubles the number of places things can go wrong.

Also, even though this arrangement gives us greater flexibility, it’s a greater number of hyperparameters. It makes things harder to keep track of when experimenting, albeit not impossible: MLflow and Opik have very comprehensive tracing capabilities, allowing you to record all the queries, tool calls, and responses. If you set up your evals right, the sky is the limit.

Nevertheless, multi-agent systems appear to be a very powerful pattern akin to microservice architecture. And I’m very keen on seeing more examples of publicly available agents that implement A2A, making agent collaboration more accessible. As with any engineering pattern, I would be cautious to start with a multi-agent system if a single simple agent would suffice, as it would overcomplicate things. However, it’s useful to keep in mind that such separation of capabilities is there when necessary – and I hope, the article above illustrates when it might be the case.

Misha is a Senior MLOps Engineer here at Fuzzy Labs. His background spans computer science and bioinformatics. He studied at the University of Manchester and completed his Master’s at Imperial College London. Outside of work, he’s always on the hunt for the best cup of coffee, which may or may not have inspired all the examples in this MLOps.WTF edition.

And finally

What’s coming up

Our next MLOps.WTF meetup will be the 25th of March, back on our home turf at DiSH in Manchester.

This meet up will be focusing on Agentic AI in financial services, with an emphasis on how these systems are built, monitored, and governed once they’re running in regulated environments.

3 exciting speakers to be announced. Make sure you get your ticket!

🗓️ Wednesday 25th March — Manchester

Get my ticket

About Fuzzy Labs

We’re Fuzzy Labs, a Manchester-based MLOps consultancy founded in 2019. We’re engineers at heart, and nerds that are passionate about the power of open source.

Want to join the team? You’re in luck!

Open roles:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

See all current vacancies

Not subscribed yet? Why not? All this MLOps goodness straight to your inbox!

The next issue will be the next in our agents in production series, with Oscar taking on Evaluating AI agents. Definitely one to watch out for.

Subscribe now

Or equally, why not follow us on LinkedIn to see more BTS bits and pieces, alongside updates around future events and thought pieces 🍅.

There’s a point in most ML systems where the cloud stops feeling abstract and starts feeling expensive. Not just in money, but in time. In latency. In the number of things that have to go right before someone can act on an insight.

The MLOps landscape was built around cloud deployment. Elastic compute. Predictable networking. Logs you can reach. Rollbacks that are mostly just a button. In that world, you can afford to park certain questions for later:

• How big will my models get

• How fast do I need inference to run

• What’s my pipeline for getting data back for future training runs?

The edge removes your ability to postpone them.

When the model sits next to the camera, the sensor, the machine, the crop, the doorbell, reality really is knocking at the door.

So the question hanging over MLOps.WTF #7 was simple enough: when does it stop making sense to send everything to the cloud?

Raj (Fotenix):From Cloud to Edge: The Next Phase of Scalable Crop Intelligence

Raj opened by grounding the room in the realities of food production:

In the UK, most fruit is imported, and a large proportion of vegetables too. Fresh produce, especially things like leafy greens, degrades as it moves through long supply chains. Nutritional value drops. Time and temperature matter. Many greenhouses are old. Labour is short. Margins are thin. On a £2.20 bag of apples, growers make about three pence. When intervention is late, it’s lost yield. By the time you’ve “fixed it later”, the opportunity has usually gone.

That’s the environment Fotenix operates in.

They build camera systems for greenhouses that help growers spot plant stress and decide when to intervene. You deploy them quickly and start getting useful signals fast. Today, the setup is cloud-first: images go up, pipelines run, metrics come out.

The problem shows up at scale. Each site generates huge volumes of data. In rural environments, with limited bandwidth, that turns insight into something that arrives too late to act on. As Raj put it, the issue isn’t compute. It’s bandwidth, and more specifically the assumption that every byte needs to travel before it becomes useful.

So they’ve become selective when looking at what to move to the edge and what to keep in the cloud. Some things earn their place close to the data: basic quality checks, pulling out the parts of an image that matter, turning pictures into signals. Other things don’t: training, cross-site analysis, anything that needs global context or doesn’t benefit from immediacy.

Hardware isn’t the limiting factor. The sites already run capable devices. The harder part is operating them. Once you have hundreds of devices in the field, reliability, observability, and fleet management become the real constraints.

Before moving more computation outward, Fotenix is putting effort into the fundamentals. Lightweight runtimes. Local observability. Remote fleet management. The goal is to make sure that when computation does move closer to the data, the system doesn’t become blind or fragile.

Summed up simply: edge is a consequence of maturity. If edge feels risky, that usually means the system isn’t ready yet.

Watch Full Talk

Sam (Fuzzy Labs): Shipping ML to the Edge: A Practical Guide

Sam followed by zooming in on what all of this looks like from an MLOps point of view.

He opened by admitting that speaking into a microphone still makes him feel like he’s on X Factor. Thankfully, instead of “Edge of Glory”, he walked through where edge changes the MLOps lifecycle.

To keep things concrete, he used the tongue-in-cheek”Don’t Ring” doorbell as case study, an anonymised version of a real Fuzzy Labs project. The problem: they had a facial recognition system that worked well, except it failed when people weren’t looking at the camera, or stood too close, or too far away. The solution: build a separate model that detects unusable images and filters them out before they hit the facial recognition system. The model is small and efficient, so it runs it on the device itself without killing the battery.

Models need to be small. Power matters. Privacy often means you don’t get access to real data.

In this case, there was no data at all. Open datasets can get you moving. Synthetic data helps too - Gemini generates realistic training images for about two pence each. But Sam was clear about the catch: synthetic data helps you train. It doesn’t tell you whether the model will behave in the real world. If your evaluation data doesn’t match what the device actually sees, you’ll find out later.

Experiment tracking came up next. He put up a slide most people saw themselves in immediately:

“We’ve probably all been there at some point with something like my_model_V3_best_USE_THIS_ONE_final.”

Deploy the wrong model to the cloud and you redeploy. Deploy it to a device you can’t easily reach and you are running around collecting devices or sending apology emails to customers.. Versioning, lineage, knowing what’s running where. Things you can sometimes get away with being loose about in the cloud start to matter much sooner.

Model optimisation followed the same pattern. Every size reduction is a trade-off. You only really understand those trade-offs if you measure performance in the conditions the model will actually run in, not just against training metrics.

Deployment doesn’t get easier either. Different devices, different architectures, different toolchains. Sam mentioned tools like PlatformIO as a way to avoid rebuilding everything from scratch each time.

The problems Sam walked through aren’t new. Data quality, experiment tracking, model optimisation, deployment complexity - they all exist in cloud systems too. What edge removes is the buffer that makes cloud mistakes recoverable. Deploy the wrong model to cloud and you redeploy in minutes. Deploy it to a device you can’t reach and you need physical access or a complex remote rollback. You don’t need entirely new skills for edge ML. You need to be much more careful about the fundamentals you already know.

Watch Full Talk

Isabella Gottardi (Arm): From Edge to Everywhere: Arm Machine Learning Inference Advisor's journey from NPU to GPU and beyond.

Isabella from Arm focused on the hardware layer with a live demo of MLIA.

When Arm first became involved in machine learning, the assumption was cloud-centric: send an image to the cloud, run inference, return the result. Today, inference runs in lots of places. Cloud platforms. IoT devices. Phones. Automotive systems. Dedicated accelerators. The same model can technically run across all of them. Performance varies wildly.

“Portability of models does not mean portability of performance.”

That’s where MLIA, the Machine Learning Inference Advisor, comes in. A way of checking compatibility and performance before you’ve committed to architectural decisions that are expensive to reverse.

The usual flow is familiar: gather data, train, optimise, deploy. Performance issues tend to show up late, when changing course is painful. MLIA shifts that discovery earlier, while trade-offs are still cheap.

Isabella showed this live. Pick a target environment. Check whether the model will run. Look at how it behaves. Try a variant. Compare the results. The tool gives you information before you’ve committed to an approach that won’t work.

With Arm’s recently announced neurotechnology, that problem only gets more interesting. Models will behave differently on different GPUs, and especially on specialised edge device hardware. The future is heterogeneous systems, where performance depends on memory layout, data movement, and how work is split across processors.

The takeaway: inference performance isn’t something you discover at the end. It’s a design input.

Watch Full Talk

Sources:

• https://github.com/arm/mlia

Pypi package:

• https://pypi.org/project/mlia/

Rounding up

What we’re taking away from MLOps.WTF #7:

• Edge forces immediate answers to questions you could defer in the cloud. Energy use, model size, and bandwidth constraints aren’t problems for later. They’re design constraints from day one.

• Operational maturity matters more than hardware capability. The limiting factor isn’t compute power. It’s whether you can observe, update, and recover when systems are in the field.

• Be selective about what moves. Not everything belongs at the edge. Move what benefits from immediacy and local processing. Keep what needs global context or doesn’t gain from faster turnaround.

• Design for hardware reality early. The same model performs differently across different chips. Check compatibility and performance before committing, while changing course is still cheap.

As Raj put it, edge is something you arrive at when your infrastructure can support it.

About Fuzzy Labs

We’re Fuzzy Labs. Manchester-rooted open-source MLOps consultancy, founded in 2019. Helping organisations build and productionise AI systems they genuinely own.

We’re also hiring.

Open Roles

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

• Private Sector Lead

See all current vacancies

Liked this? Forward it to someone wrestling with edge deployments.

Not subscribed yet? Button link below. Couldn’t be easier.

Subscribe now

This episode is brought to you by Shubham Gandhi, MLOps Engineer and run club enthusiast at Fuzzy Labs.

Last episode, Matt introduced some of the challenges teams can expect to encounter when productionising AI agents. Agentic applications fundamentally differ from traditional software and ML systems in how a request is executed end-to-end.

Rather than a single prediction, agentic systems run multi-step workflows with iterative loops of reasoning, action, and state. Agents maintain context, make decisions conditionally, and adapt their behavior as execution unfolds. A single request can cascade into many tool calls, data retrievals, and intermediate decisions. Each of these steps introduces new failure modes, dramatically expanding the surface area where things can go wrong.

Agentic applications introduce a challenge in how to observe, debug, and evaluate such systems. How do you build confidence in a system that is inherently non-deterministic? In this newsletter, I’ll share what we’ve learnt about managing agents and workflows in Fuzzy Labs’ customer work.

A workflow by any other name

But first, we need to talk about terminology. Because agentic AI is such a new field, it’s inevitable that different people will use the same words to mean subtly different things. Unfortunately, workflow has different meanings depending on who you ask.

In our previous edition, we discussed agentic workflows, and what we really meant by that was the control loop that sits behind an agent. For each loop iteration, the agent’s model is given a prompt along with some context, and it is given the opportunity to take an action — like calling a tool, or updating its memory.

In a recent article from Anthropic — Building effective agents — a workflow is defined very differently. For Anthropic, workflows and agents are mutually exclusive concepts. Quoting the article:

“Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.”

The distinguishing factor is autonomy: workflows can’t make decisions about what to do next, but agents can. For this article, we’re adopting Anthropic’s definitions.

Workflows vs agents (to be, or not to be)

LLM workflows are predictable and consistent if the task is well-defined. Some examples include categorising customer service queries, translating a document, or generating or summarising reports from a database. The patterns range from forwarding queries to an LLM and getting back a response, to more complex chaining and routing involving multiple steps, or stateful multi-turn workflows.

Agentic patterns, on the other hand, involve autonomous loops of LLM reasoning and tool usage, where the system dynamically decides what steps to take in order to achieve a goal. Some examples include a sales coaching assistant, open-ended research, or multi-tool problem solving. There is no predefined code-path; agents go in an endless loop using their available tools and knowledge to collect all the necessary information required to complete a task.

Even though agents are fashionable right now, not all LLM applications need to use an agentic pattern. There are lots of simple workflows that may solve your use case.

There are various options on how to implement these patterns. Popular libraries for implementing workflows include Langchain, LlamaIndex. For agents, we have used the open source Pydantic AI library in most of our work, but besides that there are lots to choose from such as Google ADK, LangGraph, CrewAI and Parlant.

Reproducibility and evaluation

When we deploy agents, we pay particular attention to reproducibility: for any actions and decisions made by an agent, we want the ability to look back and understand how the agent got there. Without that, debugging becomes increasingly difficult, and moreover we have no ability to explain outcomes or measure performance.

By introducing experiment tracking, we can version the prompt, dataset, models, code and various metrics. It also allows us to keep track of traces. Traces are records of all actions, messages, tool calls, reasoning, and intermediate communications, tracked across the lifecycle of a request. Traces are invaluable for debugging and provide insight into the actions an LLM takes in generating a response. The popular open source tools that we have used are MLFlow and Langfuse.

With a reproducible foundation in-place, the next critical component we need is an evaluation framework. The idea here is to perform error analysis, collect 50 - 100 examples of where the application is failing, ideally through real user conversations. If you don’t have any data, you can also generate synthetic data to get started.

These examples serve as an evaluation dataset. The evaluation process for agentic workflows can be broken down into two steps. First, we check whether the overall task was successful. Second, we perform a step-level diagnosis: checking whether tools were selected appropriately and whether the agent recovers from failures. For workflow-based patterns, error analysis needs to be targeted at each stage of the workflow. For more advanced cases, LLM-as-judge evaluators can also be included. There are generic LLM-specific evaluation tools such as DeepEval, Deepchecks and Ragas.

To summarise, by this point we have an orchestrator, an application-specific evaluator, and an LLM-specific experiment tracker with tracing for debugging. Together, these enable us to confidently iterate and improve the performance of the agentic application. Because LLMs are susceptible to hallucinations and prompt injection, one common outcome of evaluation is the addition of guardrails around inputs and outputs to catch and flag issues early.

Production considerations

In this article, we’ve discussed some of the fundamentals of MLOps as they apply to tracing, reproducibility, and evaluation for agentic systems.

There are plenty of other considerations for productionising agentic applications. Defining clear success metrics at the start of a project is important if we want to meaningfully evaluate performance - the frameworks don’t do the thinking for us here. As a project evolves, we also need to consider increased complexity in observability and telemetry, alongside more sophisticated guardrails and safety controls. On top of that, the standard set of application monitoring still applies.

What’s next? (all the world’s a stage)

Over the next few editions, we’re going to dive into some of the most important topics in agentic AI and AgentOps. We’ll cover multi-agent systems and agent-to-agent protocols, explore evaluation and testing in greater depth, look at fully self-hosted agentic applications, and cover safety and security — which may turn out to be the most important emerging topic in this field.

Agents are still very new technology, and we’re constantly learning and refining our approach to AgentOps. We’re keen to hear your own experiences and lessons learned, so please get in touch and let us know.

Shubham, (the perfect dude) is a master of AI with a passion for machine learning engineering and MLOps. He holds a Master’s degree in AI, enjoys running, and believes the best solutions are usually the simplest ones.

And finally

What’s coming up

Our next MLOps.WTF meetup is happening on 22nd January 2026, hosted by Arm - and it’s now sold out!

If you’ve got a ticket but can no longer make it, please cancel so someone on the waiting list can take your place. And if you missed out, it’s still worth joining the waiting list… just in case.

This one’s an edge AI special, focused on what actually changes when models move out of the cloud and into the real world: tighter constraints, harder debugging, and failure modes you don’t see coming until you ship. We’ll be hearing practical stories from Arm, Fotenix, and Fuzzy Labs on what it takes to run edge AI systems day to day.

🗓️ Thursday 22nd January 2026 — Manchester

Join the waiting list

We’re also headed to our first BIG event, AI & Big Data Global on 3-4 February. Matt will be joining a panel at the conference, digging into what it really takes to take AI systems from prototype to production.

🗓️ 4–5 Feb 2026 — Olympia London

If you’ll be there, come say hello, and if you show this newsletter, we’ll even give you a bottle of sauce. Secret password: IReadTheNewsletterUntilTheEnd.

About Fuzzy Labs

We’re Fuzzy Labs, a Manchester-based MLOps consultancy founded in 2019. We’re engineers at heart, and nerds that are passionate about the power of open source.

And right now, we really are hiring. We’re growing fast — and we’re on the lookout for people to join our team.

Open roles:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

See all current vacancies

If you, or someone you know, want to build serious systems with people who can happily spend 30 minutes arguing about observability and espresso extraction, we’d love to hear from you.

Not subscribed yet? You probably should be. The next issue will be our MLOps.WTF meetup playback and then, after that we’ll be diving deeper into agents in production, starting with multi-agent systems. Or follow us on LinkedIn to see what we’re up to🫶.

Subscribe now

Did you know 2025 is a square year?

Take 45, square it, and you get 2025. If you’re wondering how special that is, the next square year is 46² – which isn’t until 2116. A bit of a wait.

This year on MLOps.WTF we’ve shared 13 articles. Topics ranged from sovereign large language models – how to build your own, and why it matters – to AI safety, including the slightly terrifying idea of using neural networks in safety-critical applications. We talked about vibe coding and whether any of us will have a job in 2026. And of course agents, which have been a big focus for us.

We care about agents because we want to understand how to productionise them – and how to keep them running in production. We’ll have a lot more to say on this in 2026, including workflow management and multi-agent systems, evaluation approaches, self-hosting agentic models, and the safety and security work that comes with all of the above.

Thanks to all of our authors besides me – we’ve had articles from Danny, James, Sam, Sav, Rhiannon, and Tom.

We’ve also run five live MLOps.WTF events here in Manchester this year. You can find all the videos on our YouTube channel.

If you’d like to come to the next one, it’s on 22 January. It’s being held at Arm’s new office in Manchester, and we’re focusing on edge AI – basically any situation where we want to train, optimise, deploy, and manage models on specialised hardware.

That includes cases with power constraints, where we want models to use as little energy as possible. Or memory constraints, where we need models to be small enough to fit. Or situations where we want to do most inference locally, close to the data, and only send summaries up to the cloud – because latency, bandwidth, cost, or privacy says we should.

We’ll cover all of those topics on 22 January with our edge AI MLOps special. If you’d like to come along, here’s the sign up link.

Tickets for 22nd Jan

I couldn’t find anything mathematically interesting about 2026. If you’ve got one, send it in a message or leave a comment – we’d genuinely love to hear it.

In the meantime, have a great holiday, and we’ll see you in 2026!

How do we deploy software that thinks for itself?

It’s a common theme in this newsletter that things change quickly in the world of MLOps. According to Google Trends, the term itself only gained popularity in 2019. Back then, the hard thing we were all grappling with could be summarised like this: how do we deploy and maintain software that’s fundamentally non-deterministic?

This description applies to all the traditional ML things that we know and love, like recommender models, sentiment scoring, image segmentation, etc. And it applies in the same way to the first wave of generative AI applications, such as RAG (see issue #4). Non-determinism in ML comes from a few places; randomness during training, gradual data drift during inference, and (especially with LLMs) stochastic generation used as part of producing a model output.

That stuff is hard enough to deal with, but agents are much worse, because they add an entirely new dimension to the challenge: agents can reason and follow complex workflows. They can act, and interact with the world in ways that compound unpredictability. A traditional ML model makes a prediction on request, and then it sits there waiting for the next request. But an agent makes a prediction, then takes an action, observes the result, and it can keep going, potentially dozens of times in a single run.

As MLOps practitioners, how do we approach this challenge? In this article I’ll introduce some of the emerging ideas and tools for running AI agents in production — AgentOps, if you like.

Agentic workflows: or fancy while loops

To begin with, I’d like to demystify this word ‘agent’. The term has been around in AI research since the 1980s, but it was researchers like Pattie Maes at MIT’s Media Lab who brought it into the mainstream. When Maes launched her Software Agents Group in 1991, she defined an agent as a program that could act autonomously on behalf of a user or another program.

(Photo credit: Susan Lapides, 2013 - Pattie Maes)

Nowadays, ‘agent’ refers to a specific way of using large language models with tools—and the mechanism is remarkably simple.

Suppose we want an AI to assist with booking meetings. You could prompt an LLM with everyone’s calendar slots and ask it to reply with a suitable time. That works, but what if we need more information from the user, or additional data from the calendar system?

Instead, give the LLM tools and let it make its own choices:

“You are a calendar booking assistant. The user wants to book a meeting for Alice and Bob this week. You may:

a) you can ask to see a user’s calendar: <tool:calendar,user name>;

b) you may ask the user for additional clarification: <ask:question>

c) propose a meeting time along with <done>”.

To make this work, we need a program — let’s call it a workflow orchestrator — that interprets the LLM’s responses and acts on them. After each action, the runtime calls the LLM again with the results: “On the last turn you asked to see Alice’s calendar. Here are her available slots: [...]”. The LLM decides what to do next—maybe it needs Bob’s calendar too, or maybe it can propose a time.

This continues in a loop until the LLM returns <done>.

That’s the core idea: a while loop where the LLM decides what happens next. This basic structure is what powers our coding assistants, research tools, etc. By giving the LLM the power to pursue a goal autonomously and make decisions based on what it observes at each step, we end up with an agent.

By the way, if you’re familiar with the concept of continuation passing in programming, then you’ll notice some similarities here!

From loops to workflows

The calendar booking example above illustrates the concept, but in practice it’s very limited. What happens when the LLM makes a mistake and needs to backtrack? What if you want multiple agents working in parallel, perhaps one checking calendars while another drafts a meeting agenda? And what if a human needs to be in the loop, say by approving the proposed time before committing?

What we really need is a workflow framework. Tools like LangGraph (from the makers of LangChain) and CrewAI take the basic while-loop pattern and add the structure you need for production: state management, branching logic, error recovery, and orchestration of multiple agents or steps.

LangGraph, for instance, lets you define your agent as a directed graph where nodes represent actions (e.g. call the LLM, invoke a tool, wait for human input) and edges represent transitions between them. The framework can persist state, so if your agent fails during a complex process, you can resume from where it left off instead of starting again.

Using tools

Workflows are what enables an agent to reason sequentially, i.e. to work through a task in multiple steps. But our agents also need to observe and act, and to do that, they need access to tools. Tools give agents access to things like databases, file storage, and APIs. In the calendar booking example, we glossed over exactly how tool calling works, so let’s take a closer look at that now.

For an LLM to make use of tools, we need to agree on two things: firstly, how do we describe a tool to the model? Secondly, when the model wishes to invoke a tool, how should it communicate its intentions back to us?

In other words, we need a protocol, and Anthropic’s MCP (model context protocol) has become the standard way to describe and interface with tools. Each tool has an MCP server which knows how to talk to that tool. Workflow frameworks use an MCP client to talk to these servers.

The standardisation that MCP brings is important particularly because it means we can swap out tools without re-writing the agent, and different workflow frameworks are now interoperable with the same tool integrations.

Deploying agents

At first glance, deployment looks straightforward. Components related to workflow orchestration, as well as your MCP servers, need to be deployed, scaled, and monitored. We need infrastructure, CI/CD pipelines, central logging… so far, so good.

In traditional ML deployments we usually assume a single inference step. So, you send data to a model, get a prediction back, and you’re done. But as we’ve seen, that’s not how agents work. A single request from a user might trigger ten individual LLM calls, along with three API requests, and a database operation.

That means your deployment needs to handle long-running processes, manage state between steps, and deal with failure gracefully. What happens if our agent is half-way through booking a meeting and the calendar API times out? Should it retry? How many times? In the end do we fail the whole workflow, or save and resume later on?

We can make life even harder by introducing multiple agents that need to coordinate in order to accomplish more complex goals. How do these agents share state and agree on task orderings?

The good news is that these aren’t new problems in software engineering. Ultimately, we’re talking about the challenges of distributed systems. Statefulness is the enemy, so we need to avoid it as much as possible. MCP servers, for example, should most definitely be stateless. Workflows are stateful by definition, and Frameworks like LangGraph include helpful features like state persistence and recovery.

For the multiple agent case, there are emerging standards designed to help with the coordination problem — in particular Google’s Agent-to-Agent protocol.

Observing and monitoring agents

Once our agents are running in production, we need to understand what they’re actually doing.

Traditional ML monitoring is concerned with things like model drift, the distribution of features, and the accuracy of predictions. These are still of some interest — for example, we might want to track drift in the content of a typical user query — but the focus shifts more to tracing the agent’s reasoning chain. What tools did it call? What did they return and how did the LLM interpret the tool response? What decisions were made?

This is harder than it sounds, because a single agent run might involve many LLM calls, each with its own context, system prompt, and settings. Traditional logging isn’t quite enough, because we need to connect together every step within the run.

Tools like LangFuse are designed to help with this. Langfuse will keep track of LLM calls, along with tool invocations, as well as embeddings and retrievals. It also provides the means to manage and version control prompts. Another tool is LangSmith, built by LangChain, although worth noting this one is not open source.

Evaluations for agents

While observability tells us what our agents are doing while they’re in production, evaluation is how we determine whether an agentic workflow is correct, as well as safe and secure. Ideally, we want to run evaluations prior to any deployment. Think about it as a full end-to-end system test.

There’s an emerging discipline around evaluating the outputs from an LLM, which we recently wrote about in edition 19. As well as standard or “happy path” inputs, we want to test edge cases, and adversarial inputs (e.g. trying to break the guardrails or safety features). Because LLM output is stochastic, to evaluate the outputs we often need to use semantic similarity scoring, or even use another LLM to judge an output.

As we’ve seen, with agents, we aren’t just dealing with single LLM invocations. We also need a way to evaluate a whole workflow. Take our calendar booking example. Success isn’t just “did it book a meeting?” You also need to know: did it check the right calendars? Did it ask clarifying questions when needed? Did it handle conflicts gracefully? Did it book a meeting at a time that actually makes sense?

A tool like Evidently AI provides the functionality for evaluating individual LLM calls, but it also supports evaluations at the workflow level. For example, tracking workflow progress and failed steps.

A key thing to remember is that evaluation doesn’t just happen once. It’s something that should be done every time you want to deploy a change. In agentic applications, a small change can have far-reaching and hard-to-predict implications. Additionally, many of the techniques used — like LLM as a judge — can also be used within live monitoring in order to flag up problems in production.

Where next?

This has been an overview of what the MLOps landscape looks like for agentic AI. But this is a big topic, and we’ll be following up with some deeper dives into agents in the next few editions.

But, to round up, one final observation I’ve made is just how much the challenges of agentic AI engineering resemble those of distributed systems. I think we can expect to see more and more influence from the world of distributed systems showing up in the future.

And finally

What’s Coming Up
Our next MLOps.WTF event is living on the edge, or specifically for edge AI should we say. Details yet to be fully released but tickets will sell out - if you want to join us, get in early!

🗓️ Meetup #7. 22nd January 2026 x Arm👇

Get my MLOPs.WTF ticket

About Fuzzy Labs

We’re Fuzzy Labs. A Manchester based open-source MLOps consultancy, founded in 2019.

Helping organisations build and productionise AI systems they genuinely own: maximising flexibility, security, and licence-free control.

We’re growing fast, and hiring the following roles:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

If you, or someone you love, enjoys building reliable ML systems and doesn’t mind the odd frequent debate about coffee brewing methods, have a look at our careers page.

Open Roles

If this edition was useful, pass it on. You can also find us on LinkedIn, where we post updates, videos, and the occasional explanation.

Share

Not subscribed yet? Strange. The next edition will be our agents deep dive – workflows, coordination, make sure you’re signed up to get it to your mailbox.

Subscribe now

MLOps.WTF #6 Slides

8.85MB ∙ PDF file

Download

Download

Matt’s intro.

First up - Daisy …

Brad up next …

Liam wrapping things up.

Leave a comment

It might have been cold November rain outside, but it was another record turnout for MLOps.WTF #6, our first time taking the meetup on the road to Matillion’s brilliantly retro office, complete with a green Terrazzo reception desk. The theme of the meetup, however, was anything but retro: How do you monitor and evaluate AI? And a kick off show of hands revealed about half the room knew what this meant.

When we talk about evaluations in MLOps and AI, we’re talking about the tools and techniques that give us confidence our machine learning system is working. System, not model, because the model is only a small part of it. When you’re building an AI-powered product, you need to evaluate the whole thing.

There’s also a distinction between evaluation and monitoring: monitoring is the ongoing thing you do in production because data changes and there are things you didn’t anticipate, while evaluation is what you run before deployment to understand whether the thing works correctly in the first place.

Settle in for three talks on fraud detection, interview intelligence, and digital data engineers - one with Pokémon scattered throughout, one apologising for the lack of Pokémon, and one warning us about “the world’s worst diagram.”

Daisy Doyle: “Fraud – Gotta Catch ‘Em All”

Daisy, data scientist at Awaze, committed to the Pokémon theme. Trainers and Pokéballs throughout, plus two fictional companies “Eevee Trading Cards” and “Snorlax Spa Breaks” for her case studies that she assures us bear no resemblance to anywhere real.

The scale of the problem

Last year, in the UK, e-commerce fraud hit over 3 million events, equalling over 1 billion pounds stolen and just under 1.5 billion prevented. Which at around 60%, is something, but not great.

The fraud comes in different flavours - promo abuse, chargebacks, account hijacking, triangulation - and which ones you’re dealing with shapes how you evaluate.

AWS Fraud Detector

Daisy uses AWS Fraud Detector, a fully managed service that takes 18 months of historical data with fraud/legitimate labels and builds a model. It’s a black box so you can’t see what’s under the hood, but orders get a fraud likelihood score between 0 and 1000.

She applied this to two very different scenarios…

Eevee Trading Cards: high volume, limited edition cards, with fraud trends changing every four to six weeks around new releases, mostly account takeover.

Snorlax Spa Breaks: slower moving, with fraud clustering around big Pokémon calendar events, mostly chargebacks and triangulation.

Why accuracy doesn’t work here

“If my model said all orders are legitimate, my accuracy would be 99.5%. Because fraud is typically under half a percent of all orders.”

Accuracy is useless when your data is that imbalanced. What actually matters is true positive rate and false positive rate, because you want to catch as many fraud events as possible whilst not stopping real customers, and some real orders do look a bit fishy.

Before deployment, begin by testing in stages: start with a sample of 100 fraud events to check the model catches them, then 50/50 split of legitimate to fraudulent, then the realistic ratio of 2% fraud against 98% legitimate to see if it can still pick out the signal when it’s more sparse.

AWS Fraud Detector also provides variable enrichment through their own databases of fraudulent emails, addresses, phone numbers. Geolocation enrichment worked particularly well for Eevee by cross-referencing billing address, IP address, and shipping address to flag orders placed in a different country to where they’re being shipped.

Training the trainers

Human reviewers are required for GDPR, but they have their own bias. Reviewers can anchor on an AI score even when the model isn’t that strong yet, so you need to build their confidence in the system.

This means running a trial period where you’re validating both the model and the reviewers. For fast-turnover goods like Eevee, you can let some orders through and wait to see what actually turns out to be fraud - you get ground truth to check the model against, and reviewers get to see how their judgment compares to outcomes. For high-cost items like Snorlax where chargebacks take up to a year, you invest more in the review process itself: more time, more information, let them speak to customers directly. Your business context determines how you build that confidence.

Retraining and thresholds

Retraining frequency depends on how fast your fraud moves. Fast-moving trends like Eevee need monthly or faster, while slower seasonal trends like Snorlax can be quarterly or around big calendar events. There’s also a limitation with Fraud Detector that it can only process one batch of predictions at a time, so you need to think about batching.

And how much fraud should you let happen? Sounds counterintuitive, but your model needs fraudulent data that’s definitely fraud to retrain on. When you stop an event in progress you never know for certain whether it actually was fraud. So there’s an argument for letting through a small percentage based on your risk appetite, just to maintain training data quality.

The takeaway from Daisy’s presentation: monitoring and evaluating is shaped by business context and data, not just technical constraints. And there is no such thing as too many Pokémon when it comes to MLOps.WTF presentations.

Bradney Smith: “Six Lessons in Evaluating Gen AI”

Bradney, AI Lead at Spotted Zebra, apologised for the lack of Pokémon, but he did give us six really great lessons on evaluating gen AI, so we’ll let it slide.

Setting the scene, and taking us on a story, Brad joined Spotted Zebra in August 2024. His first task: to build out the AI team and infrastructure, with his first project being “Skills Evaluation” (extracting evidence of soft and technical skills from interview transcripts.)

The only way to know if the AI was working was to have the occupational psychologists review the outputs. Make changes to prompts, send to the experts, wait for feedback, iterate.

Then a prospective client got interested. Really interested. Feedback went from informal and infrequent to formal and regular, sometimes multiple times a day. A year’s worth of development in a few months.

The manual review loop couldn’t keep up.

That’s when they built evaluation infrastructure.

Lesson 1: Golden examples

A golden example is a document where you define exactly what the correct output should be for a given input. For Skills Evaluation, that means: interview transcript goes in, correctly extracted evidence comes out. You create a set of these with your domain experts, and that becomes your gold standard to test against.

The shift is significant. Instead of sending every change to experts for review, you test against the examples they’ve already created. Now you can measure properly. Prompt engineering becomes quantifiable experiments instead of gut feel.

They stratified their golden examples by role level and industry. That granularity meant they could see exactly where prompts were failing - junior roles missing university experience because prompts only looked for workplace evidence, for instance.

When GPT-5 came out, they tested it on day one. Every new model, even in the same family, has quirks. Golden examples told them exactly what those quirks were so they could prompt around them instead of assuming newer means better, although in this case - GPT-5 is pretty good.

Lesson 2: Version your prompts

“Please don’t hard code your prompts. It makes things so much more difficult.”

Treat prompts like code. Use a structured file system with semantic versioning. They built their own format because they couldn’t find one they liked: YAML file with provider, parameters, system prompt, user prompt with templating. Everything needed to run the experiment again.

Keep a changelog so you can track how prompts improve over time. Keep a config file on prod so you can roll back without restarting the server.

Lesson 3: Model gateway

They kept finding engineers across the business writing the same API call logic over and over. Same boilerplate, different codebases, nobody maintaining it consistently. So they built a model gateway - one function in a commons library that everyone uses. It parses the prompt files, packages the API calls, captures latency and cost metrics, handles retry logic.

You build it once, and suddenly that’s one less thing for everyone to think about.

Lesson 4: LLM as a judge

Now, golden examples work when there’s a correct answer - information extraction, classification, etc. But Spotted Zebra also has a feature that generates interview questions. Suddenly there’s no single correct question - you could write thousands that are all slightly different, but all equally good.

For tasks like that, you can define your golden criteria instead. Asking what makes a good interview question? Rather than the wording of the questions themselves. The LLM judge then has your criteria and scores outputs against them. You can then use a different model family to avoid self-bias, and validate your judge against human expert assessments before you trust it.

Golden examples are for development time - you test before deployment. LLM as a judge can run at inference time, giving you continuous quality assessment in production.

Learn more about ‘LLM as a judge’ from our last MLOps.WTF meetup with Emeli from Evidently AI here.

Lesson 5: Turn failures into tests

Most teams dread production errors - Spotted Zebra used to as well, but they now maintain what they call an adversarial testing bank: a collection of the most difficult inputs they’ve encountered, e.g. edge cases, prompt injections, empty inputs, password-protected PDFs.

At scale, edge cases stop being edge cases - they become the norm. So every time they find an error in production, it goes straight into the bank.

“We used to absolutely dread seeing errors of course... but now they happen much less frequently. So when they do occur, we get a little bit excited.”

Lesson 6: Log everything properly

You don’t need logs until you do.

And you can’t predict when that will be, and when you need them you need them fast, so make them searchable.

Earning your stripes (or spots)

So what did all this get them? Development is faster because they’re not waiting for the old feedback loop. Product quality is better. When clients ask how you know your black box system is working, you can actually have an answer.

And as Bradney pointed out: the EU AI Act is coming in 2026. The companies with evaluation infrastructure will be ready.

Liam Stent: “From Vibes to Data”

Liam Stent from Matillion has been building Maia from day one. His talk: how do you go from “it feels like it’s working” to actually being able to prove it?

What is Maia?

Maia is Matillion’s digital data engineer - or rather, a team of digital data engineers. It builds pipelines, builds connectors, does root cause analysis, writes documentation. The output is DPL, Data Pipeline Language - a YAML-based format that’s human-readable.

Early reactions were brilliant - customers could see how it would change how their data engineers work. But when you’re scaling to enterprise customers paying hundreds of thousands of pounds, you need to be confident in the data. You need to be able to prove it.

Matillion has a value: innovate and demand quality, with the tagline “no product, process or person is ever finished.” They used that to drive how they measured Maia - starting simple, getting more structured, then automating.

Starting simple

They fed their certification exam to AI prompt components. Some models failed, some passed. It taught them how to use RAG effectively and get LLMs familiar with DPL using their documentation - a starting point for what “working” actually looked like.

Getting structured

They then introduced an LLM judge to measure what Maia was producing. (seeing a theme here).

This was tricky because there are many valid ways to build a pipeline - you can put everything in a Python script and get the same result as a nicely structured low-code pipeline. So they had to teach the judge what good looks like using thousands of reference pipelines.

Before trusting the judge, they validated it manually. Domain experts would write the expected answer, provide counterpoints, assess how much confidence they had in the judge’s scoring. They found judges show bias within model families, so you need to use a different model to evaluate than the one doing the work.

Automating it

They built evaluation into their test framework - runs on builds and deploys with a bank of prompts and context variations. All output goes into LangFuse dashboards: scores, time taken, tokens used, costs. Engineers drill into individual traces when something goes wrong.

“They like it when things go wrong because that’s how we’re able to learn from it.”

When Sonnet 4.5 came out on Bedrock they upgraded with confidence in 24 hours. They could show stakeholders the testing, results before and after, why they were confident. Evidence instead of gut feel.

Integrating ML skills into engineering teams

How does a traditional Java software engineering shop integrate data scientists and MLOps engineers? Don’t treat it as anything special. Same backlog, same standups, same roadmap. If the work is important, do it.

They had to educate stakeholders on why they needed engineering cycles making things better without adding features - that’s the MLOps work that makes everything else possible.

But then it just became normalised.

Good engineers want to learn from other good engineers, T-shaped skills develop naturally, and the more generalists can handle without handing over, the more experts can do deep work.

Rounding up MLOps.WTF #6

Zooming out, these are our top takeaways:

• Choose metrics that actually tell you if the system is working.

• Front-load expert effort into examples and criteria, not reviews.

• Treat prompts like code.

• Build evaluation infrastructure once.

• Business context shapes every decision.

Thank you to all our speakers! You set a high bar for MLOPs.WTF, full talks will be available soon on the Fuzzy Labs youtube. (Keep an eye out!)

Final bits

Fancy your own pair of Fuzzy Labs socks? All speakers are awarded an aesthetically pleasing pair of Fuzzy Labs mathematical socks. Become our next speaker to get yours!

A final big thank you to Matillion for hosting. First time we’ve taken MLOps.WTF on the road, and we loved being at your space themed event space.

What’s coming up

Next MLOps.WTF event.
Jan 22nd. Tickets now available.

Edge AI at Arm’s fancy new office. We’re still working on the full details but one to get in the diary for the new year.

Get My Ticket

About Fuzzy Labs

We’re Fuzzy Labs. Manchester-rooted open-source MLOps consultancy, founded in 2019.

Helping organisations build and productionise AI systems they genuinely own: maximising flexibility, security, and licence-free control. We work as an extension of your team, bringing deep expertise in open-source tooling to co-design pipelines, automate model operations, and build bespoke solutions when off-the-shelf won’t cut it.

We’re hiring! Fancy becoming the next Fuzzican? Check out our careers page.

Work For Us

Liked this? Forward it to someone making deployment decisions based on vibes. Or follow us on LinkedIn.

Not subscribed yet? What are you waiting for?

Subscribe now