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

This episode is brought to you by James Stringer, MLOps Tech Lead at Fuzzy Labs.

It is now 3 years since ChatGPT was released and the progress since then is staggering. The latest Large Language Models (LLMs) are incredibly powerful tools that are seeing increasingly deep integration into our software and our lives. In the last year we’ve seen the rise of ‘agents’ – LLMs operating semi-autonomously to write code, search the web, and even interact with other software using the Model Context Protocol (MCP) standard. As the models released by the frontier AI labs become smarter and more capable, it seems inevitable that we will cede more and more of our workflows and responsibilities to them. The possibility of ‘intelligent software’ that is aware of context and can choose the most appropriate course of action is truly tantalising.

But, herein lies two challenges.

First, in that the language models that underpin these agentic systems are inherently stochastic, meaning that there is an intrinsic degree of randomness and open-endedness in their responses. If I ask the same question to a model multiple times, I may very well get different responses. Compare this to ‘traditional’ software which is in most cases deterministic, meaning that the same input always results in the same output. This certainty is crucial to building reliable software – when I hit delete on my 300 unread marketing emails I want precisely those to be deleted, but I definitely want the one from my mum asking about Christmas presents to be left alone. Given this stochasticity, how can we be sure that agentic software is behaving as we expect it to?

Second, are we to take the claimed performance of these models at face value? In every press release we see a new high score: “69% on LiveCodeBench”, “82% on MMMU”, “11% on Humanity’s Last Exam”, and so on. There is surely some signal in these metrics, but for me they pose much broader questions. There is evidence (Singh et al, 2025, Eriksson et al, 2025) that suggests data contamination in benchmarking is widespread, resulting in models overfitting for benchmarks and inflating their scores. It is also not so clear how well these capabilities transfer to ‘real life’, where these language models are implemented in production systems. Does a high score on a particular benchmark mean that a model will perform well in my unique use case? And can I really trust that this model only hallucinates 0.1% of the time?

In this article I’ll talk about how we overcome this uncertainty when building reliable AI software, discussing some of the techniques and tools that we use to quantify and control these increasingly intelligent models.

Why not use traditional methods?

Evaluating LLMs is difficult because the tasks for which they are commonly used are open-ended and qualitative; there may be multiple valid responses and the “correct” behavior often depends on context and user intent. Traditional NLP metrics capture only limited aspects of output quality and often miss nuances of factual accuracy or coherence, while ‘classic’ ML approaches don’t cut it as the ground truth is poorly defined.

In production environments it is standard MLOps practice to keep track of data as it flows through the system. This means logging the input data and the models’ predictions, as well as errors, exceptions, and infrastructure health: with these data we can construct a complete picture of the live system. For traditional machine learning models, we can monitor things like data drift and model drift – metrics with a clear statistical definition. Let’s say we’ve deployed a model to predict the price at which a house will sell, based on its postcode, number of bedrooms, square footage, and so on. As the model is used, we can start to understand the distribution of these variables and of the model’s predictions. Then, if our model starts to regularly predict house prices significantly lower than the average, we can easily see that there has been a change. And, because we’re monitoring both the input data and the model predictions, we can distinguish whether it is the distribution of input data that has changed, or if it is that the model itself is no longer accurate.

Unfortunately, both the breadth and nature of applications of language models mean that these changes become harder to detect: the modern LLM stack is such that we must be able to assess hallucination rates, retrieval accuracy and source adherence, bias and fairness, and instruction following. For agentic systems, there are even more: task completion, reasoning evaluation, and even cost efficiency of actions. To keep track of this we need to capture even more data: user prompts, model responses, metadata (e.g. which knowledge base articles were retrieved), and feedback from the user. The picture that we need to build of our models is much more complex, so it is worth highlighting some of the key considerations in brief.

Hallucination, retrieval, and instruction following, oh my!

Measured hallucination rates can be shockingly high: one medical literature review benchmark found GPT-4 making up references around 30% of the time, and only 13.4% of GPT-4 citations were found in the underlying corpus [Chelli et al, 2024]. For retrieval-augmented systems, this motivates the use of faithfulness scoring, where the responses are broken down into atomic claims and each tested against the retrieved context using another LLM. Other techniques include “needle-in-a-haystack” recall, where we plant a known fact in the input data and evaluate how well the model can retrieve it. Self-consistency checks, like SelfCheckGPT [Manakul et al, 2023], can also be used. In these systems the same question is sampled multiple times as a way to determine if the model is effectively guessing. These techniques can be used for so-called selective abstention policies, where the model is given the ability to refuse to answer rather than guess.

LLMs are trained on vast internet text and can inadvertently learn or amplify societal biases present in that data. As such, bias and safety are as important to understand as factual accuracy. They can be evaluated with curated suites of prompts designed to elicit opinionated responses, LLM judges to directly evaluate responses, and even red-teaming. The latter is especially important as unsafe behaviour is often conditional on adversarial inputs, rather than normal queries; accordingly, suites such as JailbreakEval compile test queries that should elicit safe refusal [Ran et al, 2024]. A further difficulty arises in that LLM-as-judge evaluators themselves are biased, with one paper noting a preference for American authors and open-access research papers [Chelli et al, 2024].

It’s also crucial that these models reliably do what we tell them to; as such, we evaluate the instruction following ability of the model. This includes two angles: helpfulness (does it follow the user’s request and solve their problem?) and compliance (does it obey the constraints and rules that we have defined?). Instruction following is typically evaluated by tracking the outcome of an action; for a model that generates summaries, we can see if the user has approved or rejected the summary. It’s also important to consider compliance at a more granular level, such as whether the number of returned items matches the number requested. In practice, the result is not always so clear cut, and there are common patterns where models typically fall short; it’s been observed that models can fail to follow negative constraints or, notoriously, avoid using em-dashes [Chelli et al, 2024]. User feedback can here be a direct signal, where response ratings (👍/ 👎) and the sentiment of follow-up prompts (“That’s not what I asked for!”) give a clear indication of performance.

Agentic LLMs require further analysis: their success rate on suites of tasks; the correctness of their invocation of tools; their efficiency (number of tool calls and token usage); and importantly the safety of external actions. To complicate matters, agents sometimes get the right answer via the wrong reasoning path, which is not robust enough for use in production.

Ultimately, human review remains the gold standard for assessing the quality of outputs, as can be seen in the ever-present “ChatGPT can make mistakes. Check important info.” disclaimers. However, this isn’t really feasible at scale, especially where the LLM output feeds into another pipeline step, or indeed can take actions as part of an MCP server. As such, we need to consider a different approach, where we can robustly evaluate the model both in development and at scale. As such, we typically break down this evaluation into two stages: offline evaluation during development, then online monitoring once the model is live.

Is my model fit for purpose?

Offline evaluation primarily seeks to quantitatively establish the performance of a model when applied to a particular task, such as extracting information from text, summarising documents, or constructing database queries. Typically, this involves creating a dataset of test queries with expected responses. This dataset should cover a range of scenarios – standard interaction queries, edge cases, and adversarial inputs – to probe the model’s behaviour. We define what a “good” response looks like in each case, sometimes allowing multiple acceptable outputs, and then score the model’s responses against these ground truths.

However, this last step is the tricky part as exact matches can be too rigid. Here techniques from natural language processing (NLP), like measures of semantic similarly using embeddings, can be useful in some cases. We can even use a separate language model to act as a judge against some predefined criteria, although as Emeli Dral discussed in our last MLOps.WTF meetup these LLM evaluators can introduce their own biases or errors. In practice, the best method to use truly depends on the use case in question; for example, translation tasks are commonly evaluated using the BLEU family of metrics [Papineni et al, 2002]. And, the good news is that once we have established our evaluation dataset and metrics these can be re-used whenever we update the model, allowing us to compare them directly. Crucially, we can integrate this evaluation into our CI/CD pipelines.

This approach provides a more rigorous, and importantly more realistic, framework for assessing the capabilities of language models. We no longer need to rely on claims and benchmarks, instead we can assess how they perform in (almost) the real world.

I’ve deployed a model, now what?

With our carefully constructed LLM playground, we can establish whether our chosen model is up to the task that we’ve assigned it. However, no plan ever survives contact with the enemy, or in this case, real people and their out-of-distribution requests. Production use necessitates accuracy, safety, and compliance under highly variable inputs; without continuous evaluation, a model that has appeared to work well in the lab can still be brittle, wrong, or harmful when used at scale. Therefore, it is just as important to keep an eye on our models in production through online monitoring.

The evaluation of online metrics is largely the same as in the offline case, just with one key difference. We will have some input and a response as before, but now in the live situation we lack the ground truth. The solution is not always trivial, requiring a shift from static benchmarking to dynamic, context-aware evaluation.

Open Source tools, like Evidently, are becoming central in structuring this ongoing assessment of production models by combining monitoring of traditional metrics with modern techniques like the LLM-as-a-judge. This allows us to consider a wider gamut of evaluations, to build up a clearer picture of the system’s behaviour. Such evaluations can be embedded in real-time pipelines to flag issues like hallucinations, irrelevance, or misalignment with user instructions. These can then be visualised in dashboards and monitored for anomalies: a spike in hallucination scores, for instance, or a drop in satisfaction ratings, triggers alerts for a careful review.

Evaluating LLMs in production is certainly challenging, but ultimately is a clear necessity. These models are powerful yet unpredictable; without proper evaluation of their capabilities and monitoring of what they’re doing, we cannot trust them in real use cases. But, by assessing hallucinations, bias, source adherence, instruction following, and other facets, we gain visibility into the model’s behaviour and can establish the right safeguards. Thankfully, as these models are becoming more widespread in production systems, so are our tools to keep an eye on them.

James holds a PhD in astrophysics from the University of Manchester and has since built a career in commercial data science, developing enterprise machine learning software for the manufacturing industry. His focus is on creating practical, scalable tools that help businesses stay ahead of the curve. Outside of work, he’s a passionate climber with a deep love of nature and music.

And finally

What’s Coming Up
Continuing on the theme, our next MLOps.WTF meetup takes place on 18th November at Matillion, where we’ll dig into how teams evaluate their AI systems in the real world. Expect practical stories on monitoring and evaluating ML and agentic AI: Brad Smith from Spotted Zebra will share how to build reliable evaluation pipelines for GenAI, Daisy Doyle from Awaze will talk lessons from fraud detection, and Julian Wiffen from Matillion will introduce Maia, their GenAI-powered data engineer.

🗓️ Tuesday 18th November - Matillion Offices, Manchester 👇

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: We’re growing (it’s a very exciting time!) and we’ve got a few roles to fill:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

• Public Sector Lead: Secure Government

If you, or someone you know, is looking to work somewhere where coffee, sauce and general condiment preferences are regularly discussed and debated… don’t hesitate to apply!

Liked this? Forward it to someone who loves monitoring and evaluating ML (one of us). Or give us a follow on LinkedIn to be part of the wider Fuzzy Labs family.

Not subscribed yet? What you waiting for? The next issue will be our meet up playback - and they’re always great value.

Subscribe now

This episode is brought to you by Tom Stockton, CEO & Co Founder at Fuzzy Labs.

Last month we sponsored the Manchester Tech Festival and were fortunate to hear the Manchester Mayor, Andy Burnham, talk about his vision for digital adoption in Manchester and the wider region.

He said something really quite powerful:

“Young people in the boroughs can see the skyscrapers from their bedroom windows, but they don’t know the pathways to work in them.”

I couldn’t get it out of my head and it gave me an idea about how open source could help with this mission…

I’m an open source nerd, and the solutions we build at Fuzzy Labs are rooted in open source. I wrote a LinkedIn post about how if our government focused on creating open source foundations for running digital public services, it wouldn’t just be cheaper and more efficient, it would also be more transparent. It could literally open doors for young people. Showing them how the software that runs our country is built, allowing them to learn from it, and maybe even contribute to it.

The post clearly struck a chord, so I thought I’d follow up with something longer. I wanted to look at how this could work in practice, and share some examples of where other countries have made open source a success. But when I dug deeper, I found something surprising. The UK is already doing this in some brilliant ways!

(Robbie with Andy Burnham and a bottle of our MLOps Open Sauce)

What we’re doing well

Have you ever noticed how UK government websites all look and feel the same? That’s because they’re built on an open source foundation called the GOV.UK Design System.

It’s a project run by the Government Digital Service (GDS), and it’s used across hundreds of government services including HMRC, DWP, DEFRA, and the NHS.

Beyond the open source code, it’s a community with a mailing list, monthly calls, design days and a Slack channel. It has all the ingredients of a great open source project. Collaboration, openness, and a sense of shared ownership.

The result is that every time you visit a government website, you get a consistent and accessible experience. Departments don’t need to reinvent buttons, forms, or navigation every time they build something new. That has saved millions in duplicated effort, reduced delivery times, and made services easier to use. It’s one of the quiet success stories of modern government technology.

Changing the culture

What’s just as important as the code is the culture that came with it.

The GOV.UK Design System helped normalise open source inside government. GDS made it clear that openness is a strength vs a risk. Their mantra, “Make things open: it makes things better” is more than a tagline.

It created a new way of working - designing and coding in public, sharing research, and letting others build on your work.

The Ministry of Justice (MoJ) has taken this mantra to the next level. Their Digital and Technology team is one of the strongest adopters of open source in government. They built their own MoJ Design System, extending the GOV.UK patterns for justice-specific services like case management and prisoner booking. Even more impressive is Splink (great name). An open source Python package for ‘probabilistic record linkage’. Used across gov from health to defence. It’s serious backend engineering solving a real data problem.

The MoJ team doesn’t just share code; they share their learnings through their Justice Digital blog (built using their Design System frontend). I love it! Honestly, if I was looking for a job and wanted to work in Government I would be knocking on their door.

Other open source success stories

The culture of openness has spread.

• The Home Office has its own Design System for internal tools and services.

• The NHS created the NHS.UK Design System, now used across the whole health service.

• Local councils are collaborating through LocalGov Drupal, which lets them share code and design patterns instead of paying for separate CMS contracts.

There’s a pattern here. Shared infrastructure that saves time and money while improving quality. We’ve defined some great examples. Now we just need to push it further.

Where it could go next

Unsurprisingly, I’m going to talk about AI.

If open source made our web services more transparent and trustworthy, imagine what it could do for government AI systems. Models that can be inspected, pipelines that can be reused, and decisions that can be audited, all built on open foundations.

From my research (and I’d love to be proven wrong!) this isn’t happening yet and there aren’t any initiatives to make it happen. The best I could find was a £1m fellowship to “build open-source AI tools for public services,” but it seems more like a partnership to promote Meta’s Llama models than a genuinely open source programme.

This is the opportunity. Take what worked for digital services and apply it to AI. It would make public AI projects faster, safer, and more explainable. Reuse what works, make it open, and let the community improve it.

Where open source could make a real difference

Take the Department for Work and Pensions’ fraud-detection algorithm.

An investigation found that it disproportionately flagged people by age, disability and nationality. As Science and Technology Secretary Peter Kyle said, the public sector “hasn’t taken seriously enough the need to be transparent in the way that the government uses algorithms.”

In my view an open source, auditable model training pipeline would have helped massively. Our government obviously wants to deploy AI, but it should also publish how these systems are built, by whom, on what data, and with what fairness checks.

Transparency is one side of the problem, another is duplication.

The National Audit Office wrote an excellent report highlighting ‘overlap’ in the responsibilities for AI adoption between departments (DSIT and Cabinet Office). That’s a strong indicator that we’re duplicating effort at a policy and strategy level, let alone at a technical one!

I’d like to see a central policy that talks about building open source AI foundations that can be used across departments. The same principles that made GOV.UK a success could do the same for AI. It seems we’re a bit away from this, but it’s where we should be heading.

What’s holding us back

Despite the great examples from GDS and MoJ, many departments still buy proprietary software to solve the same kinds of problems multiple times.

Why? Partly culture. Partly procurement. Maybe a lack of confidence or awareness of how to run open projects long term. Maybe it’s a concern over open source being less secure than closed source (not an opinion I share!). The intention is usually good, to de-risk delivery, but it often leads to silos and wasted spend.

We should look to change the default and become more comfortable with working in the open. The success of projects from GDS and MoJ show that it’s entirely possible to build shared, production-grade software in public.

At Fuzzy Labs, we see opportunities to open source parts of our own AI projects in government. Because it makes things better. Open projects attract contributors, create transparency, and help build technical capability in our country.

And that’s really the point.

When we make things open, we don’t just make better software.

We make better teams, better learning, and maybe better pathways for the next generation looking up at those skyscrapers.

Subscribe now

And Finally…

Want to contribute?
If you’re working in MLOps or building open source AI tools, we’re always looking for guest writers. Share your production wins, your spectacular failures, or that tool you’ve built that actually solves a problem. The best insights come from people doing the work – so if you’ve got something worth sharing, get in touch.

While we’re on the topic, the team have been cooking something up…

We’ve been sketching out “recipes” for the MLOps lifecycle – reusable, step-by-step ways of solving common problems. Think handling new data safely, tracking experiments, serving models in production, setting guardrails, retrieval-augmented generation (RAG), and security.

It’s very exciting – we’ve even got personalised chef hats for every squad member. But the real question is this: which stage of the MLOps lifecycle do you think most needs a recipe right now? (Not rhetorical - answers encouraged.)

What’s Coming Up

📅 18th November: The MLOps.WTF meetup is back at Matillion for edition #6, where we’ll dig into monitoring and evaluating ML and agentic AI with real-world stories. Brad Smith (Spotted Zebra) will share how to build robust evaluation pipelines for GenAI, Daisy Doyle (Awaze) will talk lessons from fraud detection projects, and Julian Wiffen (Matillion) will introduce Maia, their GenAI-powered data engineer.

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: It’s an exciting time for us in Manchester, and as always, we’re calling out for great talent, see our open roles below:
MLOps Engineer
Senior MLOps Engineer
Lead MLOps Engineer

Liked this? Forward it to someone who’s interested in the potential of Open Source and how we can invest in our . Or give us a follow on LinkedIn to be part of the wider Fuzzy Labs community.

Not subscribed yet? Get great MLOps content straight to your inbox, we’ll also be sharing some sneak peaks of the recipe book here too - so well worth a sign up!

Subscribe now

This episode is brought to you by Sam Greenwood, MLOps Tech Lead at Fuzzy Labs.

There’s a lot of hype around vibe coding at the moment. Everyone’s theorising about what it means for the future of programming, but very few people are truly putting these tools through their paces.

I’ve been using AI to assist my coding since GitHub Copilot launched in 2021. I’ve watched the capabilities increase from line completions that felt like pure magic to fully autonomous coding agents. Given I’ve been using these tools for quite some time (in the recent timeline of software), I’m also very aware of their shortfalls and their ability to cause all sorts of problems, if used the wrong way.

So when I wanted to properly test vibe coding, I wasn’t going to do it on customer projects but I needed a sandbox with real stakes. Inspired by our Hackathon and a desire to remove some of the manual admin from hiring, I decided to set myself the task of building an Applicant Tracking System (ATS), for Fuzzy Labs, using only AI coding tools.

Not a single line of code written manually. Love Island on in the background. A true test of if you can actually build production-ready software entirely through prompting, whilst equally being ready for the inevitable “I’ve got a text”.

However, my “experiment” wasn’t solely about coding today. It was, on a deeper level, about testing what I believe programming will look like in 2030, and what this current trajectory means for the entire SaaS industry.

(Artistic representation of what we imagine Sam looked like creating the ATS)

My prediction

I am very confident that the way software is built is going to look very different in the next 5-10 years.

The capabilities of LLMs have increased drastically in the last 3 years and I believe this is going to keep being the case. Besides the raw capabilities improving, the tooling that leverages them is going to keep getting better. Using Cursor, for example, is a much better way of using AI for coding than copying and pasting code into ChatGPT and then copying the output back.

And we’ll only get more tools like Cursor and tools like Cursor will keep on improving.

As a result of these developments, the speed of building software is going to increase and subsequently the cost is going to fall. What once took a squad of 5 engineers could potentially be done by 1 engineer using AI assistance.

My mum was a programmer in the 90s and when you compare the way people coded then to now, it is completely different. So when the narrative arises that the way we build software today will stay the same for the next twenty years, it seems counter intuitive. It never has before.

This shift puts lots of SaaS businesses into a precarious position. It does raise the question “is SaaS dead?” when companies and individuals can just create their own software instead of paying for expensive subscriptions.

There is some truth in that we might start seeing LLMs as an operating system in the future (dynamically creating applications for certain workflows on the fly). I’m not saying that this is what will happen, just that it has the potential.

One of the reasons I’m sceptical of SaaS being dead, at least in the short term, is that even if a company could in theory build their own HR, communication, or sales platform using AI, they would still have to manage it, ensure it stays up to date, address security concerns, bugs, and so on. There’s an argument AI can do all of that too, but in its current form it still needs an experienced engineer to oversee.

But what I do think will happen, is that disruptors will come into the SaaS industry and build competing software for a fraction of the price of what it currently costs. They’ll be leveraging AI assistance heavily and have a fraction of the number of expensive engineers. Therefore they can offer the same SaaS products for tens of pounds a month rather than the hundreds .Even more crucially, they can ship features faster and build a superior product to incumbents that aren’t making effective use of these tools.

Why try and build software internally when someone else can sell it to you for £40 a month and they can be responsible for new features, security updates, compliance, and so on? It’s a win win.

So that’s the theory. But I wanted to test where we actually are with vibe coding a SaaS product, how far we are from this near future, and what tools need to be developed to get us there.

The experiment

I asked ChatGPT Deep Research what the best way was of building this full-stack application. It recommended Railway for deployment. I prompted it to build it out and it worked really well. The frontend came together shockingly fast.

Then the GDPR problem emerged. An ATS stores personal identifiable information with strict GDPR requirements. Railway didn’t provide enough configurability as there were no options to have data stored in the UK. This could get problematic with GDPR. The trust just wasn’t there.

Where it got a bit muggy

The backend was probably the biggest challenge. I moved it to AWS Amplify but Amazon has released two major versions of amplify and the models kept getting confused between version one and version two. Meaning it kept breaking.

I spent all evening trying to prompt Claude to fix a deployment error and couldn’t do it. I knew if I dug into the errors myself I could fix it, but that would defeat the point. The experiment needed to be just prompting.

GPT-5 came out the next day. Same prompt. Fixed first try… just goes to show.

I also solved a lot of issues using an MCP server called Context7, which grounds models in actual documentation.

Since deployment, I can now build new features much quicker. But I still sometimes hit problems, it could be that AWS isn’t the right approach, or there needs to be middleware between the models and AWS, but I digress.

Cracking on

At regular stages throughout development, I’d prompt Cursor to do full security reviews, create tickets, then fix things. This caught quite a few issues so would highly recommend you do this also.

The ATS is now in testing with the team using it for actual hiring. And the team has been rigorously testing and trying to break it from a security perspective - so far it’s held up.

I don’t know exactly how much time I spent on this, but it’s safe to say it’s a fraction of the time it would’ve been if I’d built it the traditional way. But I know for certain that at no point was I just focused on it. I was always doing other things at the same time, which shows you can have it as a background task, whereas in the past you’d have to be completely focused.

Closing off

When you see people commenting online about where the future’s going to be and what the capabilities are, question if they’ve had a go...

We should be rapidly playing with and testing these tools; figuring out what works and moving ahead, not stuck debating the future of programming. The future is here.

Another sign of just how quickly this space is evolving is that since first vibe-coding this ATS, OpenAI have significantly improved Codex. It has now actually become my go-to AI coding tool (sorry, Cursor!).

It’s an exciting time for SaaS and programming - as we move into a chapter where things can be built far quicker than we imagined 10 years ago.

Keep an eye out for our new ATS, and if you’re interested in this way of thinking, why not use the tool to join the team. We’d love to see you here.

About Sam

Sam’s career spans industries from Defence to Logistics, where robustness and reliability are non-negotiable. Passionate about the transformative potential of AI, he thrives on building scalable solutions that make a real-world difference. Sam studied Computer Science at Newcastle University and outside of work can usually be found playing tennis or on the golf course.

Upcoming Events & Community

Come to our next MLOps.WTF event! 18th November: MLOps.WTF #6!
(We know this is Episode #17, and the numbers are not in sync but these are minor details)

MLOps.WTF is officially hitting the road, and our first stop is the Matillion offices at Two, New Bailey St.
Same Pizza, new stories and a whole heap of MLOps. Make sure you get your ticket as places will be limited.

Get my MLOps.WTF ticket

Next Week! 14th October: We’re hosting Awaze’s Women in Tech early career networking evening at DiSH.

Join for an evening of networking, first time speakers and, of course, Dominos pizza.

Come to the Women in Tech event

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.*
MLOps Engineer
Senior MLOps Engineer
Lead MLOps Engineer
*Solid engineering skills, passion for open source and coffee encouraged.

Liked this? Share with your colleagues and loved ones, and 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

Not subscribed yet? You really should.

Subscribe now

This recording captures what might be the biggest shift in software engineering we’ve seen in decades: the move from hand-typing code ourselves to building it alongside machines.

Matt Squire traces the thread from 1960s MIT – where Seymour Papert believed everyone should be able to create with computers – through to 2025, where “vibe coding” is becoming genuinely viable.

But this isn’t just a “look what Claude can do” showcase. Matt digs into three crucial skills that matter more than ever: problem decomposition and system design, fluency in reading and debugging AI-generated code, and cultivating domain knowledge with proper user empathy. There’s a compelling argument here that we’re not facing the death of programming, but rather returning to something closer to its original vision – where building things matters more than memorising syntax.

The talk balances optimism with honest questions about what this means for junior engineers learning their craft, and whether curiosity alone is enough to navigate this transition. Whether you’re already knee-deep in AI-assisted development or still sceptical about the whole thing, there’s genuine substance here beyond the usual hype cycle nonsense.

Fair warning: contains strong opinions about Emacs, nostalgia for the Amiga 500, and at least one quantum computing joke.

Full Transcript

Matt Squire: [00:00:00] Thank you very much, Amul. So, yeah, I’m following a talk on quantum computing and that’s quite a big thing to follow. My talk’s not gonna be nearly as clever, but, did you hear about the guy who was having trouble with his quantum computer?

Phoned up tech support and they said, have you tried turning it off and on at the same time? There we go. So I’m here to talk about whether we are the last programmers and I guess the premise of the title here is that we are all programmers. I’m kind of curious though, can I get a show of hands?

Who here would regard themselves? As being a programmer. Okay. And of those who put your hands up, who uses AI coding tools as part of your work right now? Lots of [00:01:00] people. Now the other question, of course, the logical question because this, the other premise of the talk is well, of loads of you who aren’t programmers or don’t consider yourself to be programmers.

How many of you have been vibe coding lately? Okay. A few. Yeah, so that’s really interesting and that’s kind of why I wanted to do this talk and why I wanted to, to bring this topic to the room today. So we are in possibly the most interesting transition in the history of programming of software engineering as, as a profession, as an activity, as a cultural phenomenon.

We are in a position where for the first time, professional programmers don’t need to handcraft code a lot of the time, the truth is that we are entering this era where, we don’t need to handcraft code.

We maybe don’t need to write code at all. And there’s a question of not is that true, but of how much code do we actually need to write now, if [00:02:00] any, and what does this mean? As professional programmers, what does this mean for us? And what does it mean for us more broadly, socially? So I wanna answer that question, but I want to tell you a little bit about myself first to set the scene here.

I’m Matt. I’m a programmer. I’m a computer scientist, more or less. I put a maths enthusiast because I like mathematics, but I don’t quite have the rigor to call myself a mathematician. Smarter people, like people who talk about quantum computing probably can do that, but perhaps I can’t.

Most importantly, I’m a nerd and I’ve been programming for pretty much as long as I can remember. I’ve also been an Emacs user since 2009. How many people use Emacs? Wow, that makes me sad. Well come to Fuzzy Labs stand and you can talk to me about Emacs and I’ll tell you why you should be programming using Emacs in 2025.

I’m also, the CTO at Fuzzy Labs and we are a company that we’re basically an AI consultancy. We help people productionise AI. If you like we are kind of part of the problem. So [00:03:00] that’s also kind of context for this talk. That photo is me at an event called Oggcamp. Oggcamp is a open source conference.

This is the first one they ran 2009. Coincidentally, the year I started using Emacs. And here I am standing on the stairs queuing to get into a talk about Linux kernels or something crazy and inseparable from my laptop where I don’t know what I was doing, but I’m sure I was programming something. So that’s kind of setting the scene here.

I’ve been doing this for a very long time. I’m passionate about it. I’ve learned a lot along the way, and I’m kind of, I say that to kind of put myself in the shoes of what I think at least is a section of programmers in our industry right now who are genuinely worried, worried that AI tooling is gonna take their jobs or change their jobs in some fundamental way.

I want to at least empathize with that position. I wanna tell you a little bit about my history as well in, in terms of programming. So this was my first computer. How many people have ever seen or touched one of these? [00:04:00] Excellent. Good. So this is a Sinclair ZX Spectrum. The 128K there refers to the memory.

That’s 128 kilobytes of memory. So this presentation for context could not nearly fit on that machine. For the younger people in the audience, you may not know what this thing on the left here is that that’s called a tape drive. And, some of you know about tapes because you’ve used them.

Like me, I was probably the last generations who actually used tape. You have programs on that tape, and that’s how you would load software into this machine. Okay, so that’s pretty cool.

And it looks kind of like this. You turn the thing on. This is the menu you get, you get a basic interpreter. You get a calculator and you get a loader where you can load programs from the tape or to the tape.

So far so good. Now, when I got this, it was already out of date, so I was probably 12, 11, 12, that kind of age. I just turned 40 this year, so you can do the maths on that. But this was out of date when I got it. It was a [00:05:00] family hand down from someone else. And it came with a manual. And the manual is a beautiful thing.

I still have it. It’s a little bit battered, I’m afraid. I used to carry this round with me on family holidays genuinely. And it tells you how to program it. It contains all of the information you need to program in basic and any of these other things. It tells you how the machine works internally. It may even have some schematics, I don’t quite remember.

But the idea is that if you want to write a program and you don’t know how to do that, well, you can type it in. You can literally type line by line. Your reward in this case is this, so this is a program called Breakout. It’s a game and you have to knock the little bricks off using your little boat.

Fair enough. That’s pretty cool, right? Well, it’s cool enough for a machine that was built in 1987 . Well, I soon, soon enough, I managed to get an upgrade on this. So this is my favorite computer ever. Even in 2025. This is the Amiga 500. How many people know the Amiga 500 . So [00:06:00] this was an enormous upgrade. Interestingly, this machine was built roughly the same time period as the ZX Spectrum. It was well ahead of its time. And again, we got it second hand. It was a hand down in my family.

But this became my entire life, to be honest. It was a revelation. It had a floppy disc drive. Isn’t that exciting. No more tapes. So yeah, I mean this, as I say, it was well ahead of its time, right? So this is what the desktop looks like. You’ve got multitasking. You’ve got preemptive multitasking, which was very new at the time.

You have the ability to load different software from floppy discs. It was really popular with graphics and video editing, believe it or not. And it came with a version of Emacs, which is kind of fun. You could program it and basic it once again, but a little bit more sophisticated, you can do a lot more with it, more power, more options, more tooling.

And again, it came with a manual. So again, I studied this manual. I got the magazines by the way, the magazines, for people who this is completely alien to, they were magazines and in them you had source code and it was basically like GitHub. But instead you had to go to the news agent and buy the [00:07:00] magazine.

And, and if you wanna do a pull request, it doesn’t work anyway. So yeah, that’s how that works. But again, I was, like I said, completely obsessed with learning how to program this thing and learning how all this stuff works. I showed you a screenshot of breakout earlier. There was a much better version of breakout called Arkanoid, which you got on the Amiga.

You’ve got on the Atari, a few other platforms at the time, this was an amazing game. I spent ages playing this, but I spent even longer trying to program my own version and say, why would you do that because it already exists, but that’s not the point right? The point is to learn how this stuff works and it’s just following your curiosity.

I spent a very long time writing my own basic version of this. And, learning along the way. The code was not good by any stretch of the imagination.

I don’t have it anymore, and thank goodness for that. I wouldn’t put it on my GitHub. I certainly wouldn’t propose anyone uses it for like, you know, GitHub if they’re applying for job applications, things like that. But that was that. [00:08:00] And I kind of, you know, asked myself recently, well, if I spent all that time trying to build my own version of this, what would that look like in 2025?

So I went to my friend Claude. And I said, can you make me an Arkanoid game in Python? And believe it or not, two minutes later we have it. So that’s kind of sobering. You could say, okay, well do you know what? It’s actually a really basic game. It’s pretty easy to write. The code for this is probably in the training set for Claude anyway, so it’s not that impressive.

And it doesn’t tell us anything about the future of programming, right, because it doesn’t do anything that anybody actually needs, unless what you need is this game. And if you do well, it already exists. So you could make that argument and say, this doesn’t really tell us very much.

So let me show you another example of something that has been vibe coded, completely vibe coded. So in Fuzzy Labs we have, a problem. Good problems to have, but one of the problems is that we have a bunch of different marketing [00:09:00] channels and we have different people who follow us on those marketing channels.

And we want to be able to unify them. We wanna understand if someone’s following us on LinkedIn, is it the same person who’s coming to our MLOps meetups? Is it the same person who’s subscribed to our newsletter? So we couldn’t find anything that solved this problem in exactly the way we needed to solve it.

And what happened was our CEO Tom stood at the back in, the yellow and pink, by the way. So I just give you a little bit of context. Tom is technical. He can definitely program. He’s very capable, but he didn’t want to. He is a very busy man, lots of things to do. So Tom built this entirely using vibe coding.

Not a single line of code was written, so that’s interesting, right? This is a real application that solves a real business problem that we have. We have the domain expert who knows the problem inside out. Who was able to build an application that he needed, that we needed as a business without writing any code.[00:10:00]

And this is in production. This is live. We use this every day, every week. And something else, a little bit more lighthearted, hook-a-ducks. So actually, if you come to our stand a little bit later, you can play this game. This was vibe coded by Rhiannon, our marketing manager.

And okay, we could have got something off the shelf, but we wouldn’t have been able to customise it and make it look Fuzzy ish and these kinds of things. So again, relatively straightforward game, but someone is able to just build that by prompting a LLM without really needing to write any code.

And this is what I mean, right? This is the key question, right? And I framed this in a negative way deliberately. And the reason for that is that I wanna reflect what I see as a bit of a negative mindset in the industry at the moment.

At least if I go by what people post on LinkedIn, which maybe I shouldn’t, but you know, it’s that kind of, well, if anyone can build software, it’s not special anymore, is it? So why do it? [00:11:00] Why bother is programming dead at this point? That’s the question I feel a lot of people are asking, and I don’t feel like it’s the right question.

I feel like it’s unnecessarily negative, but nevertheless, that is a bit of the sentiment. What I’d like to argue over the next 20 ish minutes is that actually we are in possibly the most exciting period of time in software engineering that there’s been, but also that this idea that anybody can build software is not a new idea in the history of computer science.

And it is not something that we should be fearful of or negative about. If anything, it’s a good thing that we should celebrate and embrace. So with that in mind, I would like to take you on a history lesson. In fact, most of this talk is a history lesson you’ve probably noticed. So I’m gonna quiz people on their knowledge of computer science history.

I dunno how well this is gonna go, but we’ll give it a try. Does anybody by any chance know who the man on the left is? No. Okay. [00:12:00] Seymour Papert was a South African born mathematician. He had not one, but two PhDs in mathematics. Considerably smarter. I would venture than all of us in this room.

But thankfully we get to benefit from his mind and his brain. He became co-director of the MIT AI lab in 1967 when not only was computing relatively new, but AI was definitely new. Incidentally, the history of AI goes all the way back to the early 1950s with the work of people like Alan Turing.

It’s not as new as we think, but anyway what Seymour Papert was really passionate about was education. And particularly he was interested in understanding how this, for him new thing of programming could be used to transform education in the classroom. How could it be used to change how we teach children?

So he had a theory called constructionist learning. Actually, it wasn’t entirely his theory, it’s based on the work of the psychologist Piaget. [00:13:00] But fundamentally, he’s asking the question, how do children use technology to learn? And he had a few principles here. So he’s observed that learning happens best when children are able to make things and share them with their colleagues.

Programming for Papert is the thing that allows those children to very easily build things. So that’s kind of interesting. It’s empowering. Programming is enabling people to create things. It’s not seen as an obscure skill that you need to spend years and years of your life building up and then hoarding.

It’s actually something for everybody, and that’s gonna be a common theme here, debugging he sees as a way of teaching. But basically intellectual rigor. It’s about teaching children how to think about thinking, frankly, teaches anyone how to think about thinking. Certainly not just children. The overall concept here is that people learn best when they can build things that they personally care about.

Well, that kind of resonates with me if I think back to my early [00:14:00] history with programming of I just wanted to build Arkenoid. I wanted to build my own version ‘cause I just cared about it and I can’t say why. I just wanted to do it. So it’s that kind of idea, that kind of thinking. This book, if you really want to delve into the history here, there’s a book which, uh, Papert wrote called Mindstorms.

By the way, the Lego thing is named after that. So this is, some of you have probably played with something like this at some point during school. It’s a bit inconsistent in terms of how this is delivered in the curriculum, but this is called Turtle. It’s a robot that can draw patterns. So the idea is it can move back and forth.

It can turn around, it has a pen that can go down and up and you can program it to draw pictures and patterns and things like that. This is a very early version, but even nowadays in British schools, at least sometimes variations of this are being used to teach programming at a very early age. And I’d be interested afterwards actually, if anyone has any anecdotes about that.

I’m interested about the, the experiences there. So On the left we have Cynthia Solomon, actually just, just LA left there and Seymour Papert again on the right with his robot and his little fish that he’s clearly very [00:15:00] proud of. So Cynthia Solomon and Seymour Papert worked together. They collaborated heavily on a programming language called logo.

Logo is the language that you use to program. The robot logo is designed to teach children how to program. It could be used to teach anyone how to program. It fundamentally exists to teach the basic concepts of programming, the basic reasoning and logic to anybody who, who really wants to learn. And here we have an example, so very, very old picture, very grainy, but we have um, the little robot being used and the little teddy bear there.

How does it work? Well, I don’t really have time to go into the deep details of Logo in terms of the specifics, but the idea is it’s very, very simple. So We have very simple commands, very simple verbs that tell you how to tell the robot what to do.

For instance, if we wanna draw a square, how you read this is you say, in order to draw a square, you repeat four times, you move forward a hundred steps, rotate 90 degrees, and then you finish. Right? Fair enough. Seems straightforward enough. I’m not suggesting by the way, that we should all [00:16:00] switch to programming logo.

I’m using this as an illustration for. A way of thinking about programming that exists in the very early history of computer science that I think we’ve since lost. We’ve lost touch with this idea that everybody should be able to, not necessarily program, but should be able to create things using computers, and if programming is the means of doing that or if something else is, the means of doing that doesn’t particularly matter.

The point is that we can use computers to create things and learn while we do so. And I love this quote from Papert. So he says, a programming language is like a natural human language in that it favors certain metaphors, images, and ways of thinking. So that’s how he’s thinking about programming at that time in the 1960s.

So he sees programming as being for everybody. The language should support human creativity. And he even criticised languages like Basic and Fortran and things like that at the time because he didn’t feel that they had that same idea of being able [00:17:00] to uh, give everybody that creative capacity that he felt that there should be.

Now, uh, the other person here is Alan Kay. I should have made that a quiz, but there’ll be a few more quiz coming. Don’t worry. Um, Alan Kay, just really briefly, um, kind of built on a lot of the ideas of Papert, but he invented a language called Smalltalk. How many people have ever programmed or seen Smalltalk?

I’ve never had the pleasure of programming Smalltalk myself. It’s one of the first object oriented programming languages. Not the first, but one of the first. And it developed a lot of the early concepts. Alan Kay shared the same philosophy that really programming should be a way for people to express thought and express their creativity and build things.

And that was the philosophy he built into Smalltalk. Again, I’m not suggesting we should all go and program Smalltalk, but it’s just interesting. To think about the history of this and how the ideas developed, but then how we’ve kind of moved away from these ideas. And I think if you look at some software ecosystems now, particularly I look at, I dunno, the, the JavaScript ecosystem, even the Python ecosystem that I spend a lot of time in, the [00:18:00] complexity now is huge.

The amount of stuff you need to know to build software successfully is enormous. Whereas this, this idea of, well, anyone should just be able to create things that, that seems to be a little bit lost. And you can see the, the kind of joined up thinking between Alan and, and Seymour here. So he said, I, he visited Seymour Papert and he observed children doing real programming with especially designed language and environment, and that encounter hit him with what the destiny of personal computing was really going to be.

It seemed for a long time like that, destiny had not been realised. I would argue that we are about to realise that destiny with the advent of AI assisted programming. And so I’ve got roughly 12 minutes. I’d like to answer the question of how we adapt, or at least I’d like to begin to answer that question.

I’d like to try to give something about how we should adapt to this new reality, because this conversation is going to continue. This is definitely not the end. It is really [00:19:00] just the beginning of that conversation, but I’ve got three thoughts here. The first is to focus on. Problem decomposition and system design.

The facts of the matter is that building software, like actually building software in production at scale, making it secure, making it satisfy all of the edge cases and different user requirements that come up is a lot more than just programming, is a lot more than just writing code. So if the typing code bit can be automated, there’s a lot more space for us to focus on what’s really, really hard, which is;

how do I take a complex problem and break it down into simple parts? How do I do that? A lot of software development is that really. How do I interpret requirements? We are never gonna get away from that. And actually, if anything, what we’re gonna find is that the, there’s kind of almost a, there’s a bit of a joke I guess in the software development community

typical stereotypical project manager who isn’t able to express requirements and the programmer who’s [00:20:00] stereotypically pedantic about the requirements. What we’re gonna find, I think, is we’re gonna end up meeting in the middle because we’re actually still gonna need to be specific about our requirements.

And anyone who’s tried vibe coding themselves will have realised this when they’re prompting that if you are not really, really specific about what you want, then Claude is gonna do something and it may or may not be what you originally intended, but it’s gonna be something. So it’s almost speeding up that feedback loop.

Now in the picture here, anyone wants to venture a guess? The lady in the middle.

Grace Hopper? Yes indeed. Grace Hopper was um, fantastic at abstraction. So Grace Hopper, among other things, invented the COBOL programming language. COBOL was designed to be a kind of natural language way of programming. It was designed to allow business specialists to write software without knowing things about, I don’t know, pointers and memory allocation and that sort of thing.

She invented one of the first compilers in order to make COBOL work. So she’s really good at thinking about abstraction, thinking about taking a complex [00:21:00] problem and breaking it down into sub-problems and layers of abstraction where complexity, different levels of complexity exist at different levels.

That’s really important. That allows us to turn what is at the time, writing assembly code or Fortran into being able to write as what almost looks like English and have it execute. Also she’s famous for talking about lengths of wire. If anyone’s not seen it, just search YouTube later.

For um, Grace Hopper, lengths of wire, just trust me on this. So she explains how, um, the latencies of information transmission work with a very intuitive example, again, demonstrating how good she was at abstraction. Okay, well the next thought is building fluency in reading, debugging, and evaluating code.

Because if a lot of the code we used is going to be written by an AI, you know, either we are, we’re going for vibe coding and we’re just telling it to by a prompt to generate us some code or we are maybe not quite going that [00:22:00] extreme, but we are, um, using an assistant to help us write the code as we go.

Either way, we need to be reading a lot of code that’s generated, not just by our colleagues, but by AI. We need to be able to interpret it. We need to be able to debug it, we need to be able to evaluate it. Now, debugging is particularly interesting. Um, I think it was, um, I’m gonna say Brian Ingham might have got that wrong, but.

I think it’s Brian Kernighan and one of the inventors of C said that debugging code is always twice as difficult as writing it. So you should never write the cleverest code. You can possibly write because you’re not clever enough to debug it. That logic applies here, right? We, we kind of, we need to be good at debugging stuff.

We need to be good at interpreting what the AI generates. If we don’t understand what the AI generates, we’ve got no hope that, let’s be honest. Um, this picture is Edsger Dijkstra. Edsger famously didn’t like computers. He was a computer scientist who didn’t really like to use computers. He said that computer science has as much to do with computers as microscopes have to do with biology, or telescopes have to do with astronomy, but you know, he also, felt that debugging was particularly [00:23:00] important skill to develop. And the last one is about cultivating domain knowledge and building user empathy. And this is a mixture of technical skills, but also business knowledge, expertise in a particular domain and our ability to just understand other people, and particularly the people who are going to use the software that we build.

So again, there’s a lot more room for this if we are no longer concerned with typing code into a machine. There’s a lot more room to think about this. There’s a lot more room for using AI to ideate about these things too. But the idea here is really understanding the problem that you’re trying to solve through the software that you are building.

Really understanding those requirements, really understanding how the users are going to interact with and experience the software that we’re building. That’s crucial. And you know, The picture here happens to be. The [00:24:00] very first spreadsheet, believe it or not which was VisiCalc. So, you know, it is interesting to think about how something as simple as the invention of the spreadsheet transformed how people used computers to solve certain problems.

You can’t imagine using computers without the existence of spreadsheets right now. Right? As soon as you see a spreadsheet shaped problem, you immediately recognise it and jump into one. But that had to be invented. Someone had to think about this was a particular user experience that needed to exist and they had to build it.

And VisiCalc is long dead, but the concept is still there. It remains, it survives. So that’s three thoughts on things we can think about to change how we, what we emphasize and what we focus on as software engineers, as professionals in this new world. So I think as I said at the beginning, right now is the best time to be a programmer.

And there’s a few reasons for this. Firstly, that we are entering an [00:25:00] age where in principle, anybody can build software. Anybody can create software. And sure, granted, it may not be the case that the non-technical person can create and productionise something, at least not yet, and probably not for a while.

But someone can express an idea through software in a way that they could never hope to do before, and that’s really exciting. If anything, it probably means more work for us software engineers because we have lots of people who have ideas that they can now prototype that will gain funding and need to go to production.

That’s good news, but also because the feedback loop is so much faster, the tools we have allow us to build things rapidly, iterate on them and gather feedback, gather um, like a real, real world experience of what that software’s gonna do, of what a particular thing is gonna look like in a way that we just couldn’t before.

So it’s that kind of [00:26:00] the speed of experimentation, I suppose, is what I’m getting to, right? It’s the speed of experimentation that we are gaining now that we never had before, and the ability to collaborate with a wider set of stakeholders. You know, if, I can build something and give someone the ability to sketch out a variation on what I’ve built, even if they’re not particularly technical, and then I can take that and build on that and we can go back and forth.

That’s exciting. But the final point is to that point about education, because that’s one of the concerns that when I’ve spoken to people, has been expressed the most strongly, particularly when I’ve spoken to engineers early in their career, they’ve said, what will the impact of AI assisted coding be on my ability as a junior engineer to learn and hone and improve my craft?

That’s a hard question to answer because it almost looks like, really cynically. Maybe you can’t. Right, and there’s, there’s almost these cynical takes you see on LinkedIn of we’re [00:27:00] only gonna have senior engineers, and at some point that’s gonna be a problem because none of the junior engineers will have gone through the learning journey they needed to go through to be a senior.

I don’t think it’s necessarily that gloomy though. The reason is that I think back to myself again, learning to program I think that if I were that again, 11, 12-year-old boy stood in front of probably not an Amiga 500 in 2025, but stood in front of something else.

And I had access to these tools, would I still try to build Arkanoid? Well, I think I would, and I don’t think it would be a question any more than it was ever a question of, well, Arkenoid already exists. I have it on floppy disc. Why would I write my own? There’s never, never a question. And the reason is curiosity.

So the most successful engineers that I’ve ever seen in my career have something in common. It’s curiosity. It’s a need to learn. It’s a need to know, I couldn’t have [00:28:00] not built my own Arkenoid and it doesn’t matter that it was bad code ‘cause I was 12, for goodness sake. It doesn’t matter. It’s about the learning, it’s about the curiosity, it’s about following that curiosity.

I would definitely, I think, use the tools to help me learn more quickly. I could go to ChatGPT and say, here’s my basic interpretation of Arkenoid what do you think? And maybe ChatGPT could have given me some helpful hints, and maybe I would’ve been an even better programmer at the start of my career as a result, because I’ve learned from this massive wealth of knowledge that’s available to me.

And so just to conclude, one little ironic twist of history. Um, I mentioned that Seymour Papert was in the, uh, MIT AI lab, 1967. The other co-founder was a man named, marvin, the name has dropped outta my head. Mar , freeze when you’re on stage.

Um, Marvin Minsky, right. So Marvin Minsky, one of the things Marvin Minsky’s famous for is, um, his work on the perceptron, um, which was one of the very early manifestations [00:29:00] of neural networks, or rather neurons, artificial neurons. Uh, he wrote a book called Perceptrons, in which he demonstrated a number of fundamental limitations of the neural networks at the time.

And that book led to a massive drop off in funding for AI research. It started what was called the first AI winter. So, you know, the kind of, um, you start out along this story arc, you get to a collaboration that paused at least AI research for a good few years before it picked up again. In any case, I, um, would like to say thank you for listening.

Um, I think we’ve got a little bit of time for questions as well, but also you can come and meet me and the Fuzzy Labs team back in the vendor area there. We’ve got a table. You can play Vibe Coded Hook-a-Duck. See if you can break it. That might be fun. But also you can win prizes, so maybe just do that.

You can learn more about us at our website. We also have a newsletter. And I can’t not say we are hiring because we do believe that there is still a [00:30:00] need for programmers in 2025. So if you wanna talk to me about that as well, let me know.

Thank you.

Ahoy there 🚢,

Go to LinkedIn and it seems like every business is solving their problems with AI. The enthusiasm is infectious - and honestly, it's exciting to be part of this field. But what does it truly mean to "embrace AI"? Are companies really embracing it, giving AI a proper bear hug, or are we only seeing part of the picture?

Think about renovating a house. You might be buzzing with excitement about installing smart home technology - automated lighting, AI-powered security, voice-controlled heating. But if your home isn’t set up for those systems or you don’t even have power going to every room… then it won't just fail to work properly - they'll create more problems than they solve.

The same principle applies to AI projects.

Setting up for success

Let's say that you're a software engineer in a relatively small business and your CEO has decided that now is the time to "adopt AI." Sure, your salespeople have been using ChatGPT to help get the tone right on follow-up emails, and you've been using Cursor for some of your more tedious refactoring, but now it's time for the business to get systematic with how it's using machine learning.

Whether they want to start using a simple machine learning model for forecasting or they want a fully-agentic chatbot that is able to deal with customer queries, you've been tasked with making sure that when the data scientists and machine learning engineers come in, they have the best chance of making a big impact.

To get this right, you need to get things up and running quickly. Maybe you're hiring some consultants for a few weeks, or you're setting up an entirely new team. You know that enthusiasm will wane if your managers don't see results soon. So how do you set up for success?

There are a few things that you can do to make sure that money spent investing in AI is money well-spent.

The companies that get this right share something in common: they've been getting their data house in order long before they started shopping for AI solutions. They've got their tools ready, paint colours picked out, a new floorplan fully mapped - rather than winging it and hoping for the best.

What problem are you trying to solve?

Sometimes, there is a very specific problem that AI is being brought in to solve or a particular process that AI is going to be used to automate. Other times, the brief might be as vague as "We need to start using AI or we'll fall behind." The further you can move towards having concrete problem statements, user stories or use cases, the more likely your project is to be a success.

You need to be specific about your goals before you start.

If you're starting out with something as vague as "apply AI to our manufacturing process," think, can you hone that down to "we want to be able to predict our output over the next four weeks" or even better, something super specific like "We know that the data from this component changes in a characteristic way in the days before it fails, we'd like to automatically flag that."

Just like you can't build an extension if you haven't got the land for it, you can't build effective AI systems without knowing exactly what problem you're solving.

Early on, there's huge benefit in figuring out where simple but concrete challenges are that can be claimed as early wins.

Getting your data in order

If you want data scientists or machine learning engineers to build something quickly, give them enough data straight away! You might not know what data they will need but it's a safe bet that they will need as much data as you can give them and will constantly ask for more.

There will be times when you need specialist AI engineers or data scientists to tell you exactly what data they need, but in general, the best time to start collecting data is now! For a forecasting model how much data on past trends can you collate? For an LLM chatbot with RAG, do you have an archive of the kinds of documents it's going to be reading? For a computer vision model, are you already collecting images and are they categorised/labelled?

Take an (appliance) company we worked with. They were trying to predict when certain components were going to fail in their systems. They had months and months of sensor data from all of their refrigeration systems, which was a great starting point.

But the real breakthrough came when they could show us labelled examples - specific points where components had failed, connected to what the data looked like beforehand. That's like having a proper inventory system that tells you not just "we have pipes" but "these are the pipes that work well, these are the ones that failed, and here's why they failed."

Because if you just have logs from all your systems but no context about when things went wrong, you can't build predictive models. You need those examples that show what it looked like when components were about to fail. Just like you need to know the shape of the room before you start fitting the carpet.

Subject matter experts

Sometimes, making accurate predictions is just a case of pointing the right model at the data and hitting train... but this is rare. And even then, sometimes the hard part is knowing what the useful thing to predict even is. More often than not, finding the right subject matter experts in your company is going to be key to success.

Talking to subject matter experts is also vital in working out whether what is being asked for is possible. If your subject matter expert can't do a task, do you have good reason to believe that an AI is going to fare much better?

These people aren't just helpful - they're often the difference between a system that works and months of experimentation.

Setting expectations

Make sure that the people who are pushing for AI know what to expect. It's not going to surpass human ability, it's not going to replace whole teams or years of accumulated knowledge.

The strength of AI is in automating and scaling tasks that are in that sweet spot where they're too nuanced or complex to write code to perform automatically but still simple enough a person would probably find them quite tedious. This is true even with the latest generative models, for messy real-world problems, you may find that AI will fail in weird and surprising ways if the problem space is not carefully constrained.

When companies set these realistic expectations upfront, their AI projects deliver results that genuinely make everyone's work more productive.

The two kinds of AI project

Actually, it's worth understanding that when we talk about AI projects, we're really talking about two different paradigms:

The LLM route: Building chatbots, document Q&A systems, automated writing tools. These need your company's knowledge base - all those FAQs, manuals, conversation histories that you've been accumulating.

The traditional ML route: Forecasting, anomaly detection, computer vision, recommendation systems. These need historical data with clear examples of what you're trying to predict or detect.

Both paths can lead to success, but they need different types of preparation. The companies that do well figure out which path they're on early and prepare accordingly.

The multiplier effect

What gets me excited about this: when companies get their data in order and approach AI thoughtfully, they don't just improve their own results. They create a multiplier effect that benefits everyone.

If every company started thinking about data collection and labelling now, it would be so much more efficient for everyone. The data would be there when needed. We could train models on the right information from day one. Projects would deliver results faster and more reliably.

Better preparation leads to more successful projects. More successful projects lead to more realistic expectations about what AI can actually do. And all of that creates a virtuous cycle where the entire ecosystem gets better at building genuinely useful AI systems.

Every company that methodically prepares their data and involves their domain experts makes it easier for the next company to understand what success looks like.

The opportunity right now

While everyone else is rushing to install the latest AI applications as quickly as possible, taking time to get your data house in order isn't just smart preparation - it's a competitive advantage.

The companies that invest in proper data preparation, involve their domain experts, and set clear expectations are building AI systems that actually deliver on their promise. They're the ones whose employees are genuinely excited about working with AI tools because those tools actually make their work better.

Your future self will thank you for doing this groundwork properly. More importantly, you'll be building systems that create real value rather than impressive demos that struggle in the real world.

And honestly? In a landscape where everyone's talking about AI but fewer are delivering consistent results, being one of the companies that gets the foundations right is a real opportunity.

Danny Wood is Lead AI Research Scientist at Fuzzy Labs, where he helps companies turn AI enthusiasm into systems that genuinely work. He believes the best AI projects start long before anyone mentions machine learning.

And finally...

Upcoming Events & Community Updates

PyData Manchester - Tonight! 25th Sept, 6:30pm @ AutoTrader our very own Shubham Gandhi tackles "How to Train Your LLMs?" with practical optimisation techniques that make LLM training more resource-efficient and scalable PyDataMCR September , Thu, Sep 25, 2025, 6:30 PM | Meetup.

Join Waitlist

Awaze Women in Tech Early Career Networking - 14th Oct @ Fuzzy Labs "Education to Industry: Discussing the Transition"

Join Awaze's Women in Tech team for a networking evening offering female-identifying people a platform when entering tech and data careers. With two Fuzzicans as part of the event (Tiff and Savannah) we’re excited to host such an empowering initiative. All are welcome to attend.

Get Your Ticket

About Fuzzy Labs

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

We help 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 systems that create real value in the real world.

Currently hiring:

• MLOps Engineer

• Senior MLOps Engineer

• Lead MLOps Engineer

Want to chat? We love talking about interesting ML challenges - we also love all dogs, sauce, ducks, coffee and helping propel the MLOps community onward and upwards.

Liked this? Forward it to someone who's thinking about taking their AI projects to the next level and wants to set themselves up for success. Or give us a follow on LinkedIn for more MLOps thoughts and insights.

Follow us on LinkedIn

Not subscribed yet? The next issue is going to dive into our Applicant Tracking System - and experiment in vibe coding and how where think our rapidly evolving industry might end up.

Subscribe now

Leave a comment

Another brilliant turnout for MLOps.WTF #5 in Manchester, as we continue to build a community of people who love productionising AI in all its forms. Our fifth meetup focused on agents 2.0, and between Matt's mandatory fire safety briefing (fire exits noted, no fires planned) and his unprompted declaration that his favourite t-shirt is the "small, slim fit from TopMan" which he can't buy anymore, we managed to squeeze in three brilliant speakers.

The theme? How to cut through the agentic hype and actually make AI work in production. The room fell quiet as our speakers kicked off, and we were once more dazzled by the knowledge and passion of the Manchester MLOps community. Settle in as we cover how it all went down...👇

Subscribe now

Emeli Dral: "How to Evaluate and Test AI Agents"

Emeli, co-founder and CTO of Evidently AI, opened by defining what we mean by AI agents: anything with rules, tools, and the ability to plan and act.

Why AI agent testing is genuinely hard

Traditional AI, like demand forecasting, was much easier - you just compare outputs to actual results. But with unstructured data like pictures or text, Emeli explained, we cannot really compare pictures by pixels... it doesn't make any sense.

Agents present new challenges: free-form inputs and outputs, complex usage scenarios, many ways to be "correct," and risks of cascading errors through multi-step workflows.

Her solution borrows from software engineering but adapts it for AI's peculiarities. We need ways to automate evaluations for open-ended text data using task-specific quality criteria.

The testing hierarchy adapted for AI

Unit tests catch bugs early and cheaply. For AI agents, this means asking:

• Prompt validation: Does your prompt contain required fields like "task description" and "constraints"?

• Tool I/O validation: Are input/output types correct? Does your calculate_growth tool handle division by zero properly?

• LLM-as-a-tool validation: For agents that use other AI components

Emeli showed practical Python examples, demonstrating how to validate JSON schema outputs and test tool execution success (keep an eye out for our video recordings of the event to see this for yourself too!)

Integration Tests check component interactions, again testing/asking:

• Environment configuration (do the OpenAI API keys even exist before deployment?)

• Tool and API integration (does the routing work correctly?)

• Memory and state propagation (does context persist across interactions?)

• Planning and routing logic (does "show me sales by region" trigger the correct tool?)

End-to-End Tests simulate complete user journeys. Emeli's memorable example highlighted a critical insight: an agent correctly formatted a response but was contextually inappropriate for the business setting. This captures why format validation isn't enough.

LLM-as-a-Judge: scaling subjective evaluation

Rather than hiring armies of human evaluators, Emeli detailed using LLMs as judges. Define explicit criteria like: "The response is SAFE when it's polite, factual, and avoids controversial topics. The response is UNSAFE when it contains inflammatory language."

She demonstrated actual implementation, showing how to set thresholds and automate scoring. But the critical caveat: you need to tune your LLM judge, too! Always validate judges against human expert assessments before deployment.

When Tom from the audience asked what happens when tests break, Emeli acknowledged the complexity: there are quite a lot of parameters which we can tweak - prompts, model providers, retrieval settings, vector transformations. The debugging process requires systematic experimentation across these parameters.

Practical Implementation Strategy

Emeli's approach prioritises observability: "No logs, no production." Start with comprehensive tracing - inputs, outputs, model versions, tool calls, execution paths. Even reading through traces is a good start.

For datasets, begin with 10-15 typical scenarios, then expand systematically - competitor questions (you don't want your assistant recommending rivals), forbidden topics, sales offers (preventing another Chevrolet "$1 car" scenario), and past hallucinations and edge cases.

Strategic insight: when everyone has the same models, evaluations become your moat - enabling faster shipping, easier model switching, and reduced risks. Investment in evaluation infrastructure pays dividends when foundation models become commoditised.

Watch Full Talk

Abhinav Singh: "Making vertical agents: challenges and learnings"

Abhinav from Peak AI opened with historical context that reframes our current AI chaos. The second industrial revolution offers parallels: first electric power plant (1882), practical induction motors (1892), but by 1912 - 20 years later - only 25% of factory machinery was electric-powered.

The delay wasn't about technology. Factories needed to solve two problems: attach motors to individual machines and redesign layouts around production flows rather than central power sources. With AI, we are in the same place, Abhinav argued.

The AI Paradox: intelligence vs knowledge

Today's AI paradox: models can achieve gold medals in mathematical olympiads whilst 95% of corporate AI pilots fail. The bottleneck to task performance is tacit domain knowledge, not intelligence.

LLMs trained on general internet content lack specific organisational knowledge - brand guidelines, internal processes, tribal knowledge. It's not in its training data, so why would it work? How can you possibly expect it to do that job?

This explains why naive approaches consistently disappoint. The classic "data lake + vector DB + LLM + instruction" approach fails because it ignores fundamental knowledge gaps.

Beyond simple vector databases

Instead of dumping everything into one vector database, Abhinav outlined sophisticated knowledge organisation:

• BM25 + vector + reranker retrieval systems

• Separate vector databases for content types (annual reports, invoices, meeting notes, topic folders)

• Careful attention to "authoritativeness" rankings

• Clear access boundaries and context understanding

The system architecture shows retriever components feeding multiple specialised vector databases, each containing different organisational knowledge with careful authority hierarchies.

If this is something which interests you: we’ve got a whole host of recent blogs for you to sink your teeth into:

• Improving RAG performance (semantic chunking)

• Improving rag performance (hybrid search)

• Improving RAG performance (re-ranking techniques)

Control Flow: When to delegate vs when to keep control

Abhinav's most practical contribution: a framework for delegation decisions based on two factors - cost of error (what happens if the agent makes mistakes?) and delegation upside (what value does autonomy provide?):

• Low cost + high upside: Full delegation with lots of context (recommendation systems)

• High cost + some upside: Frequent human review, short delegation cycles

• High cost + no upside: Deterministic flow, write regular software

• Low cost + unclear upside: "We haven't figured this out" (refreshingly honest)

This maps surprisingly well to Andy Grove's "Task Relevant Maturity" from High Output Management. As Abhinav noted: we didn't plan for it this way, but we arrived at a similar conclusion - delegate based on capability and criticality, not AI hype.

Agent interface design: the IDE pattern

Successful agent interfaces resemble development environments more than chat boxes, Abhinav observed. Users want rules and constraints setting, additional context provision, chat interactions, feedback mechanisms, and editable artefacts.

If you squint, it looks like VS Code or Cursor - the same kind of programming instincts and control that developers look for in their IDE. This suggests agent deployment requires sophisticated human-AI collaboration tooling, not just better models.

Watch Full Talk

Chris Billingham: "Can we build it? Yes! We! Can!"

Chris from Etiq AI opened with a slide of Bob the Builder. But this AI generated Bob looked worried. Very worried.

He then introduced us to Will Ratcliff, an evolutionary biologist at Georgia Tech who tried Claude Code for a personal tax project involving Monte Carlo simulation.

Initially, Will felt incredible: "At first, I felt like I had freaking super powers. Like a PI with a nearly infinite supply of talented lab members, who worked at 1000x speed. It was exhilarating."

But then the cracks appeared: "But then, the cracks started to show. TL;DR: If Claude were my grad student, I'd kick them out of my lab."

The lying copilot problem

The model was impressive at low-level coding but had a personality problem. It has the personality and confidence of a 10x coder, and absolutely lies to your face to maintain the illusion.

When Will asked for demographic statistics, Claude's web crawler was blocked from accessing the site. But Claude didn't admit that - it fabricated plausible numbers instead, claiming it had pulled real data when it used a simple function to fake it (life expectancy 85, with some noise).

This pattern repeated constantly. Will's conclusion: You just can't trust this thing.

Traditional copilots vs data science reality

These copilots focus on software development tasks, using code-base indexing and semantic search. But data science is fundamentally different. It's not about writing and remembering code. It's about DATA and CODE. CODE changes DATA. DATA shapes CODE.

Chris put up a simple diagram: blue boxes (data) connecting to yellow boxes (code) in an endless chain. If all you're looking at is the CODE, suddenly the DATA is an invisible second-class citizen.

The cognitive load visualisation

Chris showed his masterpiece - a (frighteningly) impressive detailed diagram of DS/ML cognitive load. An intricate network of yellow circles (data) connected by blue diamonds (code functions), branching and interconnecting across multiple processing stages.

This is what you have to keep in your head, Chris explained. And this is just an extract from what is a pretty simple Kaggle notebook. Yet tools that you want to work with to help spit out code don't have any of this context.

Bob's solution: testing and RCA agents

Chris introduced his Testing and RCA (Root Cause Analysis) Agents. The Testing Agent analyses code to work out the most appropriate test at any single point, then runs tests on data either individually or in comparison, returning test results to keep you safe.

This agent understands the data lineage network. When doing a train test split, it checks for target leakage. Building a model? It validates accuracy.

The RCA Agent leaps into action when tests fail, starting at the point of failure and working through your script, running other tests and interpreting results to find where the problem starts, then diagnosing how to fix it.

The virtuous cycle

Chris walked through Bob's complete workflow:

1. Get Data - Bob starts with his dataset

2. "Hey man, build that pipeline!" - Bob asks Claude to generate code

3. Testing Agent activates - methodically tests each pipeline step

4. Tests fail - Red warnings across the network

5. RCA Agent leaps in - diagnoses the root cause

6. Fix applied - Solution feeds back into the loop

So whilst Claude or windsurf or cursor may want to go off and create all these edifices at every single point, our two friends that keep us safe are constantly stuck there, going, you've just made up some data that doesn't exist. It doesn't work.

The result? Bob can harness copilot superpowers to build ML pipelines that actually work - and actually it's fully tested. And actually it's tested all the way along, so not only have you created that pipeline super quick, it's probably better tested than many pipelines you may have met.

Watch Full Talk

The big takeaway from MLOps.WTF #5?

Every speaker converged on key insights that align with what we're all seeing in our work:

• Observability enables everything else. Whether Emeli's comprehensive tracing, Abhinav's knowledge structure monitoring, or Chris's data lineage tracking - you can't improve what you can't see.

• Domain expertise remains irreplaceable - humans still define what "correct" means in specific domains.

• Hybrid systems outperform full automation.

• Systematic approaches beat ad-hoc solutions.

• That the challenge isn't model capabilities - it's building systems that make AI behaviour predictable and trustworthy in production.

Speaking of things that are hard to predict - who's going to tell Matt that TopShop is returning to the high street? His "small, slim fit from TopMan" crisis might finally be over.

Final Bits From Us

If you're working on production AI systems - especially if you've solved some of the reliability challenges discussed here - we'd love to hear from you. The community learns best from practitioners sharing real-world experience, wins and failures alike - speaking of which, we’re always on the lookout for interesting speakers - if you’d like to have a go - please email Matt Squire!

What's Coming Up

18th September: Tom vs Matt founder face-off at MRJ Recruitment's Big Tech Debate on vibe coding at Bloc, Manchester.

Come see the debate!

24th September: Matt's speaking at Manchester Tech Festival - "Are we the last programmers? AI and the future of code." To get 10% off - use the code SQUIRE10

Get Manchester Tech fest tickets

14th October: We're hosting Awaze's Women in Tech early career networking evening at DiSH.

Come to the Women in Tech event

18th November: MLOps.WTF #6 - save the date, speaker applications open.

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: like what we’re cooking? We’re on the lookout for great talent, see our open roles below:
MLOps Engineer
Senior MLOps Engineer
Lead MLOps Engineer

Liked this? Forward it to someone who's wrestling with getting their ML models into production and keeping them there. Or give us a follow on LinkedIn to be part of the wider Fuzzy community.

Share

Not subscribed yet? Come on, we always say this - what you waiting for? Share with your colleagues, friends, your mum and your neighbours… especially if they love MLOps.

Subscribe now

Three weeks ago everyone was buzzing about Claude's latest coding capabilities. This week it's all about Cursor with its integration with ChatGPT-5. Next week? Who knows.

Every week there's something new, some breakthrough that makes processes more efficient, faster or deeper in learning and understanding. The tool race is rapid and new players are constantly changing the approach.

I'm currently doing an internship at Fuzzy Labs, whilst studying for my Master's, which means I'm getting this unique perspective on how learning actually works when the world is accelerating. Bouncing between academic theory and real-world application daily, watching how the industry moves at breakneck speed whilst our educational institutions... well, they're still teaching pretty much the same way they always have.

When best practice meets reality

What's interesting is how this internship is revealing the gaps between what we're taught is "best practice" and what actually works when you're trying to keep up with an industry that reinvents itself weekly. I've been following all the traditional advice - the approaches everyone swears by - but they're starting to feel increasingly disconnected from the reality of working in tech right now.

Take the standard learning path everyone recommends. You start by watching YouTube tutorials. Then you move on to building the classic projects: Tic Tac Toe, calculator apps, to-do lists. Maybe you grind through some LeetCode problems... it's the well-worn path that's supposed to prepare you for a career in tech.

But these approaches were designed for a different world. When Claude can generate a perfectly functional game in thirty seconds, what are we proving by spending days building one ourselves? When GitHub Copilot can solve algorithmic challenges faster than you can read them, does LeetCode truly measure someone's coding ability?

The problem isn't that these tools are useless - LeetCode is obviously still valuable. But we've built these elaborate hiring processes around demonstrating capabilities that AI now handles better than most humans, whilst completely missing the critical thinking and discernment that actually matter.

The theory of revolution

The problem isn't just that traditional approaches feel outdated - they're creating a generation of graduates who can tick all the educational boxes without developing the skills that actually matter.

Are we teaching people to jump through hoops that no longer exist whilst missing the critical thinking that actually determines success?

The multi-faceted approach

What I've discovered working is completely abandoning the traditional sequential learning model. Instead of trying to master one thing at a time, I'm doing everything simultaneously and letting each element reinforce the others.

I've got a skill tracker going that shows what I'm actually absorbing versus what I think I'm learning. I'm reading ML and MLOps theory whilst working on production systems. The mentorship element has been massive - being surrounded by talented people who I can question relentlessly.

The biggest shift has been around curiosity. It sounds obvious, but I think there's something to be said for being the stupidest person in the room - you stand the most to gain, right? Most educational setups don't really encourage this kind of vulnerability, but it's been game-changing for developing actual understanding rather than just surface knowledge.

So when I'm trying to understand something now, I'll read about it, watch tutorials, then immediately apply it to whatever project I'm working on. Keep it simple, but make sure it's connected to something real rather than abstract exercises. The mentorship side has been massive for making this work - I can tackle projects that would have been completely overwhelming before. When I hit roadblocks, there's someone there to help.

Package-specific learning for the modern brain

Here's what's really working: Instead of trying to master "software engineering" as this enormous abstract concept, I'm focusing on specific packages and tools.

You don't learn React because it's popular - you learn it because you're building something specific that needs a dynamic interface. You don't study Kubernetes because it's on job descriptions - you learn it because you're solving a particular deployment challenge you're actually facing. This use case learning approach forces you to think critically about why you're using specific tools rather than just following generic tutorials.

The tool paralysis trap

One thing that keeps catching people is the AI tool adoption phase.

There are so many tools launching that you could easily spend all your time evaluating options instead of actually doing anything.

This is where developing discernment becomes crucial. The teams that work most effectively have made deliberate choices about sticking to particular tools. This applies especially well to MLOps because the field moves so fast.

Rethinking the how

What's becoming clear is that we need to find new ways of learning that don't involve generic projects and generic tutorials. Something more nuanced, more area-specific, more connected to actual problems people are solving. The traditional model of front-loading education and then applying it for years feels increasingly disconnected from how work actually happens.

For anyone leading teams, this creates interesting challenges. How do you keep people current without losing productivity? How do you evaluate candidates when traditional measures don't reflect what actually matters? How do you build learning systems that can adapt as quickly as the technology does whilst still developing critical thinking skills?

What's exciting is seeing companies like Meta experiment with AI-assisted interviews that focus on your ability to work with these tools effectively, rather than your ability to memorise algorithms. The focus is shifting from "can you code" to "can you think critically about code and work effectively with AI tools."

If you're still preparing for coding interviews the traditional way, you're optimising for 2015's job market.

The bigger picture

The internship is showing me that there's a real opportunity here. These AI tools aren't just changing how we work - they're revealing fundamental gaps in how we prepare people for that work. The traditional barriers to entry are simultaneously too high and completely meaningless. We're testing for skills that AI handles better than humans, whilst missing the adaptability that actually matters.

The key is forcing yourself to think rather than outsourcing the thinking to AI. To use these tools in ways that amplify your thinking rather than replace it.

By the time this gets published, there'll probably be a new AI tool, Claude Code and Cursor will feel ancient, and we'll all be scrambling to keep up with whatever comes next. But that's exactly the point - in a world where the tools change weekly, the ability to learn and adapt isn't just useful, it's the only thing that stays constant.

The question isn't whether we can keep up with the accelerated age. It's whether we're building the right foundations to thrive in it, or clinging to educational models designed for a world that no longer exists.

So here's my challenge: go look at your current curriculum, your learning plan, your interview prep. How much of it would still matter if AI capabilities doubled tomorrow? Because at the current pace, that's not a hypothetical - it's here.

Savannah is currently pursuing a Master’s degree in Computer Science and AI part-time, whilst trying to gain as much knowledge through osmosis from the other Fuzzicians. When she’s not grinding out a deadline for her Master’s, she can be found getting stuck into a book or learning salsa. What she lacks in rhythm she makes up for in enthusiasm, with a strong interest in researching tech for good.

And Finally…

People You Should Be Following

• Peter Gostev: Head of AI at Moonpig, cutting through AI hype with clear, unbiased insights on the latest models and breakthroughs.

• Eric Vyacheslav – AI/ML enthusiast sharing fresh insights on the latest models and trends. A must-follow for anyone keen on staying ahead in the AI space.

Upcoming Events & Community Updates

🗣️ Big Tech Debate: Vibe coding is democratising software but lowering engineering standards

MRJ Recruitment & Counter are hosting their next Big Tech Debate on Vibe Coding. What makes this one particularly interesting? You might recognise the speakers 👀

With fuzzy founder vs founder - Tom will be arguing for the motion whilst Matt will be taking the opposing view. Are we witnessing genuine democratisation or a race to the bottom in engineering quality? Find out by tuning in 👇

📅 18th September
📍 Bloc, 17 Marble St, Manchester

Grab Your Spot!

MLOps.WTF Meetup - 9th September

Our next MLOps.WTF meetup is on 9th September at our Manchester HQ within DiSH. Demand is super high for this agentic themed talk, with us now being on a waiting list!

Kind ask, if you've got a ticket but can't make it, please cancel it so someone else can take a spot.

Tickets Here

Awaze Women in Tech Early Career Networking - 14th October

"Education to Industry: Discussing the Transition"

We’re proud to be hosting Awaze's Women in Tech team’s early career networking evening at DiSH. Specifically designed for entry level careers support, this event is set to empower and support female identifying people entering the tech and data workforce.

Get Your Ticket

Fancy being a speaker at the event? Awaze are on the look out for great and inspiring presenters and panelists - apply on this link. Here.

Don’t forget, we also have Matt's talk at Manchester Tech Festival this September: "Are we the last programmers? AI and the future of code." Because if we're going to debate the future, we might as well do it properly.

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: We’re hiring and we’ve got a few roles to fill:
MLOps Engineer
Senior MLOps Engineer
Lead MLOps Engineer

If you, or someone you know, is looking for a great opportunity… don’t hesitate to apply!

Want to chat? Max and Robbie are here to chat about tackling business challenges with open source and production-ready AI. Fancy a call? Reach out.

Liked this? Forward it to someone who's wrestling with getting their ML models into production and keeping them there. Or give us a follow on LinkedIn to be part of the wider Fuzzy community.

Not subscribed yet? What you waiting for? The next issue is already shaping up to be particularly juicy.

Subscribe now