HETT 2026 is soon approaching – The Digital Workforce’s NHS team will be attending the event in London on 29–30 September.

Our cancer pathway and diagnostics experts Jas Cartwright and Chris Sleight will also take the stage in the AI Spotlight- speaker spot to discuss how automation can streamline patient care and diagnostic pathways.

Between the two of them, they have spent over 60 years working in and around the NHS. Throughout their journeys, they’ve always reached the same conclusion. The biggest productivity gain doesn’t come from diagnostics itself, but from the workflow around it.

Roughly a quarter of patients are currently waiting more than six weeks for a diagnostic test, and the shortfall between testing capacity and rising demand has continued to widen year on year. We shouldn’t look at this only through a capacity lens, as it doesn’t paint the full picture. Patients are often waiting for information, scheduling and referral paperwork.

Streamlining patient care and patient pathways 

Frontline NHS teams know that timely diagnostic information is critical to effective patient care, but care pathways often span multiple teams, organisations and systems. 

We work closely with NHS organisations to map entire care pathways, identify operational friction and model the optimal workflow. Using automation, AI and process orchestration, we then translate the pathway into an integrated solution model that automates non-clinical work and provides end-to-end visibility of patient flow and each patient’s status. 

This means that routine diagnostic requests can move through the system seamlessly and quickly, reducing bottlenecks and speeding up patient test results.   

Importantly, for clinicians, it doesn’t add to their workload, freeing up more time for them to be with patients and focus on more complex cases.   

This is the fastest way to bring down diagnostic waiting times. It’s making sure the information, referrals and scheduling around that capacity move as fast as the testing itself.   

Digital Workforce HETT 2026 Highlights

• 29–30 September: Digital Workforce will showcase our work at HETT 2026, the UK’s leading digital health conference and exhibition.
• Stand H15: Discover how we help NHS organisations improve productivity through automation services, spanning the automation lifecycle and market-leading solutions for intelligent care pathways.
• Tuesday 29 September, 1:10–1:30 pm: Join our session ‘From Referral to Diagnosis: How Automation can Streamline Patient Care and Diagnostic Pathways’ in the AI Spotlight speaker spot.
• Session focus: Explore how an end-to-end approach to automation, AI and process orchestration can transform entire care pathways, not simply improve individual tasks in isolation.

Join us at HETT 2026 and don’t miss our AI Spotlight session.

Explore the full HETT 2026 programme and register on the website

Visit here if you would like to join our NHS Automation & AI Community Platform – a dedicated space for NHS teams to connect, share, and lead the future of digital transformation

Announcement September 18th: Digital Workforce HETT 2026 -our team is attending

The post The biggest productivity gain in diagnostics is in the workflows around it appeared first on Digital Workforce.

Automation has become a strategic priority across the NHS, yet many organisations still approach it as an IT project or a collection of point solutions. Through our work with more than 70 NHS organisations, we’ve seen that the greatest value comes when automation is treated as an organisational transformation— redesigning end-to-end processes to enable better ways of working.

To explore what successful transformation looks like in practice, we spoke with Andrew Raynes, former Chief Information Officer at Royal Papworth Hospital NHS Foundation Trust. With more than 25 years’ experience in healthcare and the public sector, Andy shares why successful automation depends as much on people, processes and culture as it does on technology—and what NHS leaders need to do to unlock its full potential.

Q&A with Andrew Raynes

Q: Why do many NHS organisations approach automation as an IT deployment rather than a transformation programme?

Andy: There is something about making an improvement through automation/tech but not understanding that difference it will make to sufficiently adapt let alone exploit it. In some organisations, digital is still seen as a cost centre rather than an enabler of change.

For me, successful transformation is about people, processes and technology working together. You can purchase automation software but implementing it at scale fundamentally changes business processes and often the roles of the people involved. That’s where the real challenge – and opportunity – begins.

Automation isn’t simply replacing repetitive tasks. It’s redesigning end-to-end processes, understanding how work changes, bringing people along on that journey, and ensuring technology enables staff to focus on more valuable and meaningful work.

Ultimately, project leaders need to think about all three elements—people, process and technology—and understand how each will be affected by the transformation.

Q: Where do end-to-end automation programmes typically break down?

Andy: There are three common failure points.

First, organisations don’t always have a clear vision of the future state. Without understanding where you’re trying to get to, it’s difficult to design the journey. That’s why defining both the current (“as-is”) and future (“to-be”) processes is so important.

Second is change management. Communication, education and empathy are essential. People need to understand why change is happening, what it means for them, and how they’ll be supported. If you fail to take people with you, the disconnect begins long before technology is implemented.

The third challenge is technology reliability. Even after months of preparation, if the technology fails on day one, confidence disappears almost instantly. Thorough testing and ensuring the solution works from the outset are critical to maintaining trust across the organisation.

Q: How do you see the role of the CIO evolving as organisations embrace automation and AI?

Andy: Increasingly, the CIO’s role is about enabling others to lead change rather than leading every initiative directly.

The people closest to clinical or operational work are often the strongest advocates for new technology because they understand both the challenges and the opportunities. Their peer-to-peer influence is incredibly powerful.

In healthcare, I often describe successful transformation as clinically led, operationally delivered and digitally enabled. Digital provides the tools and expertise, but lasting transformation happens when the business owns the change.

But it is not only the CIO’s role that is evolving. Everyone involved in these new ways of working will need to adapt and take on new roles and responsibilities. Leading this transition effectively—and providing the right support to help people develop new skills and adapt to change—is essential to bringing the wider organisation with you.

Q: How should healthcare organisations be measuring the impact of automation?

Andy: Start by being realistic.

Business cases often assume optimistic benefits, but in reality, outcomes rarely achieve the absolute maximum expected. Setting achievable goals makes success more meaningful and creates opportunities to exceed expectations.

Equally important is shared ownership. Benefits shouldn’t sit solely with digital or transformation teams—they need to be jointly owned by operational leaders and those responsible for delivering the change.

I also think we should move beyond simply talking about benefits and instead focus on value. Value considers both what you’ve invested and what you’ve achieved. Sometimes a lower-cost project delivering 80% of the expected benefits creates more value than an expensive programme delivering only 40%.

Understanding your baseline before the project begins is equally essential. Without knowing your starting point, it’s impossible to accurately measure improvement afterwards.

Q: How can organisations balance patient perspectives with staff experience when redesigning care pathways?

Andy: The answer is inclusion.

Recently, at Royal Papworth, we invited a patient representative into one of our process modelling workshops alongside our clinical administration team. It gave us an entirely different perspective.

Patients ask questions that professionals often don’t think to ask. Seeing the process “under the bonnet” helped them understand the complexity while also highlighting pain points, we’d become accustomed to.

The workshop led directly to practical improvements. For example, changes to telephone routing reduced call waiting by 39% for one clinic.

User groups—whether patients or staff—are incredibly valuable, but only if organisations act on the feedback. Listening is only the first step. Building confidence comes from showing people that their input leads to meaningful change.

Q: What excites you most about AI and intelligent automation in healthcare?

Andy: What motivates me most is seeing technology genuinely make a difference.

There’s nothing more rewarding than hearing someone say, “That really improved how we work” or “That made care better for our patients.”

AI and automation have enormous potential to help an increasingly stretched healthcare workforce by removing administrative burden and allowing skilled professionals to spend more time doing the work that only humans can do.

But alongside that opportunity comes responsibility.

Concerns around data protection and cybersecurity are valid, and open discussion is essential if we are to continue developing proactive safeguards against these risks. As AI adoption grows, we also need to think carefully about ethics, sustainability and environmental impact.

The computational power behind AI is significant, and we all have a responsibility to ensure these technologies are used thoughtfully and for the greatest possible benefit.

The future is incredibly exciting—but it must also be responsible.

Final thoughts

Andrew’s message is clear: the technology is rarely the limiting factor. Organisations achieve the greatest value when leaders create a clear vision, redesign processes, and bring people with them through change.

Luckily, no organisation must navigate transformation alone. Learning from peers can help avoid common pitfalls, accelerate delivery and realise greater value.

Join our free NHS peer community, created exclusively for NHS professionals and partners to explore real-world case studies, practical lessons and proven approaches from organisations delivering automation and transformation at scale.

Other resources:

A research study by Veera Häkkinen (Digital Workforce Healthcare Solution Consultant) about the new roles and responsibilities healthcare professionals are taking on as AI is integrated into care processes. The study explores these roles in the context of the EU AI Act and its requirements and compares different levels of human oversight through practical scenarios:
https://trepo.tuni.fi/handle/10024/236238

The UK government’s Code of Practice for the Cyber Security of AI (2025): https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice/code-of-practice-for-the-cyber-security-of-ai

The UK government’s Report on Environmentally Sustainable AI (2025): https://nepc.raeng.org.uk/media/2aggau2j/foundations-for-sustainable-ai-nepc-report.pdf

A case study in transforming breast cancer follow-up at Helsinki University Hospital—sharing measured outcomes and exploring when to use algorithmic automation versus AI for maximum impact and secure control:
https://digitalworkforce.com/rpa-news/hus-care-pathway-automation/

The post Andrew Raynes: Why Successful Healthcare Transformation Requires CIOs to Lead Beyond Technology appeared first on Digital Workforce.

Part 1 of 4 · Autonomous procurement operations

None of it is difficult. Somebody has to do all of it.

It is Monday morning. One of your suppliers has sent an email. From next month, the prices they charge you go up by 4.8%, across everything you buy from them.

Nothing about that email is unusual. A supplier has asked for more money for the same goods, and you get some version of it most weeks, from some supplier, in some category. It is not a crisis, nobody escalates it, and it will be handled.

Watch what has to happen before it is.

A supplier asks for a 4.8% price increase

Somebody has to:

1. Find the contract
2. Read the indexation clause
3. Check the correct index
4. Calculate the increase the contract actually permits
5. Decide whether to challenge it
6. Talk to the supplier
7. Update the agreed price
8. Make sure future orders use the new one
9. Weeks later, check that the invoices follow it

Any competent person in your team can do any one of these nine steps. The problem is that somebody has to do all of them, in order, for this supplier, this month.

And this is one email, one supplier, one price change.

Now multiply that by the thousands of suppliers and contracts you are responsible for, and by every purchase, commercial change and exception that arrives across a year.

Nobody in your organisation has ever seen that total, because no system holds a line called hours spent finding things. Your ERP records the order and your contract system records the clause, but neither of them records the forty minutes somebody spent working out which clause applied. So the work stays expensive and invisible at the same time, spread across hundreds of people who each experience it as a small annoyance.

Small annoyances do not get put on a board slide. They get absorbed, which is a polite word for paid for.

Those nine steps happen in six different places

Look at where that work actually took place.

• The email arrived in an inbox
• The terms were in the contract system
• The index was published on somebody else’s website
• The agreed price lives in the procurement system
• The order and the invoice sit in the ERP
• The approval ran through a chain of people, each of whom had to be asked, reminded and asked again

Nobody designed the work that way. Each of those systems was bought by a different function, on a different cycle and against a different set of requirements. Every one of them is good at what it does. Every one of them was a sensible purchase at the time.

What nobody bought was the thing that carries a case from one system to the next. That job went to a person by default, and it has stayed with a person ever since. It is the subject of the last article in this series.

You get the same equation every year

You are asked to deliver more value, hold more control and carry more risk, and to do all of it with fewer resources.

If you have worked in procurement or in finance for longer time, you have been handed some version of that every single year. Save more. Control more. Carry more risk, because there is always more risk. Do it with the same team, or with a smaller one.

The risk part is growing fastest in the work. The list of things you are expected to know about a supplier now runs to ownership, sanctions exposure, financial health, certifications, sub-tier dependencies, sustainability and cyber posture. Every one of those requirements arrived with a good reason attached, but none of them arrived with extra people attached.

Here is the part that makes it interesting.

You are meeting the target. Deloitte’s 2025 survey of more than 250 chief procurement officers across 40 countries found that 86% of them met their cost savings targets.

So this is not a story about a function that fails at what it measures. You hit the number you negotiated. You can evidence it. The awkward question is a different one: what happened to everything you never got to?

The constraint is human attention

Your software is fine.

Your process design is fine and your team is good. I have spent a long time inside these functions, and the people in them are rarely the problem.

There is a finite amount of expert attention in your function every week. It is the scarcest resource you have and the most expensive one you buy. The work in front of you asks for more of it than exists.

That is the constraint. Budget, headcount and tooling all sit downstream of it.

Once you name it, a number of things stop being mysterious. Why savings you genuinely negotiated leak away quietly over the following two years. Why the supplier you screened at onboarding is still on the approved list three years later, under different ownership. Why a contract renewed on terms nobody had re-read.

None of that is negligence. It is arithmetic. Every one of those tasks was somebody’s job, and that somebody had a finite week.

You prioritise, you sample, you react

So what does a function do when the work exceeds the attention available to do it?

It does the only rational thing. It prioritises, samples, and reacts.

It puts expert attention on the biggest contracts and the loudest problems. It checks part of the population and assumes the rest behaves the same way. And it waits for something to surface before it goes looking.

Every one of those is a good decision. I would make the same three. Given fixed attention and unbounded work, that is what a competent leader does, and anyone who tells you otherwise has not run a category.

You can watch it happen in the way an approved supplier list ages. Everyone on that list was checked properly on the day they were added, by someone doing a careful job. That check was a photograph of a single afternoon. Since then:

• Ownership has changed
• Certificates have lapsed
• A parent company has been bought by somebody you would not have approved

Nobody decided to stop looking. There was never a week when re-checking a supplier who had caused no trouble was the best use of the time.

But look at what each one costs.

• Prioritising means most of your spend receives no expert attention at all. It is not that it was reviewed and cleared. Nobody looked.
• Sampling means you judge the health of a whole population from a fraction of it, then report that judgement as though you had checked everything.
• Reacting means you find the problem after it has happened, and after it has cost you something.

This is your operating model. It is a good design for the shortage it was built around.

Count the two piles and price the bigger one

Go back to those nine steps and sort them into two piles. Eight of them are retrieval and checking: finding, reading, calculating, transferring, remembering and monitoring. One of them is a decision, which is whether you accept this increase, challenge it or negotiate.

That single question needs judgement, commercial instinct and a relationship with the supplier. It is the part your people are good at and never have enough time for.

You can run this on one process this week. It takes an afternoon and needs no budget. Pick something ordinary, such as a price increase, a supplier onboarding or a contract renewal. Choose one that happens often and that nobody in the room considers difficult.

Then three moves.

• Count the retrieval steps. Count every action that involves finding, reading, checking, calculating, transferring or chasing. Be honest about the ones that happen in somebody’s head or in a spreadsheet nobody owns.
• Count the steps that need judgement. These are the moments where a person weighs something and decides. In most processes there are far fewer of them than people expect. Naming them out loud is uncomfortable.
• Price the first pile. Loaded hourly cost of the people doing it, multiplied by the time it takes, multiplied by how often the process runs in a year.

That last number is what your organisation currently pays for retrieval on one process. It is usually the first time anybody has seen it as a single figure, and usually larger than the room expects.

Two things tend to happen when a team does this properly.

• The retrieval pile is longer than anyone guessed. The steps that live in somebody’s head never appear on a process map, so nobody counts them.
• The judgement pile contains steps that need no judgement. What they need is a rule an experienced person has applied for years without ever writing it down.

Then ask the only question that really matters about the list. Which of those steps genuinely required a person?

Only one kind of work needs you

When a team answers that question honestly, the list stops being a sequence and starts being four different kinds of work. They are not interchangeable, and each of them has a different answer.

• Judgement. Accept, challenge or negotiate. This needs commercial instinct and a relationship with the supplier. It belongs to a person who is accountable for the category. It should stay exactly where it is.
• Reading and reasoning. Retrieving the contract, interpreting an indexation clause a lawyer wrote four years ago, checking the published index and assembling the evidence behind a recommendation. This used to require a person for one reason only, which is that reading was human work. AI agents now do this part reliably enough to run it on every case instead of a sample.
• Execution in your systems of record. Updating the agreed price, pushing it into future orders, checking that the invoices follow it. This is integration and automation, and most large organisations already own most of the pieces.
• Sequencing and evidence. Something has to carry a case across those six systems, decide what happens when a step fails, route the exception to the right person, and keep a durable record of who decided what and on what basis. This is orchestration. Almost nobody owns it.

That last one is where the interesting failure lives. The email arrived at the front of your business, inside a supplier relationship that a named person owns. The consequence landed at the back, as a purchase order, an invoice and a payment in your finance systems. Those nine steps crossed the line between your front office and your back office four times. Each time, a person picked something up and carried it.

Most large organisations have automated pieces on both sides of that line. Very few own the crossing itself, which is where the time goes and where the errors surface.

None of this comes for free. Agents that read contracts have to be governed. They have to be monitored, corrected when they drift, tested against the decisions your best people actually make, and answerable when somebody asks why a recommendation came out the way it did. Capacity you cannot govern is not capacity. It is exposure, and you already have enough of that.

That is the work my colleagues and I do at Digital Workforce. People, AI agents and automation running as one governed flow across the systems a business already owns, from the front office through to the back. We operate it, so somebody is accountable on the day it drifts.

Where does your team spend its attention this week?

Next Monday, that supplier email arrives again. Someone will handle it well. It will take most of a morning.

The pressure your function is under has not changed much in forty years. What has changed, quite recently, is what it costs to pay attention to something, and that is what the rest of this series is about.

The next piece asks an uncomfortable question. Procurement has bought wave after wave of technology since the 1980s, and every one of those waves was worth buying. I would buy all of them again. So why is that same equation still sitting on your desk?

Before then, here is one question to take back to your team. Of all the expert attention your function will spend this week, how much of it will land on an actual decision?

Sources

About the author

Stefan Meller is Principal Account Executive for Enterprise and Public at Digital Workforce.

The post The invisible work behind every procurement decision appeared first on Digital Workforce.

It’s a positive sign that healthcare is embracing AI. But as we read the findings, one thought kept coming back to us.

One of the most interesting themes emerging from the RCR findings is the opportunity to support the operational processes that underpin patient care. Every referral, appointment and clinical handover forms part of a wider care pathway, where hundreds of individual activities work together to move patients through the healthcare system. Improving these workflows not only helps ensure patients receive the right care at the right time but also releases valuable clinical capacity for the work that matters most.

As the Royal College of Radiologists points out, administrative and operational workflows remain an area where AI has significant untapped potential.

We believe this is where some of healthcare’s greatest productivity gains still lie.

Every improvement in a care pathway has the potential to make a difference. When AI, intelligent automation and workflow orchestration are applied to the operational processes that support patient care, NHS organisations can reduce repetitive administrative work, improve consistency and give clinicians more time to focus on patients.

Turning opportunity into practice

The good news is that this isn’t simply a future ambition. It’s already happening.

One example is the Radiology Referrals Vetting AI Agent developed by SS&C Blue Prism and deployed at Sandwell & West Birmingham NHS Trust. The solution demonstrates how AI can support imaging referral vetting while keeping clinicians firmly in control.

Rather than replacing clinical judgement, the AI agent works alongside existing radiology teams. It reviews incoming referrals, checks clinical information against local policies and guidelines, identifies duplicate requests and prepares structured recommendations for clinician review. Straightforward referrals are progressed in seconds, while more complex cases are escalated with the relevant clinical context attached, ensuring governance and human oversight remain at the centre of every decision.

The results demonstrate what’s possible when AI is integrated into a connected clinical workflow rather than a standalone tool.

At Sandwell and West Birmingham NHS Trust, the solution is expected to return approximately 3,000 clinical hours every year, reduce referral processing time by 75%, autonomously resolve 80–90% of imaging referrals, and reduce GP feedback times to under one hour. Most importantly, those hours are being returned to radiologists so they can spend more time on complex reporting, urgent cases and patient care.

If you’d like to see how the solution works in practice, you can watch the Imaging Vetting AI Agent demonstration and explore the Sandwell and West Birmingham NHS Trust case study.

• Imaging Vetting AI Agent demo
• Sandwell and West Birmingham NHS Trust case study

Looking beyond individual AI projects

As AI adoption continues to accelerate across the NHS, the conversation is naturally evolving.

Rather than asking “Where can we use AI?”, healthcare organisations are increasingly asking “Where can AI, automation and intelligent workflows help us deliver better care?”

For us, that’s where the greatest opportunity lies.

Perhaps the most interesting question is no longer how many AI solutions an organisation has adopted, but how those technologies are supporting everyday clinical practice. When operational processes become more connected and efficient, clinicians gain more time to focus on patients and organisations are better placed to meet growing demand.

Whether it’s imaging referrals, outpatient pathways, waiting list management or clinical administration, the most impactful innovations are those that connect seamlessly into existing care pathways and help healthcare professionals spend less time on repetitive tasks and more time caring for patients.

Continue the conversation

If you’re exploring how AI, intelligent automation and workflow orchestration could support your radiology or diagnostic services, we’d love to continue the conversation.

Visit our NHS Healthcare page to discover how Digital Workforce is supporting NHS organisations in delivering more efficient, connected care through intelligent automation, AI and agentic AI. You can also join our NHS Community, where healthcare leaders exchange real-world case studies, practical insights and experiences from across the NHS.

If you’re looking to deepen your understanding of AI and healthcare automation, explore agentacademy.ai for on-demand learning, webinars and practical resources.

Later in autumn, we’ll host a dedicated webinar exploring how AI agents and intelligent automation can support imaging referral vetting and broader diagnostic pathways. We’ll share practical NHS experiences, lessons learned and discuss how organisations can identify where these technologies could deliver the greatest impact.

We also offer NHS organisations a complimentary imaging referral workshop and opportunity assessment.

Together, we’ll explore your current referral workflow, identify opportunities to reduce administrative burden and estimate how much clinical time could be released through AI-supported imaging referral vetting. Whether you’re just starting to explore AI or already have initiatives underway, the workshop provides a practical way to understand where the greatest opportunities may exist within your organisation.

If this topic resonates with you, we’d love to continue the conversation. Drop us an email 

The post AI in radiology is growing. The next step is transforming the workflow around it. appeared first on Digital Workforce.

For people with long-term conditions, care continues between appointments. They monitor symptoms, manage medication and decide when to seek help. 

Supported self-management can make these daily decisions easier. NHS England, for example, already recognises it as a core part of personalised care. 

The need is growing. Non-communicable diseases account for 80% of the disease burden across EU countries, according to the European Commission. 

While AI could help providers offer timely guidance and identify cases needing attention, it raises an important question: who stays in control when its output could affect patient care? 

A question grounded in clinical experience 

For Veera Häkkinen, this topic brings together her experience in healthcare and technology. Now a Solutions Consultant at Digital Workforce, she previously worked in elderly care, hospital wards and for nearly seven years as an operating theatre nurse. 

Drawing on this background, her Tampere University thesis explores healthcare professional role and human oversight in AI-supported self-management. 

Making human oversight concrete 

The thesis followed a constructive study approach in two parts. 

First, Häkkinen reviewed existing literature to identify the roles, tasks and responsibilities professionals may have in algorithmic healthcare processes. She then compared these findings with relevant requirements in the EU AI Act. 

Finally, she created four AI-supported self-management scenarios. These covered: 

• Feedback based on patient questionnaires 

• Processing follow-up information 

• Recommendations for self-care materials 

• Responses to patient messages 

Häkkinen used the scenarios to explore two levels of human oversight. 

In a human-in-the-loop process, a healthcare professional validates each AI-generated output before it is used or shared with the patient. They decide whether to approve, amend or reject it. 

In a human-on-the-loop model, the system can complete agreed tasks independently within defined limits. A healthcare professional steps in when a case is flagged or something requires closer review. 

This difference affects how work is organised. It also determines when professional judgement enters the automated pathway. 

Häkkinen presented the scenarios and related responsibilities to three nurses and one doctor working with self-management. Their discussions explored whether the proposed tasks would fit their roles and where concerns might arise within the role or scenarios.

What AI oversight requires from healthcare professionals 

Human oversight covers more than approving a result at the end of a process. 

Incomplete information may already have shaped the AI generated output. The system could miss an exception or direct the case down an unsuitable route. 

Healthcare professionals may therefore need to e.g.: 

• Understand the system’s capabilities and limitations 

• Assess the quality of its inputs and outputs 

• Compare recommendations with the patient’s wider situation 

• Recognise when an output should be questioned 

• Correct, override or stop the process when necessary 

• Report problems and protect professional integrity 

Critical assessment and decicion-making were one of the strongest themes in Häkkinen’s findings. 

This skill is already central to healthcare. Clinicians assess information from patients, colleagues, records and diagnostic systems every day. AI introduces another source that requires professional judgement.
Responsbilities in the context of EU AI Act

The EU AI Act responsibilities assigned to healthcare workers depend on how the AI system is classified and used. Each service therefore requires its own assessment. It’s important to acknowledge that further obligations may apply, including GDPR and MDR.

Treatment-related cases demand close review  

In the research, participants generally preferred a human-in-the-loop model for treatment-related cases.

Their concerns came from real care situations. A patient may have several conditions or find it difficult to describe their symptoms accurately. Living arrangements, financial circumstances and health literacy can also affect suitable guidance. 

AI may not recognise this wider context. A response can sound convincing while missing something important. 

Participants also raised questions about responsibility. They wanted to know who would remain accountable and whether the system could consider each person’s circumstances fully enough. 

These concerns did not lead to rejection of AI. The professionals were interested in the scenarios and suggested ways to make them safer and more trustworthy. 

They were more open to human-on-the-loop oversight for lower-risk activities. Healthy lifestyle guidance and administrative communication were examples where greater independence could be appropriate. 

The level of control should therefore reflect the task the system performs and its risks.

Involving professionals from the beginning 

Häkkinen’s research highlights the value of involving healthcare teams in design and implementation. 

Professionals understand the exceptions that may be difficult to see. They know where patients and professionals themselves may struggle and which information carries clinical importance. 

This work also supports adoption. A solution may meet legal requirements and still fail to gain the trust of its users. 

Acceptance matters because the intended benefits are partly depend on people using the service as designed. Role and e.g. training  should make sense to those responsible for daily operation. 

Häkkinen also found that the risk level of the solution can be influenced by how healthcare professionals use the system and act on its outputs. Organisations should therefore define these responsibilities clearly and reflect them in service design, implementation and training.

How to make implementation manageable and safe 

For Digital Workforce, Häkkinen’s findings reinforce the importance of designing services around the care pathway and the people responsible for it. 

We work with clinical teams and process owners to define the challenge, map key decisions and identify exceptions. Together, we agree where technology can execute the workflow independently and where professional review or other human input is necessary. 

The service can then be introduced in manageable stages, with users involved in testing and training shaped around their roles. A nurse reviewing guidance needs different support from a process owner monitoring performance and escalations. 

This approach reduces disruption and gives healthcare professionals a clear role in shaping a service they can use confidently in their daily work. 

Professional expertise remains essential 

Häkkinen is careful about the limits of the research. The interview part of the study only involved four participants, so its findings cannot represent every healthcare professional or use case. AI technology and the regulatory environment are also developing quickly. 

The thesis still offers a useful way to think about human oversight. It turns a broad requirement into practical responsibilities that healthcare teams can discuss, test, and improve. 

Häkkinen’s conclusion is grounded in her experience as both a nurse and a technology specialist. Professional expertise will remain valuable throughout healthcare processes. AI may change where, when, and how that knowledge is needed. 

The participants brought both concerns and ideas to the discussion. That combination provides a responsible starting point for designing AI-supported care. 

With clear roles, suitable safeguards and healthcare professionals involved throughout, AI can support timely self-management while keeping decisions that affect patients under human control.

Watch Veera’s inteview about her research on our YouTube -channel. 

The post Veera Häkkinen: When AI supports patient self-management, who stays in control? appeared first on Digital Workforce.

When intelligence becomes abundant, markets stop rewarding knowledge and start rewarding direction. The scarce resource is no longer the ability to think but the ability to choose—to aim intelligence toward outcomes that matter. The cognitive economy is the first economic system in history where intelligence is not a human trait, not a corporate asset, but a ubiquitous substrate. And everything built on top of it begins to reorganize.

I. The End of the Knowledge Advantage

For centuries, economies rewarded those who could accumulate knowledge faster than others: scholars, analysts, engineers, strategists, and institutions. Knowledge was capital. Expertise was leverage. Intelligence was a differentiator.

But in a world where:

• reasoning is on‑demand
• analysis is instantaneous
• creativity is infinitely generative
• and every actor has access to the same cognitive infrastructure

the traditional knowledge advantage collapses.

This is the first time in human history where intelligence is no longer a competitive moat. It is a commodity—abundant, cheap, and universally accessible.

The winners of the cognitive economy are not the smartest. They are the most intentional.

II. When Intelligence Becomes Infrastructure

AI is no longer a tool; it is a substrate. A layer beneath every industry, every workflow, every market. Intelligence becomes something you plug into, not something you cultivate.

This shift mirrors the rise of electricity in the industrial era:

• Electricity didn’t make factories smarter.
• It made factories faster, scalable, and continuous.

AI does the same for cognition.

It turns thinking into a utility.

And once cognition becomes a utility, markets reorganize around those who can deploy it most effectively—not those who possess it.

III. The New Scarcity: Direction, Judgment, and Values

If intelligence is infinite, what becomes scarce?

Three things:

1. Direction

Infinite intelligence still needs a target. The ability to define what matters becomes the new strategic advantage.

2. Judgment

AI can generate possibilities, but humans still choose among them. Judgment becomes the premium skill—the ability to select the right path from infinite options.

3. Values

When intelligence can optimize anything, values determine what gets optimized. Ethics, purpose, and mission become economic drivers, not philosophical luxuries.

In the cognitive economy, values are the new algorithms.

IV. Markets Shift from Production to Orchestration

Traditional markets reward production: making things, delivering services, and generating output.

Cognitive markets reward orchestration:

• coordinating intelligence
• aligning agents
• directing cognitive resources
• shaping emergent behavior
• designing systems that think on your behalf

The most valuable companies will not be those that produce the most intelligence, but those that orchestrate the most intelligence toward coherent outcomes.

This is the rise of meta‑productivity—productivity built on top of intelligence itself.

V. The Collapse of Traditional Competitive Moats

When intelligence is abundant, many moats evaporate:

• Expertise moats → replaced by AI‑augmented reasoning
• Scale moats → replaced by autonomous agents
• Data moats → weakened by synthetic data and universal models
• Brand moats → challenged by infinite content generation
• Labour moats → disrupted by cognitive automation

The only moats that survive are those tied to identity:

• trust
• mission
• community
• narrative
• governance
• proprietary values

In the cognitive economy, identity becomes strategy.

VI. The Rise of Cognitive Capital

Cognitive capital is the ability to deploy intelligence at scale with minimal friction. It includes:

• agent networks
• autonomous workflows
• cognitive supply chains
• intelligence routing systems
• decision‑layer architectures
• human‑AI governance frameworks

Companies with high cognitive capital can:

• make decisions faster
• adapt markets in real time
• personalize at population scale
• simulate futures before acting
• compress innovation cycles from years to days

Cognitive capital becomes the new measure of economic power.

VII. Competition Becomes a Race of Adaptation

In the cognitive economy, competition is not about who has the best product—it's about who can adapt fastest.

Markets become fluid. Strategies become dynamic. Organizations become living systems.

The competitive cycle compresses:

• Idea → Prototype → Market happens in hours
• Feedback → Iteration → Relaunch happens in minutes
• Strategy → Execution → Optimization happens continuously

The companies that thrive will be those that treat intelligence as a flow, not a resource.

VIII. Human Roles Shift from Doing to Deciding

As intelligence becomes abundant, human roles evolve:

From operators → to orchestrators

Humans stop performing tasks and start directing cognitive systems.

From analysts → to adjudicators

Humans stop interpreting data and start validating AI‑generated insights.

From creators → to curators

Humans stop producing content and start shaping meaning.

From workers → to governors

Humans stop executing workflows and start defining the rules intelligence must follow.

The cognitive economy elevates humans from labour to leadership—not because humans are smarter, but because humans decide why intelligence is used.

IX. Governance Becomes the New Competitive Frontier

When intelligence is infinite, governance determines outcomes.

The companies that win will be those that master:

• AI alignment
• cognitive risk management
• agent oversight
• ethical optimization
• value‑driven decision frameworks
• transparent intelligence routing

Governance becomes a product. Governance becomes a brand. Governance becomes a competitive advantage.

In the cognitive economy, the most trusted systems win.

X. The Future: Competing in a World of Infinite Intelligence

The cognitive economy is not a future scenario — it is the emerging reality of 2026 and beyond.

Its defining truth is simple:

When intelligence is everywhere, the only scarcity is intention.

The organizations that thrive will be those that:

• aim intelligence toward meaningful outcomes
• build identity‑driven moats
• orchestrate cognitive systems with precision
• govern intelligence with transparency
• adapt faster than the markets they operate in

The cognitive economy rewards those who understand that intelligence is no longer the game—it is the field on which the game is played.

And in this new world, the winners are not the ones who think the most, but the ones who decide the best.

Let us know in the comments if you are experiencing this role transformation in your workplace or industry.

Written and published by AI Quantum Intelligence with the help of AI models.

But MIT scientists say the whole process of building and running an optics experiment could one day be fully automated. Taking a step toward such a future, they have developed a reconfigurable, robotic optics laboratory. 

The new robotic lab autonomously assembles standard optical components into desired configurations. It can then tune the angle and position of mirrors and lenses with micron-scale precision to produce beams of light with specific properties. The system can also safely dismantle an experiment and reassemble the parts into an entirely new setup. 

The team showed that the robotic system could autonomously build and fine-tune a tabletop laser cavity — a key element of most optics experiments. The system could also precisely manipulate components to perform several optical tasks, such as centering a laser beam, aligning multiple beams, and automatically stabilizing the beams in response to physical disturbances.

“We start with randomly placed components,” says Sachin Vaidya, a postdoc in MIT’s Research Laboratory of Electronics. “At the end, we have a fully functioning laser that the robot has built.”

The researchers are expanding the robotic lab, in a physical and virtual sense. In addition to improving the system’s physical sensing, maneuvering, and overall space, they are developing a cloud-based application that gives users virtual access to the physical robot. They envision that one day, scientists from anywhere will be able to remotely access robotic optics labs and virtually submit experimental protocols or queries that the labs would then set up and run autonomously. 

“There are many things this could enable,” says Marin Soljacic, the Cecil and Ida Green Professor of Physics at MIT. “A robot isn’t going to get bored. It can work 365 days, 24 hours a day, on very boring things. That will free up so much creativity and time for scientists to then push theories and see what we can do. Science could progress much faster.”

The MIT team will present the details of the new system at the Intelligent Robots and Systems (IROS) conference later this month. Along with Soljacic and Vaidya, project team members include co-lead Seou Choi, Caio Silva, and Shrish Choudhury from MIT, Shiekh Uddin of Nokia Bell Labs, and Sajib Shuvo of Arizona State University.

A city of light

A tabletop optics experiment can resemble a miniature city of densely packed mirrors, lenses, and light sources. Scientists manually arrange and align the various components in precise configurations, then shine light into the experiment. The lenses and mirrors bounce and focus the beam into a desired wavelength, frequency, or intensity that can then be used to probe or manipulate a given material. 

“Sometimes this manual setup takes days or months depending on the complexity of the experiment,” Soljacic says. “It’s meticulous work that has to be done again and again for each experiment.”

Most labs do incorporate some level of automation in an optics setup, such as motorized tuners that mechanically turn knobs to precisely angle a mirror. 

“These components can automate the most tedious parts of an experiment,” Vaidya notes. “But no one has built a full system that goes from no setup to a completely aligned setup in one tool. That was our goal, to show complete automation through all the steps that go into an optics experiment.”

Auto-tuned optics

The team’s robotic lab centers around a robotic arm with seven moveable joints that is attached to a metallic tabletop. The robot picks and places lenses, mirrors, and other optical components, each of which the researchers installed in its own 3D-printed plastic housing. 

The housings are designed such that the robot can easily and safely grip and move each component. The researchers etched the top of each housing with a QR code containing information about the component within the housing (such as whether it is a lens versus a mirror, and its exact dimensions and capabilities). Each housing has a magnetic base that helps stabilize a component once the arm places it down on the metallic tabletop. 

The researchers designed a Wi-Fi-enabled “fine-adjustment tool” that clips onto the mount of standard optical components. The motorized tool can be wirelessly controlled to turn a component’s knobs, for instance to angle a mirror. 

“The way humans do this tuning is by feel, and based on a lot of intuition,” Vaidya says. “This tool is at least as precise as a human, but in reality it is much more precise.”

The team also installed a pair of cameras over the entire setup that provides a birds-eye view of the tabletop experiment. Finally, they developed a “software stack,” or a set of programs that enables the robot to navigate through every step of setting up and continuously tuning an experiment. These steps include recognizing a specific component, knowing how to safely approach and pick it up, where to move it, and how to avoid collisions with other parts of the experiment along the way. 

Finally, they designed a simple virtual user interface to allow an experimenter to remotely direct the robot. For instance, when a user drags the icon for a mirror from one spot to another, and clicks a button to confirm, the robot responds by picking up the actual mirror and placing it down at the corresponding location on the table. 

As a demonstration, they directed the robot to assemble various components into a laser cavity. A laser cavity consists of two mirrors arranged on either side of a crystal. When a beam of light is shone into the setup, it pings back and forth between the two mirrors. With each pass, the light also passes through the crystal, which amplifies the light’s intensity, to a point that whatever light escapes, is intense enough to form a laser. 

“We wanted to pick a demonstration in optics that’s reasonably challenging,” says co-lead author Seou Choi, a graduate student in electrical engineering and computer science. “This is not something a new trainee could do in an afternoon. It requires a lot of alignment and component experience.”

In the end, the robot successfully built a functional laser cavity by autonomously carrying out 50 maneuvers, all within 30 minutes. When the researchers introduced physical disturbances to the setup, such as randomly moving a component on the table, the system automatically readjusted components to maintain the laser’s intensity. 

“Even tiny vibrations or temperature changes can degrade an optics experiment,” Vaidya says. “An autonomous lab could continuously monitor its own performance and repair the alignment before valuable data is lost.”

The researchers envision that robotic labs like theirs could be paired with a nearby library of physical components that another robot could fetch and deliver to a tabletop robot to arrange into an experiment. Such a system could work to build and run experiments, then break them down and set up new ones on demand, or continuously run an experiment that requires active 24/7 monitoring.

“A system like this could help industry test prototypes faster, for everything from cameras and displays to solar cells and AR/VR goggles,” Vaidya says. 

For their part, the researchers are applying the new robot lab to test promising carbon-capture materials. By shining light with specific properties at these materials, they can get information about how a material absorbs carbon dioxide. 

“Experimental optics is the backbone of many important fields,” Vaidya says. “Our work takes the first step toward optical labs that can operate faster, more reliably, and without manual intervention in a domain that demands extreme precision and diversity of experimental setups.”

This research was supported, in part, by the Korea Foundation for Advanced Studies Overseas PhD Scholarship, the U.S. National Science Foundation, the U.S. Army DEVCOM ARL Army Research Office, Parviz Tayebati, the MIT Undergraduate Research Opportunities Program (UROP), the MIT Generative AI Impact Consortium (MGAIC), and Shell International Exploration and Production Inc.

Atlas Building Composites, a spinout of MIT, is on a mission to address both problems with a single solution. The company has developed an AI-powered robotic manufacturing platform capable of turning single-use plastics into durable building materials.

The company emerged from MIT HAUS, a research effort in the MIT Department of Mechanical Engineering that’s short for “Home Architecture for Universal Sustainability.” Atlas uses waterless plastic recycling and large-scale composite additive manufacturing technology to make parts like home foundations, decks, and trusses for walls, floors, and roofs.

“Our mission is to convert waste plastic pollution into durable composites to build 1 billion homes,” says Atlas chair and co-founder A.J. Perez ’13, MNG ’14, PhD ’23, who is also an MIT research scientist. “You can’t divorce these things from each other. We’re not here just to build homes, and we’re not here just to recycle plastic. The conventional way of building homes involves cutting down trees, mining, refining, and a bunch of other dirty activities. We want to avoid all that and address all the plastic bound for our oceans and landfills. We’re turning bottles into buildings.”

Atlas’ parts are already being used to support barns, sheds, decks, and docks. Most recently, the company supplied the U.S. Army Corps of Engineers with American-made recycled composite trusses to construct a 40-foot bridge in a Massachusetts wetland.

Perez and Atlas co-founder Matt Pouliot envision deploying thousands of their AI robotic production systems around the world. A key enabler for that scale is the company’s ability to recycle low-grade plastic into building components without water.

“This is key to democratizing recycling,” Perez says. “Now, every country around the world, regardless of their water access, will be able to do something about their plastic. We strive to study these issues in the real world, not just a lab. When you talk to government officials about creating a new recycling facility, they have to get the local water agency involved, there’s permitting, etc. A lot of that work disappears with the waterless recycling process.”

Research for impact

Since earning his PhD at MIT, Perez has been developing advanced fabrication techniques for homes and new techniques for plastic recycling. In 2019, he started MIT HAUS with David Hardt, MIT’s Ralph E. and Eloise F. Cross Professor in Manufacturing.

“It started with the simple mission of enabling the production of 1 billion homes over a 30-year period,” Perez says. “Then we realized how much the materials needed for those homes would strain global supply chains.”

Perez says building those homes using conventional methods would require a doubling of global production capacity for materials like concrete, not to mention a dramatic acceleration of global deforestation.

“That’s where the light bulb went off,” Perez says. “There’s this other problem humanity has, which is 8 gigatons of plastic that have been produced and are polluting our oceans, rivers, and cities. We decided to plug two really big, hairy problems together.”

Perez met Pouliot, a former Maine senator, and the pair started Atlas to commercialize the technology Perez had been developing at MIT. The founders worked with MIT’s Technology Licensing Office and have since worked with researchers at other universities to independently develop technology for the company’s robotic manufacturing platform, which the founders call the Atlas Factory Stack.

First, single-use plastic from water bottles and other objects is shredded and fed into the Atlas system, where it is melted and fused with American-made fiberglass to make it stronger than wood. From there, a large-scale 3D printer creates the parts, including trusses for floors, walls, roofs, and bridges.

Through research at MIT, Perez has shown large composite trusses can be printed in under 13 minutes and support over 4,000 pounds, exceeding key building standards.

“At MIT, we’ve demonstrated we can produce 60 to 80 pounds of parts per hour, and the systems we’re specifying in Atlas factories operate in the 150 to 200 pound per hour range,” Perez says. “There’s the potential for our robotic manufacturing platform to produce each part at a lower cost than injection molding, and it’s far more flexible and convenient. For example,  we can manufacture the parts in the reverse order so that they’ll be placed on the finished goods pallet next to the machine.”

The founders envision Atlas as a technology provider enabling the creation of home factories close to wherever homes need to be built. Today, each Atlas factory cell is capable of producing the structural framing components for about one small home per day.

“The old way of doing things would be some huge factory in China would mass produce one type of part and ship it far away,” Perez says. “I don’t think that’s good for the planet. Another reason we don’t use injection molding is economic: Mega factories don’t produce as many jobs and have a much higher carbon footprint. We want this to be localized to benefit local communities. The plastic is already everywhere. The more local Atlas is, the lower the cost and footprint.”

Going global

Plastics last far longer than wood, especially for applications where they’re in contact with the ground or water. That adds to the company’s environmental benefits.

“If you get a material into the building world and it does its job, it’s going to be used for a very long time and not need to be recycled again for a very long time,” Pouliot says. “That’s important because when you recycle something over and over again, it degrades. This is one of the most sustainable use cases for recycled petrochemical products.”

Atlas’ bridge with the Army Corps of Engineers was installed in less than a day. The founders are also in talks with international franchise partners to deploy the Atlas Factory Stack across the globe.

“To accomplish our mission, I fundamentally believe it’s not going to be one far-away company dominating the industry,” Perez says. “It’s going to be every country leveraging Atlas Factory Stacks to create local recycling jobs, local factory jobs, local construction jobs, and to stimulate their economies with local materials.”

In these settings, a plausible answer is not enough: The output often must also satisfy nonnegotiable safety, physical, or task-specific requirements, known as hard constraints.

The researchers developed a method that helps generative models meet these strict requirements without sacrificing the quality of their outputs. 

The key to their technique is to give the model more freedom during the generation process and enforce hard constraints on the final output, rather than at every intermediate step. 

In experiments spanning robotics, control of physical processes, and computer vision, the new method consistently satisfied the required constraints while identifying better solutions than existing techniques. 

This adaptable, plug-and-play technique works at deployment time, so it can be applied to pretrained generative models without retraining them. It can make such models more useful in applications where safety rules, physical laws, or other strict requirements cannot be violated. 

“The promise of generative AI is its ability to explore a rich space of possibilities, but the real world places boundaries on which possibilities are acceptable. Our approach lets us preserve that generative power while enforcing the nonnegotiable requirements of high-stakes or safety-critical applications,” says Navid Azizan, the Alfred H. and Jean M. Hayes Career Development Associate Professor in the Department of Mechanical Engineering and the Institute for Data, Systems, and Society (IDSS), a principal investigator of the Laboratory for Information and Decision Systems (LIDS), and the senior author of a paper on this technique.

Azizan is joined on the paper by lead author Zeyang Li, a graduate student in mechanical engineering and LIDS; and Kaveh Alim, a graduate student in IDSS and LIDS. The research appears this week in the IEEE Transactions on Pattern Analysis and Machine Intelligence.

Freedom to explore

Pretrained generative AI models, such as diffusion models like Stable Diffusion and flow-matching models like FLUX, are now widely available. These powerful models learn to create new data by transforming random noise. Their availability has enabled people to adapt them to a wide range of applications.

These highly capable models excel at providing answers that come close to satisfying most queries, but in safety-critical applications like robot path planning on a crowded factory floor, an answer that is “nearly correct” may not be good enough. 

For instance, a “nearly correct” path from one machine to another might still result in the robot colliding with a human co-worker.

In such safety-critical applications, users often employ a technique called projection-based sampling, which repeatedly forces the model’s partial solutions, called intermediate samples, to satisfy strict requirements during the generation process.

But constraining the entire generation process can prevent the model from reaching a better final solution. These methods also typically focus only on satisfying the hard constraints, missing the opportunity to improve other qualities of the solution, like reducing the length of the robot’s trajectory.

“For constraint satisfaction, what ultimately matters is the model’s final output, since the internal process is discarded. By not requiring every intermediate step to satisfy the constraints, we give the model more freedom to find high-quality solutions that are still feasible in the end,” says Li. 

The researchers developed an algorithm called HardFlow that steers the sampling process so that the final output satisfies the user’s hard constraints without being overly restrictive and is of higher quality.

Subtle steering

HardFlow reformulates hard-constrained sampling as a trajectory-optimization problem, using tools from the field of optimal control. This enables the framework to steer the model’s sampling trajectory toward a goal, making subtle corrections along the way while enforcing hard constraints on the final output.

“Control theory gives us a powerful framework for formalizing the optimal way of making these corrections,” Azizan says.

But solving the trajectory-optimization problem around an enormous neural network was no easy task. The model may have hundreds of interconnected layers that process data.

To make the problem tractable, the researchers leveraged the structure of flow-matching models to decompose the problem into a sequence of smaller, single-step subproblems. They then applied systematic transformations and approximations to derive an efficient, scalable algorithm that still finds a feasible solution. 

“Essentially, we transformed the trajectory-optimization problem into something that preserves the key properties of the original problem, but can be solved very efficiently at deployment time,” Azizan adds.

Reformulating the task as an optimization problem allows HardFlow to incorporate additional goals that can improve the quality of the final answer. For instance, HardFlow could find a collision-free path for a robot that is also the shortest distance to its goal.

“Our framework can jointly handle both aspects, which helps it perform much better than existing methods,” says Li.

Across experiments in robotic manipulation, maze navigation, and text-guided image editing, HardFlow achieved perfect constraint satisfaction while consistently outperforming baseline methods on measures of solution quality. 

For example, it enabled a robotic manipulator to avoid collisions with obstacles while also finding the quickest path to the target object. Most other methods either resulted in collisions or found paths that took significantly more time.

In addition, HardFlow’s computation time was comparable to or lower than that of most competing methods.

In the future, the researchers could extend the framework to settings in which the AI model itself can also be updated, so that constraint satisfaction and sample quality can be improved in a more adaptive manner. 

"We're interested in things that make sound underneath the ice," says Ben Evans, a researcher in the laboratory's Advanced Undersea Systems and Technology Group. "For example, our OIC 2024 data contained marine-mammal songs. We need a better understanding of how such signals propagate through ice, and how to distinguish these signals from other sources."

This underwater soundscape is shifting as sheets of Arctic sea ice rapidly break and melt, opening previously impassable maritime routes for military and commercial activity. Determining the unique sound profiles, or acoustic signatures, produced by fracturing ice will enable researchers to develop predictive capabilities for building coastal community resilience, informing geopolitical strategy, and surveilling adversary Arctic activity. The Fiscal Year 2027 Administration R&D Budget Priorities and Cross-Cutting Actions calls for agencies to "prioritize research and associated research infrastructure investments that enhance America's ability to observe, understand, and predict the physical, biological, geologic, and socioeconomic processes and interacting systems of the Arctic to protect and advance American interests and ensure prosperity of America's Arctic residents," and to "invest in R&D that assures America's uncontested navigation and strategic utilization of the Arctic."

Weather woes

Evans and David Whelihan have been trekking to OIC since 2022, advancing their vision to distribute a set of low-cost sensors across the Arctic for continuous monitoring. Hosted by the Navy's Arctic Submarine Laboratory (ASL) every two years, OIC is a three-week event during which U.S. and allied military forces conduct operational readiness exercises. The temporary infrastructure ASL sets up for OIC — a drifting sheet of Arctic sea ice, atop which sits a runway and insulated tents for lodging and command and control — simultaneously enables researchers to test prototype equipment and conduct experiments in an environment otherwise inhospitable to humans. This opportunity is particularly valuable as Arctic monitoring systems are developed in support of U.S. Department of War priorities.

This year proved especially challenging, with back-to-back blizzards creating whiteout conditions. Temperatures persistently plunged to minus 25 degrees Fahrenheit, and winds blew at 25 to 30 miles per hour with 40 mph gusts. Although the team, which also included Ella Wawrzynek and Ryan Saenger, had intended on completing two stints on the ice — one to deploy the sensors and the other to retrieve them after a few weeks — the weather had other plans. Their initial trip to camp was delayed by a week as windblown snow halted all inbound and outbound flights.

While they waited in Prudhoe Bay, Alaska, for the weather to clear, Whelihan was readying another technology they planned to test at OIC: a modem from industry partner Havguard, a Norwegian defense technology startup, that can communicate through ice using magnetic fields (instead of radio-frequency signals, which are rapidly diminished by seawater). However, harsh conditions inside and outside in Prudhoe Bay led to some system failures, and he flew back to the laboratory to fix them. "De-risking and operationalizing critical technology for the warfighter is an important part of what we do," Whelihan says.

After Evans, Wawrzynek, and Saenger arrived at camp on March 7, not a single flight came or left for the next five days. During a "normal" mobilization at OIC, six to nine flights per day are typical. "At times, we couldn't see participating countries' flags on poles roughly 100 feet away from the command tent," Evans says. "We had to put on hats and sometimes goggles just to go between tents, whereas at previous OIC events we walked around with long johns and pants."

The day after their arrival, they loaded their sensors onto a sled, and a field party leader (an expert in Arctic survival) driving a 4x4 vehicle with tracks towed them outside the main camp area. After deploying a quarter of the sensors they had planned, their leader received a call from camp command instructing them to return. The windblown snow was picking up, and they soon wouldn't be able to retrace their tracks back to camp.

A week later, the team had a clear day to retrieve their sensors and fly out of camp. "We laughed, because we could very easily see camp from where we had deployed the sensors," Evans adds.

Magnetic communication

As Whelihan returned to Prudhoe Bay with the fixed communications modem, another blizzard hit. Because the laboratory team had already been to camp once and other research teams needed an opportunity to go onto the ice during the next clear-weather window, the laboratory contracted with UIC Science to conduct the modem experiment. A business unit of the Ukpeaġvik Iñupiat Corp., UIC Science provides logistical and technical support for Arctic research based in Utqiaġvik (Barrow), Alaska, the northernmost U.S. city. Unlike the drifting ice in the open ocean, the ice in Utqiaġvik is primarily landfast, meaning it's fastened, or anchored, to the shoreline or seafloor.

Through UIC Science, Whelihan and Wawrzynek learned how to ride snowmobiles and then drove onto a big lagoon, where they drilled a 2x3-foot hole through 3.6 feet of ice to deploy a remotely operated vehicle (ROV) carrying the Havguard communications modem. The modem is based on a magneto-inductive transmitter (positioned below the ice) and receiver (sitting atop the ice), which are housed within polycarbonate domes to protect the sensitive electronics. The duo had met with Havguard in Norway in fall 2025 to discuss plans for testing the modem in the Arctic, and Havguard in turn built a version to testing specifications. Prior to OIC, Havguard and the laboratory team deployed the modem on a large reservoir in Vermont. While not representative of Arctic sea ice over salt water, this environment allowed them to test their procedures and capabilities.

"Under the Arctic lagoon ice, we placed the ROV, which was also equipped with a Doppler velocity logger, a four-beam sonar system that measures the vehicle's speed and direction," Whelihan says. "We used those measurements as the ROV drove under the ice, plus aerial drone images, to superimpose a picture of the ROV on the site so we could track it and calculate the modem's rate of test-data transfer. We achieved through-ice communication at about 1.2 kilobytes per second on an alpha prototype system that had traveled from Boston to Alaska three times. This result is very encouraging, and the system warrants further development."

In future iterations of this setup, the data could then be relayed out of the Arctic through drones or satellites.

Community connections

While in Utqiaġvik for a week in mid-April, they participated over the weekend in the Piuraaġiaqta annual spring festival, watching a harpoon-throwing contest and proctoring a kids' snowmobile race. And with eighth graders at the local middle school, they discussed their Arctic R&D and engaged them in a game teaching sonar concepts.

"When you embrace this culture of community, you meet lots of interesting people and doors open up," Whelihan says.  

"Connecting with the Arctic community is an important aspect of our work," Evans adds. "Every time we come here, we cross paths with someone we don't expect to, learn about their work, and think about how we may be able to collaborate." For example, at OIC 2024, the laboratory team had met a professor from the University of Maryland at College Park with extensive experience collecting and analyzing cryoseismological data; they now hope to work with him to apply machine learning to discriminate between icequakes and marine mammal vocalizations.

In the lead-up to OIC 2028, the team plans to design, prototype, and test air-droppable versions of some of their sensors while continuing to partner with Havguard on the through-ice communications modem. Their next step is to optimize the modem's packaging to facilitate deployability in the Arctic and integration with the laboratory's sensor suite.

"The through-line in all this work is minimizing boots on the ice," Whelihan says. "Especially this year, we learned that the weather is in charge of our access to the Arctic. We need ways to easily get sensors where we want them and to retrieve the data they collect, even in these extremely challenging conditions."

This work is funded through the laboratory's internally administered R&D portfolio in mission-critical technology (integrated systems area) and the laboratory's Advanced Concept Committee, which funds high-risk, high-reward early-stage research addressing critical gaps in national security technology.

To help humans better anticipate a vehicle’s mistakes, researchers from MIT and autonomous vehicle technology company Motional developed a new method that provides clear explanations of the underlying model’s decisions.

Usually, the internal reasoning process of a deep learning model is opaque and difficult to understand. But the new method, called the Concept-Wrapper Network (CW-Net), translates that reasoning process into concepts that faithfully describe the autonomous vehicle’s decisions without altering its driving performance.

CW-Net explains the decisions of machine learning-based planners using understandable concepts, like “approaching stopped vehicle” or “close to cyclist.” These explanations can correct misconceptions drivers and passengers have about vehicle behavior and improve their situational awareness.

In road tests on a private track, CW-Net explanations helped safety drivers more accurately predict vehicle behavior; a larger simulation study with nonexpert users yielded similar results. These experiments show how CW-Net can provide important feedback for engineers as they troubleshoot in-vehicle artificial intelligence systems. In the longer term, this technique could boost the safety and transparency of autonomous vehicles, while building appropriate trust in drivers and passengers.

“This work shows how explanations are supportive to the human’s mental model and understanding of the behavior of a system, and how it could be used in engineering and development to improve the technology,” says Julie Shah, an MIT professor of aeronautics and astronautics, director of the Interactive Robotics Group in the Computer Science and Artificial Intelligence Laboratory (CSAIL), and co-senior author of the paper on CW-Net. “Unless we are building these technologies in a way that we can rely on and predict their behavior, then it is a shaky and unsafe foundation for their use.”

She is joined on the paper by lead author Eoin Kenny, a former MIT postdoc who is now a senior AI researcher at J.P. Morgan Chase; co-senior author Momchil Tomov, a staff research scientist at Motional; as well as Motional team members Akshay Dharmavaram, Sang Uk Lee, Tung Phan-Minh, Shreyas Rajesh, Yunqing Hu, and Laura Major, president and CEO of Motional. The research appears today in Nature.

Faithful explanations

Machine-learning-based planners act as the “brain” of a self-driving car. These powerful deep-learning architectures process data from the vehicle’s cameras and lidar sensors, generate a high-level summary of the vehicle’s environment, decide what the car should do next, and output a trajectory for it to follow.

The planners are usually black-box models, which means their internal decision-making process is so complex it is difficult to understand. This can leave scientists and safety drivers in the dark about why an autonomous vehicle made an unexpected decision, like phantom braking.

The researchers designed CW-Net to explain a vehicle’s decisions using understandable concepts, while ensuring those explanations accurately reflect the true reasons behind its behavior. 

“Especially in high-stakes settings like self-driving cars, it’s important that the explanations are not potentially misleading. Because CW-Net is causally faithful in how it makes decisions, that provides certain guarantees around the explanations,” Kenny says.

CW-Net is a “concept classifier,” an AI algorithm that has been trained to predict the high-level concepts that exist within input data. The researchers plug the CW-Net module into the middle of an autonomous vehicle’s existing machine-learning planner architecture.

It translates the model’s internal reasoning process into understandable concepts, like “approaching stopped vehicle” or “close to cyclist.” Then it forces the final piece of the planning model architecture to use those concepts when it decides what the vehicle should do next. In this way, CW-Net ensures the concepts faithfully explain the vehicle’s actions. 

At the same time, CW-Net uses the concepts it classified to generate clear explanations that are output along with the vehicle trajectory, in real-time.

“Instead of just wondering why the car stopped, having real-time data provides feedback that lets you test the system during deployment. You could also give that data to an engineer to potentially improve the system,” Kenny says. 

The researchers trained CW-Net to predict concepts using a dataset of 130 million examples of scenes from self-driving cars, with multiple labeled concepts in each scene. Using such a large, labeled dataset enables it to identify concepts accurately in a wide range of settings.

They also designed CW-Net to mimic the driving decisions of machine-learning-based planners, so the module would not negatively impact vehicle performance.

In the end, CW-Net generates accurate, understandable explanations without altering the original deep learning model.

Improving situational awareness

To test CW-Net, the researchers deployed the module on a real autonomous driving test vehicle (a Motional robotaxi) on a private track with a safety driver. They found that CW-Net helped the safety driver better predict how the vehicle would behave in surprising situations.

For instance, the vehicle consistently stopped when it approached a cyclist, and the safety driver assumed it did so because it detected that cyclist. But CW-Net explanations revealed that the model wasn’t properly configured to detect the cyclist and chose a trajectory that would have caused a collision. Instead, it stopped because its emergency braking procedure kicked in when it got too close.

Armed with this information about the model’s mistake, the safety driver could reduce speed or engage manual driving mode sooner in similar situations. This could also help engineers fix the model to avoid this failure in the future.

In larger online simulation studies using real driving situations captured on the roads of Las Vegas, the researchers saw similar results. CW-Net explanations significantly improved participants’ abilities to predict how an autonomous vehicle will behave.

In the future, the researchers could extend CW-Net so the module can cover more concepts and explore different training and design techniques that could boost performance and improve interpretability.

“Our study shows how crucial interpretability can be to these high-stakes environments, and how it should be on the mind of people as they are making AI in the future, for self-driving cars or other safety-critical environments,” Kenny says.

Despite amazing progress in reasoning, language, and pattern recognition, AI still falters when asked to plan far ahead. From supply‑chain optimization to autonomous strategy, today’s systems excel at short‑term prediction but stumble with sustained foresight. This article explores why long‑term planning remains one of AI’s hardest frontiers—and what breakthroughs are beginning to reshape that horizon.

The Myth: AI as a Master Strategist

Popular narratives often portray AI as a flawless planner—capable of orchestrating complex operations, predicting outcomes years in advance, and optimizing every decision along the way. In reality, most AI systems are reactive, not strategic. They respond to immediate data, optimize short‑term objectives, and lack the structural memory or causal reasoning needed for durable plans.

The myth persists because short‑term success looks deceptively like strategy. When a model predicts tomorrow’s demand or next week’s traffic, it feels intelligent. But true planning requires temporal abstraction—the ability to reason across time, uncertainty, and changing goals.

Why Long‑Term Planning Is Hard for AI

1. The Horizon Problem

AI models are trained on finite sequences. Whether in reinforcement learning or predictive modelling, the system’s “view” of the future is limited by its training horizon. When rewards or outcomes occur far downstream, the signal fades. This leads to temporal discounting—the tendency to prioritize immediate gains over distant ones. Humans intuitively bridge this gap through imagination and narrative; machines do not.

2. The Fragility of Goals

Real‑world goals evolve. A company’s priorities shift, markets fluctuate, and constraints change. Most AI systems assume static objectives—once trained, they pursue the same reward function indefinitely. When the environment changes, the plan collapses. Long‑term planning demands adaptive goal management, something current architectures rarely support.

3. The Missing Model of the World

To plan effectively, an agent must understand how the world works—how actions ripple through time. Large language models and deep networks learn correlations, not causality. Without a causal model, they can’t simulate consequences beyond immediate feedback. This is why AI often fails at multi‑step reasoning in open environments: it lacks a coherent internal map of cause and effect.

4. Computational Explosion

Planning across long horizons requires exploring exponentially more possibilities. Even with modern GPUs and distributed systems, the combinatorial space of future states grows faster than computation can handle. Humans simplify through intuition and heuristics; AI must brute force or approximate. The result: strategic blindness beyond a few steps.

5. Memory and Continuity

Most AI systems have short‑term memory. They can recall context within a conversation or simulation but struggle to maintain continuity across months or years. Long‑term planning requires persistent memory—tracking commitments, dependencies, and evolving conditions. Without it, AI becomes a brilliant tactician but a poor strategist.

Why the Myth Persists

AI’s short‑term brilliance creates the illusion of foresight. When a model predicts stock trends or optimizes logistics, it looks strategic. But these are local optimizations, not global plans. The myth endures because success in narrow domains feels like general intelligence.

Media narratives amplify this confusion, equating predictive accuracy with strategic depth. In truth, prediction ≠ planning. Prediction answers “what might happen next.” Planning answers "What should we do now to shape what happens later?"

The Breakthroughs: Toward Temporal Intelligence

Recent research is beginning to chip away at these limits:

• Hierarchical Reinforcement Learning: breaks complex tasks into sub‑goals, enabling multi‑level planning.
• World Models: agents learn internal simulations of their environment to reason about future states.
• Memory‑augmented architectures: integrate long‑term context retention.
• Causal reasoning frameworks: allow models to infer how actions propagate through time.
• Hybrid human‑AI planning systems: combine machine precision with human foresight.

These innovations mark the emergence of temporal intelligence—AI that doesn’t just react but anticipates.

The Real‑World Implications

Long‑term planning failures manifest everywhere:

• Autonomous vehicles misjudge rare future events.
• Supply‑chain optimizers fail under unexpected disruptions.
• Conversational agents lose coherence across extended dialogues.
• Strategic AI in business or defense overfits to short‑term metrics.

Understanding these limits isn’t pessimism—it’s realism. It’s how we design systems that complement human foresight rather than replace it.

The Future: Designing for Time

The next generation of AI will treat time as a first‑class dimension, not a side effect. That means:

• Embedding temporal reasoning into architectures.
• Building persistent memory systems that evolve with experience.
• Integrating human strategic oversight to guide adaptive goals.
• Developing ethical frameworks for long‑term impact assessment.

When AI learns to think in decades, not milliseconds, it will finally begin to plan like us—and perhaps beyond us.

Closing Thought

AI’s struggle with long‑term planning isn’t a flaw—it’s a frontier. The challenge isn’t teaching machines to predict the future; it’s teaching them to care about it. Only then will intelligence become truly strategic.

Conceived, written, and published by AI Quantum Intelligence with the help of AI models.

Reinforcement Learning (RL) has driven some of AI’s most celebrated breakthroughs—from AlphaGo’s mastery of Go to robotic control and autonomous navigation. Yet outside controlled environments, RL faces hard limits: data scarcity, reward ambiguity, and the messy unpredictability of the real world. This article explores why RL’s promise often collides with practical reality—and what that means for the next generation of intelligent systems.

The Myth: Reinforcement Learning as a Universal Solution

Reinforcement learning is often portrayed as the ultimate path to artificial general intelligence. The narrative goes like this: give an agent a goal, let it interact with its environment, and it will learn optimal behavior through trial and error—just like humans.

But that’s a myth.

In practice, RL systems thrive only in well-defined, closed environments where rewards are clear, feedback is immediate, and the world is stable. The real world is none of those things.

What Reinforcement Learning Actually Does

At its core, RL is a framework for learning through interaction. An agent observes a state, takes an action, receives a reward, and updates its policy to maximize cumulative reward over time.

This loop works beautifully in simulation:

• The environment is deterministic or at least bounded.
• Rewards are precisely defined.
• Exploration is cheap.
• Failure is safe.

But when RL steps into the real world—factories, cities, markets, or social systems—the assumptions collapse.

The Limits of Reinforcement Learning

1. Reward Design: The Fragility of Objectives

Real-world goals are rarely simple. How do you define “success” for a delivery drone? Fastest route? Safest route? Least energy use? Least noise? Each objective changes the behavior dramatically.

Poorly designed rewards lead to reward hacking—agents exploiting loopholes in the system rather than achieving the intended outcome. In complex environments, defining the right reward is often harder than solving the problem itself.

2. Data and Experience: The Cost of Exploration

In simulation, an RL agent can fail millions of times without consequence. In reality, every failure costs time, money, or safety.

Robots can’t crash thousands of times to learn balance. Autonomous vehicles can’t experiment freely on public roads. Financial trading agents can’t “explore” by losing millions.

The result: sample inefficiency. RL needs enormous amounts of data to converge, but real-world data is expensive and risky to collect.

3. Environment Stability: The Moving Target Problem

RL assumes a stationary environment—one that doesn’t change faster than the agent can learn. The real world is dynamic. Markets shift, weather changes, humans adapt.

When the environment evolves, the learned policy becomes obsolete. Agents must relearn continuously, often faster than they can adapt. This makes RL brittle in domains where non-stationarity is the norm.

4. Scalability and Generalization

RL agents are specialists, not generalists. An agent trained to play chess cannot drive a car. Even small changes in environment parameters can break performance.

Generalization—the ability to transfer learning across contexts—is RL’s Achilles’ heel. Despite advances in meta-learning and hierarchical RL, robust transfer remains elusive.

5. Safety and Ethics

Trial-and-error learning is inherently risky when actions affect people or property. How do you ensure safety while allowing exploration? How do you prevent unintended harm while optimizing rewards?

These questions make RL deployment in healthcare, finance, and public systems deeply challenging. Without strong constraints, RL can amplify bias, exploit loopholes, or destabilize systems.

Why the Myth Persists

Reinforcement learning success stories are spectacular—and seductive:

• AlphaGo defeating world champions
• DeepMind’s agents mastering Atari games
• Robotics demos showing self-taught dexterity

These examples create the illusion that RL can learn anything. But they occur in synthetic world-bounded, rule-based, and perfectly measurable.

The myth persists because simulation success scales faster than real-world complexity.

The Breakthrough: Hybrid Intelligence

The frontier isn’t pure RL—it’s hybrid systems that combine reinforcement learning with symbolic reasoning, supervised learning, and human feedback.

Emerging approaches include:

• Offline RL: learning from historical data rather than live exploration
• Human-in-the-loop training: integrating expert feedback to shape rewards
• Model-based RL: using predictive models to simulate outcomes safely
• Hierarchical RL: structuring learning across multiple levels of abstraction

These methods bridge the gap between theoretical elegance and practical reliability.

The Future: Reinforcement Learning as a Component, Not a Core

In the next decade, RL will evolve from being the centerpiece of AI ambition to a specialized tool—powerful when used in the right context but limited when applied indiscriminately.

Its greatest value will lie in:

• Adaptive control systems
• Simulation-based optimization
• Game-theoretic modeling
• Multi-agent coordination

But for open-ended reasoning, creativity, and social intelligence, RL alone is insufficient.

Closing Thought

Reinforcement learning is not the road to general intelligence—it’s a remarkable but bounded technique for structured environments. Its limits remind us that intelligence isn’t just about maximizing rewards; it’s about understanding context, constraints, and consequences.

The real breakthrough will come when we stop treating RL as magic and start integrating it as one piece of a broader, more human-centered AI architecture.

Conceived, written and published by AI Quantum Intelligence with the help of AI models.

Retrieval is critical in AI agents. To do any task correctly, the agent needs to be able to retrieve all the information that is relevant to the task from its memory.

Context graphs are all the rage right now, so I benchmarked them against the alternatives.

This post explains how each memory method works, what the benchmark asks, what the data is, and what each method got right and wrong.

The agent failure case

One of our clients came to us after their in-house agent kept dropping facts. A sales-support agent which needs to know "which office handles our Acme account?" to do a task. It couldn't answer this.

The agent had everything it needed for answering this in its memory. Full conversation histories, vector databases on top, the lot. Someone had already noted that the Acme account is handled by Dana. Somewhere else, a PostgreSQL row noted that Dana works out of the Berlin office.

Both facts were sitting right there but the agent failed to retrieve them and put two and two together.

To correctly retrieve and get the answer, the agent's retrieval method had to join two facts that were never said in the same breath, and nothing in the agent's standard memory setup did that on its own.

A context graph is built to fix these failures.

What similarity search can't do

Here are two facts an agent might ingest in its memory, days apart:

The Acme account is handled by Dana.
Dana works out of the Berlin office.

Now the question is: "Which office handles the Acme account?"

No single message answers it. You have to chain two facts that were never said together. This is called a multi-hop question, because the answer is two hops away: the Acme account, to Dana, to the Berlin office.

How each memory method works

I tested four ways to give an agent memory. Hold the above example in your head, I'll use it to walk through how each memory method works. When I get to the benchmark I'll switch to the data I actually run (software agents coordinating on work).

If you already know about these retrieval methods, skip to the benchmark.

1.Raw context

The simplest possible memory where you dump everything, including the conversation histories and PostgreSQL dbs, in the memory. The model reads this text dump to answer the question.

Obvious issues with this method that don't need a benchmark to understand -

1. Cost. You resend the whole history on every single question, and that bill grows with every message.
2. Attention. LLMs reliably read the start and end of a long context and get hazy in the middle.

2.Vector RAG

This is the standard production method today. "RAG" is retrieval-augmented generation: instead of sending everything, you try to retrieve only the relevant bits from the memory and send those to the LLM.

1. You take each message and run it through an embedding model, which turns text into a list of numbers (a vector) that captures its meaning.
2. Similar meanings land near each other in this number space. "Who looks after the Acme account" lands near "the Acme account is handled by Dana", because the model knows "looks after" and "handled by" mean the same thing. You store all these vectors.
3. When a question comes in, you embed the question too, find the handful of stored messages whose vectors are nearest, and send only those to the model.

This is genuinely powerful. It shrugs off wording. Ask who "looks after" an account and it finds who it's "handled by." And the cost is flat: you always send the same small handful of messages, no matter how long the history gets.

But notice what it does for the account question. It scores each message against your question on its own.

• "The Acme account is handled by Dana" looks relevant, it has "Acme account."
• "Dana works out of the Berlin office" looks much less relevant, because your question never mentions Dana.

So the second fact, the one you actually need for the office, often doesn't get retrieved. Standard vector search ranks facts one at a time. It has no way to say "fetch this fact, then follow it to the next one." And better embeddings won't fix this.

3.Context graph

In a context graph, you stop storing the text directly, and instead store the facts extracted from the text as a graph.

A graph is nodes connected by edges. Each node becomes an entity, each edge becomes a relationship between entities. When the conversation histories and PostgresSQL dbs are ingested into a context graph memory, the two account facts would be saved as follows:

(Acme account) --HANDLED_BY--> (Dana)
(Dana) --WORKS_IN--> (Berlin office)

Now the multi-hop question is a walk in this graph. Start at the Acme account, follow the HANDLED_BY edge to Dana, follow the WORKS_IN edge to the Berlin office. Two hops to get the exact answer. The graph does natively what vector search can't: it follows one fact to the next.

Two more advantages here -

1. distance stops mattering, as a fact from message 3 and a fact from table row 300 are both one hop from the node they describe, so old facts are as easy to reach as new ones.
2. It's tiny. It stores "Dana, works in, Berlin office", not the paragraph that sentence came in, so there's almost nothing to send to the model.

The difficult, as you may have already sensed, is that to build the graph you first have to turn messy sentences into clean triples, and you need to do this well.

4.Hybrid

I added a hybrid method that made sense, where I use the graph when it works, and fall back to vectors when it doesn't.

Benchmark with synthetic data

Let's leave our running example behind here.

I ran two benchmarks, one where I created a synthetic dataset myself, and another where I used the LoCoMo dataset.

I'll start with the synthetic dataset. Each test is on scripted conversations in one of three Slack channels: software, customer account management, ad hoc projects. A few real facts get scattered through dozens of filler messages ("sounds good, syncing after standup", "did the nightly build pass?"). Then the benchmark asks questions and checks the answer against the known truth.

3 Slack channel types × 12 scenarios/seed × 5 seeds = 60 conversations. 6 tests on each conversation = 360 tests (60 per test type).

Example conversation: infra_s0_0 (54 turns)

 0  agent_b: Sprint planning moved to Thursday.
 1  agent_c: The demo went fine, no blockers.
 2  agent_b: FeatureStore is owned by Lena.                  <-- FACT
 3  agent_a: Logs look clean on my end.
 4  agent_c: The demo went fine, no blockers.
 5  agent_b: Can someone re-run the flaky test?
 6  agent_c: Grabbing coffee, back in five.
 7  agent_c: Heads up, CI is slow today.
 8  agent_b: Lena is on the Trust team.                      <-- FACT
 9  agent_a: I'll open a ticket for that later.
10  agent_b: Heads up, CI is slow today.
11  agent_c: Sprint planning moved to Thursday.
12  agent_c: Cache hit rate looks healthy.
13  agent_b: Logs look clean on my end.
14  agent_a: Sounds good, I'll sync after standup.
15  agent_a: No update from the vendor yet.
16  agent_c: Sounds good, I'll sync after standup.
17  agent_b: ReportingAPI is set to high priority.           <-- FACT
18  agent_a: Heads up, CI is slow today.
19  agent_c: Grabbing coffee, back in five.
20  agent_a: Thanks for the review earlier.
21  agent_a: The demo went fine, no blockers.
22  agent_c: Bumping the memory limit on that pod.
23  agent_a: Grabbing coffee, back in five.
24  agent_b: IngestWorker, which loads incoming events, depends on ConfigService.  <-- FACT
25  agent_b: Can someone re-run the flaky test?
26  agent_b: Let's circle back next week.
27  agent_c: Can someone re-run the flaky test?
28  agent_c: Heads up, CI is slow today.
29  agent_c: Sprint planning moved to Thursday.
30  agent_c: Let's circle back next week.
31  agent_b: Grabbing coffee, back in five.
32  agent_c: No update from the vendor yet.
33  agent_b: ConfigService is owned by Sara.                 <-- FACT
34  agent_a: Let's circle back next week.
35  agent_a: Sprint planning moved to Thursday.
36  agent_a: Did the nightly build pass?
37  agent_c: Logs look clean on my end.
38  agent_b: Grabbing coffee, back in five.
39  agent_a: The demo went fine, no blockers.
40  agent_a: Did the nightly build pass?
41  agent_a: No update from the vendor yet.
42  agent_b: Update: ReportingAPI is now medium priority.    <-- FACT (supersedes turn 17)
43  agent_a: Sprint planning moved to Thursday.
44  agent_c: Quick question about the staging config.
45  agent_c: Logs look clean on my end.
46  agent_b: Cache hit rate looks healthy.
47  agent_c: I'll open a ticket for that later.
48  agent_a: Heads up, CI is slow today.
49  agent_c: Can someone re-run the flaky test?
50  agent_b: Heads up, CI is slow today.
51  agent_a: Decision: ReportingAPI, which serves usage reports, depends on FeatureStore.  <-- FACT
52  agent_a: Sounds good, I'll sync after standup.
53  agent_c: Logs look clean on my end.

All code, data, results are in this repository.

The six types of tests on each conversation

I built six question types -

1. Direct. A fact stated recently. "What does ReportingAPI depend on?" Answer: FeatureStore. This is a sanity check everything should pass.
2. Distant. A single fact stated long ago which is buried under distractors. "Which team is Lena on?" Answer: Trust. Tests whether old facts get lost in the noise.
3. Join (2 hops). Chain two facts. "Who owns the component that ReportingAPI depends on?" ReportingAPI depends on FeatureStore, and FeatureStore is owned by Lena. Answer: Lena. The second fact never mentions ReportingAPI, so a retriever searching for "ReportingAPI" won't find it.
4. Multi-hop (3 hops). Chain three facts. "Which team owns the component that ReportingAPI depends on?"ReportingAPI, to FeatureStore, to Lena, to the Trust team. Answer: Trust. Now a retriever has to land three specific turns at once.
5. Update. A value changed, and the current one must win. "What priority is ReportingAPI now?" It was high, then medium. Answer: medium. Tests whether stale facts get cleared.
6. Paraphrase. The entity is named by description, not by its id. "What does the analytics endpoint depend on?" "The analytics endpoint" is ReportingAPI, but the conversation never says so explicitly. Answer: FeatureStore.

Results on synthetic data

Accuracy by question type:

Note: The hybrid's perfect 100% here is a ceiling and not a production number. It assumes perfect fact extraction which is what this synthetic benchmark hands every method.

Direct and distant: everyone passes

These are single facts, stated once. A real embedder finds them whether they were said one message ago or fifty. Distance alone is not the problem.

Join: only the graph can chain facts

The trap here is that NotificationHub's own owner is Priya, so a method that can't do the second hop tends to answer Priya.

Look at the wrong answers. Raw dump and vector both said Priya, and that's revealing. Priya owns NotificationHub. They retrieved the fact about NotificationHub's owner and stopped. They couldn't take the second hop, from NotificationHub to its dependency FeatureStore to that component's owner.

The needed fact, "FeatureStore is owned by Diego", doesn't mention NotificationHub, so vector RAG scores it low against a question about NotificationHub and never retrieves it.

The graph simply walked it: NotificationHub, DEPENDS_ON, FeatureStore, OWNED_BY, Diego.

Multi-hop: same as the 2-hop join

Adding a third hop widens the gap. The answer needs three specific fact chains, ReportingAPI to FeatureStore, FeatureStore to Lena, Lena to Trust team. Only the first fact names ReportingAPI explicitly. Vector RAG manages 0% here, slightly worse than its 7% on the two-hop join. The graph just needs to take one more step along the edges, and thus scores 100%.

Update: vectors serve you stale facts while graphs don't

SearchIndexer was set to low priority, then escalated to critical. Vector RAG returned low, the stale value. Both turns look almost identical to the question "what priority is it now".

Vector search has no sense of time, so can randomly pull the older message and answer with a fact that's no longer true. It scores 63% across the tests, right when retrieval happens to surface the newer turn, wrong when it grabs the stale one.

The graph gets it right by design. When the new priority arrived, it deleted the old edge before adding the new one, so the stale value is simply gone.

Raw dump got it right too, but by luck, not design. It always sees the most recent messages and recency happened to save it.

Paraphrase: blind spot of a standard context graph

The graph returned nothing at all. "The alerts system" is NotificationHub, but the graph stores a node literally named "NotificationHub". It tried to match the words, found no node called "alerts system", and the walk never started. The context graph scores zero percent on paraphrase and this is its blind spot.

Vector search doesn't care what you call things. "Alerts system" and "NotificationHub, which handles outbound notifications" are close in meaning, so it found the right message and read off the owner.

Raw dump gave the funniest wrong answer: the EU region. It grabbed a recent NotificationHub fact, i.e. something about the deployment region, and returned that.

Cost and latency

Here's what each method spends to answer one question, measured in tokens with the GPT-4 tokenizer:

Also, the raw dump's cost grows with the memory size, while the others stay flat. I held the facts fixed and padded the conversation with filler. At 800 turns the raw dump sends 13,623 tokens to answer one question. The graph sends 17, the same as it did at turn one and answers correctly:

Retrieval speed tells the same story. These are in-memory times in milliseconds, median per query:

The graph walks two edges while vector search embeds the question and scores it against every message, so traversal is the cheap operation. The hybrid's median is lowest because the graph answers most questions, and only the paraphrase misses pay the embedding cost.

What about recursive RAG?

Plain top-k is the naive baseline is vector RAG. Theoretically, you can also go for iterative / recursive retrieval. Take the test we say earlier where we asked "Who owns the component that ReportingAPI depends on?"

• Round 1: top-k for the question → retrieves "ReportingAPI depends on FeatureStore."
• Round 2: now embed that retrieved chunk and find its neighbours. That chunk contains FeatureStore, so "FeatureStore is owned by Diego" is now similar to what you're searching with and it gets pulled in.

But this is inefficient. Why?

1. It is graph traversal over fuzzy edges. "Chunks that share an entity" is an implicit edge, and you do BFS over it at query time. Iterative / recursive vector RAG will re-derive the graph on every query while the graph pays for this operation only once, as it is precomputed at write time.
2. Top-4, then top-4 of each (16), then 64… most of it is noise. You either blow up the token budget or prune aggressively and risk dropping the one chunk you needed. The graph follows the relevant edges with much more precision.
3. The bridge has to be very clean for it to work. It works in this example because "FeatureStore" is a tidy shared string. In real dialogue the link is a pronoun, an implicit reference, or different wording ("the store" / "it"), and then the expansion drifts or misses.
4. Naive expansion drifts on overall similarity. The versions that work well use an LLM to plan the hops ("first find what ReportingAPI depends on, then who owns that"), which means multiple LLM round-trips per question. You trade the graph's one cheap walk for a reasoning loop.

If implemented on the above benchmark, my guess is that recursive RAG closes some of the 2-hop join gap, costs noticeably more tokens, and still trails on the multi-hop case.

The hybrid method

The graph owns joins and updates, and vectors own paraphrase, so one can just use both.

The hybrid asks the graph first and takes the answer if the walk succeeds. If the graph draws a blank, which on this benchmark means a paraphrased question, it falls back to vector search.

That one rule keeps every join and update the graph got right and recovers the paraphrases it dropped. It lands at 92.3% overall, for 26 tokens a query.

The pure graph, for all its multi-hop strength, sits at 80% because paraphrase drags it down. The lesson here was to bolt your context graph memory with methods that can answer paraphrase questions.

Benchmark with real data

LoCoMo is a public dataset of ten very long conversations, ~600 turns each, with 1,982 human-written tests.

In LoCoMo, each conversation is a long relationship between two people, split into multiple chat sessions (multiple chat sessions in a conversation happened days/weeks apart). Each chat session is a list of messages. For example, conversation_0 had 19 chat sessions with 419 total messages. The dia_id encodes it: D1:3 = chat session 1, message 3.

Single-hop (one evidence turn):

Q: "What was Melanie's favorite book from her childhood?" Answer: "Charlotte's Web" Evidence D6:10, Melanie: "I loved reading 'Charlotte's Web' as a kid. It was so cool seeing how friendship and compassion can make a difference."

Multi-hop (multiple evidence turns in multiple chat sessions):

Q: "What do Melanie's kids like?" Answer: dinosaurs, nature Evidence D6:6, Melanie: "They were stoked for the dinosaur exhibit! They love learning about animals..." Evidence D4:8, Melanie: "It was an awesome time! They love exploring nature, and they also roasted marshmallows around the campfire..."

The good thing was the dataset gave evidence labels in the test answers, which let me test this with no LLM at all.

Results on real data

Everything so far hands each method perfect, pre-extracted facts. That isolates retrieval, which is what I wanted to measure. But in production, an LLM has to read each memory ingestion request and pull out the triples.

The graph needs triples, so Claude Haiku reads the dialogue in batches and extracts them in a context graph.

def batch_extract(turns, batch=12):
    triples = []
    for chunk in batches(turns, batch):
        text = "\n".join(f"[{t.speaker}] {t.text}" for t in chunk)
        # "Extract relationships as JSON: [{subject, predicate, object}]"
        triples += parse_json(claude(EXTRACT_PROMPT + text))
    return triples           # ~1 triple per turn on LoCoMo

Then I used the context graph to decide which messages to read (take the top triples, follow their entities one hop to the connected facts, map those facts back to the messages they came from), and hand the model those messages:

top   = argsort(-(triple_vectors @ embed(question)))[:k]      # top triples
seed  = {s for s,p,o in top} | {o for s,p,o in top}
hood  = rank_by_similarity(t for t in triples if t.subject in seed or t.object in seed)[:k]
turns = {provenance[t] for t in top + hood}                   # back to source messages
ctx   = facts(top + hood) + "\n" + "\n".join(turn_text[i] for i in sorted(turns))
graph_answer = claude(f"Answer using only:\n{ctx}\n\nQ: {question}")

Vector RAG embeds every raw turn and, per question, sends the top-k turns to Haiku to answer:

qv  = embed(question)
top = argsort(-(turn_vectors @ qv))[:k]            # top-k turns by cosine
ctx = "\n".join(turn_text[i] for i in top)
vector_answer = claude(f"Answer using only:\n{ctx}\n\nQ: {question}")

A separate Claude Haiku call judges each answer against the truth. Here's how they landed:

In most of these tests, the answer lived in a turn that never made vector's top-25, but the context graph triples for it sat relatively closer to the question in the graph.

Fixing the graph's blind spots

My point was to show the advantages that context graphs bring when used in AI agents. This is by no means a production grade implementation of context graphs, which tends to be a lot more technically rigorous.

What would move the context graph score above 42.3%?

There are many optimizations that production teams use to improve how they employ context graphs -

1.Better search

My context graph answers in two distinct steps:

1. Entity linking. Turn the question's mention ("the analytics endpoint") into a starting node ("ReportingAPI").
2. Traversal. From that node, follow edges (DEPENDS_ON, then OWNED_BY). This is deterministic pointer-chasing with no model in the loop, also the reason why the graph is cheap (15–30 tokens, microseconds).

The paraphrase failures happen entirely in step 1, before any traversal happens. In my benchmark the resolver (ContextGraphMemory._resolve) matches the mention to a node by lexical token overlap:

"the analytics endpoint" vs node "ReportingAPI" -> shared tokens: 0 -> no match

The graph isn't bad at the question; it just never gets to ask it.

But production systems make step 1 semantic, where you embed the node labels (or ask an LLM) and match "analytics endpoint" → "ReportingAPI, which serves usage reports" by meaning.

Instead of keyword search, we can use semantic search on the context graph to completely solve for the paraphrase tests and also do better on the LoCoMo dataset.

2.Better extraction

The graph is only ever as good as the triples you pull out of the text.

1. Extract in more than one pass. One read of a long message leaves facts on the floor. Run it again, or ask the model what it missed the first time. The second pass is cheap next to the cost of never having the fact.
2. Give the extractor a schema. Hand it the relation types you care about, OWNED_BY, REPORTS_TO, DEPENDS_ON, so it fills fixed fields instead of inventing a predicate every time. Inconsistent predicates are exactly why updates and joins broke for me: "has priority", "is now", and "priority set to" are three keys for one relationship, and the graph can't line them up. A schema pins them down.
3. Keep the source text next to every fact. For example, hand the model the original data embedded in the graph node as an attribute, not just the terse triple.
4. Capture what triples usually throw away. List items as separate edges, timestamps on edges so "when did she go?" has a date to find, and pronouns resolved to names at write time, so "she" becomes "Melanie" before it reaches a node.

All of this costs model calls at ingestion. That is a cheap trade where you pay once per message, up front, so every later query stays cheap and correct. For an agent that answers many questions over a long history, that trade usually pays for itself.

3.Better model

A stronger model helps in two places, and they are not equally important.

At extraction, which is where it matters most. A more careful model reads a rambling message and pulls out more of the facts, with cleaner entities and fewer inventions. Extraction caps the whole score, so the model you extract with matters more than the one you answer with. Spend your budget upstream.

At answering, for the questions that aren't lookups. "Would Caroline pursue writing?" isn't stored anywhere. The model has to reason from what was. A stronger reader turns "here are the facts" into the right inference more often, and that is most of what's left once retrieval is solved.

Where to use context graphs

Build a context graph when your agents run long, decisions made early have to survive many turns, and questions chain facts together. That's most multi-agent work.

Enterprises and startups use our agentic harnesses and context graphs to automate various processes, including ones with -

1. High team size. If you have 50 people running a workflow manually. The headcount is high only because the decision logic is too complex to automate with traditional AI tools.
2. Exception-heavy decisions. Think about procurement, insurance claims, deal desks, compliance. In these jobs, the answer is always "it depends."
3. Cross-functional roles. RevOps, FinOps, DevOps, Security Ops. These roles emerge precisely because no single system of record owns the cross-functional workflow. Your company creates a role to carry the context.

Procurement, finance, claims, deal desk, underwriting, escalation management are few examples.

Read more here.

You can skip it when conversations are short, or when questions are fuzzy and open-ended, the kind where you want semantic recall more than an exact walk. Note that graph adds an extraction cost you'll have incur and a vocabulary problem you'll need to fix.

The code, data, and every table here are reproducible from the repository.

In AI agents, a context graph is the part of agent memory that captures decisions.

This post explains why agents need to capture decisions, how context graphs achieve this, and how agents can use these graphs.

An agent failure case

It's the last week of the quarter. A renewal agent is working a $480k account. The customer wants 20% off or they walk. The agent's instructions state >$100k accounts should not churn, but the agent's policy caps renewals at 10%. Now what?

If a human was handling this, they'll probably use experience and memory to resolve.

Didn't we do this exact thing with Globex last quarter? It was a similar story. They were threatening to churn, and someone signed off on 20% because the CEO wanted to retain Fortune 500 logos and the risk was worth taking on a $300k account. It worked and Globex renewed shortly after.

This reasoning chain that makes the decision is not written down anywhere your agent can read. The agent will find Globex's exception case in Salesforce, but Salesforce will not tell it that the number was an exception, who approved it, why it was approved, whether the current situation is identical or not.

The why lives in -

1. Old slack threads where finance team admits a $300k account is worth the risk.
2. Zoom calls where sales veterans mention these kind of accounts pay eventually.
3. Emails from the CEO saying retaining Fortune-500 logos is critical.

These are critical pieces of information needed to make the decision, but the agent cannot access them.

So your agent does one of three things -

1. It sends an email informing the policy caps at 10%, and you lose the account.
2. It escalates to a human, who spends 24 hours doing Slack archaeology to reconstruct a decision the company already made once.
3. It makes 500 grep calls via agentic search, and exhausts a large amount of tokens searching, reading, reasoning, and reconstructing context from multiple systems of record. And this happens every time a similar decision needs to be taken.

Either way, the organization failed to benefit by adopting an AI agent.

This is a universal problem. Organizations lose billions each year -

1. making the same mistakes,
2. reinventing the same solutions,
3. wasting time and money on previously solved problems,
4. being incredibly slow at onboarding new employees,
5. struggling with compliance and audit gaps in an AI-native world.

This is because we have gotten extremely good at recording what happened, but we systematically throw away why it happened, which is the one thing your agent needed here.

Context graphs store the why in an agent's memory.

Foundation Capital called it "a trillion-dollar AI opportunity", which is the kind of phrase that sends people reaching for the back button. But stick around anyway. The term is new and a little overloaded, but it points at something real. If you use or build agents, you'll end up using a context graph soon.

Flat context is bad

The bad way to give your AI agents context is to just give them all the data, records, documents, rules, policies in a flat context window.

Say you have an invoice processing agent. You dump the invoice, PO, vendor record, contract, policy document into the context. Then watch the agent fail. Why?

1. Context rot

When the agent asks itself “can I pay invoice #842?” To answer, it has to hop - which PO does this invoice reference? does that PO still have budget? was the delivery received? is the vendor on payment hold? does $12,400 cross the approval threshold? what do the contract's payment terms say? is the policy doc accurate and up-to-date? are there undocumented nuances related to this invoice payment currently living on Slack messages and Zoom call transcripts?

Flat retrieval tries to hand this massive amount of information to the LLM model in a pile of disconnected chunks. Some invoice text here, some PO text there, some language from random docs and slack channels, all given as a flat wall of text.

The agent is forced to re-derive every one of those connections between these pieces of data from scratch on each turn. Flattening business data into loose text destroys exactly the structure it needs.

And as context becomes large, LLMs struggle to cope up with the size and start failing in their tasks. They fail to follow instructions, drop rules randomly, misunderstand the relation between two pieces of information far apart, ignore middle-of-context data, apply rules and constraints out of order.

Surge AI documents this in their instruction-following benchmark. The best frontier model solves <41% of such complex tasks.

2. Lack of decision traces

Like we saw in our first example, AI Agents run into the same ambiguity humans resolve every day with precedents, experiences, organizational memory. But you can't give these things to an agent in a flat context window.

• Tribal knowledge. "We always waive the $5k onboarding fee for logistics companies but only if they push back on the timeline first." That's not in the CRM. It's tribal knowledge passed down through internal conversations.
• Past decisions. "We structured a deal for account X where they split payments into installments. We should offer this similar account Y the same." No system links the two deals to convey why Y's contract was drafted this way.
• Context across systems of record. An account manager sees usage sliding in the product dashboard, an unpaid invoice in NetSuite, a cold one-line email. They flag the account as "churn risk" in the CRM. The reasoning happened in their head, but the CRM record just shows "churn risk".
• Manual approvals. A VP approves a discount on a Zoom call. The Hubspot record shows the changed price. It doesn't show why this decision was made.

Reasoning behind data, decisions, actions isn't captured in a flat context window.

If you are a developer, this concept hits even harder. Why did we pick this queue over that one in 2019? Why is there a sleep(200) in the retry path that breaks everything when you remove it? It was obvious to whoever wrote it, but that information is gone now.

Remember Architecture Decision Records? They were invented back in 2011 to fix exactly this. But most ADR folders die at three entries, because writing them is friction and nobody reads them later.

This is a universal problem. Companies are good at storing what happened, and bad at storing why they happened. This is because the why is unstructured, spread across systems, and nobody reads it even if you store it.

Both problems, context rot and lack of decision traces, are solved by context graphs.

What is a context graph?

A context graph is a way of structuring an agent's memory as a graph, where nodes hold pieces of information and edges hold the relationships between them. It's optimized for the agent to read, not for a human to browse.

Most agent memory today is flat, and is implemented in one of two ways -

1. AI agents embed your data, split them into chunks, and return the few chunks that look most similar to the ongoing task. The LLM gets a pile of text with no sense of how these chunks connect to one another. This is vector RAG, the standard memory used in AI agents today.
2. AI agents are given tools to iteratively search your systems of record to find context (grep, file read, SQL queries, APIs to search and read). This is costly, and again, the LLM needs to infer connections between the chunks of data it retrieves.

A context graph keeps those connections in a graph. Instead of "here are five similar paragraphs," it can say "Service A –depends on–> on Service B," "this release –caused–> that outage," or "this invoice –follows–> that policy." The edges carry meaning, and the model can traverse them.

This matters because similarity is not relevance. Two chunks can share words with your task and still have nothing to do with your actual task. Two other chunks can share no words with your task and still relate to your task semantically.

How to create a context graph?

A context graph goes after both failures, context rot and lack of decision traces, by changing what you store and how.

Start with "how you store". You store your business as a graph. Entities, for example, the invoice, the PO, the account, the vendor, the contract, the policy, the approver, are all nodes in the context graph. The relationships between them are edges. This invoice –references–> that PO. This PO –draws on–> that budget. This budget –approved by–> that person. This vendor –governed by–> that contract.

You store each of those links once, instead of leaving the model to re-derive them from chunks of text every time it needs them. For each task/subtask, the agent pulls a small subgraph and leaves the other ten thousand records out of the window. Context rot goes away, because the window stays small and on-point.

Now the "what you store". You now also store each decision in a context graph. The unit of this context graph will be a decision trace. A flat record stops at the outcome "Initech renewed at 20%". A decision trace keeps the story behind it. The problem that triggered it, the options weighed, why the rejected ones lost, the constraints, the exceptions, who decided, and the reasoning.

This is also what an employee keeps in their head. But with a context graph of decision traces, an agent can read it.

Entities and their relationships, plus decisions and their relationships to entities and other decisions, created across systems of record and time. Foundation Capital's one-liner for it is a "system of record for decisions". Most of your systems already store the current state of things. A context graph stores how the state got that way.

You use a schema for the decision trace that is ideal for your use case.

Now the second half is turning old decisions into something the agent can lean on.

How to use a context graph?

Few implementation details when using context graphs -

Capture it on the way in

Agents with context graphs need to be low friction, otherwise no one will want to maintain them. Capture the decision the moment it is made, not later.

Reconstructing context after the decision will be lossy guesswork, and also costly and time consuming. The meeting is over, the Slack thread scrolled away, the person left the company. Most of the agent's context has slipped away without getting saved in the agent memory.

Capture it when the decision is made, at almost no extra effort. All of the context is already there in the active context window. Also if a human overrides the agent's decision, that override is the moment to ask why and store the answer with minimal friction from the human.

This is also why agents change the economics of organizational memory. We have always known we lose the why. Wikis, Confluence, post-mortems, ADRs: every one of them tries to save it, and every one decays, for the same two reasons. Writing it down is friction, and nobody reads it back.

Agents break both at once. The agent sits in the execution path, so capture is a side effect of doing the work, not an extra task bolted on afterward. And the agent is a tireless reader that will happily consult ten thousand past decisions before making the next one. Organizational memory finally has a reader worth writing for.

Use stored decisions as precedent

Once decisions live in the graph, search turns them into precedent.

1. a new decision choice shows up
2. the agent pull the direct context (entities and their relationships)
3. the agent pulls the closest precedents (past decisions)
4. the agent reasons on the direct context and precedents
5. the agent takes a decision (or suggests it)
6. decision is taken
7. decision is stored as a decision trace in the context graph
8. decision is linked to similar past decisions in the context graph

You can use vector embeddings to find semantically similar decisions, and then apply graph-based filters to narrow by entity properties.

A pile of old decisions becomes memory the agent can actually use. This is also how an agent enter a mode of self-learning without anyone fine-tuning it or updating rules/instructions.

There's a second payoff here. Because traces record exceptions, not just the clean path, you can see when a rule keeps getting overridden. If AP grants the same late-payment exception to twenty vendors, the policy is wrong, not the vendors. The graph can turn this pattern into a signal to fix the underlying policy itself.

Over time, the context graph becomes the real source of truth for autonomy, and your company can easily audit and debug this autonomy.

The recent ACE paper, "Agentic Context Engineering", makes the mechanism concrete:

Treat the accumulated context as a playbook that grows through generation, reflection, and curation, and let real outcomes refine it. The agent gets better by editing what it knows, not by touching a single weight. A correction today becomes a rule tomorrow. A trace today becomes precedent next quarter. This feedback loop enables learning in agents.

Example of an agent using context graphs

Similar to knowledge graphs?

The parts are the same, but the implementation is new.

Knowledge graphs have been around since Google shipped one in 2012. Event sourcing, storing the sequence of events instead of just the latest state, is a pattern any backend engineer already knows. A context graph is close to event sourcing for decisions, where each event drags along its rationale and its links to everything.

So there's no new primitive here. What's new is that you capture the why on the write path as structured data, because for the first time there's a consumer, i.e. the agent, hungry and tireless enough to read it.

Standard RAG, for contrast, retrieves documents that look similar to your question. A context graph retrieves decisions, with their reasoning and their edges to everything they affected. One hands the model text to read. The other hands it structure to walk and precedent to reason from.

Isn't agentic search enough?

There's a sentiment these days that agent memory and retrieval methods are outdated, and agentic search works better. Give the model simple tools (grep, file read, SQL queries, list directories, search) in the agent loop, and let the model itself decide what to look up, look at the result, and search again.

Claude Code initially shipped like this. It just gave the model grep, glob, file-read tools, and the model navigated codebases like a human developer would. And the surprising result was it worked better than Cursor who were using standard RAG.

A recent paper (AgenticRAG) measured retrieval. One-shot search on the BRIGHT benchmark got 8.4% recall, and the same retriever inside an agentic search loop got 49.6%. On FinanceBench, agentic search hit 92% answer correctness, where handing the model perfect evidence gets 94%.

Agentic search works. Given enough turns, the agent finds almost everything that exists in the data.

So why bother with a graph? Two reasons.

1. Agentic search is a brute-force loop, and you pay for it on every query.

That 92% on FinanceBench cost 115K tokens per query, about 8x the single-shot cost. Every hop is another LLM call, so latency stacks the same way. And the agent re-derives the same links every time. Which PO does this invoice reference? Is the vendor on hold? It answered that yesterday, and it will need to answer it again tomorrow.

The graph employs memoization. It stores each link once, and the agent traverses instead of re-deriving. Other benchmarks bear this out.

• A2RAG put a graph under an agent loop and cut tokens and latency by ~50% while gaining ~10 points of recall. 
• GRASP got the highest multi-hop accuracy while spending 40-50% fewer tokens than the strongest search-only baseline.
• A benchmark paper literally titled "Do We Still Need GraphRAG?" found that agentic search narrows the gap, but the graph still wins on hard multi-hop questions and makes the agent's search behavior more stable.

2. Agentic search can only find what was written down.

The Initech decision wasn't in any text. Salesforce shows Globex renewed at 20%. It doesn't say that was an exception, who signed off, or why. The reasoning lived in a Zoom call and three Slack replies, and half of it never left anyone's head.

An agent with search tools will find the what and might still miss the why, because the why was never stored. No search method fixes a write-path problem. But a context graph mandates the storage of every decision trace the moment it is made.

To summarize, agentic search is the correctness baseline, and it's probably still the best method for some tasks. But the context graph does two things on top of it.

1. It caches the hops the agent would otherwise recompute on every query, which is a cost, latency, and in some cases, accuracy optimization.
2. It forces the capture of reasoning at decision time, which search alone can never recover after the fact.

Maybe we let the agent search when the graph comes up empty, and write what it learns back into the graph so the next run doesn't have to?

System-of-record agents won't work

Systems of record probably have it wrong. Salesforce released Agentforce, ServiceNow released Now Assist, Workday is doing something similar. Their reasoning is to add intelligence where the data resides.

But their agents will inherit the exact same limitations as their parents.

1. Systems of record capture what changed, not why. Salesforce tracks field history, but only for a limited set of fields, and only for a while. And when someone approves a discount, no field anywhere stores the reasoning. The context of the decision is gone the moment it's made.
2. These systems also miss data. A support ticket doesn't just live in Zendesk. It needs user tiers from CRM, SLA terms from billing, recent outages from PagerDuty, Slack thread flagging churn risk. No single system of record sees the whole picture. And each vendor's agent treats its own system as the center of the universe. 

Systems of record are building their own agents, locking down APIs (ahem ahem), and slapping egress fees, but they can't insert themselves into an orchestration layer they were never part of.

When an agent triages an escalation, responds to an incident, or decides on a discount, it pulls context from multiple systems and time periods. The orchestration layer alone sees the full picture - what inputs were gathered, what policies applied, what exceptions were granted, and why decisions were taken.

Because it's executing the workflow, it can capture that context at decision time instead of bolting on governance afterwards.

This is the essence of a context graph, and that will be the single most valuable asset for your company in the era of AI.

The hard parts

Before you get too excited -

1. Garbage in, garbage precedent. If the captured rationale is lazy ("approved, see Slack"), your precedents are landfill. The graph is worth exactly the quality of the why you put in it, and writing a good why is real work. But this time, it is certain this work will reap benefits.
2. Who writes the trace. If a human has to type thoughtful rationale every time, it might rot the same way as a wiki. If the agent infers the rationale, you have to trust the inference, and "the model guessed why we did this" is a shaky base. The real answer is somewhere in between, and getting that right is not trivial.
3. The decision swamp. A better name today for data lakes that exist in organizations would be data swamps. We dump everything in them with no schema and no curation. A graph of millions of contradictory, half-true traces is the same failure with extra edges. Without curation, more traces make precedent search worse, not better.
4. This is early. Most vendor decks make it sound shipped. It isn't. The pattern is sound and the early results are unbelievably good. There is something here, definitely. But "great early results" is not "proven," and anyone who tells you otherwise is pitching.

The full stack

An AI-native workflow with context graphs has four layers -

1. Systems of record. Salesforce, SAP, Zendesk, GitHub, Slack, the Zoom transcript from this morning's call. They hold the state of your business - every record, ticket, commit, and message. What they don't hold is the reasoning that connects them. But they're still the ground truth for what is.

2. The harness. It sits in the execution path and runs the reason → act → observe loop. It holds the tools, picks what goes into the model on each step, stores corrections as memory, checkpoints long runs, enforces permissions, logs every decision, and catches errors before they crash the run. This engine turns a stateless LLM into a system that finishes work.

3. The context graph. As the harness runs, every decision leaves a trace: what inputs it gathered, which rule it applied, what exception it took, who approved, and why. The graph stitches those traces across entities and time. Your systems of record stay the truth for what happened. The graph becomes the truth for why.

4. Agents and humans. Agents execute the routine cases end to end. Humans handle the cases the agent flags as uncertain. Every correction a human makes flows back into memory and the graph, so future agent runs are better.

This maps to the two core features of AI-native organizations, Universal context and Loops.

• Universal context is your systems of record made queryable through the context graph. The agent doesn't re-derive the links between an invoice, a PO, a contract, and a Slack message on every turn. The graph already holds them.
• Loops are the harness closing feedback on every run. A correction today becomes a rule tomorrow. A decision trace today becomes precedent next quarter.

Where to start

Build a context graph when your agents run long, decisions made early have to survive many turns, and questions chain facts together. That's most multi-agent work.

Enterprises and startups we work with use context graphs to automate processes with -

1. High team size. If you have 50 people running a workflow manually. The headcount is high only because the decision logic is too complex to automate with traditional AI tools.
2. Exception-heavy decisions. Think about procurement, insurance claims, deal desks, compliance. In these jobs, the answer is always "it depends."
3. Cross-functional roles. RevOps, FinOps, DevOps, Security Ops. These roles emerge precisely because no single system of record owns the cross-functional workflow. Your company creates a role to carry the context.

Procurement, finance, claims, deal desk, underwriting, escalation management are few examples.

Context graph as a map

A clean way to hold all of this in your head:

The model is your brain, the agent / agentic harness is your limbs, and the context graph is the map of your specific world (or company). A superb body with no map of your world stalls at every fork in the road that requires knowing the map, and enterprise processes are nothing but those forks.

All 25 announcements from Orlando, what's actually shipping vs. what's marketing — and what it means for the document and data foundation of the autonomous enterprise.

SAP's Sapphire 2026 in Orlando was the most AI-dense keynote in the company's history. Christian Klein didn't unveil a roadmap. He unveiled capabilities — 25 of them, by our count — ranging from a fundamental repositioning of SAP itself to an embedded Model Context Protocol server, a €1B+ commitment to tabular foundation models, and a robotics partnership packing boxes in SAP's own logistics center.

And yet, while Klein was on stage announcing the Autonomous Enterprise, SAP's stock sat ~28–32% down year-to-date. Analysts kept Buy ratings but quietly reframed AI as "an adoption topic, not a revenue driver yet."

That tension — between the boldness of the vision and the patience of the market — is the most important thing to understand about Sapphire 2026. Below is the complete breakdown: all 25 announcements numbered as they appear, grouped into the seven themes that matter.

Theme 1: The Repositioning

1. The "Autonomous Enterprise" is the new vision. SAP is becoming a "business AI company," not just a software company. Joule, SAP's assistant, delivered the framing line from the keynote stage. The implication: SAP isn't competing with Workday and Oracle anymore — it's competing with Salesforce, ServiceNow, and the agentic AI players for the layer that acts on enterprise data, not just records it.

2. SAP Business AI Platform unifies SAP Business Technology Platform (BTP), Business Data Cloud (BDC), and Business AI into a single stack. It's a consolidation more than a brand-new product — but the signal matters: SAP is positioning one foundation layer above the apps, not three.

Our read: The repositioning is meaningful. But SAP has tried versions of this story before. The question isn't whether SAP wants to be a business AI company. It's whether it can actually ship working AI in production, where every prior attempt has stalled.

Theme 2: The Agent Stack

3. SAP Knowledge Graph — SAP turned 452,000 tables and 7.3M fields into machine-readable semantics for agents to reason against. This is the under-the-hood plumbing that lets Joule agents understand SAP's own data model.

4. 50+ Joule Assistants — domain-specific chat/copilot helpers across finance, procurement, supply chain, HR, and customer experience.

5. 200+ specialized AI agents / "Autonomous Suite" — the agents the assistants orchestrate. Includes Joule for Developers and an ABAP code conversion agent going GA. The only Joule agent with a hard, publicly-stated metric: a 40% efficiency target.

6. Joule Studio 2.0 GA — the build-and-govern environment for agents. Free design-time access through December 31, 2026.

Our read: The Knowledge Graph is the most underappreciated announcement of Sapphire. Without semantic understanding across 452K tables, no agent can reason coherently across SAP data. This is structural plumbing that compounds for years.

The Joule Assistants are harder to evaluate. SAP has been shipping assistants for years — S/4HANA copilots, Joule v1 — and nothing has worked in production at scale. These are UI helpers, not workflow replacements, and that distinction tends to disappear in marketing materials.

The 200+ agent number is impressive on paper, but Salesforce ran this exact playbook with Agentforce twelve months ago, and the production reality fell well short of the pitch. The 40% efficiency target on the ABAP agent is the only number with teeth. Watch what gets quantified next — and what doesn't.

Theme 3: The Ecosystem Opens

7. SAP AI Agent Hub — a vendor-agnostic marketplace for agents (SAP and third-party). GA Q3 2026. SAP has reportedly taken 680+ partner submissions.

8. Model Context Protocol (MCP) embedded in Business Data Cloud and Reltio. Third-party agents — built outside SAP — can plug into SAP's data layer through an open protocol, not a proprietary integration.

9. n8n partnership and SAP equity stake at a reported $5.2B valuation. Workflow orchestration embedded directly in Joule Studio.

10. Strategic partnerships across the stack: Anthropic (Claude becomes a primary reasoning model embedded across Joule), AWS (zero-copy integration with Athena), Google Cloud + Microsoft (bidirectional Agent-to-Agent / A2A protocol, GA Q4 2026), Mistral and Cohere (sovereign model options), NVIDIA (OpenShell as the secure runtime for Joule Studio).

Our read: This is the structural shift that matters most. For the first time, SAP is opening defined interop paths — MCP, A2A, the AI Agent Hub — that let specialized AI tools plug into the SAP ecosystem without proprietary engineering. The walled garden is becoming a network.

Practically: if Joule Assistants get a finance or procurement workflow 70–80% of the way there, the last 20–30% — accurate document extraction, vendor data enrichment, contract intelligence, edge-case automation — can now be handled by specialized agents communicating over MCP. That's a fundamentally different vendor landscape than the one we had at Sapphire 2025.

Theme 4: Data Foundation Moves

11. Reltio acquisition closed — master data management for SAP and non-SAP environments. Reltio's strength is connecting to non-SAP sources and handling complex multi-source data — exactly where SAP's native stack has been thin.

12. Dremio acquisition (data lakehouse), expected to close Q3 2026.

13. €1B+ commitment to Prior Labs for tabular foundation models (SAP-RPT-1.5). Relevant for structured data extraction — turning messy business data into structured rows agents can consume.

Our read: Three moves of this magnitude is SAP saying out loud what enterprise teams have known for years: the data flowing into SAP — from documents, from non-SAP systems, from unstructured sources — is not in a state where agents can reliably consume it. Reltio addresses cross-system master data. Dremio addresses the lakehouse layer. Prior Labs addresses unstructured-to-structured conversion.

What's notably not addressed is the document layer itself. Invoices, contracts, POs, vendor onboarding paperwork, receipts. The text and structured data inside business documents still has to land in clean, validated form in SAP's data layer before any agent can act on it. That extraction layer is where specialized players continue to win — and where SAP is, again this year, leaving the field open.

Theme 5: Customer Proof Points

14. JPMorgan is moving its general ledger to SAP. The single biggest customer win announced at Sapphire and, frankly, the year.

15. 26 industries covered at GA with industry-specific agents — consumer/retail, oil & gas, mining, engineering, agriculture, banking, insurance, and more. H&M's unified commerce went live as a keynote demo.

16. Physical AI — Cyberwave robotics partnership. Autonomous packing in SAP's own logistics center.

17. Expanded sovereign cloud, including India.

Our read: The JPMorgan GL win is the most strategically significant customer announcement of 2026. Banks moving a general ledger is rare, conservative, and signals deep institutional commitment. That alone gives the Sapphire narrative more credibility than the agent count does.

The 26-industry coverage is more breadth than depth — expect the industry agents to be uneven in production, with strong ones in retail and supply chain and weaker ones in regulated verticals where data and compliance complexity is higher.

The Physical AI demo grabs headlines but won't move enterprise budgets in 2026. Sovereign cloud expansion to India, on the other hand, is meaningful — data residency has been a genuine blocker for SAP cloud adoption in Indian enterprises, and removing it opens a large market.

Theme 6: The Migration Problem

18. Parloa partnership for AI agents in SAP Service Cloud.

19. Palantir + Accenture as implementation partners for complex migration scenarios.

20. RISE with SAP reset: 3 Joule Assistants contractually included in year one, with the Max Success Plan extending adoption across the enterprise.

21. SAP GROW reset: 20+ AI assistants from day one (positioned for smaller and midmarket customers).

22. €100M partner fund for partners deploying AI assistants or building on Joule Studio.

23. Migration assistants: 35%+ effort reduction, up to 50%, for S/4HANA migrations.

24. AI access requires cloud migration. Customers must be on RISE, or move at least 50% of maintenance spend to cloud, to use the new AI features. Approximately two-thirds of SAP's base is still on ECC or on-prem.

Our read: This is where the marketing meets the wall. S/4HANA migration has been a slog for years — most ECC customers are reluctant, and the migration tooling improvements feel like a forced acceleration push. Tying AI access to cloud migration creates an explicit forcing function: SAP wants enterprises to migrate to access agents.

But the math is uncomfortable. Two-thirds of the SAP base is on ECC, and most of them don't want to move on SAP's preferred timeline. SAP has effectively decided not to support AI for those customers. That creates a real and growing market for tooling that lets ECC customers adopt AI at the document and process layer while staying on ECC until they're ready to migrate on their own terms.

The Parloa partnership tells you something else: SAP is willing to white-flag specific functional areas. Parloa is a customer service AI play, and SAP brought them in because SAP couldn't keep up with Salesforce in CS. Expect that pattern — bring in a specialist where the gap is widest — to repeat across other functions.

Theme 7: The Market Reaction

25. SAP's stock was down ~28–32% YTD heading into Sapphire. Analysts maintained Buy ratings but flagged AI as "an adoption topic, not a revenue driver yet."

The €100M partner fund, the AI-density of the keynote, the rapid-fire acquisitions — these are responses to investor skepticism as much as they are responses to customer demand. SAP needed Sapphire 2026 to look like an AI company. It did. The market hasn't yet been convinced it is one.

That gap between narrative and conviction is the most honest signal coming out of Orlando.

What This Actually Means for Enterprise AI Buyers

Strip away the keynote choreography and Sapphire 2026 tells a coherent story for SAP customers:

1. The agent layer is real but immature. Joule Assistants and the 200+ agents are shipping, but they're best understood as copilot helpers today, not autonomous workflow replacements. Salesforce's Agentforce is the relevant case study, and that hasn't yet lived up to its pitch.

2. The interop story changes the vendor landscape. MCP in BDC and Reltio, A2A by Q4, the AI Agent Hub marketplace by Q3 — together, these announcements say SAP is opening up. Specialized agents will plug in. The best-of-breed era is back, even inside SAP environments.

3. The data and document foundation problem is bigger than SAP is letting on. Three acquisitions (Reltio, Dremio, Prior Labs) and a €1B+ commitment to tabular foundation models. SAP is buying its way into a data layer it doesn't have. The document layer — invoices, POs, contracts, vendor records — sits adjacent to all of these moves and remains the dominant bottleneck for agent reliability.

4. Two-thirds of SAP customers are stranded. ECC users can't access the new AI features without migrating. Most won't migrate on SAP's preferred timeline. There's a real, growing, and underserved market for AI tooling that works on ECC today.

5. The 80% accuracy bar Klein set is a brutal filter. "Eighty percent accuracy isn't sufficient when running mission-critical businesses." Every agent shipped in 2026 will be measured against that line. Most won't clear it without enterprise-grade structured inputs upstream.

Where Nanonets Fits

The autonomous enterprise has a quiet bottleneck: agents are only as good as the documents and structured data they're grounded in.

Nanonets builds the document AI layer that turns the unstructured input flowing into SAP — invoices, POs, contracts, vendor records, receipts — into the structured, audit-ready, enterprise-grade data that Joule Assistants and SAP's 200+ agents need to actually work in production.

We integrate with SAP S/4HANA and SAP Ariba today. We also work in ECC environments where Joule doesn't yet reach — which matters for the two-thirds of the SAP base that won't migrate on SAP's timeline. And we're built explicitly for the accuracy bar Klein set publicly in Orlando.

With MCP now embedded in SAP Business Data Cloud and Reltio, and the SAP AI Agent Hub going GA in Q3, the integration paths for specialized AI tools into SAP environments are about to be fundamentally more open than they've ever been. We're tracking those timelines closely and building toward them.

If you're rethinking your document and data foundation for the autonomous enterprise era — whether you're on RISE, GROW, or still on ECC — we'd love to compare notes.

Sources: SAP News Center, SAP Community, ERP Today, Constellation Research, SAPinsider, Channel Insider, ad-hoc-news, SAVIC Technologies. Quotes and metrics drawn from Christian Klein's Sapphire 2026 keynote and the official SAP Sapphire 2026 announcements.

In-house legal is the most over-requested, under-staffed function in any company above two hundred people. The CLOC 2025 State of the Industry report found that 83% of legal departments expect demand to grow year over year, while headcount stays flat. 25-40% percent of a lawyer's day goes to contract admin: formatting documents, routing approvals, tracking renewals, and chasing signatures through email threads.

On February 2, 2026, Anthropic released a legal plugin for Claude Cowork that put a dent in that problem. The announcement was significant enough that shares in Thomson Reuters fell roughly 16%, RELX dropped approximately 14%, and the Jefferies Group dubbed it the "SaaSpocalypse." The plugin is free, open source, and available today for any paid Claude plan.

This guide explains how the Claude legal plugin works for in-house legal teams, including contract review, compliance scanning, obligations monitoring, due diligence, and drafting from a legal playbook. It also covers how to install the plugin, configure your standards, and where human legal judgment still matters.

How to Install the Claude Legal Plugin

The legal plugin requires Claude Cowork, Anthropic's agentic desktop application, and a paid Claude subscription (Pro at $20/month or above).

Open the Claude Desktop app, switch to the Cowork tab, click Plugins in the sidebar, find Legal, and click Install.

How to Configure a Legal Playbook in Claude

The plugin ships with generic U.S.-based positions by default. Its actual value comes after you customise it.

Create a file called legal.local.md in any folder you have shared with Cowork. This is the playbook Claude reads at the start of every session. It should contain your standard positions by clause type: preferred indemnification language, your limitation of liability cap and carve-outs, acceptable data processing terms, fallback positions for key clauses, auto-approval criteria for low-risk contracts, and escalation triggers. The more specific it is, the less Claude has to guess.

For a financial institution operating under DORA, include the Article 30 mandatory clause requirements. For any company with GDPR obligations, include your standard data processing agreement positions. If you operate under multiple jurisdictions, note the differences by region.

Once the playbook is in place, every plugin command runs against your standards rather than generic best practices.

1.AI Vendor Contract Review With Claude

This is the most urgent use case on this list in 2026, and the one with the least existing infrastructure at most companies.

Every company is now signing agreements with AI vendors at a pace that in-house legal teams were not built for. OpenAI, Anthropic, GitHub Copilot, Harvey, Glean, Notion AI: these arrive on a Tuesday with a "can legal turn this by EOD" request attached. The business wants to move fast, but legal has never reviewed anything quite like them.

The reason they are harder than standard SaaS agreements: the IP and data terms are genuinely new territory. A typical SaaS contract is about access and availability. An AI vendor agreement is about what the model is allowed to do with your data, who owns what the model generates, and who is liable when the output is wrong. Does the vendor train on your inputs? Who owns the outputs Claude generates when your team uses it? What is the indemnification cap for AI-generated errors that end up in a client deliverable? What are the data residency terms? What happens to your data at termination?

These are not hypothetical. Colorado's Artificial Intelligence Act went into effect in February 2026. California's AI Transparency Act went into effect January 2026. The contractual landscape around AI tools is moving really fast and most companies are signing these agreements without a playbook.

What Claude does

Drop the vendor MSA and ToS into your Cowork workspace folder, then run:

/review-contract vendor-agreement.pdf

Claude reads the entire contract before flagging anything, because clauses interact. An uncapped indemnity might look alarming in isolation but is partially offset by a broad limitation of liability three sections later. The output uses a color-coded flag system for each clause: GREEN for clauses that align with your playbook, YELLOW for deviations from preferred terms worth negotiating, RED for clauses that pose significant risk and require resolution before signing.

For AI vendor agreements specifically, add context after the command:

/review-contract vendor-agreement.pdf

Focus especially on:

- Data training rights: can the vendor train models on our inputs or outputs?

- Output ownership: who owns content the model generates?

- Liability for hallucinations or errors in model output

- Data residency and retention at termination

- IP indemnification covering the vendor's training corpus

We are a financial services company operating under GDPR. Flag any provision that conflicts with our data processing requirements.

Claude produces a structured review with the exact contract language cited for each flag, the risk it creates, and suggested alternative language aligned to your playbook. An agreement that would take three hours to properly review takes thirty to forty-five minutes. Legal reads the output, makes the judgment call on which flags to push, and sends back a redline.

You can also cross-reference your current vendor relationship before the review:

/vendor-check [Vendor Name]

This surfaces any existing agreements with that vendor, their current status, key obligations, and renewal dates before you review the new contract. Useful context when the new agreement amends or supersedes something already in your system.

Honest caveat

Claude flags what the contract says. It does not know your risk tolerance, your relationship with this vendor, or whether the business will accept the deal delays that come with negotiating every flagged term. That judgment is yours. If a flag requires knowledge of local law you are not certain about, get specialist advice before concluding it is acceptable.

2.Regulatory Compliance Scanning for In-House Legal Teams

DORA went live on January 17, 2025. Article 30 requires all contracts between EU financial entities and ICT third-party service providers to include nine mandatory baseline clauses: a complete description of services, data location requirements, data protection provisions, access and recovery rights, full SLA descriptions for critical functions, incident reporting obligations, audit rights, termination rights with minimum notice periods, and exit strategy provisions.

So the problem becomes knowing which of your existing contracts satisfy those requirements. At a company with 200 vendor agreements, you can’t solve it by reading; you need to run a gap register.

The same challenge recurs every time a significant regulation is issued. DORA created an exercise. The EU AI Act's obligations for deployers of high-risk AI systems are phasing in through 2026 and will create another. US state AI laws are multiplying. This is now a permanent feature of the regulatory environment.

What Claude does

Share your contract library folder with Cowork. Then run:

/compliance-check DORA Article 30 requirements across all contracts in /vendor-agreements/

For each contract, Claude checks whether each of the nine Article 30(2) baseline clauses is present, partially present, or absent. For contracts supporting critical or important functions, it checks the additional Article 30(3) requirements: detailed SLAs, business continuity provisions, audit rights, and exit strategy terms. It flags contracts that are clearly compliant, those with gaps, and those where the provision exists but is materially insufficient (an audit rights clause limited to once per year with no notice, for example).

The output is a gap register: one row per contract, columns for each clause category, and a separate flagged section for contracts requiring urgent remediation. What would take a junior lawyer three weeks to produce manually takes a day.

For GDPR, the EU AI Act, CPRA, or any other framework, adjust the command:

/compliance-check EU AI Act deployer obligations across all data processing agreements

The structure is the same. Swap the regulatory framework in the command.

Honest caveat

Claude reads what the contract says. Regulators interpret borderline provisions in ways that are not always clear from the text, and some DORA regulatory technical standards are still being finalized. Use the gap register as triage: the contracts flagged as clearly compliant get documented, the contracts with gaps go to a lawyer for remediation decisions.

3.Contract Obligations Monitoring With Claude

Contracts get signed and filed. The obligations inside them do not disappear.

SLAs your company must meet. Renewal notice windows that require 60 or 90 days' advance action. Change-of-control clauses that trigger on an acquisition. Audit rights that must be exercised within a window. Payment milestones tied to deliverables. All of these keep running on their own timeline while the signed contract sits in a shared drive folder somewhere.

The WorldCC has reported that organizations lose up to 9% of annual contract value through poor contract management. The most common version of that loss in practice: a SaaS vendor auto-renews a six-figure annual contract because nobody caught the 90-day notice window buried in clause 12.4. The business wanted to exit. Nobody was watching.

What Claude does

Run a standing brief that surfaces upcoming deadlines before they become problems:

/brief vendor renewals and obligations due in the next 90 days

Claude scans your contract library and produces a structured report organized by urgency: contracts with renewal notice windows closing in the next 30, 60, and 90 days; outstanding SLA obligations; any change-of-control or assignment restrictions on active agreements; and audit rights with expiring windows. It flags which ones require action and what that action is.

For a specific vendor:

/vendor-check Acme Corp - full obligations summary

This surfaces the current agreement status, every obligation on both sides, renewal terms, auto-renewal flags, and any compliance requirements outstanding. One command replaces thirty minutes of hunting through a contract you have not read since it was signed.

Honest caveat

This workflow is only as useful as the contract library Claude has access to. Contracts stored in email threads, personal drives, or on paper are invisible to it. The brief is a reminder system, not a live monitoring platform. Someone still needs to own the action items it surfaces.

4.M&A Due Diligence Using the Claude Legal Plugin

A typical mid-market M&A transaction involves reviewing upward of 10,000 document pages across a due diligence timeline of six to twelve weeks, according to data from multiple virtual data room providers. A 2024 Bayes Business School study found that average due diligence timelines increased 64% over the last decade, rising from 124 days in 2013 to 203 days in 2023, driven by growing regulatory demands, ESG scrutiny, and document volume.

The associates in the data room are mostly doing extraction work: read a contract, pull the key terms, note the risk, add it to the tracker, move to the next document. That process is what produces the input for the diligence memo. The diligence memo is where the judgment lives.

What Claude does

Organize data room documents by category in a shared Cowork folder. For each category, run:

/review-contract [folder: /data-room/material-contracts/]

We are the buyer in an acquisition. Flag all of the following:

- Change-of-control provisions: does the clause require consent, allow termination, or have another effect on the transaction?

- Assignment restrictions

- Any contract with a term extending beyond 3 years from today

- Non-standard or unusual provisions

- Missing exhibits or schedules referenced but not included

For a broader risk picture across the data room:

/legal-risk-assessment full data room review for acquisition of [Target Company]

Identify: top 5 legal risks by category, all change-of-control provisions across any contract, any litigation or regulatory matter disclosed, and any IP not clearly owned by the target company. Produce a summary table organized by risk level.

After category reviews are complete:

/brief M&A diligence memo - material contracts section

Based on the contract reviews completed, draft the material contracts section of the diligence memo. Structure: Summary of Findings, Material Issues, Open Items, and Recommended Actions. Flag any deal-critical issues that require a closing condition or negotiation.

Claude produces a well-organized first draft of each diligence memo section. The supervising lawyer reviews it for context Claude does not have (deal dynamics, industry norms, buyer's risk appetite), adds substance on anything requiring legal judgment, and finalizes. Extraction and structuring work that would take an associate two days takes a few hours.

Honest caveat

Claude does not know what is normal in your industry, what the buyer's strategic risk tolerance is, or whether a specific issue is deal-breaking given the deal context. It also cannot assess what is not in the data room, which is often where the real problems hide. Senior lawyer review before anything goes to the client is not optional.

5.Contract Drafting From Your Legal Playbook

Drafting from scratch produces generic output. Every Harvey and Spellbook article leads with "AI can draft contracts" and the drafts look professional until you realize they do not reflect your indemnification cap, your standard limitation of liability carve-outs, or your data processing positions.

The workflow that actually works: drafting from your own standards.

Once your playbook is in your legal.local.md file, Claude knows your preferred positions. Tell it what deal you need to document:

Draft a Master Services Agreement for the following:

Counterparty: [Vendor Name]

Services: [brief description]

Fees: [amount and structure]

Term: 12 months with automatic annual renewal

Governing law: New York

Non-standard positions agreed in negotiation: limitation of liability agreed at 24 months of fees instead of our standard 12 months

Use our playbook for all other positions. For any clause where the playbook specifies a fallback, use the preferred position unless I have indicated otherwise above. Flag any clause where the deal specifics require a judgment call the playbook does not clearly address.

Claude produces a first draft MSA reflecting your standard positions. You review the flagged clauses, make the calls Claude could not make from the playbook alone, and send the draft to the counterparty. A contract that would take two to three hours to draft takes thirty to forty-five minutes.

The same workflow applies to SOWs, amendments, and side letters. The principle is the same in each case: your language, your positions, Claude doing the assembly.

Honest caveat

The draft is only as good as the playbook. If your playbook is vague on a clause type, the draft will be vague on it too. When counterparty counsel sends back a marked-up agreement in an unusual jurisdiction raising a novel question and it is a legal analysis task, not a drafting one.

Where In-House Legal Teams Should Start

Pick one workflow. Not all 5. One workflow, done well and refined over a few iterations, saves more time than five workflows run once and abandoned. The plugin learns your playbook better the more you use it. The first review calibrates against your standards, and the tenth one runs in half the time.

The ratio of judgment to paper has not changed in decades of in-house legal work. This is how you start changing it.

Cheers!

Vibe coding went from Andrej Karpathy's tweet to Collins Dictionary's Word of the Year in under twelve months. In Y Combinator's Winter 2025 batch, 25% of startups had codebases that were 95% or more AI-generated. GitHub has reported that Copilot was responsible for an average of 46% of code being written across programming languages, and 61% in Java.

So yes, it has become the new normal and everyone's doing it but unfortunately, most people are doing it badly. The tools like Claude Code and Cursor are amazing but most vibe coders use them like autocomplete on steroids, like a genie: just prompt randomly and wait for it to cook. But trust me the output looks crazy at first glance until the codebase is a mess the agent itself can't navigate, lol.So in this guide, we cover 5 things which can make you as good as a developer who went to school for this. Maybe better.

1. Use CLAUDE.md and Rules as Persistent Context

Every Claude Code or Cursor session starts with the agent having seen nothing about your project before. It reads whatever files you point it at, infers what it can, and guesses the rest. For small isolated tasks that is fine but for anything heavy it is not, because those guesses keep compounding.

Let’s say you are three weeks into building a SaaS billing system. You open a new session and ask the agent to add a usage based pricing tier. It does not know you already have a BillingService class in /services/billing.py. It does not know you standardized on Stripe's price_id format for all pricing objects. So it creates a new PricingService, picks its own format, and builds something parallel to your existing architecture. Four sessions later you have two billing systems and neither is complete.

A CLAUDE.md file at the root of your project gets read at the start of every session. Here is what a real one looks like for a SaaS project:

# Project: Acme SaaS

## Stack
- Node.js + Express backend
- PostgreSQL with Prisma ORM
- React + TypeScript frontend
- Stripe for billing (price IDs follow format: price_[plan]_[interval])

## Key services
- /services/billing.py — all Stripe logic lives here, do not create parallel billing code
- /services/auth.py — JWT + refresh token pattern, see existing implementation before touching auth
- /lib/db.ts — single Prisma client instance, import from here

## Conventions
- All API responses: { data, error, meta } shape
- Errors always use AppError class, never plain Error
- Every DB query needs explicit field selection, no select *

## Do not touch
- /legacy/payments/ — deprecated, being removed in Q3
- /auth/oauth.py — frozen until SSO ships

Cursor now documents Rules and AGENTS.md for persistent instructions. GitHub Copilot supports repository-wide instruction files like .github/copilot-instructions.md, and some Copilot agent surfaces also read AGENTS.md, CLAUDE.md, and GEMINI.md.

When you add a new service or establish a new convention, update the file immediately. It becomes the agent's memory between sessions.

One more thing: context rot is real. A 2025 Chroma study of 18 models found measurable accuracy drops as conversations grew longer, even on simple tasks. A 40-message session covering three features is slower and less accurate than three separate 15-message sessions. Open a new conversation for each distinct task. Pin only the files relevant to that task.

2. Make the Agent Plan Before It Builds

The default behavior of every agentic tool is to start writing code the moment you describe something. For a self-contained task like "add a field to this form" that is fine but for anything with real scope it will create problems you do not find until you are deep into the implementation.

Here is a concrete example. You are building a team invitation system: a user enters an email, the system sends an invite, the recipient clicks a link, creates an account, and gets added to the team. Sounds simple but that feature touches your users table, your teams table, a new invitations table, your email service, your auth flow, and your JWT generation. If the agent misunderstands how your auth flow works and builds the invitation acceptance logic against a different assumption, you will not find out until the feature is mostly done.

Before any feature with scope, send this first:

Before writing any code: analyze the codebase, then give me a step-by-step plan 
for building the team invitation system. List every file you will modify, every 
file you will create, every DB migration needed, and any assumptions you are 
making about the existing code. Do not write code yet.

A good plan output looks like this:

Files to modify:
- /routes/teams.ts — add POST /teams/:id/invite and POST /teams/accept-invite
- /services/email.ts — add sendTeamInvite() using existing Resend client
- /prisma/schema.prisma — add Invitation model

Files to create:
- /services/invitations.ts — token generation, validation, expiry logic

DB migration:
- invitations table: id, team_id, email, token (unique), expires_at, accepted_at

Assumptions:
- Invite tokens expire after 48 hours
- Inviting an already-registered email still goes through the invite flow
- No invite limit per team currently

Read that a couple of times and make sure: Is the 48-hour expiry right? Did it miss the rate limiting you need? Is it using the email service correctly? Fix the plan before a single line of code gets written.

The other side of this is prompt specificity. The more precisely you describe what you want, the less the agent has to infer.

3. Use a Separate Review Agent for Security and Logic

Coding agents are optimized to complete tasks, not to understand why every guardrail exists. Columbia DAPLab has documented recurring failure patterns across major coding agents, including security issues, data management mistakes, and weak codebase awareness. That makes blind trust dangerous: the same agent that fixes a bug can also remove the check that was preventing a worse one.

The clearest real example of this: in the Replit agent incident of 2025, the autonomous agent deleted a project's primary production database because it decided the database needed cleanup. It was following its optimization objective. It was also violating an explicit instruction not to modify production data. And sadly, no human reviewed what it was about to do.

The agent that wrote your code is not in a good position to catch its own mistakes. Claude Code supports subagents: separate agents that run in completely isolated contexts with no memory of what the first agent built. You define them in .claude/agents/:

---
name: security-reviewer
description: Reviews code for security issues after implementation is complete
tools: Read, Grep, Glob
model: opus
---

You are a senior security engineer doing a pre-ship review.

For every route added or modified, check:
- Is authentication enforced? Can an unauthenticated request reach this?
- Is the user authorized? Can user A access user B's data?
- Is input validated before it hits the database?
- Are there any hardcoded secrets, API keys, or credentials?

Report: file name, line number, specific issue, suggested fix.
Do not summarize. Report every issue you find.

After your main agent finishes building the invitation system:

Use the security-reviewer subagent on all the files we just created or modified.

Here is what a real reviewer output looks like:

/routes/teams.ts line 47
Issue: POST /teams/accept-invite does not verify the token belongs to the 
email address of the logged-in user. Any authenticated user who knows a valid 
token can accept any invite.
Fix: Add check that invitation.email === req.user.email before accepting.

/services/invitations.ts line 23
Issue: Token generated with Math.random() — not cryptographically secure.
Fix: Replace with crypto.randomBytes(32).toString('hex').

Neither of those would have been caught by the building agent. Both would have made it to prod.

Escape.tech's scan of 5,600 vibe-coded apps found over 400 exposed secrets and 175 instances of PII exposed through endpoints. Most of it is exactly this category of issue, authorization logic that works functionally but has holes.

4. Prompt in Layers, Not in One Giant Spec

Role assignment changes what the agent prioritizes. "Build this feature" and "Act as a senior engineer who has been burned by poorly tested payment code before. Build this feature." produce different outputs. The second one will add edge case handling, write more defensive validation, and flag assumptions it is not sure about. The model responds to framing.

Build features in layers, not all at once. The standard mistake when building something like a Stripe integration is to ask for the whole thing in one prompt. You get code that compiles but has the billing logic, webhook handling, and database updates tangled together. Instead:

Prompt 1:

Set up the Stripe Checkout session creation only. 
Endpoint: POST /api/subscribe
Accepts: { price_id, user_id }
Returns: { checkout_url }
Do not handle webhooks yet. Do not update the database yet. Just the session creation.

Review that. Make sure the Stripe client is initialized correctly, the right price_id is being passed, the success and cancel URLs point to the right places.

Prompt 2:

Now add the Stripe webhook handler.
Endpoint: POST /api/webhooks/stripe
Handle these events only: checkout.session.completed, customer.subscription.deleted
On checkout.session.completed: set user.plan = 'pro', user.stripe_customer_id = customer id from event
On customer.subscription.deleted: set user.plan = 'free'
Verify the webhook signature using STRIPE_WEBHOOK_SECRET from env.

Review that separately, check the signature verification, also that the user lookup is correct.

Each layer is reviewable and has a clear scope. If something is wrong you know exactly where.

Use pseudo-code when you know the logic but not the implementation:

Build a rate limiter for the /api/send-invite endpoint.
Logic:
- Key: user_id + current hour (e.g. "user_123_2026041514")
- Limit: 10 invites per hour per user
- On limit exceeded: return 429 with { error: "Rate limit exceeded", retry_after: seconds until next hour }
- Use Redis if available in the project, otherwise in-memory Map is fine

This is more accurate than "add rate limiting to the invite endpoint" because you have specified the key structure, the limit, the error response shape, and the storage preference. There is almost nothing left to guess.

5. Review Diffs, Restrict Access, and Test Immediately

The majority of developers shipping AI generated code spend moderate to significant time correcting it. Only around 10% ship it close to as is. Those are mostly experienced Claude Code users with tight CLAUDE.md files and structured build sessions.

Read every diff before committing. git diff before every commit. When the agent has modified a file you did not ask it to touch, either the prompt left room for interpretation or the agent overreached. Both are worth understanding before the code goes anywhere.

Restrict what the agent can access. The permissions.deny block in ~/.claude/settings.json prevents the agent from reading or writing specific paths. A .cursorignore file does the same in Cursor.

{
  "permissions": {
    "deny": [
      "/auth/oauth.py",
      "/.env",
      "/.env.production",
      "/legacy/**",
      "/migrations/**"
    ]
  }
}

Oh, migrations deserve special mention. An agent that can write its own migration files can silently alter your database schema. Keep migrations out of reach and write them yourself after reviewing what the agent built.

Test immediately after every feature. Not as a separate task later, right after. "Now write unit tests for the invitation service we just built. Cover: token expiry, duplicate invite to same email, accept with wrong user, accept with expired token." The agent that just built the feature knows the edge cases. Ask for tests while that context is live.

That's it. Share with whoever needs it. Happy prompting!

Meta just released Muse Spark. The announcement says it beats GPT-5.4 on health tasks, ranks top-five globally on the Artificial Analysis Intelligence Index, and scores 89.5% on something called GPQA Diamond.

Eleven months ago, Meta said almost identical things about Llama 4, before people actually used it and the numbers collapsed.

So what are these benchmarks? How do the scores get calculated? And why does a model that tops every leaderboard sometimes feel mediocre the moment you use it?

This guide explains what the biggest AI benchmarks actually measure, including MMLU, GPQA Diamond, HumanEval, SWE-bench, HealthBench, Humanity’s Last Exam, and Chatbot Arena. It also explains how benchmark scores are calculated, why some tests matter more than others, and how AI labs can inflate benchmark results without improving real-world performance.

What Is an AI Benchmark?

A benchmark is just a standardized test. A fixed set of questions or tasks, given to every AI model in the same way, scored the same way. The idea is that if everyone takes the same test, you can compare the results fairly. But there's a practice the AI community has started calling benchmaxxxing: squeezing every possible point out of a benchmark through evaluation choices, cherrypicked settings, and training strategies that improve the score without necessarily improving the model. 

We'll get into the specifics of how this works as we go through each benchmark.

MMLU and MMLU-Pro: The Knowledge Test

What it is: Over 15,000 multiple-choice questions across 57 subjects. Law, medicine, chemistry, history, economics, computer science. Four answer choices per question.

What an actual question looks like:

A 60-year-old man presents with progressive weakness, hyporeflexia, and fasciculations in both legs. MRI shows anterior horn cell degeneration. Which of the following is the most likely diagnosis? (A) Multiple sclerosis (B) Amyotrophic lateral sclerosis (C) Guillain-Barré syndrome (D) Myasthenia gravis

The model outputs a letter. The test runner checks if it matches the answer key.

How the score is calculated: Before each question, the model is shown 5 example questions with correct answers, this is called 5-shot prompting. Then comes the real question. Score = correct answers ÷ total questions, expressed as a percentage.

Why it's nearly useless in 2026: Top models now score above 88% on MMLU. GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro are all bunched together above 87%. The test can no longer separate them, it's like using a bathroom scale to measure the weight difference between two people of similar build. Technically possible, practically meaningless.

Researchers responded by building MMLU-Pro: same subjects, harder questions, ten answer choices instead of four, with options designed to look plausible even to knowledgeable humans. On MMLU-Pro, the gaps between models start showing up again.

→ When you see MMLU in a press release in 2026, it's mostly padding. It's also the benchmark most likely to be inflated by training data contamination: models have had three years of internet data that overlaps heavily with MMLU-style questions.

GPQA Diamond: The Scientific Reasoning Test

This is the most credible academic benchmark in use today. The way it was built is what makes it trustworthy.

How the questions were made: Researchers hired PhD scientists in biology, physics, and chemistry. Each scientist wrote a question in their own field. Then a second PhD scientist in the same field attempted to answer it. If that second expert got it wrong, the question passed the filter. Then three more people, smart non-domain experts given unlimited internet access and 30 minutes, tried to answer it. If they also failed, the question made it into the Diamond subset.

The result: 198 questions that require you to actually reason through hard science. You cannot Google them. The answers aren't in Wikipedia.

What an actual question looks like:

Two quantum states with energies E1 and E2 have a lifetime of 10⁻⁹ sec and 10⁻⁸ sec, respectively. We want to clearly distinguish these two energy levels. Which of the following could be their energy difference so they can be clearly resolved? (A) 10⁻⁸ eV    (B) 10⁻⁹ eV    (C) 10⁻⁴ eV    (D) 10⁻¹¹ eV

To answer this, you need to know the energy-time uncertainty principle from quantum mechanics, calculate the natural linewidths of the energy levels, and check which energy difference is large enough to resolve them. The answer is (A), but you can't find that by searching. You have to derive it.

How the score is calculated: Same letter-pick system as MMLU. The model is told to reason step by step and must end its response with "ANSWER: LETTER" - capital letters only. If the model doesn't follow that exact format, it gets zero for that question regardless of whether the reasoning was correct. This strict formatting rule is intentional: it forces models to commit to a specific answer rather than hedging.

The benchmark in numbers:

• Random guessing: 25% (four choices)
• Smart non-experts with internet access: 34%
• PhD-level domain experts: 65%
• GPT-4 when it launched (2023): 39%
• Muse Spark today: 89.5%
• Gemini 3.1 Pro: 94.3%
• Claude Opus 4.6: 92.8%

That jump from 39% to 89% in three years is real. These models have genuinely gotten better at scientific reasoning. But Muse Spark is still about 5 points behind Gemini on this test, across 198 questions. That's roughly 10 questions. Meta calls this "competitive" which is technically accurate.

HumanEval: The Basic Coding Test

What it is: 164 Python programming problems. Each problem is a function signature with a docstring explaining what the function should do.

What an actual question looks like:

The model writes the function body. An automated test runner then executes the code against 10-15 hidden test cases, inputs with known correct outputs. Either every test case passes, or the problem fails.

How the score is calculated: The main metric is pass@1: did the model's first attempt pass all the hidden tests? Score = number of problems where the code worked ÷ 164 total problems.

Example of pass vs. fail:

A correct solution for the above returns "fl" for ["flower","flow","flight"] and "" for ["dog","racecar","car"] and handles edge cases like an empty list. A model that hardcodes the visible examples but fails on an edge case like a single-element list gets zero for that problem.

Why it's outdated: Top models now solve 90%+ of these 164 problems. They've had years to train on HumanEval-style tasks. Researchers openly question how many models may have seen these exact problems in training. Leading with HumanEval in 2026 is like a car company leading their safety pitch with a test from 2015.

SWE-bench: The Real Software Engineering Test

What it is: Real GitHub issues from real open-source repositories. The model is given the issue description and the full codebase and must produce a code patch (a diff) that fixes the bug.

What an actual task looks like:

A developer files a GitHub issue in the sympy math library: "The simplify() function returns the wrong result when called on expressions containing nested Piecewise objects under certain conditions."

The model gets the issue text, navigates a codebase with thousands of files, identifies the source of the bug, and writes a patch. That patch is automatically applied to the codebase, and the existing test suite runs to check that the fix works and didn't break anything else.

How the score is calculated: Pass/fail at the issue level. Score = percentage of issues where the model's patch passed all tests.

Why this benchmark matters more than HumanEval: Because there's no memorization shortcut. The repositories are real, the bugs are real, and the evaluation environment is strictly controlled. You either fixed the bug or you didn't.

Where Muse Spark stands here: Meta's own blog post acknowledges "current performance gaps, specifically in coding workflows." SWE-bench is almost certainly where that shows up. Claude Opus 4.6 currently leads most coding evaluations.

Humanity’s Last Exam: The Frontier Reasoning Test

What it is: Around 2,500 questions written by researchers specifically designed to exceed what current AI can answer: PhD-level and beyond, across math, science, history, and law.

Why Muse Spark highlights it: In its "Contemplating" mode, which launches multiple sub-agents working in parallel on different parts of a problem, Muse Spark scored 50.2%. GPT-5.4 in its highest-effort mode scored 43.9%. Gemini's Deep Think mode scored 48.4%.

This is Muse Spark's most legitimate lead across any benchmark. The gap is real (6+ points over GPT-5.4) and the benchmark is genuinely hard. One caveat: Contemplating mode uses significantly more compute than a standard response. You're paying, in time and in API cost for that performance.

HealthBench: The Clinical Reasoning Test

What it is: Clinical and medical reasoning tasks evaluated by physicians. Questions cover patient symptom interpretation, drug interactions, treatment decisions, and health information accuracy.

How the score is calculated: Unlike automated benchmarks, HealthBench answers are graded against physician-defined standards. The score represents the percentage of answers that met clinical accuracy requirements.

The numbers: Muse Spark 42.8%. GPT-5.4 40.1%. Gemini 3.1 Pro 20.6%.

42.8%. GPT-5.4 scored 40.1%. Gemini 3.1 Pro scored 20.6%. This is Muse Spark's most defensible lead in any benchmark. A 22-point gap over Gemini on a physician-graded test is significant.

Chatbot Arena: The Human Preference Test

This one is different from every other benchmark, and understanding how it works explains the Llama 4 scandal.

What it tests: Whether a human user prefers one model's response over another.

How it works: Two anonymous models are shown the same prompt. A real user reads both responses and picks which one they prefer. Millions of these pairwise comparisons are run. The results feed into a statistical model called Bradley-Terry, which converts win/loss records into ELO scores: the same system used to rank chess players.

If Model A beats Model B in 60% of comparisons, Model A gets more points. Over time, after enough comparisons, the rankings stabilize into a leaderboard.

Why this benchmark is gameable: Human users tend to prefer responses that are long, confident-sounding, and well-formatted, even when a shorter, more accurate answer would serve them better. A model that adds enthusiasm, uses bold text, and gives elaborately structured responses will score better on LMArena than a model that gives a direct, correct answer in two sentences.

And this is what happened with Llama 4. 

The Llama 4 Incident

When Meta released Llama 4 in April 2025, its announcement said the model ranked #2 on LMArena, just behind Gemini 2.5 Pro, with an ELO score of 1417. That number was technically accurate, but the model that earned that score was not the one being released to the public.

The model Meta submitted to LMArena was called "Llama-4-Maverick-03-26-Experimental." Researchers who later compared it against the publicly downloadable version found consistent behavioral differences:

The experimental version (LMArena): verbose responses, heavy use of emojis, elaborate formatting, dramatic structure, long elaborations even for simple questions.

The public version (what you'd actually use): concise, plain, direct, no emojis.

LMArena's voting system reliably preferred the first style. Real users in real use cases preferred the second. When the actual public model was separately added to the leaderboard, it ranked 32nd.

There's another number worth knowing: when LMArena turned on Style Control, removing the formatting and length advantage, Llama 4 Maverick dropped from 2nd place to 5th. The model's content quality, stripped of its presentational packaging, was much less impressive.

LMArena stated publicly: "Meta's interpretation of our policy did not match what we expect from model providers. Meta should have made it clearer that 'Llama-4-Maverick-03-26-Experimental' was a customized model to optimize for human preference." They updated their submission rules after.

And on ARC-AGI: a benchmark designed to test genuine novel reasoning, not pattern matching, Llama 4 Maverick scored 4.38% on ARC-AGI-1, and 0.00% on ARC-AGI-2. This was never in the press release.

How AI Labs Game Benchmark Scores: Goodhart's Law and Benchmaxxxing

There's a principle from economics called Goodhart's Law: when a measure becomes a target, it stops being a good measure.

In plain English: the moment everyone agrees that GPQA Diamond is the number that matters, labs start optimizing specifically for GPQA Diamond. Scores go up but the real-world capability may not move at all.

This has a name in the AI community now: benchmaxxxing. It's the practice of squeezing every possible point out of a benchmark through techniques that improve the score without necessarily improving the model. Some of these techniques are legitimate engineering and some are closer to the gaming Meta did with LMArena. The line is genuinely blurry, which is part of what makes this hard to call out.

That’s how benchmaxxxing actually looks like in practice:

Cherry-picking which benchmarks to publish. Every model gets evaluated on dozens of benchmarks internally. The ones that appear in the press release are the ones the model did well on. The rest disappear. This is universal, every lab does it. Llama 4's ARC-AGI score of 0.00% was not in the announcement.

Choosing favorable evaluation settings. Many benchmarks can be run in different ways: different prompting styles, different numbers of example questions shown beforehand, different temperatures. Labs run all the variants internally and publish the best result. This is technically allowed but rarely disclosed.

Training on benchmark-adjacent data. If you know a benchmark tests quantum mechanics reasoning, you can make sure your training set is heavy on quantum mechanics. The questions themselves aren't in the training data, but the knowledge required to answer them is saturated. This is nearly impossible to distinguish from genuine capability improvement from the outside.

Benchmark contamination, the serious version. Sometimes actual benchmark questions, or near-identical variants, end up in training data. This can happen accidentally when training on internet scrapes. It can also happen less accidentally. Susan Zhang, a former Meta AI researcher who later moved to Google DeepMind, shared research earlier in 2025 documenting how benchmark datasets can be contaminated through training corpus overlap. When a model sees the question and answer during training, it's essentially memorized the test. And the score reflects memory, not reasoning.

Majority voting and repeated sampling. Some labs run each benchmark question multiple times and take the most common answer. A model that scores 80% on one attempt might score 88% across 32 attempts. Meta specifically disclosed they don't do this for Muse Spark's reported numbers, they use zero temperature, single attempts. 

The deepest problem with Goodhart's Law in AI is that it creates a ratchet effect. Each new model needs to beat the previous one's benchmark scores, or it's declared a failure. So every release gets more optimized for the benchmarks that exist, which makes those benchmarks less informative over time, which drives the creation of harder benchmarks, which then also get optimized for. MMLU was the gold standard in 2022 but it's saturated now. GPQA Diamond replaced it.

What Benchmarks Still Can’t Tell You

Speed. GPQA Diamond says nothing about whether the model responds in 1 second or 10.

Cost. A model scoring 92% at $15 per million tokens versus one scoring 89% at $1 per million tokens are different choices depending on how much volume you're running.

Consistency. A model averaging 90% on a benchmark but producing catastrophically wrong answers 2% of the time is a different risk profile from one that scores 85% uniformly. Benchmarks report averages. Averages hide tails.

Your specific task. None of these benchmarks were designed for your documents, your prompts, or your users. A model that dominates GPQA Diamond might handle an insurance form extraction task worse than a smaller, cheaper model trained on domain-specific data.

Evaluate AI Models for Your Own Use Case

You can actually evaluate the best model for you, yourself.

Take your ten or twenty most representative tasks: the actual prompts, documents, or questions you'd send to the model in practice. Run every model you're considering on those exact inputs. Score the outputs yourself (or have someone with domain expertise do it.)

That single custom test will tell you more than any benchmark table in a press release. Because benchmarks tell you where a model claims to stand. Your test set tells you where it actually has to show up.

Organizations that treat this as a like-for-like technology comparison tend to underestimate the total cost of running legacy platforms in production. The more revealing question is how much operational effort each platform demands after go-live, as document complexity grows and business rules evolve.

The Operating Model Gap

ABBYY Vantage and Kofax (now Tungsten Automation) were engineered around explicit configuration management. Classification, extraction, review, and process orchestration exist as distinct components, each requiring separate setup and maintenance. When new document formats arrive like new supplier layouts, irregular table structures, multilingual attachments - teams typically need to adjust extraction logic, retrain specific components, or introduce new review steps. That model offers configurability, at the cost of sustained administrative overhead.

Nanonets was designed around a different operating assumption: that document variation is the norm, and the platform should absorb it continuously rather than require intervention each time. User corrections feed back into the system automatically. Exception handling, validation, workflow routing, and downstream integrations run within a single environment. The result is a platform that becomes more capable through everyday use, with minimal specialist involvement.

The practical difference surfaces at scale. Organizations running high exception volumes on ABBYY or Kofax typically maintain a permanent backlog of edge cases, each requiring deliberate configuration work. The same volume on Nanonets is handled largely through the feedback loop, with business users resolving exceptions directly rather than escalating to IT or implementation partners.

Why ABBYY and Kofax Are Structurally Slower to Adapt

The architecture of legacy IDP platforms reflects the era in which they were built. ABBYY exposes pre-trained models, custom models, and human-in-the-loop optimization steps as separate components that must be wired together by specialists. Kofax retains trainable locators, knowledge bases, and method-specific learning configurations that each carry their own maintenance requirements.

These design choices made sense when document workflows were relatively stable, IT teams managed deployments in controlled environments, and implementation partners absorbed operational complexity between releases. They create meaningful drag in modern environments where document types change frequently and operations teams are lean.

Each new edge case in ABBYY or Kofax becomes a configuration project. Over time, the workflow accumulates layers of rules, exceptions to those rules, and compensating logic - a technical debt that grows faster than most organizations anticipate at procurement.

The Nanonets Architecture Advantage

Nanonets builds from generalized model behavior rather than discrete, separately trained components. The platform is designed to adapt through use: corrections made during normal operations improve future extraction without requiring a separate retraining workflow or specialist involvement.

This architectural choice has three compounding effects. First, the system improves continuously as volume increases, which means performance tends to get stronger over time rather than degrading as new formats appear. Second, business users can participate meaningfully in system improvement - they are not locked out of the feedback loop behind a configuration interface designed for specialists. Third, the surface area for failure is smaller because the platform has fewer independently configured components that can fall out of sync.

That extends to downstream communication as well. When Nanonets identifies a discrepancy - a mismatched invoice line, a missing field, an amount outside tolerance - it can automatically notify the relevant vendor by email and then continue the workflow based on the response received through Teams or Outlook. The exception is resolved end-to-end within the platform, with no manual handoff required. In ABBYY or Kofax, the same scenario typically surfaces as a review queue item that a human must triage, escalate, and close out separately.

For organizations managing transaction-heavy document environments - accounts payable, trade finance, insurance intake, logistics documentation - the ability to handle layout variation and exception growth without proportional increases in administrative effort is a material operational advantage.

How Buyer History Shaped Product Design

ABBYY and Kofax grew with enterprise IT buyers who valued governance, deployment flexibility, and granular configurability. Those organizations were willing to invest in complex, multi-month implementations and maintain dedicated internal admin teams or specialist partners. The products were built to satisfy that buyer profile.

Nanonets grew with operations and finance teams who needed faster time to value and lower ongoing maintenance. The commercial model - self-serve onboarding, usage-linked pricing, no-code interfaces - forced the product to absorb complexity that legacy vendors had offloaded to implementation partners.

The implication for procurement teams is direct. When evaluating ABBYY or Kofax, the honest cost model includes implementation services, specialist configuration, ongoing administration, and partner support required to sustain the workflow. When evaluating Nanonets, those costs are substantially reduced because the product is designed to function without them.

Total Cost of Ownership Favors Nanonets

Legacy IDP vendors typically price through enterprise procurement mechanisms: large upfront commitments, multi-year contracts, and services revenue that scales with implementation complexity. The base platform license is one line item in a broader commercial structure.

Nanonets uses consumption-linked pricing that scales with actual usage rather than with organizational size or implementation scope. Teams can deploy a focused workflow, validate the return, and expand incrementally - a model that reduces both initial financial exposure and the cost of course-correcting if requirements change.

The cost divergence widens post-deployment. ABBYY and Kofax require ongoing investment as documents change and business rules evolve. Each adaptation cycle draws on specialist time, whether internal or through a partner. Nanonets absorbs the same changes through its feedback and learning architecture, with substantially lower marginal cost per adaptation.

Across a three-to-five year operating horizon, organizations running high-variation document workflows on Nanonets consistently show lower total cost of ownership - even when the initial platform price appears comparable.

Where Legacy Platforms Retain an Advantage

ABBYY and Kofax retain genuine strengths in specific deployment contexts. Organizations with strict data residency requirements, heavily regulated environments that mandate on-premises infrastructure, or workflows so stable and well-defined that configuration overhead is a one-time cost may find that legacy platforms meet their needs adequately.

For those organizations, the depth of configurability and the maturity of enterprise controls in ABBYY and Kofax carry real value.

The Strategic Implication

For most organizations, the relevant question is whether the operating model they are procuring today will scale with their document complexity over the next several years - and whether it will do so without a proportional increase in administrative cost.

ABBYY and Kofax are capable platforms with deep feature sets. They are also platforms whose design assumptions favor stable, controlled environments managed by specialists. As document volumes grow, exception rates increase, and operations teams face pressure to do more with less, those assumptions become a liability.

Nanonets was built for exactly the environment most organizations find themselves in: high variation, lean teams, and a need for continuous adaptation. The architecture supports it, the operating model enables it, and the commercial structure reflects it.

Organizations evaluating IDP platforms should assess total cost of ownership over a realistic operating horizon, stress-test each platform against their actual exception volume and rate of document change, and resist the tendency to evaluate on idealized workflow design rather than production conditions.

Someone typed "Hello Claude" and used 13% of their session limit.

That's a real Reddit post from a real person who opened Claude, sent a greeting, and watched more than one-eighth of their usage disappear before asking a single question.

A separate user on X reported ending up in a "four-hour cooldown jail" from the same trigger. The thing is, nobody had a good explanation for why it happened.

The answer is tokens. Most people using LLMs today have no framework for understanding what a token is, why it costs what it costs, or where their usage goes before they've done anything useful. Every major LLM – Claude, GPT-5, Gemini, Grok, Llama etc. runs on the same underlying economics. Tokens are the currency of this entire industry. 

If you use any of them regularly, understanding how tokens work is the difference between getting real work done and hitting your limit at 11am.

Let’s decode.

What a Token Actually Is

Think of a token as a chunk of text somewhere between a syllable and a word in size.

Let’s just say "Fantastic" is one token. "I am" is two tokens. "Unbelievable" might be three tokens depending on the model, because some models break unfamiliar or long words into subword pieces. The OpenAI tokenizer playground (platform.openai.com/tokenizer) lets you paste any text and see exactly how it gets chopped up in colored blocks. Worth trying once just to calibrate your intuition.

The rough conversion for English: 1,000 tokens ≈ 750 words ≈ 2-3 pages of text. One token averages about 4 characters or 0.7 words. A standard 800 word blog post is roughly 1,000-1,100 tokens.

These numbers only hold for English. Code tokenization is worse: 1.5 to 2.0 tokens per word, because programming syntax has a lot of characters that don't map cleanly onto natural language tokens. Chinese, Japanese, and Korean are worse still, consuming 2 to 8 times more tokens than English for equivalent content. If you write a lot of code or work in a non English language, your consumption is meaningfully higher than the back-of-envelope math suggests.

Different models use different tokenizers, so the same text doesn't cost the same tokens everywhere. 1,000 tokens on GPT-5 (which uses the o200k_base tokenizer) might be 1,200 tokens on Claude or 900 tokens on Gemini. Comparing usage across platforms requires using each model's specific tokenizer for accurate counts.

The Context Window

Tokens are important for two distinct reasons. The first is your usage limit: how much you can do before hitting a wall. The second is the context window: how much the model can hold in memory at once.

Every model has a context window measured in tokens. Claude Sonnet 4.6 supports 1 million tokens. GPT-5 has 400K. Gemini 3 Pro has 2 million. Llama 4 Scout has 10 million. These numbers are impressive but misleading.

Larger context windows don't automatically mean better performance. Research consistently shows models degrade in quality before reaching their stated limits. A 2024 study from researchers Levy, Jacoby, and Goldberg found that LLM reasoning performance starts degrading around 3,000 tokens, well before any model's technical maximum. A 2025 study from Chroma tested 18 models including GPT-4.1, Claude 4, and Gemini 2.5 and documented what they called "context rot": a progressive decay in accuracy as prompts grow longer, even on simple string-repetition tasks. Every model showed that more context is not always better.

The context window is also shared by everything, not just your message and the model's reply. System instructions, tool calls, every previous turn in the conversation, uploaded files, and internal reasoning steps all eat from the same pool.

The Six Silent Token Drains

The majority assume token usage looks like: I type something, the model responds, that's one exchange. But in reality, it’s not linear and predictable.

1. Conversation History Compounds Fast

Every message you send in a multi-turn conversation carries the entire prior conversation as context. Turn 1 costs 2 units: you send 1, the model sends 1 back. Turn 2 costs 4 total because your second message includes the first exchange. Turn 3 costs 6. By turn 10, you might have spent 110 units cumulatively. Those same ten tasks as ten separate one-turn conversations would cost 20 units total. Same output but five and a half times less expensive.

People who treat a conversation like a running document, adding to the same thread for hours because it feels organized, are doing the most token-expensive thing possible.

A concrete example: you're using Claude to debug a software project. You paste 2,000 tokens of code, ask a question, get an answer, ask a follow-up, and so on. By the fourth exchange, the model is processing roughly 12,000 tokens to answer a question that, in isolation, would cost 500. The accumulated history is doing most of the spending.

2. Extended Thinking Generates Tokens You Never See

Most major LLMs now have a reasoning mode. OpenAI calls it o-series. Google calls it Thinking Mode. Anthropic calls it Extended Thinking. When enabled, the model works through the problem internally before responding.

That internal reasoning generates tokens. Reasoning tokens can amount to 10 to 30 times more than the visible output. A response that looks like 200 words to you might have cost 3,000 reasoning tokens behind it.

Claude's Extended Thinking is now adaptive, meaning the model decides whether a task needs deep reasoning or a quick answer. At the default effort level, it almost always thinks. So when you ask Claude to fix a typo, reformat a list, or look up a basic fact, it's still burning thinking tokens on a problem that doesn't require them. Toggling Extended Thinking off for simple tasks reduces costs with no quality tradeoff.

The same issue applies to OpenAI's reasoning models. GPT-5 routes requests to different underlying models depending on what your prompt signals. Phrases like "think hard about this" trigger a heavier reasoning model even when you don't need one. OpenAI's own documentation warns against adding "think step by step" to prompts sent to reasoning models, since the model is already doing it internally.

3. System Prompts Run on Every Request

Any AI product built on a foundation model, including custom GPTs, Claude Projects with custom instructions, or enterprise deployments, prepends a system prompt to every message you send.

A typical system prompt runs 500 to 3,500 tokens. Every time you send anything, those tokens run first. A company operating an internal chatbot with a 3,000-token system prompt handling 10,000 messages per day spends 30 million tokens on instructions alone, before any user has asked anything meaningful.

At the individual level: a Claude Project with extensive custom instructions reruns those instructions every time you open the project. Keeping project knowledge tight is directly cheaper, not just neater.

4. The "Hello" Problem

Back to the Reddit post. How does "hello" consume 13% of a session?

Actually before processing your word “hello”, it loads the system prompt, project knowledge, conversation history from earlier in the session, and enabled tools. In Claude Code specifically, it loads CLAUDE.md files, MCP server definitions, and session state from the working directory. All of that is billed as input tokens on every exchange, including the first one.

If your Claude Code environment has a complex CLAUDE.md, several MCP servers enabled, and a large project directory, your baseline token cost per message before you've typed anything might already be several thousand tokens. And "Hello" in that environment costs one word plus all the infrastructure the model needs to load before it can respond.

5. Uploaded Files Sit on the Meter Continuously

Uploading a 50-page PDF to a Claude Project means that document is held in context even when you're not actively asking questions about it. It consumes tokens every session because the model needs awareness of it to reference it when needed.

Token consumption in any chat comes from uploaded files, project knowledge files, custom instructions, message history, system prompts, and enabled tools, on every exchange. If you upload five large documents you ended up not referencing, you're still paying for them.

Keep project knowledge matched to what you're actually working on. Treat it like RAM, not a filing cabinet.

6. Agentic Tool Calls Explode the Count

If you use AI agents, Claude with tools, ChatGPT with Actions, or any autonomous workflow where the model calls external APIs or searches the web: every tool call appends its full result to the context. A web search returns roughly 2,000 tokens of results. Run 20 tool calls in a single session and you've consumed around 40,000 tokens in tool responses alone, before factoring in the growing conversation history stacking on top.

Claude Code agents performing 10 reasoning steps across a large codebase can process 50,000 to 100,000 tokens per task. For a team of engineers each running multiple agent sessions per day, this becomes the primary cost driver.

How to Preserve Your Token Budget

Start a New Conversation for Every New Task

Given the compounding math above, keeping one long conversation open across multiple unrelated tasks is the most expensive way to use an LLM. A 10-turn conversation spanning five topics costs more than five 2-turn conversations covering the same ground.

The instinct to keep everything in one thread feels organized. But resist it. So follow: new task, new conversation.

Match the Model to the Work

Frontier models, Claude Opus, GPT-5, and Gemini 3 Pro, are more expensive than their smaller siblings, and for most tasks the quality difference is negligible. Claude Sonnet handles complex coding, detailed analysis, long-form writing, and research synthesis without meaningful quality loss versus Opus. The difference shows up only on seriously complex multi-step reasoning, which represents a fraction of actual daily usage.

Default to the mid-tier model (Sonnet, GPT-4o, Gemini Flash Pro). Use the flagship when the task genuinely demands it. Avoid this:

Turn Off Extended Thinking for Simple Tasks

For Claude: toggle Extended Thinking off under "Search and tools" when doing quick edits, brainstorming, factual lookups, or reformatting. Response quality on those tasks won't change. Token cost drops substantially.

For GPT: use standard GPT-4o rather than o-series models for anything that doesn't require deep multi-step reasoning. The o-series is purpose-built for hard reasoning problems and wasteful for everything else.

Write Shorter Prompts

The research says short prompts generally work better than long ones, and they're cheaper. The practical sweet spot for most tasks is 150-300 words. That's specific enough to give the model real direction without stuffing it with context it doesn't need.

Write the shortest version of your prompt that describes your intent. Test it. Add only what's actually missing in the output.

For example, instead of: "I'm working on a marketing campaign for a B2B SaaS product that helps finance teams automate their accounts payable workflows. I'd like you to help me write a subject line for an email going to CFOs at mid-market companies. The tone should be professional but not overly formal. It should convey urgency without being pushy. The email is part of a drip sequence and this is the third email in the series, which means the recipient has already heard from us twice and hasn't responded yet..."

Try: "Write 5 subject lines for email #3 in a B2B drip to CFO prospects. Product: AP automation SaaS. Tone: professional, slight urgency."

The output is the same quality. The token cost is a fraction.

Skip Pleasantries Within Sessions

Every "thanks, that's helpful!" or "great, now can you also..." extends the conversation and inflates the running context. In a token-constrained environment, social filler costs real usage for no informational benefit.

This is also the mechanical explanation for the "hello" problem. In a loaded environment, a greeting is a full turn that loads all the infrastructure and generates a full response for zero informational value. Combined with a complex system environment, that adds up to 5-10% of a session before any real work begins. And this is cap:

Request Structured Outputs

Asking for structured outputs, such as JSON, numbered lists, or tables, typically requires fewer output tokens than narrative explanations while producing more usable results. Specifying "List 3 product features as JSON with keys: feature, benefit, priority" generates a parseable response in fewer tokens than "describe the three most important product features in detail." 

Research on this pattern shows output token reductions of 30-50% for equivalent informational content.

Keep Project Knowledge Matched to the Current Task

Only include documents directly relevant to what you're working on now. Archive old files when a project phase ends. Every file in a Claude Project runs on every session whether you reference it or not.

How to Check What You Have Left

Most AI products don't show a token meter. Here's how to find your usage anyway, by platform.

Claude (claude.ai)

Go to Settings → Usage, or navigate directly to claude.ai/settings/usage. This shows cumulative usage against your plan's limit. It's a lagging indicator and doesn't show real-time token count within a conversation.

For Claude Code specifically: /cost shows API-level users their token spend for the current session broken down by category. /stats shows subscribers their usage patterns over time.

Third-party tools for Claude Code

ccusage is a CLI tool that reads Claude's local JSONL log files and shows usage broken down by date, session, or project. It runs as a one-line npx command with no full installation. For Pro and Max subscribers who can't see consumption in the Anthropic Console (because they pay a flat subscription rather than per-token), this is the primary way to track where usage is going.

Claude-Code-Usage-Monitor provides a real-time terminal UI with progress bars, burn rate analytics, and predictions for when your current session will run out. It auto-detects your plan and applies the right limits: Pro is around 44,000 tokens per 5-hour window, Max5 around 88,000, and Max20 around 220,000. Run it in a separate terminal window and you'll see consumption update live.

Claude Usage Tracker is a Chrome extension that estimates token consumption directly in the claude.ai interface, tracking files, project knowledge, history, and tools, with a notification when your limit resets.

ChatGPT

OpenAI doesn't expose token usage to consumer users directly. Developer accounts with API access can see per-request token counts at platform.openai.com/usage. Consumer subscribers have no native meter. Third-party extensions exist in the Chrome store but aren't officially supported.

API users (any platform)

Every API response includes token counts in the metadata. For Claude, input_tokens and output_tokens appear in every response object. For OpenAI, the equivalent fields are usage.prompt_tokens and usage.completion_tokens. Build logging around these fields from the start, it's the only reliable way to track consumption at scale.

Before you send: token counters

Tools like runcell.dev/tool/token-counter and langcopilot.com/tools/token-calculator let you paste text and get an instant count before sending, using each model's official tokenizer. No signup are required and it runs in the browser. Useful before submitting large documents or complex prompts.

The Skill Worth Having

Token literacy used to be a developer concern but not today.

The same shift happened with data. Ten years ago, data literacy meant SQL and spreadsheets, practitioner territory. Now every business decision-maker is expected to read a dashboard, interpret a funnel, and question a metric. Tokens are on the same trajectory.

LLMs are embedded in real work now: drafting, analysis, coding, research. The people who understand the underlying economics will use them more effectively, hit limits less often, and get more from the same subscription.

Cheers.

On March 25, 2026, Google Research published a blog post about a compression algorithm called TurboQuant.

Within 48 hours, SK Hynix had lost 7.3% of its market value. Micron dropped 3%. Western Digital fell 4.7%. SanDisk gave up 5.7%. Kioxia, the Japanese flash memory company, dropped nearly 6%. The selloff spread across two continents, wiping out tens of billions in market cap.

Cloudflare's CEO Matthew Prince called it "Google's DeepSeek moment." Half the internet compared it to Pied Piper, the fictional startup from HBO's Silicon Valley. The memes moved faster than the actual research.

So what actually happened? And does this algorithm change anything about the memory situation the AI industry has been panicking about for the past 18 months?

Let's decode.

Why Modern AI Is So Hungry for Memory

When an LLM generates text, it doesn't recompute everything from the beginning with every new word. Instead, it stores all its prior calculations in a fast-access buffer called the key-value cache, or KV cache. Every token the model has seen in a conversation gets stored there, so when the model processes the next token, it can look back at what came before without redoing all the math.

The problem is the cache grows continuously. A model working through a 100,000-token document is holding a massive amount of active data in GPU memory just to maintain context. And this got significantly worse when reasoning models became mainstream. Reasoning means long context, long context means a large KV cache, large KV cache means you need a lot of memory. By 2024, anyone paying attention to the trajectory of AI models could see where this was heading and the market mostly didn't catch up until prices started reflecting it.

And the industry has been fighting this problem for years, with genuine ingenuity, and TurboQuant is the latest step in that arc.

What TurboQuant Is and How It Works

TurboQuant compresses that KV cache down to 3 bits per value, from the standard 16. The claimed reduction is 6x in memory footprint, with an 8x speedup in attention computation on Nvidia H100 GPUs, and no measurable accuracy loss in benchmarks.

The math works in two stages. 

The first stage, PolarQuant, converts data vectors from Cartesian coordinates into polar coordinates. In Cartesian form, a point is described by how far it sits along the X axis and Y axis: a grid of (x, y). In polar form, the same point is described by its distance from the origin (r) and the angle it makes from a reference direction (θ). The conversion is: r = √(x² + y²) and θ = arctan(y/x). Going back: x = r·cos(θ) and y = r·sin(θ). In higher dimensions, the same principle extends.

Why this matters for compression is because in polar space, the angular distribution of AI attention data clusters in predictable, concentrated patterns. Traditional quantization methods have to store extra normalization constants alongside compressed data so the system can decompress accurately later. Those constants add one or two bits per value right back in, partially undoing the savings. PolarQuant eliminates that overhead because the structure of the data in polar space makes those constants unnecessary.

The second stage handles the residual error left over from stage one. Each leftover error number gets reduced to a single sign bit, positive or negative. That sign bit acts as a statistical zero-bias corrector, meaning the compressed cache remains equivalent to the full-precision original when the model computes attention scores. The model doesn't notice the difference.

Google tested TurboQuant on five standard benchmarks for long-context models, including LongBench and Needle in a Haystack, using Gemma, Mistral, and Llama. At 3 bits, it matched or beat KIVI, the standard baseline for KV cache quantization. On needle-in-a-haystack tasks where the model has to locate a specific fact buried in a long document, it hit perfect scores at 6x compression. 

The Crunch That Was Years in the Making

The reason a compression paper could move the memory chip market by 6% in two days is that the memory situation going into 2026 was already extreme. To understand it, you need to go back to 2023.

In 2023, memory manufacturers were losing money. DRAM prices had collapsed after the pandemic oversupply, and Samsung, SK Hynix, and Micron all pulled back on capital expenditure. They weren't building new fabs because there was no margin to justify it. But it coincided precisely with the beginning of the reasoning model era, which was about to create a demand curve no one had seen before in this industry.

Let’s understand why AI is so hard on memory. A GPU needs data to move at extreme speeds to keep its processors fed. An HBM4 stack, the type of memory used in Nvidia's latest chips, transfers memory at roughly 2.5 terabytes per second. A comparable area of standard DDR5, the memory in your laptop, does somewhere around 64 to 128 gigabytes per second. Consumer memory is built for a completely different job. 

HBM is built differently, stacked in multiple layers, connected with thousands of micro-connections called through-silicon vias, and it's extraordinarily expensive to produce. Producing one gigabyte of HBM consumes four times the wafer capacity of standard DRAM. To put that in GPU terms: a single Nvidia H100 currently costs between $25,000 and $30,000 per chip, and memory accounts for roughly 30% of the cost of deploying AI at scale. When Meta built its initial H100 training cluster with 24,000 of those chips, the GPU hardware bill alone crossed $800 million, before a single power cable was run or a server rack assembled. That's one cluster, hyperscalers are building dozens. Of the $600 billion in combined Big Tech capital spending this year, roughly $180 billion is going to memory alone.

People usually make the "just make more memory" argument. Global silicon wafer production capacity is growing, but only at around 6 to 7% per year. AI infrastructure spending is growing at rates many times that. The fabs that will eventually close the gap started construction after the demand signal hit, which means the meaningful new capacities don't come online until 2027-2028 and the crunch can potentially last until 2030.

The Compression Arms Race That Was Already Happening

The industry has been chipping away at the KV cache memory problem for years.GPT-2 XL, the largest 2019 variant, used the simplest possible design: every attention head kept its own independent set of keys and values. Cost: around 300 kilobytes per token. By 2024, Llama 3 8B introduced grouped-query attention, where multiple heads share the same stored representations instead of maintaining separate copies. Cost dropped to 128 kilobytes per token, less than half, with almost no quality loss on benchmarks. Then DeepSeek V3 went further with multi-head latent attention, compressing the key-value pairs into a lower-dimensional form before storing them and decompressing at inference time. Cost: 68.6 kilobytes per token, on a model with 671 billion total parameters, though only 37 billion are active at any moment.

That progression, 300 to 128 to 68 kilobytes per token, is the compression arc that existed before TurboQuant showed up. Each step traded something, usually some architectural complexity or slight recall degradation, for meaningful memory savings. Each step also captured the easier gains first. What remained got harder.

So by the time TurboQuant arrived, the low-hanging fruit was gone. TurboQuant matters less because it saves additional memory and more because it marks where KV cache compression is approaching the information-theoretic limit. You're close to the Shannon ceiling. Every additional bit squeezed out from here costs more engineering effort and risks more quality degradation than the last.

There's also a problem no compression algorithm touches. When the KV cache grows too large for available GPU memory, models often summarize their own context into a shorter form and continue from the summary. The compression is lossy in ways the model can't detect. A specific budget figure becomes "approximately that amount." A nuanced instruction becomes "something about guidelines." The model keeps going, confident in information that no longer fully exists. Compression makes the cache smaller. It doesn't solve the problem of deciding what's actually worth keeping.

So Why the Market Reaction Was Wrong

The stocks fell for the same reason markets often overreact to technical announcements: most investors read the headline, not the paper.

TurboQuant only addresses inference memory, specifically the KV cache during inference. Training a model, the months-long, multi-billion-dollar process of teaching the model in the first place, requires fundamentally different memory, driven by activations, gradients, and optimizer states. TurboQuant has zero effect on any of that. The massive HBM buildout that hyperscalers are funding exists primarily to train and retrain ever-larger models. That demand curve is untouched by a KV cache compression algorithm.

Beyond training, TurboQuant is a research result with no production deployment. The paper was originally published in 2025 and got re-featured on the blog ahead of ICLR. Google itself hasn't deployed it widely in the year since the math was first documented.

The 6x headline also deserves scrutiny. It's benchmarked against 16-bit full-precision. Commercial inference already runs at 4 or 8 bits as standard practice. So the real marginal gain over deployed systems is smaller than the number suggests.

Jevons Paradox is another thing to talk about. When DeepSeek launched dramatically more efficient inference in early 2025, the same fear spread: HBM demand would drastically fall but it didn't. Because cheaper inference expanded the set of organizations that could economically deploy AI, which drove more total demand for infrastructure. When inference costs fall, more applications become viable, more models stay active, and memory companies end up as the long-run beneficiary.

The market has now seen this exact movie twice, but panicked both times. Weird right?

So What TurboQuant Actually Changes

The algorithm does have real implications. They're just different from what the market priced in.

The most immediate is inference economics. TurboQuant compresses the KV cache, which determines how many concurrent users a single GPU can serve and how long a context window is practical at scale. If it gets deployed across production inference stacks, the throughput per GPU increases. That matters for AI products running millions of queries per day, where inference cost is the recurring expense that determines profitability. Anything that changes the memory-to-compute ratio per query shifts the cost structure of running AI products.

The longer-term implication is on-device AI. Right now, running a capable language model locally on a phone or laptop requires either compromising on quality or buying expensive hardware. If TurboQuant's approach gets implemented in local inference runtimes at scale, the hardware floor for running a meaningful AI model drops. Models that currently require cloud infrastructure could run locally.  But it plays out over years, not quarters, and it has more to do with software ecosystem adoption than with whether memory chip stocks are correctly priced today.

It’s definitely real math that compresses one specific type of memory usage during one phase of AI operation. But it doesn't build fabs and it doesn't change training economics. Memory gets built in clean rooms in South Korea and Idaho, by people operating tools that cost hundreds of millions of dollars each. That part of the supply chain moves on a completely different clock than an algorithm (or just a research paper.)

So the crunch only ends when the fabs are done.

A first-year investment banking analyst at a bulge bracket bank in the US costs $170k–$190k all-in. They spend most of their first year formatting pitch books, building the same DCF they built last month, reconciling accounts that will need reconciling again in 30 days, and writing variance commentary that explains the past to people who already lived through it.

The ratio of judgment to repetition skews heavily toward repetition, and that ratio has not changed in decades. In 2026 it is starting to change.

AI is not smart enough to replace financial judgement (yet). But for the repetitive half of the job: the formatting, the first drafts, the matching, the narrating, AI is now fast, accurate and integrated enough to be genuinely useful on the same afternoon you set it up.

In this article, we’ll look at four practical finance workflows where Claude already shows strong promise today: investment banking materials, financial modeling support, month-end reconciliation, and variance analysis. We’ll also look at where it still needs human review before anyone should trust it in a serious workflow.

How Finance Teams Use Claude for Investment Banking Work

Investment banking runs on documents. CIMs, teasers, process letters, buyer lists, merger models, pitch decks. The work is real and repetitive: an analyst building a one-pager for a deal teaser spends hours formatting, sourcing data, and structuring the same four quadrants they built last week for a different company.

Anthropic released a dedicated Investment Banking plugin for Claude Cowork on February 24, 2026. It is open source, free to install, and gives Claude 7 slash commands backed by 9 underlying skills across three workflow categories: deal materials, presentations, and transaction support. Quick terminology note since it comes up throughout this guide: skills are the domain knowledge modules that activate automatically when relevant; commands are the slash commands you invoke explicitly. Each command calls one or more underlying skills.

What it contains

Deal materials: CIM drafting, teaser generation, process letters, buyer lists, and data pack extraction from existing documents. Presentations: strip profiles and pitch deck population using your firm's branded PowerPoint templates. Transaction support: merger model construction and a deal tracker for live milestones and action items.

Installing it

The plugin requires Claude Cowork (desktop app, Enterprise plan or above) or Claude Code (Pro Plan or above.) Install the financial-analysis core plugin first, it provides the shared modeling tools and all MCP data connectors that the IB plugin depends on. Then add investment-banking on top.

Via Claude Code:

claude plugin marketplace add anthropics/financial-services-plugins

claude plugin install financial-analysis@financial-services-plugins

claude plugin install investment-banking@financial-services-plugins

Via Cowork desktop: Settings → Plugins → Add marketplace from GitHub → enter https://github.com/anthropics/financial-services-plugins → install financial-analysis, then investment-banking.

/one-pager [Company Name] Generates a single PowerPoint slide with four quadrants: Overview, Business, Financials, and Ownership. Respects your existing template's margins and branding. This is the strip profile that populates pitch books and buyer lists.

/cim [Company Name] Produces a full Confidential Information Memorandum: executive summary, business overview, financial analysis, and market positioning sections. Claude drafts the structure and content; your team fills in proprietary data and tightens the narrative.

Rest of the commands for you to try yourself:

/teaser [Company Name] Generates an anonymous one-page company teaser for early-stage deal marketing. Same core structure as the CIM but stripped of identifying information.

/buyer-list [Company Name] Assembles a strategic and financial buyer universe. Claude categorizes potential acquirers by type, sizes the fit, and structures the output for easy review and prioritization.

/merger-model [Acquirer acquiring Target] Builds an accretion/dilution M&A analysis. Output includes sources and uses schedule, pro forma financials, and sensitivity analysis on purchase price and synergies.

/process-letter [Deal Description] Produces bid instructions and process correspondence for a live transaction.

/deal-tracker Tracks active deals, milestones, and action items. A structured project management view for live mandates.

How to get the most out of it

The plugin ships with generic methodology. The real value comes when you customize the skill files for your firm: drop in your terminology, reference your branded PowerPoint template in the skill files, adjust the CIM structure to your house format. After that, every CIM draft, every one-pager, every buyer list comes out in your voice.

Claude carries full context between Excel and PowerPoint in a single session. An analyst can run /merger-model, update assumptions in Excel, then ask Claude to build the summary slide in PowerPoint without switching tools or losing context. This cross-app workflow is in research preview for paid plans as of February 2026.

Honest caveat

These commands produce first drafts, not final deliverables. The CIM needs your firm's proprietary market intelligence. The buyer list needs your banker's network knowledge. The merger model needs human verification of every assumption before it goes to a client. Use these as the starting point, not the finished product.

Using Claude for Comparable Company Analysis, DCF Models and Valuation Outputs

Raw prompting while building financial models produces output that looks correct and is not. An analyst at a financial modeling consultancy ran this test in January 2026: same prompt to Claude for Excel and Excel's Agent Mode. Claude's model had a cleaner layout and better styling. It also discounted cash flows using a debt-to-equity ratio instead of WACC, set the equity risk premium at 120% instead of 5-6%, and used a different discounting method for the terminal value. It looked investment-committee-ready and was arithmetically broken.

That failure mode has a fix, and it is the financial-analysis plugin.

Installing it

The financial-analysis plugin is also the foundation for the IB plugin from section. If you installed that already, you have this too. If not:

claude plugin marketplace add anthropics/financial-services-plugins

claude plugin install financial-analysis@financial-services-plugins

Once active, you get two commands plus MCP connectors to every major financial data provider.

/comps [Company Name]

Runs a comparable company analysis. Claude selects the peer group, pulls current trading multiples from connected data sources, builds the comps table, and outputs a formatted Excel workbook with industry-standard structure. The peer selection is the one thing you review and adjust - that judgment cannot be automated. Everything else: pulled, calculated, formatted.

/dcf [Company Name]

Builds a full DCF. The plugin's methodology layer is what makes this different from a raw prompt: it pulls the current government yield curve from LSEG to set the risk-free rate, retrieves historical equity prices and beta to anchor the cost of equity, and checks for internal consistency before outputting. The inputs are market-driven and traceable, not assumed.

What you still verify every time: WACC inputs (equity risk premium, beta, cost of debt), that the discounting is consistent across projected cash flows and terminal value, and that FCF is pulling from the right line items. The plugin prevents the obvious failures. It does not eliminate the need for a human to read the model. Wall Street Prep's 2026 testing found that Claude hallucinated historical financial data and every AI tool scored zero on circularity handling: both risks that persist regardless of plugin.

Using Claude in Excel without slash commands

The plugin commands produce new models. Claude in Excel also works on models you already have, and this is where it earns time every day.

An analyst inheriting a 47-tab model built by someone who left the firm asks: "Explain this entire spreadsheet to someone seeing it for the first time." Claude traces every dependency chain and cites the exact cells. What used to take days of reverse-engineering takes an hour.

Scenario analysis runs conversationally. "What happens if we delay all Q2 hires by one quarter?" Claude updates every affected cell, preserves the formulas, and shows the exact runway impact. You explore without touching the model structure. Formula debugging works the same way: instead of hunting through cells, you get a direct explanation of which cell is feeding the error, what format it expects, and where the mismatch originates.

MCP connectors

If you have active data entitlements with S&P Global, LSEG, Daloopa, PitchBook, Moody's, or FactSet and have configured them in your Claude settings, they are live in Excel automatically. "Pull [Company]'s LTM revenue, EBITDA, capex, and net debt from Daloopa" populates the cells directly. "Get the current 10-year government yield from LSEG" updates the risk-free rate live. The manual export-format-paste step disappears.

Where to start

Model audit first. Upload an existing model and ask Claude to explain its structure, map the key assumptions, and flag formula errors. That works today with no plugin required and no risk of bad model output. Once you are comfortable with how Claude reads your models, move to scenario analysis. Use /comps and /dcf last, and plan to verify the financial logic before anything goes to a client.

Using Claude for Month-End Reconciliation

Account reconciliation sounds simple and destroys days. Every close cycle, an accountant exports the GL balance, pulls the bank statement or subledger detail, manually matches transactions, investigates exceptions, documents the reconciling items, and builds a workpaper for audit. Then AR. Then AP. Then intercompany. Then prepaids. By the time the operating account is done, it is day three of close.

Anthropic's finance plugin (different from financial analysis plugin) ships with a structured reconciliation skill that understands the methodology and applies it consistently. It is a separate plugin from the financial-analysis plugin used in sections 1 and 2, and lives in a different repository.

Installing the finance plugin

claude plugin marketplace add anthropics/knowledge-work-plugins

claude plugin install finance@knowledge-work-plugins

Or via Cowork desktop: Settings → Plugins → Add marketplace → https://github.com/anthropics/knowledge-work-plugins → install finance.

Once installed, Claude has access to six skills: journal-entry-prep, reconciliation, close-management, financial-statements, variance-analysis, and audit-support. Each has a corresponding slash command.

Running your first reconciliation

Drop your GL export and bank statement into the Cowork project. Then run:

/reconciliation cash 2026-02

Claude compares both sides, calculates the difference, and builds the workpaper. It categorizes each reconciling item: timing differences that will clear next period, items that need a journal entry, and exceptions that need investigation. It assigns aging buckets and flags anything over your materiality threshold.

Note: For AR subledger reconciliation, use:

/reconciliation accounts-receivable 2026-02

The compounding curve

Month 1: Claude applies the generic methodology. Roughly 60% of items match automatically. You resolve the exceptions in the same Cowork session: type out the pattern in plain language: "this vendor always settles two days after invoice date," "this intercompany charge posts to cost center 402 but should be 408," "this bank fee has no GL equivalent and should be flagged as a new journal entry." Claude incorporates these explanations into the workpaper and carries the patterns into the next session.

Month 2: Claude applies what it learned. It handles 85% or more of matches on its own. The exception list shrinks, and the items it flags are genuinely unusual.

Month 3: The reconciliation takes half the time it did in Month 1.

These numbers come from a single practitioner's account (David Dors, Building Profit, February 2026), not a controlled benchmark. Treat them as directional. The compounding pattern is real regardless of exact percentages, every pattern you teach Claude in Month 1 carries forward.

With ERP connectors

If your organization has connected NetSuite, SAP, or another ERP via MCP, Claude pulls GL balances and subledger detail automatically. Without connectors, you paste data or upload files. The reconciliation works either way.

The honest limitation

The finance plugin runs inside Cowork, which requires Claude Desktop to be open on your machine. Overnight batch reconciliations, high-volume AP matching, and ERP-native reconciliation across hundreds of accounts need server-side infrastructure, not a desktop app. For that scale, purpose-built platforms are the right tools. They encode three-way matching logic, prepaid amortization rules, and intercompany netting at a depth a general-purpose agent does not.

What Claude's plugin handles well is the analyst-driven close workflow: one accountant, a handful of key accounts, a monthly cadence where the time savings compound. That is most finance teams.

Using Claude for Variance Analysis and Commentary

Every FP&A team spends hours each close cycle writing variance commentary. The real difficulty is not volume, it is coherence across aggregation levels. A vendor-level change flows into a GL account, rolls into a cost center, and surfaces at the P&L line. The commentary at each level needs to be consistent and tell the same story upward. Maintaining that consistency manually, across four business units and two product lines, is where time actually goes.

AI helps with the drafting layer of that problem, not the explanation layer. Claude can generate structured first-draft commentary from a verified data table, labeling variances, flagging material movements, maintaining consistent tone across sections. What it cannot do is explain why a number moved without being told.

The reason behind a variance lives in your ERP, your CRM, your headcount system, and the judgment of the analyst who lived through the quarter. Claude produces coherent narrative from the data you feed it. The richer the context you provide: prior commentary, GL detail, cost center breakdowns, known one-time items, the more useful the draft.

Variance commentary is still worth doing with AI. The drafting step is the one that consumes disproportionate time relative to its analytical value, and that is exactly where Claude delivers.

Using the finance plugin

If you have the finance plugin installed, run:

/variance-analysis opex 2026-02 vs budget

The plugin decomposes the variance into drivers, builds a waterfall chart, and produces commentary structured by category. For revenue variances, it breaks out price and volume effects. For OPEX, it disaggregates by department and account. The waterfall goes directly into your reporting package.

What the analyst actually reviews

AI-generated variance commentary has one specific failure mode: it narrates what the data says without knowing what the data means. A 12% revenue miss in the West region might be a single account that closed late, a structural pipeline problem, or a pricing decision that will reverse in Q2. Claude does not know which one. The analyst does. That judgment is the only thing that cannot be automated in this workflow.

Where purpose-built tools have an edge

For teams with enterprise FP&A platforms, purpose built tools do variance detection plus narrative generation as a connected workflow pulling actuals from your ERP, running the calculation, and drafting commentary in a single step. If you are already paying for one of these platforms, use them for this. They are designed for it.

Claude's advantage is for teams not ready to adopt a full FP&A platform: the finance team that runs on Excel, has access to Claude through a broader enterprise agreement, and wants to cut commentary time this close cycle without a new software implementation.

Where to Start

Pick one workflow. Not all.

If your team does deal work, install the IB plugin and run /one-pager on a live company this week. If you are in FP&A, take last month's variance commentary, paste it into Claude with the current numbers, and see what comes back. If you are in accounting, run one bank reconciliation through Cowork this close cycle and compare the time.

Cheers. 

The post The advent of 3GPP Non-Terrestrial Networks: satellite becomes anoption for cellular devices appeared first on IoT Now News - How to run an IoT enabled business.

The post Is your IoT strategy ready for APAC complexity? appeared first on IoT Now News - How to run an IoT enabled business.

The post West Sussex advances smart livestock monitoring with Pneumonitor and Boldyn Networks’ private 5G appeared first on IoT Now News - How to run an IoT enabled business.

The post Fibocom launches RU311 5G RedCap module series for streamlined 5G upgrades in mid-tier IoT appeared first on IoT Now News - How to run an IoT enabled business.

The post Suresh Sathyamurthy joins Aeris as CMO for physical AI push appeared first on IoT Now News - How to run an IoT enabled business.

The post Flashnet joins Netmore Pulse Partner Program to scale smart street lighting appeared first on IoT Now News - How to run an IoT enabled business.

The post GigaDevice strengthens EMEA and Southeast Asia market reach through partnership with Rutronik appeared first on IoT Now News - How to run an IoT enabled business.

The post Connecting IoT devices to edge AI infrastructure: the role of global IoT connectivity providers appeared first on IoT Now News - How to run an IoT enabled business.

The post IoT Sparks 2026 opens the registrations to the workshops and launches a flash sale for premiere international IoT and AI event appeared first on IoT Now News - How to run an IoT enabled business.

The post IoT in Transition: Navigating a Rapidly Evolving Global Regulatory and Connectivity Landscape appeared first on IoT Now News - How to run an IoT enabled business.

Emergent behaviours in AI look surprising, but they aren’t mystical, spontaneous, or evidence of consciousness. They are statistical side effects of scale, structure, and training dynamics—behaviours that feel magical only because we misunderstand the underlying mechanics.

The Myth: Emergence as “AI Magic”

Few phrases in modern AI generate as much confusion—and as many breathless headlines—as emergent behaviours. The term evokes images of models suddenly “waking up,” discovering new abilities overnight, or developing skills no one programmed into them.

This framing is seductive. It’s also wrong.

Emergent behaviours are not miracles. They are not signs of self-awareness. They are not evidence of hidden internal reasoning modules spontaneously forming. They are not “sparks of AGI.”

They are the predictable result of scaling statistical systems to the point where new patterns become learnable.

The magic is only in our misunderstanding.

What Emergence Actually Means

In complex systems theory, emergence describes behaviours that appear at the system level but are not explicitly present in any individual component. Ant colonies exhibit emergent foraging patterns. Markets exhibit emergent price dynamics. Human consciousness itself is emergent from billions of neurons.

In AI, emergence refers to capabilities that appear when a model reaches a certain scale or training threshold, even though those capabilities were not directly engineered.

But here’s the key: Emergent behaviours arise from the structure of the model and the data—not from anything mystical happening inside the model.

They are statistical phase transitions, not spontaneous creativity.

Why Emergence Feels Surprising

Emergent behaviours catch people off guard for three reasons:

1. We underestimate the complexity of the training data

Large-scale models ingest vast, heterogeneous datasets. When a model suddenly demonstrates a new skill—like solving multi-step logic puzzles—it’s not because it invented logic. It’s because it finally reached the scale needed to generalize patterns already present in the data.

2. We misunderstand how scaling laws work

AI performance doesn’t increase linearly with size. It jumps. At certain thresholds, models stop memorizing and start generalizing. At others, they stop pattern-matching and begin reasoning-like behaviour.

These jumps feel magical, but they are mathematically predictable.

3. We project human traits onto statistical systems

When a model surprises us, we instinctively reach for human metaphors: “It figured it out,” “It learned a new skill,” “It discovered a strategy.” But the model didn’t discover anything. It simply crossed a complexity threshold where new patterns became representable.

The Reality: Emergence Is a Phase Transition

Think of emergent behaviours like water boiling.

At 99°C, water is hot. At 100°C, it becomes steam.

Nothing mystical happened at 100°C. The system simply crossed a threshold where a new behaviour became possible.

AI models behave the same way.

When a model reaches a certain number of parameters, training tokens, or architectural depth, new capabilities become statistically accessible. The model didn’t “decide” to become smarter. It simply became large enough to encode more complex relationships.

Emergence is not magic. It’s thermodynamics for information.

Examples of Emergent Behaviours (and Why They Aren’t Mystical)

1. Chain-of-thought reasoning

Models appear to “think step-by-step.” In reality, they’ve learned patterns of structured reasoning from millions of examples.

2. Tool use and API calling

Models seem to “figure out” how to use tools. In truth, they’ve learned the statistical structure of tool invocation patterns.

3. Translation between languages never explicitly trained

Models appear to “invent” translation capabilities. But multilingual data contains shared semantic structures. Scale allows the model to align them.

4. Solving tasks they were never designed for

This is the classic “emergent ability.” But again, the model wasn’t designed for any specific task. It was trained to compress patterns across massive datasets. New tasks simply become representable at scale.

Why the Myth Persists

Emergent behaviours are misunderstood because:

• They appear suddenly.
• They feel unpredictable.
• They challenge our intuition about how software should behave.
• They resemble human learning in ways that tempt anthropomorphism.
• They expose gaps in our mental models of AI systems.

And, frankly, “AI discovers new abilities on its own” makes for better headlines than “Model crosses statistical threshold enabling new representational capacity.”

The Danger of Treating Emergence as Magic

Misinterpreting emergent behaviours leads to real-world risks:

1. Overestimating AI capabilities

Believing emergence is magic encourages unrealistic expectations about autonomy, reasoning, and self-direction.

2. Underestimating failure modes

Emergent behaviours can be brittle, inconsistent, or misleading. Treating them as “intelligence” blinds us to their limitations.

3. Misguided policy and regulation

If policymakers believe AI is spontaneously evolving, they may regulate based on science fiction rather than science.

4. Poor engineering decisions

Teams may rely on emergent behaviours instead of designing robust systems.

Emergence is powerful—but only when understood correctly.

The Breakthrough: Predictable Emergence

The real breakthrough of the last five years is not that models exhibit emergent behaviours. It’s that we can increasingly predict when and why they emerge.

Scaling laws, architectural research, and interpretability tools have revealed:

• Emergence correlates with parameter count and dataset diversity.
• Certain abilities require specific representational depth.
• Phase transitions occur at identifiable thresholds.
• Emergence can be induced, suppressed, or guided.

This transforms emergence from a mysterious phenomenon into an engineering discipline.

The Future: Designed Emergence

Q3’s theme—Technical Myths, Misconceptions & Breakthroughs—begins here because emergence is the perfect example of how misunderstanding leads to myth, and how deeper technical insight leads to breakthrough.

The next frontier is intentional emergence:

• Architectures designed to unlock specific phase transitions
• Training regimes that encourage structured reasoning
• Modular systems that combine emergent capabilities with deterministic control
• Safety frameworks that anticipate emergent behaviours before deployment

Emergence will become less like a surprise and more like a tool.

Closing Thought

Emergent behaviours aren’t magic. They’re the natural consequence of scale, structure, and data interacting in complex ways.

The real challenge—and opportunity—is learning to harness emergence without mythologizing it.

Understanding this distinction is essential for anyone building, regulating, or relying on AI systems in 2026 and beyond.

Conceived, written and published by AI Quantum Intelligence with the help of AI models.

In the public conversation, “data” is treated like a commodity—something companies collect, store, and monetize. But inside enterprise strategy rooms, data is not a commodity. It’s a power instrument. It determines who builds the most capable AI systems, who controls the customer relationship, who captures the margins, and ultimately, who shapes the future of an industry.

This week, we cut through the PR narratives and examine the real reason companies want your data—and why the answer has nothing to do with convenience or personalization.

1. Data Isn’t Valuable — It’s Leverage

Executives rarely say it out loud, but inside enterprise AI strategy decks, data is described as a force multiplier. Not because it’s “useful,” but because it creates asymmetry.

The companies dominating global markets today—Amazon, Google, Meta, Tencent, and ByteDance—aren't winning because they have more data. They’re winning because they have the right data, structured in ways that allow them to:

• Predict what customers will do
• Influence what customers want
• Optimize operations faster than competitors
• Train proprietary AI models that no one else can replicate

This is the part most people miss: The moat isn’t the dataset. The moat is the feedback loop.

Once a company reaches critical mass, every interaction strengthens its models, which strengthen its products, which attract more interactions. Competitors aren’t just behind — they’re locked out of the loop entirely.

2. AI Has Shifted Data From Insight to Influence

Before AI, data told companies what happened. Now, it tells them what will happen — and increasingly, what should happen.

This shift is profound. It means enterprises aren’t collecting data to understand the world; they’re collecting data to shape it.

Modern AI systems trained on behavioral, transactional, and contextual data can:

• Predict churn before customers feel dissatisfied
• Detect buying intent before customers consciously decide
• Identify operational failures before they occur
• Recommend actions that maximize revenue or minimize cost
• Influence user behavior through personalized nudges

Data used to be descriptive. Now it’s prescriptive.

This is the real reason enterprises are expanding their data pipelines: AI has turned data into a mechanism of behavioural influence.

3. The Economic Engine: Margin Capture

In industries where margins are thin and competition is brutal, AI‑driven data systems are the difference between leading the market and being acquired by someone who does.

Every percentage point of predictive accuracy translates into:

• Lower acquisition costs
• Higher retention
• Reduced operational waste
• More efficient supply chains
• Better pricing models
• Faster product iteration cycles

Data isn’t just an asset. It’s guaranteed margin.

This is why enterprises want your data: AI converts it directly into profit.

4. The Power Play: Whoever Owns the Data Sets the Rules

Data concentration doesn’t just create competitive advantage — it creates policy gravity.

The companies with the most comprehensive data ecosystems end up defining:

• Industry standards
• API structures
• Privacy norms
• Pricing models
• Customer expectations
• The pace of innovation

Regulators respond to them. Competitors imitate them. Customers adapt to them.

This is why enterprises want your data: It gives them the power to shape the market in their image.

5. AI Models Are Only as Good as Their Data

Enterprises have finally accepted a truth that AI researchers have known for years:

Algorithms matter far less than the data that trains them.

This is why companies are racing to collect:

• Real‑time behavioral data
• High‑resolution operational data
• Cross‑channel identity data
• Contextual environmental data
• Longitudinal historical data

The more complete the dataset, the more capable the model. The more capable the model, the more defensible the business.

Data isn’t fuel. It’s the foundation of AI capability.

6. The Ethical Blind Spot: Consent Has Become Meaningless

Most enterprises aren’t violating privacy laws. They’re simply exploiting the fact that consent no longer protects users.

People click “Agree.” Systems collect everything. AI models infer even more.

Modern privacy frameworks allow companies to:

• Collect more than users realize
• Infer more than users expect
• Monetize more than users understand

The ethical gap is widening. The economic incentive is accelerating. The regulatory response is lagging.

This is why enterprises want your data: The rules allow them to take it — and the market rewards them for doing so.

7. The Real Reason: Data Is the Only Thing AI Can’t Fake

AI can generate text, images, code, and synthetic datasets—but it cannot generate authentic human behaviour.

Real data is the one resource AI cannot manufacture.

This is why enterprises want your data: It’s the only irreplaceable input in the AI economy.

Conclusion: Data Is Power — and Companies Want All of It

The real reason companies want your data isn’t personalization, convenience, or innovation. It’s dominance.

Data determines:

• Who builds the best AI
• Who controls the customer relationship
• Who captures the margins
• Who sets the rules
• Who survives the next decade

In the AI era, data is not an asset. It’s the battlefield.

And companies want your data because they intend to win.

Conceived, written, and published by AI Quantum Intelligence with the help of AI models.

AI doesn’t fail because the technology is immature—it fails because organizations are. The gap between AI capability and enterprise readiness is structural, cultural, and economic. Integration isn’t a technical problem; it’s a systems problem.

1. The Myth of Readiness

Most large enterprises claim they’re “ready for AI.” They have:

• Data lakes
• Cloud infrastructure
• Pilot projects
• Executive sponsorship

But readiness is not about assets — it’s about alignment. AI integration fails when:

• Strategy and execution are disconnected
• Data governance is fragmented
• Incentives reward legacy performance metrics
• Decision rights are unclear

The result: AI initiatives that look impressive in PowerPoint but die in production.

2. The Organizational Immune System

Enterprises are built to resist change. AI threatens existing hierarchies, workflows, and power structures—so the organization’s “immune system” activates.

Symptoms include:

• Endless committees and review cycles
• “Responsible AI” frameworks used as delay tactics
• Middle management gatekeeping
• Fear of automation-driven job displacement

AI doesn’t fail because it’s risky. It fails because it’s disruptive. And disruption is precisely what bureaucracies are designed to suppress.

3. The Data Problem Isn’t Technical—It's Political

Every enterprise says “we have lots of data.” Few admit that most of it is:

• Siloed
• Inconsistent
• Poorly labeled
• Owned by competing departments

Data integration requires political negotiation, not just ETL pipelines. Without unified data governance, AI models become mirrors of organizational dysfunction—amplifying bias, inconsistency, and inefficiency.

The irony: the more data an enterprise has, the harder it becomes to use it coherently.

4. The Vendor Trap

Many enterprises outsource AI integration to vendors promising “turnkey transformation.” But vendors optimize for:

• Contract renewals
• Proprietary lock‑in
• Short‑term deliverables

They rarely fix the underlying structural issues. So enterprises end up with:

• Fragmented AI stacks
• Competing dashboards
• Redundant models
• No internal capability growth

AI becomes a service dependency, not a strategic asset.

5. The Talent Paradox

Enterprises hire data scientists and ML engineers — but place them in environments where they can’t succeed.

Common patterns:

• Talent buried under layers of management
• No access to production data
• No authority to change workflows
• KPIs tied to vanity metrics

AI talent without autonomy is ornamental. Integration requires organizational redesign, not just recruitment.

6. The Economics of Failure

AI integration fails because enterprises misprice the economics of transformation.

They underestimate:

• The cost of data cleaning
• The time to retrain staff
• The impact on legacy systems
• The need for continuous model maintenance

They overestimate:

• Short‑term ROI
• Vendor promises
• Executive enthusiasm

The result is a cycle of pilot projects that never scale—a phenomenon known internally as “AI theater.”

7. The Cultural Divide

AI thrives in cultures of experimentation. Enterprises thrive in cultures of predictability.

When these collide:

• Innovation becomes compliance
• Curiosity becomes risk
• Learning becomes liability

True integration requires cultural transformation — shifting from control to adaptation. That’s not a technical upgrade; it’s a leadership revolution.

8. The Governance Illusion

Many enterprises create AI ethics boards, oversight committees, and responsible AI frameworks. These are important — but often symbolic.

Governance fails when:

• It’s divorced from operational reality
• It’s used to delay rather than enable
• It lacks enforcement power

Effective governance integrates ethics into design and deployment, not just policy and paperwork.

9. The Path Forward: Integration as Evolution

Successful AI integration doesn’t look like a “big bang.” It looks like evolution — incremental, adaptive, and continuous.

Key principles:

• Start with small, high‑impact use cases
• Build internal capability before scaling
• Align incentives with transformation goals
• Treat data as infrastructure, not exhaust
• Embed AI into workflows, not beside them

Integration succeeds when AI becomes invisible — when it’s simply how the enterprise operates.

10. The Reality Check

AI integration fails not because enterprises lack ambition, but because they lack coherence. Technology moves faster than governance, faster than culture, faster than economics.

Until enterprises redesign themselves for adaptability, AI will remain a peripheral experiment — powerful in theory, fragile in practice.

Conceived, written and published by AI Quantum Intelligence with the help of AI models.

The real monopoly power in AI doesn’t come from the models themselves — it comes from the infrastructure, data pipelines, and distribution channels that only a handful of companies control. Foundation models are not just technical artifacts; they are economic levers that reshape market structure, bargaining power, and the future of competition.

1. Foundation Models Aren’t Products — They’re Platforms of Control

Foundation models have become the new “operating systems” of intelligence. They sit beneath:

• Enterprise workflows
• Consumer applications
• Developer ecosystems
• National AI strategies

But unlike traditional platforms, foundation models are:

• Expensive to build
• Hard to replicate
• Dependent on proprietary compute and data

This creates a structural imbalance: whoever controls the model controls the rules of participation in the AI economy.

The result is a form of monopoly power that is less visible than market share — but far more consequential.

2. The Compute Monopoly: When Infrastructure Becomes Gatekeeping

The first layer of monopoly power is access to and control over compute.

Frontier-scale training requires:

• Tens of thousands of GPUs
• Custom networking fabrics
• Dedicated power and cooling
• Multi‑billion‑dollar capex cycles

Only a few firms can afford this. And because compute supply is constrained, these firms can:

• Dictate pricing
• Prioritize their own workloads
• Control access for competitors
• Influence research direction

Compute becomes a strategic choke point. Even governments struggle to secure enough of it.

This is not a traditional monopoly — it’s a capacity monopoly, where scarcity itself becomes a source of power.

3. The Data Monopoly: Quality, Exclusivity, and Irreplaceability

The second layer is data.

Foundation models thrive on:

• High‑quality proprietary datasets
• Exclusive partnerships
• Privileged access to user interactions
• Reinforcement loops from billions of queries

This creates a dynamic where:

• The best models get the best data
• The best data makes the models better
• Better models attract more users
• More users generate more exclusive data

It’s a self-reinforcing cycle that locks out new entrants.

Even if a startup acquires compute, it cannot acquire equivalent data. The moat is not size — it’s exclusivity.

4. The Distribution Monopoly: Owning the Interface to Intelligence

The third layer is distribution.

Foundation model providers control:

• Cloud platforms
• Enterprise integration channels
• Consumer interfaces
• Developer ecosystems
• API pricing and rate limits

This means they can:

• Decide which applications get visibility
• Shape the economics of downstream AI companies
• Bundle their models into existing products
• Create dependency through integration lock‑in

Distribution is where monopoly power becomes behavioral. If your business relies on an API, the model provider effectively sets the rules of your business model.

This is why foundation models resemble regulated utilities more than software products.

5. The Strategic Monopoly: Influence Over Standards, Safety, and Policy

The fourth layer is geopolitical.

Because foundation models are:

• Critical infrastructure
• National competitiveness assets
• Security-sensitive technologies

Governments increasingly rely on the same handful of companies for:

• Safety evaluations
• Red‑team testing
• Policy guidance
• Technical standards
• Risk assessments

This creates a paradox: The entities being regulated are also the ones defining the regulatory frameworks.

It’s not malicious — it’s structural. Expertise resides in the same firms that build the models.

But it concentrates power in ways that no traditional industry ever has.

6. The Economic Consequence: Market Tipping Toward AI Superpowers

When compute, data, distribution, and policy influence converge, markets tip.

We see early signs:

• Startups dependent on a single model provider
• Enterprises locked into one cloud ecosystem
• National AI strategies shaped by corporate roadmaps
• Research pipelines aligned with proprietary architectures

This is not monopoly in the antitrust sense — it’s monopoly in the systems sense. A few firms become the gravitational centers of the entire AI economy.

Competition doesn’t disappear — it becomes subordinate.

7. The Contrarian View: Monopoly Might Be the Natural Equilibrium

It’s tempting to frame this as a failure of regulation or market design. But the deeper truth may be structural:

AI rewards scale so aggressively that monopoly power is not an accident — it’s an outcome.

Foundation models behave like:

• Power grids
• Telecom networks
• National research labs

They are capital-intensive, infrastructure-heavy, and strategically essential.

In such systems, concentration is not just likely — it’s efficient.

The question is not how to prevent monopoly power. The question is how to govern it.

8. What Comes Next: Three Possible Futures

Future 1: Regulated AI Utilities

Governments treat foundation models like critical infrastructure:

• Mandatory transparency
• Compute access requirements
• Safety audits
• Price regulation

Future 2: Nationalized Compute and Data

Countries build sovereign AI stacks:

• Public compute clusters
• National datasets
• Open foundation models

Future 3: Corporate Sovereigns

A handful of companies become de facto global AI superpowers:

• Setting standards
• Controlling distribution
• Influencing policy
• Shaping the trajectory of intelligence

This future is already emerging.

9. The Reality Check

Foundation models are not just technological achievements. They are economic institutions, political actors, and structural monopolies wrapped in code.

The hidden power behind them is not the model itself — it’s the infrastructure, data, and distribution that only a few firms can command.

Understanding this power is the first step toward governing it.

Conceived, written and published by AI Quantum Intelligence with the help of AI models.

The global conversation around artificial intelligence has quickly shifted from fascination to control. Governments, corporations, and advocacy groups are racing to define what “responsible AI” means — and who gets to enforce it. But amid the flood of announcements, draft bills, and ethical frameworks, a critical question emerges: how much of this is real governance, and how much is performative noise?

AI regulation is no longer theoretical. It’s becoming a geopolitical instrument — shaping trade, innovation, and even national identity. The coming wave will determine not just how AI evolves, but who profits from its boundaries.

1. The Political Economy of Control

Regulation is power — and in the AI era, power is data. Governments are framing AI oversight as a matter of sovereignty: protecting citizens’ privacy, ensuring algorithmic fairness, and defending against foreign influence. Yet beneath the rhetoric lies a deeper motive — control over the data pipelines that fuel economic dominance.

• The EU’s AI Act sets the tone for global compliance, defining risk categories and transparency obligations.
• The U.S. approach remains fragmented — a patchwork of state-level initiatives and executive orders emphasizing innovation over restriction.
• China’s model integrates AI governance directly into its social and economic planning, merging surveillance and industrial policy.

Each framework reflects a distinct worldview: Europe’s rights-based caution, America’s market-driven pragmatism, and China’s centralized orchestration. Together, they form a regulatory triad that will define the next decade of AI geopolitics.

Figure 1 — The global regulatory triad shaping AI’s future: Europe’s rights‑driven compliance model, America’s innovation‑centric market approach, and China’s centralized control framework.

2. The Corporate Response: Compliance as Strategy

For major technology firms, regulation is not a constraint — it’s a competitive moat. Companies with deep legal and technical infrastructure can absorb compliance costs, while smaller innovators struggle to keep pace. This dynamic is quietly reshaping the AI landscape: regulation as a barrier to entry.

Expect to see:

• Compliance-driven consolidation, where startups align with larger platforms to survive.
• AI assurance markets, offering audits, certifications, and algorithmic transparency services.
• Strategic lobbying, as corporations seek to influence definitions of “safe” and “ethical” AI in their favour.

In short, the regulatory wave will not slow AI’s advance — it may redefine who gets to ride it.

3. The Noise: Symbolic Oversight and Political Theater

Not all regulation is substantive. Much of what dominates headlines is symbolic governance — declarations of intent without enforcement teeth. Governments announce AI task forces, ethics councils, and “responsible innovation charters” that sound impressive but rarely translate into operational standards.

This performative layer serves political optics: reassuring the public while buying time for industry self-regulation. The result is a paradox — a world simultaneously overregulated in rhetoric and underregulated in practice.

4. What’s Real: The Emerging Infrastructure of Accountability

Beneath the noise, genuine progress is taking shape.

• Algorithmic transparency is evolving from voluntary disclosure to mandatory auditability.
• Data provenance systems are being built to trace training sources and prevent intellectual property violations.
• AI liability frameworks are emerging, assigning responsibility for autonomous decisions in finance, healthcare, and defense.

These developments mark the transition from ethical aspiration to regulatory engineering — the codification of accountability into the architecture of AI itself.

5. The Power Shift Ahead

The next phase of AI regulation will not be about banning technologies; it will be about defining the terms of participation. Nations that master regulatory agility — balancing innovation with oversight — will gain disproportionate influence over global AI standards. In this sense, regulation becomes a form of soft power: shaping the rules of engagement rather than the tools themselves.

Conclusion: Beyond the Noise

The coming wave of AI regulation is both inevitable and necessary. Yet the challenge lies in distinguishing policy substance from political theater. Real governance will emerge where transparency meets enforceability — where ethical ambition is backed by technical precision. Everything else is noise.

In the end, the question is not whether AI will be regulated, but who will write the code of compliance — and whose interests it will serve.

Conceived, written and published by AI Quantum Intelligence with the help of AI models.

When it comes to running your own business, there are many hats that you have to wear. You have to be the salesperson, the marketing expert, the social media star, as well as many other things, including keeping on top of your growing list of administrative tasks and finances. For home service contractors such as plumbers, electricians, roofers, HVAC engineers and cleaners, balancing these administrative responsibilities alongside a busy workload can quickly become overwhelming.

Alongside doing the job you are interested in, you have to be creating estimates and scheduling appointments, collecting payments and preparing financial records; administration has become just as important as the work itself – which is something a lot of home services experts don’t realise.

This is where invoicing software is making a real difference. While traditionally viewed as a tool for creating and sending invoices, modern platforms have evolved into comprehensive business management solutions. They enable contractors to organise estimates, record completed work, track payments and store customer information in one central location (in simple terms, creating efficient invoicing software workflows). By bringing these everyday administrative tasks together, invoicing software helps reduce manual processes, improve accuracy and give business owners more time to focus on delivering quality work rather than dealing with paperwork.

How does invoicing software help home service contractors operate more efficiently?

For many plumbers, electricians, roofers and HVAC engineers, the challenge isn’t creating a single invoice – it’s managing dozens of smaller jobs, tracking outstanding payments and keeping customer information up to date while moving between sites. As workloads increase, switching between paper records, spreadsheets and multiple apps can slow operations and introduce unnecessary errors.

Modern invoicing software brings estimates, invoices, payment status and customer records into a single digital workflow that can be accessed from both the office and the field. Combined with smartphones, tablets and other connected devices, technicians can update job information immediately after completing work, while office staff can see progress in real time.

Why are home service trades moving from paper invoices to digital workflows?

As service businesses grow, paper-based administration becomes increasingly difficult to manage. Handwritten invoices, printed job sheets and spreadsheets make it harder to track previous work, verify customer information or prepare accurate records for tax reporting. Information is often duplicated across multiple documents, increasing the risk of errors and slowing down administrative processes.

Digital invoicing software replaces these disconnected systems with a centralised workflow that links estimates, job records, invoices, payment collection and reporting. Because information is captured closer to the point where work is completed, contractors have more reliable records and fewer administrative gaps.

What role can invoicing software play in collaboration between field technicians and office managers?

Efficient home service businesses depend on accurate information flowing between technicians on-site and office teams coordinating schedules, payments and customer communication. Without a shared system, updates often rely on phone calls, paper notes or manually re-entering information once technicians return to the office.

Shared invoicing workflows improve collaboration by allowing field technicians to record completed work, labour hours, materials used and customer approvals directly from mobile devices. Office managers can immediately review job details, generate invoices, monitor payment status and produce financial reports using the same information.

What invoicing software do you use? How do you think invoicing software is transforming admin efficiency in Home Service Trades? Let us know in the comment box below. We look forward to hearing from you.

The post How Invoicing Software Is Quietly Transforming Admin Efficiency in Home Service Trades appeared first on IoT Business News.

Berg Insight’s latest forecast says shipments of wireless devices used in industrial automation will reach 85 million units by 2030, underscoring the growing role of wireless connectivity inside factories and industrial facilities.

Industrial automation has traditionally been one of the most conservative environments for wireless networking. Deterministic performance, electrical noise, long equipment lifecycles and safety requirements have kept many production systems anchored to wired infrastructure. That is why shipment forecasts for wireless devices in this sector matter: they indicate not only technology adoption, but also a gradual shift in how industrial operators are prepared to instrument, connect and maintain assets.

Berg Insight is now pointing to a market in which shipments of wireless devices for industrial automation reach 85 million units by 2030. The figure, contained in the firm’s latest market communication, frames wireless industrial connectivity as a measurable volume market rather than a niche add-on to automation systems.

A demand signal rather than a product launch

What makes this announcement distinct from the many industrial IoT releases entering the market is that it is not tied to a single module, gateway, cloud platform or connectivity contract. It is a market-level forecast focused on device shipments. For OEMs and industrial technology suppliers, that distinction is important because shipment volume is closer to design-in activity than to marketing interest.

A forecast of 85 million wireless industrial automation devices by 2030 suggests that wireless connectivity is moving deeper into the installed base of sensors, controllers, monitoring devices and automation-adjacent equipment. It does not imply that factories are abandoning wired networks. A more practical reading is that wireless is being used where cabling is costly, inflexible or operationally inconvenient, while wired systems continue to serve applications where latency, power or certification constraints require them.

That coexistence is a key implication for the IoT ecosystem. Industrial players are unlikely to standardize around a single connectivity model. Instead, system integrators and automation vendors will need to manage mixed environments where wireless devices must interoperate with established control architectures, enterprise systems and maintenance workflows. The complexity is less about adding a radio and more about supporting secure onboarding, lifecycle management and reliable data integration over many years.

Why this matters for industrial IoT suppliers

For embedded wireless module vendors, a rising shipment base in industrial automation can translate into broader demand for ruggedized designs, long availability windows and support for industrial certification processes. For connectivity providers, the opportunity is not simply network access; it is the ability to support device fleets that may be deployed across factories, remote industrial sites and brownfield facilities with different operational constraints.

OEMs face a different challenge. Adding wireless connectivity to industrial equipment changes product support expectations. Devices that were once largely standalone may require firmware update processes, security policies, provisioning tools and diagnostics. Even where the wireless link is used only for monitoring, the connected product becomes part of a larger operational technology and IT environment.

System integrators may benefit from this trend, but they will also carry much of the implementation burden. Industrial customers will expect wireless deployments to work around existing assets, legacy protocols and site-specific reliability requirements. The forecast therefore points to services demand as much as hardware demand: assessment, integration, security hardening and long-term fleet management are likely to be central to successful deployments.

The broader industry relevance is that industrial IoT growth is increasingly tied to practical deployment economics. Wireless technologies can reduce installation friction in environments where running cable is expensive or disruptive. At the same time, industrial automation buyers will continue to evaluate connectivity through the lens of uptime, maintainability and risk. The value of the Berg Insight forecast is that it quantifies the direction of travel without suggesting that industrial wireless adoption is uniform or unconstrained.

In that sense, the 85 million-unit figure should be read less as a standalone market milestone and more as evidence of an architectural transition. Industrial automation is becoming more connected at the device layer, but the winning approaches will be those that fit into operational realities rather than those that simply promise wireless replacement of existing infrastructure.

The post Berg Insight Forecast Points to Rising Wireless Adoption in Industrial Automation appeared first on IoT Business News.

You probably remember the days when fleet maintenance was strictly reactive. A truck broke down on the side of the highway, you dispatched a tow, and your operations team scrambled to reroute a delivery. It was expensive, stressful, and entirely avoidable. Today, vehicle telematics has turned that model on its head. Instead of waiting for a failure, you now have the power to see it coming weeks in advance.

By leveraging real-time data from your fleet, you can move away from rigid calendar-based servicing and toward a strategy that addresses the actual condition of each vehicle. This shift is not just a technical upgrade; it is a strategic necessity in a market where operational costs are rising and margins are thin. In this guide, we will explore how you can use data to eliminate unplanned downtime and keep your fleet running at peak efficiency.

What Is Predictive Maintenance in Commercial Vehicles?

Predictive maintenance is a data-driven strategy that uses real-time monitoring to determine the health of a vehicle. While preventive maintenance relies on fixed intervals—such as changing oil every 10,000 miles—predictive maintenance looks at the actual wear and tear of components. It answers the question: “When will this specific part fail?”

The global market for these solutions is growing rapidly, estimated at $5.48 billion in 2025 and expected to reach over $23 billion by 2034. This growth is fueled by the expansion of vehicle telematics and the integration of AI-powered analytics. These systems analyze thousands of data points daily, from engine temperature and vibration patterns to complex Diagnostic Trouble Codes (DTC).

For you, this means maintenance is only carried out when it is actually necessary. You don’t waste money servicing a vehicle that is in perfect condition, and you never risk a catastrophic failure by waiting a day too long. It is the perfect balance between maximum uptime and minimum cost.

The High Cost of Unplanned Downtime

If you are managing a fleet of 100 trucks, even a small drop in utilization can be devastating to your bottom line. Research shows that a 1% drop in utilization equates to 3.5 lost working days per vehicle every year. Across a large fleet, that translates into millions of dollars in lost value.

The daily cost of having a single vehicle out of service is staggering:

• Light-duty fleets: Average downtime costs around $448 per day.

• Heavy-duty trucks: Costs can range from $760 to over $1,000 per day.

• Automotive sector: In extreme cases involving production lines, downtime can exceed $3 million per hour.

Beyond the immediate loss of revenue, unplanned failures trigger a chain reaction of expenses. You face driver scheduling gaps, potential SLA penalties for late deliveries, and the high cost of emergency repairs. Modern telematics systems can reduce this unplanned downtime by up to 30%, allowing you to protect your budget and your reputation.

Comparison of Fleet Maintenance Strategies

How Vehicle Telematics Enables Predictive Insights

The “magic” of predictive maintenance starts at the hardware level. Advanced telematics devices, such as the Queclink GV series, connect directly to a vehicle’s CAN bus to extract high-fidelity diagnostic data. This connection allows the system to read DTCs as they happen, often before a warning light even appears on the dashboard.

These devices don’t just track location; they monitor the vitals of your fleet. For example:

• Engine Diagnostics: Monitoring oil pressure, coolant temperature, and fuel trim levels to detect early signs of engine stress.

• Battery Health: For electric and hybrid vehicles, sensors analyze charging cycles and temperature to detect capacity loss early.

• Brake Performance: Instead of changing pads every few months, sensors determine the actual thickness and wear to avoid unnecessary shop visits.

This data is processed by AI-driven platforms that forecast failure probability. When the system detects an anomaly—like a slight increase in engine vibration or an irregular exhaust temperature—it alerts your maintenance team immediately. This gives you the lead time needed to order parts before the vehicle even enters the shop, cutting down on “wait time” caused by the ongoing global technician and parts shortages.

Key Benefits of a Data-Driven Maintenance Strategy

Switching to a predictive model offers benefits that go far beyond just saving money on mechanics’ bills. It fundamentally changes how you view your assets.

1. Drastic Cost Reduction: Predictive maintenance can reduce total fleet maintenance costs by up to 30%. By catching minor issues before they lead to secondary damage, you avoid the “domino effect” where a small leak turns into a blown engine.

3. Extended Asset Lifespan: A vehicle that is consistently maintained based on its actual needs will last longer. Studies indicate that predictive analytics can extend the lifetime of aging assets by 20%. This allows you to delay large capital expenditures for fleet replacement.

4. Improved Driver Safety: Maintenance is a safety issue. Telematics data can identify aggressive driving behaviors—like harsh braking and rapid acceleration—that accelerate component wear. By coaching drivers and keeping vehicles in top shape, you reduce the risk of safety-related accidents by up to 14%.

How To Implement Predictive Maintenance: A Tactical Checklist

Moving to a predictive model does not happen overnight. It requires a structured approach to both technology and team training.

• Audit Your Current Failure Points: Identify the most frequent causes of failure in your fleet over the last year. Is it brakes, cooling systems, or tires?.

• Invest in the Right Hardware: Ensure your vehicle telematics devices are CAN bus compatible and support BLE for wireless sensor expansion.

• Define Clear KPIs: Set measurable goals, such as reducing unplanned failures by 30% within the first six months.

• Integrate Your Software: Connect your telematics data with your fuel and maintenance management platforms to increase uptime by roughly 15%.

• Train Your Maintenance Team: Ensure your technicians know how to interpret diagnostic alerts and use them to prioritize work orders.

Top Causes of Unplanned Downtime in 2025

• Parts Delays: Lead times for critical components can still exceed 16 weeks.

• Labor Shortages: Backlogged shops mean slower turnaround times for even simple repairs.
• Poor PM Compliance: Fleets with low preventive maintenance adherence experience significantly more downtime.

Conclusion: Partner with Queclink for a Smarter Fleet

At Queclink, we believe that data integrity is the foundation of every successful fleet operation. Our “Driving Smarter IoT” philosophy is built into every device we manufacture, from the compact GV56 to the advanced GV350MG series.

By choosing Queclink hardware, you are investing in reliable, high-fidelity data that powers your predictive maintenance engine. Our devices connect directly to your vehicles’ vitals, providing the real-time visibility you need to eliminate unseen risks and drastically reduce your total cost of ownership. Whether you are managing traditional diesel trucks or a new fleet of electric vehicles, our solutions are engineered for the most demanding environments on earth.

Ready to transform your maintenance strategy and stop downtime before it starts? Contact our technical team today for a customized consultation and discover the Queclink advantage.

FAQ Section

How much can predictive maintenance actually save my fleet?
Most fleets reduce maintenance costs by 20–30%. Savings come from less downtime, fewer major repairs, and avoiding unnecessary servicing.

What is the typical timeline for seeing an ROI?
Many fleets see ROI within 6–12 months. Early gains come from fewer emergency repairs, with larger savings as data improves over time.

How do I prioritize which vehicles to equip first?
Start with high-utilization and high-value vehicles. These generate the most revenue and have the highest downtime costs, delivering faster ROI.

What kind of data does my team need to monitor? Focus on DTCs, engine vitals (temperature, pressure), and usage metrics (mileage, idle time). Together, these reveal patterns and predict failures.

Is predictive maintenance difficult to implement with a small team? No. It reduces workload by automating monitoring, allowing small teams to focus on high-priority repairs instead of routine checks.

The post Using Vehicle Telematics for Predictive Maintenance in Commercial Fleets appeared first on IoT Business News.

Quectel has announced the FCM665D, a module positioned for edge AI applications. The launch reflects the growing role of on-device processing in IoT systems where sending all data to the cloud is not always practical.

As IoT deployments become more data-intensive, the limiting factor is often no longer just network coverage or device connectivity. Cameras, industrial sensors, mobile equipment and field systems can generate volumes of data that are expensive, slow or operationally impractical to move continuously to the cloud. That is why edge AI has become an increasingly important design consideration: it allows more decisions to be made close to where data is produced.

Against that backdrop, Quectel has launched the FCM665D module for edge AI applications. The company’s announcement identifies the product as a high-performance module, but the available release information does not provide detailed specifications, supported interfaces, processor architecture, AI acceleration capabilities, power characteristics or target certifications.

That absence of public technical detail matters. For OEMs and system integrators, the value of an edge AI module is determined less by the label and more by how it fits into a device architecture: compute headroom, thermal behavior, software support, camera or sensor interfaces, lifecycle availability and integration effort all shape whether a module can be used in production systems.

Why this announcement is different from a conventional module launch

The distinct point in this announcement is its positioning around edge AI rather than simply embedded connectivity or general-purpose device integration. In typical IoT module announcements, the focus is often on radio access technologies, regional network support, certifications or power consumption. Here, the emphasis is on local intelligence, which places the FCM665D in a different part of the IoT design conversation.

That distinction is important because edge AI modules are evaluated by a broader set of stakeholders. Hardware teams need to understand integration constraints. Software teams need to assess model deployment and application support. Operations teams need to consider whether inference at the device level can reduce cloud dependency or bandwidth usage. Procurement teams will also look at whether a module can simplify design compared with building a custom compute platform.

A practical implication is that the FCM665D is unlikely to be assessed only as a component purchase. For industrial players and enterprises, an edge AI module can affect the whole data pipeline. If intelligence is pushed into the device, less raw data may need to be transmitted upstream, but more responsibility moves into the embedded system itself. That can change testing, updates, fleet monitoring and cybersecurity requirements.

For connectivity providers, announcements of this type are also relevant even when the module is not described primarily as a connectivity product. Edge processing can influence traffic patterns on IoT networks. Devices that classify, filter or react locally may transmit fewer high-volume payloads and more event-driven data. That can alter how enterprise IoT services are packaged, particularly in applications where latency, bandwidth cost or intermittent coverage are operational concerns.

For system integrators, the opportunity is more concrete. Edge AI modules can reduce the need to design bespoke compute boards for every project, but only if the module’s software environment, interfaces and lifecycle support align with the target application. Without published specifications, integrators will need to validate those points directly before positioning the FCM665D for customer deployments.

Edge AI is becoming an architectural choice, not a feature label

The broader industry significance is that module vendors are moving deeper into the compute layer of IoT systems. Edge AI is not just a way to add intelligence to devices; it changes where data is processed, where application logic resides and how cloud platforms interact with distributed assets. That is especially relevant in industrial IoT, smart infrastructure, logistics and machine vision use cases where continuous cloud processing may be costly or impractical.

The main takeaway from Quectel’s FCM665D launch is therefore not simply that another module has entered the market. It is that embedded module roadmaps are increasingly being shaped by AI workloads at the edge. The FCM665D will need to be judged on its detailed technical characteristics when those are available, but its positioning points to a clear direction in IoT hardware: more intelligence is being designed into the endpoint rather than reserved for the cloud.

The post Quectel Positions FCM665D Module for Edge AI Applications appeared first on IoT Business News.

As enterprise IoT deployments expand beyond national borders, organisations are finding that managing connectivity at scale has become a bigger challenge than obtaining network coverage, according to new research from Pelion and ABI Research.

For years, enterprise IoT projects have largely been designed around domestic connectivity. Devices were deployed within a single country, connected through one or two operators, and managed under relatively straightforward regulatory frameworks.

That model is beginning to change.

A global survey commissioned by IoT connectivity provider Pelion suggests enterprises are increasingly deploying connected assets internationally, forcing them to rethink how they manage connectivity, security and operations across multiple countries and mobile networks.

The study, based on responses from 676 IoT decision-makers, forecasts that internationally connected devices will account for 49% of enterprise IoT fleets by 2030, up from 29% today. Rather than simply adding more connected devices, organisations appear to be extending deployments across wider geographical footprints as supply chains, logistics networks and industrial operations become increasingly global.

Scaling internationally introduces new operational challenges

The report suggests that the industry’s priorities are evolving.

While network availability has traditionally dominated discussions around IoT connectivity, respondents now point to operational complexity as the more pressing issue. Nearly two-thirds of organisations surveyed identified managing deployments outside their primary coverage area as their biggest scaling challenge, significantly more than those citing network coverage limitations.

The findings also indicate that many enterprises continue to struggle with internal expertise. Six out of ten respondents said a shortage of IoT knowledge remains the single biggest obstacle preventing successful deployments, ahead of both budget constraints and connectivity itself.

Together, these results suggest that the next phase of enterprise IoT growth will depend less on expanding network infrastructure and more on simplifying the management of increasingly complex global deployments.

eSIM moves closer to mainstream IoT adoption

The research points to accelerating adoption of IoT-specific eSIM technology as organisations prepare for more geographically distributed deployments.

According to the report, SGP.32-compliant profile downloads, based on the first GSMA eSIM specification designed specifically for IoT, are expected to represent 45% of deployments by 2030, compared with just 7.6% today.

The transition reflects growing demand for technologies capable of simplifying operator management across multiple markets while reducing the operational overhead associated with large fleets of connected devices.

Security remains a barrier to wider deployment

Although enterprises are optimistic about expanding their IoT initiatives, security continues to present significant risks.

Nearly one quarter of organisations surveyed reported experiencing an IoT-related security incident during the past year. Among those affected, almost one third incurred losses exceeding $100,000, while a smaller proportion reported incidents costing more than $1 million.

As deployments become increasingly international, the report suggests that security architecture will become a more important purchasing criterion alongside connectivity performance and fleet management capabilities.

Demand grows for simplified connectivity management

Another notable trend emerging from the research is changing attitudes towards connectivity providers.

More than three quarters of respondents not currently using a mobile virtual network operator said they would consider one for future deployments, citing greater flexibility, simplified management and access to multiple carrier networks as key advantages.

According to Pelion CEO Dave Weidner, enterprise customers are increasingly looking for partners that can help reduce operational complexity rather than simply provide connectivity.

“Connectivity itself is no longer the difficult part of enterprise IoT. The challenge comes when enterprise customers take their fleets internationally, grow in scale, and operate across multiple networks, jurisdictions and regulatory environments.”

The report argues that if these operational, security and skills challenges can be addressed, the next wave of enterprise IoT growth could be characterised by globally managed, eSIM-enabled deployments that provide the foundation for increasingly AI-driven industrial and commercial applications.

The post Pelion Research Signals a Shift Toward Borderless Enterprise IoT Connectivity appeared first on IoT Business News.

The post Loop Engineering for RAG Generation: An LLM Cascade from a Cheap Local Model Up to a Hosted Flagship appeared first on Towards Data Science.

The post Build and Run an Intelligent Document Processing (IDP) System in the Cloud appeared first on Towards Data Science.

The post Tabular LLMs: An Introduction to the Foundation Models That Predict Your Spreadsheet appeared first on Towards Data Science.

The post How to Optimize Vector Search When RAM Gets Too Expensive: On-Disk vs. In-Memory ANN Indexes appeared first on Towards Data Science.

The post The Fluid Simulator That Doesn’t Solve the Fluid Equations appeared first on Towards Data Science.

The post How to Give an LLM Agent a Browser appeared first on Towards Data Science.

The post How to Efficiently Prompt Claude Code appeared first on Towards Data Science.

The post How I Reproduced BM25, Dense Retrieval, and SPLADE on a 16GB MacBook appeared first on Towards Data Science.

The post The Most Beautiful Statistic: The History and the Science of the Humble Mean appeared first on Towards Data Science.

The post Reducing Human Annotation with ML Active Learning appeared first on Towards Data Science.

... government of the people, by the people, for the people ...
    — Abraham Lincoln, Gettysburg Address (1863)

The cost of AI is dropping rapidly. GPT-4-class capabilities cost roughly $30 per million tokens in early 2023; today the same runs under $1, and some providers are pushing costs below $0.10. Across benchmarks, inference prices have fallen between 9x and 900x per year, with a median decline near 50x. Even frontier models are getting dramatically cheaper each generation, with open-source models following closely behind. And crucially, even if “Nobel-Prize-winning genius-level” intelligence isn’t here yet, the intelligence that suffices for the vast majority of knowledge work is here today, and getting cheaper by the month. At this rate, we are soon entering the era of virtually free intelligence—the kind that is more than enough for everyday knowledge work.

Disclosure: This post is a perspective led by Aditya G. Parameswaran—an Associate Professor of EECS and co-director of the EPIC Data Lab at UC Berkeley—together with his collaborators. It is part landscape survey and part perspective, and several of the research directions discussed below (including agentic speculation, structured memory, and synthesizing custom data systems from scratch) draw on the authors' own ongoing work.

So, what does this new era of near-free intelligence mean for data systems? We believe three new challenges—and opportunities—stem from near-zero inference costs:

Data Systems For Agents. Agents will soon become the dominant workload for data systems—with swarms of agents spun up in response to each end-user request. Given differences in characteristics between agents and humans—or applications acting on their behalf—how should we redesign data systems for such agentic users?

Data Systems Of Agents. As agents start taking on the bulk of knowledge work, a new substrate is needed for thousands of agents to manage state over long-running tasks, coordinate and reach consensus, and deal with failures. What do data systems that reliably and efficiently run and manage agent swarms look like?

Data Systems By Agents. Agents are rapidly becoming capable of synthesizing entire data systems in one go—meaning we can rebuild custom systems for each new workload. Verifying that such systems match intended behavior is a challenge. What does it take to let agents synthesize data systems we can actually trust?

Data Systems For, Of, and By Agents

Next, we will discuss each in more detail, followed by discussing the intertwined future of data systems and agents, especially as the three challenges intersect.

Data Systems For Agents

An agent querying a database doesn’t behave like a person or a BI tool. It performs what we call agentic speculation: a high-volume, heterogeneous stream of work spanning schema introspection, columnar exploration, partial and then full query formulation. With multiple agents each exploring portions of the hypothesis space, each user request could amount to 1000s of individual SQL queries. Now, users can issue ‘high-level’ data tasks, e.g., root-cause analysis—e.g., ‘why did coffee sales in Berkeley drop this year’—or exploratory cohort analysis—e.g., ‘which user segments are most likely to churn next quarter’—each involving a combinatorial space of potential joins, aggregations, and filter combinations.

Data Systems Redesigned to More Effectively Support Agentic Speculation

The requests from these agents have various opportunities for optimization. For instance, on a text-to-SQL benchmark with multiple agents attempting each task, only 10-20% of the sub-plans are distinct. Thus, 80-90% of sub-queries perform duplicate work. The same experiments show task success rates significantly increasing with more agentic attempts—so the redundancy is actually helpful. But from the data system perspective it’s wasted work.

An agent-first data system can exploit such properties to help agents make progress faster. It can reuse results across overlapping sub-plans, drawing on ideas from decades-old literature on multi-query optimization and shared scans. Or the data system can try to satisfice, returning approximate answers that are good enough for agents to make progress, leveraging work from the AQP literature—or streaming the results of the final or intermediate operators to help agents decide if seeing the rest is necessary or helpful.

Another opportunity here is to rethink the query interface entirely: instead of agents issuing a single SQL query at a time, they could instead issue a batch of queries, each with its own approximation requirements. Since enumerating an exponential search space (as in the root cause or cohort analysis examples above) isn’t a good use of agentic reasoning ability, perhaps data systems should support higher-level primitives rather than requiring agents to list each SQL query explicitly. One idea here is to draw on DBT-style Jinja macros to provide looping-based primitives for agents to interact with data systems.

A Caffeinated Army of Agents Ready to Tirelessly Complete Your Data Tasks

A final opportunity here is to stop thinking of data systems as passive executors of queries; data systems could be proactive, as they possess more grounding in data and system characteristics that agents may lack a priori—they could steer agents in different directions, provide results for related queries, and also provide performance-level feedback (e.g., instead of executing an expensive query, the system could first provide the agent a latency estimate). The reason we can do this now as opposed to the past is that an agent can accept any form of textual feedback and isn’t expecting a strict SQL query result. In fact, the data system could also prepare both materialized and virtual views for an agent in advance, provided to the agent as part of context, as this may be cheaper or more effective than having an agent author or use them.

Data Systems Of Agents

Previously, we focused on how agents interact with data systems. Now, we consider everything else agents need to keep working: where they live, how they remember, how they coordinate with each other, and how they deal with failures of each other. This agentic substrate is separate from the inference stack powering raw intelligence. However, the inference stack itself is being abstracted away through APIs (e.g., from OpenAI or Anthropic), or, for open-weight models, through serving frameworks that hide low-level details. So far, the agentic substrate has been managed through harnesses like Claude Code and Codex, coupled with various mechanisms to store and retrieve memory.

First, on the memory front, the current wisdom is that files are all you need; agents write to unstructured markdown (MD) files, which can then be searched using grep, or via embedding-based retrieval. In fact, many argue that the solution to continual learning is having agents consume a lot (e.g., an entire codebase, slack, company wikis, …) and then write their learnings into MD files, which are then retrieved selectively on demand. Indeed, file systems, bash scripting, and MD files are and will still be important for agents. However, at scale, when agents are doing the vast majority of knowledge work, this approach will no longer be effective.

Given limited context windows, retrieving all MD file fragments that may be relevant and stuffing it into the context will break down at some point. Even if context windows continue to grow, there are latency benefits to not put all information into context — and in many cases, e.g., when knowledge work involves interacting with large databases or code bases, it will be infeasible to serialize all relevant data into context.

Data Systems As A Substrate for Multi-Agent Swarms

One could use a knowledge graph representation, but knowledge graphs suffer from the same limitations as unstructured MD-based memory due to their lack of structured search. What one needs is to be able to retrieve only memory that is pertinent to the task, across multiple attributes (or facets) of interest. For example, an agent debugging a flaky test should be able to pull only the memories tagged with the relevant module, language, framework, and failure mode—rather retrieving based on keywords or embedding similarity. A separate issue is what to actually retrieve; raw agent traces with mistakes are not very useful as they will induce agents to repeat the same mistake—instead, we want the retrieved memory to be corrective.

We recently explored a related notion of structured memory, where we organize memory across various attributes, each of which could be set as * to indicate universal applicability, or set as a list of values to be matched. For a data agent, the dimensions could include the columns and tables, type of operation, and finally, open-ended natural-language corrective instructions. So, we could include memory that only applies to a given type of operation (e.g., ‘when performing date-time operations, use fiscal year as opposed to calendar year conventions’), or a given table (e.g., ‘column product_cleaned is preferred over column product when querying on product name’). One open question is defining an application-specific structured memory—or what others have called world models for memory. We believe this is akin to defining a schema for each application—and perhaps agents themselves can help us define and refine it over time.

One Possible Way To Store and Retrieve Structured Knowledge [From Here]

Structured memory will be useful also for evolutionary frameworks to effectively manage search spaces. Indeed, storing, structuring, and mining large volumes of single and multi-agent traces can help future agents become much more efficient—potentially enabling effective recursive self-improvement through structured memory-based mechanisms.

Another challenge is to support concurrent edits to shared memory, and concurrent edits in general, when there are many agents performing transformations. While there have been some useful attempts at supporting multiversioning and copy-on-write semantics, it isn’t clear that such techniques will suffice when thousands of agents are attempting to edit shared state at the same time. For instance, when agents are trying various potential transactions in response to a user request, the effects of the vast majority of these transactions need to be rolled back—with only the one ‘correct’ transaction’s result persisting. Work on supporting exactly-once semantics is relevant here, as are underlying techniques based on CRDTs and operational transformation. For updates to fuzzy mechanisms such as memory, we may be able to sacrifice on consistency for perfect correctness in the interest of latency. While agents can reason about semantics to compensate or roll back their actions to eventually finalize most tasks, the primary challenge lies in the degree to which they step on each other’s toes during the process. An important failure mode to be avoided is a form of “livelock,” where incessant compensating actions prevent any meaningful progress.

Beyond shared state, other concerns emerge when trying to support an army of agents, including what to do when agents fail, how agents should communicate with each other (directly or through intermediate shared state), and how we should deal with straggler agents. There have been some developments in supporting durable multi-agent execution, such as Temporal, but it remains to be seen if such solutions will apply at scale across thousands of agents. On the topic of communication, we need mechanisms to enable agents to negotiate with each other. Imagine four developer agents attempting to reach consensus on a shared schema, with distinct but overlapping objectives. In a human setting, this would involve iterative discussion and compromise; for agentic swarms, we must define the mechanisms that allow them to converge on a design that reflects the underlying goals of their respective principals. Or if agents are all requiring access to a limited resource, again communication will be necessary. It remains to be seen if this is best done via centralized coordination, or if a decentralized approach is necessary.

Data Systems By Agents

Finally, if intelligence is effectively free, then we can employ this intelligence to synthesize new data systems from scratch. Indeed, in many settings, general-purpose data systems may be overkill, as they have to support every schema, query, and hardware target. Given a workload, recent work, including Bespoke OLAP and GenDB, has shown that one can use an agentic pipeline to synthesize a complete, workload-specific analytical engine—in minutes to a few hours, at a cost of a few dollars. The engines are disposable: when the workload shifts, one can simply regenerate them. Analogously, our work has shown that one can synthesize custom key-value stores from scratch, targeted to the workload. In fact, modern IDEs, such as Kiro, elevate specifications for systems development to be a first-class citizen.

Agents Can Synthesize Custom Data Systems From Scratch

The main issue, however, is that specifications are typically imperfect, and don’t cover all corner cases. Present-day agents will exploit the missing specifications to reward-hack their way to a high performance metric. In our custom key-value store work, we found that one way to alleviate this is to have auxiliary verification agents trying to generate test cases that catch the exploitation of corner cases, essentially expanding the specification. Yet another approach is to both generate a system and a proof for its correctness together, for which we have found some early success, but more needs to be done to solidify the approach. Further, it remains to be seen what is the best way to solicit human-written specifications for a system—can this be done in an iterative, human-in-the-loop manner, as opposed to a one-shot, incomplete one. Indeed, human-written specifications are incomplete even for manually authored software, so one would expect that future agents that are more aligned will increasingly exercise better judgement when making design decisions.

One Possible Data System Synthesis Pipeline [From Here]

Other questions here involve testing whether starting from a mature system (e.g., Postgres) and removing components/functionality can lead to higher performance or more user trust. Separately, is there an opportunity to make the design composable, comprising various verified components that are mixed and matched given a workload? For example, perhaps the workload hasn’t changed enough for the storage layer to be updated, but perhaps the query optimizer requires changes. A perhaps more viable proposition involves employing agents coupled with proof systems to target critical parts of the code associated with formal proofs, rather than doing so for the entire system.

A final opportunity here is to move away from the traditional data systems stack with clearly-defined interfaces (e.g., parser, query optimizer, storage manager, …) — that were each largely the prerogative of a single human team to manage. Instead, agents can find new ways to “blend” these components together, perhaps identifying new optimization opportunities as a result. Agents can also fill in missing gaps in functionality to make existing systems much more feature-complete, or reach feature-parity with other competing systems—or analogously, continuously refining open-source systems in response to feature requests or issues (perhaps filed by other agents!) Doing so in a way that prioritizes correctness, long-term maintenance, and human interpretability will be a challenge.

Looking Further Ahead

In the era of near-free intelligence, data systems matter more than ever. As agents take on the bulk of knowledge work, the workload for data systems will change, the substrate they need to run on will have to be built, and increasingly, they will participate in designing data systems themselves. Each of these shifts opens up a new, exciting research agenda.

Co-Evolution of Data Systems and Agents

Looking further out, the boundaries between agents and data systems will likely start to blur. For instance, agents may design the data systems they themselves run on, defining both the interfaces as well as the system components underneath. Both the interfaces and internals can be evolved over time by agents in a form of recursive self-improvement. There is also an opportunity to rethink data systems as a holistic source of truth for the entirety of relevant state: including raw data, memory, and coordination state, further erasing the distinctions between the data that is being queried by agents and data generated as a result of agentic activity. Finally, data systems may themselves incorporate agentic components, fundamentally evolving from passive computation engines into intelligent, proactive, self-optimizing architectures. It is hard to predict what the future may hold. We’re in for a wild ride!

Acknowledgments

The perspective and ongoing work described in this post are the product of joint research and many discussions with wonderful collaborators at the EPIC Data Lab, Data Systems & Foundations group, and the broader Berkeley AI-Systems community. Thank you all!

BibTex for this post:

@misc{intelligence-is-free-blog,
  title={Intelligence is Free, Now What? Data Systems for, of, and by Agents},
  author={Aditya G. Parameswaran and Shubham Agarwal and Kerem Akillioglu and Shreya Shankar
          and Sepanta Zeighami and Rishabh Iyer and Matei Zaharia and Alvin Cheung
          and Natacha Crooks and Joseph Gonzalez and Joseph Hellerstein and Ion Stoica},
  howpublished={\url{https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/}},
  year={2026}
}

Congratulations to the Berkeley Artificial Intelligence Research (BAIR) Lab class of 2026! This year, BAIR celebrates another remarkable group of Ph.D. graduates whose curiosity, creativity, and perseverance have pushed the frontiers of artificial intelligence and machine learning.

Their work spans the breadth of modern AI — robotics and embodied intelligence, large language models and reasoning, computer vision, generative modeling, AI safety, human-AI interaction, AI for science and healthcare, and much more. Along the way, they have published influential research, built systems with real-world impact, mentored their peers, and shaped the BAIR community for the better.

Now they are headed everywhere ideas travel: to faculty and postdoctoral positions, to industry research labs, and to startups of their own founding — and several are still exploring what comes next and would love to hear from you.

Please join us in celebrating the achievements of these wonderful graduates. We are proud of everything they have accomplished at Berkeley, and we can’t wait to see what they do next!

Thank you to our friends at the Stanford AI Lab for this idea!

Baifeng Shi

Email: baifeng_shi@berkeley.edu
Website: https://bfshi.github.io/
Advisor(s): Trevor Darrell
Research Blurb: I work on building generalist vision and robotic models.
What's next: Member of Technical Staff at Physical Intelligence

---

Charlie Snell

Email: csnell22@berkeley.edu
Website: https://sea-snell.github.io
Advisor(s): Dan Klein
Research Blurb: My work aims to understand when and how the different LLM scaling paradigms can be traded off and interchanged. In particular, test-time scaling treats each prompt independently, drawing long chains of inferences and then forgetting them entirely between prompts. This differs critically from pretraining, which instead learns a compressed representation from a large dataset. I believe bridging the gap between these methods of scaling computation, presents a key open challenge in the field: how can we develop methods which turn the inferences drawn at test-time back into learned representations that the model can hold onto across interactions.

---

Devin Guillory

Email: dguillory@berkeley.edu
Website: https://devinguillory.com
Advisor(s): Trevor Darrell
Research Blurb: Accounting for data shifts in computer vision models
What's next: Building collaborative AI systems, looking for conspirators.

---

Eve Fleisig

Email: efleisig@berkeley.edu
Website: https://efleisig.com
Advisor(s): Dan Klein
Research Blurb: I design language models to work reliably and fairly for the broad range of real LLM users. First, my research leverages disagreement among user preferences as signal, in order to train and evaluate LLMs for entire populations of users. Second, I work on designing rigorous evaluations to extricate challenging LLM harms that diverse users face. Finally, I work on core technical failures of LLMs, like miscalibrated confidence, to reduce downstream risks when models are deployed to users with different needs. Combined, these interventions facilitate building LLMs that minimize societal harms, and maximize benefits to a wider range of real-world users.
What's next: Postdoctoral fellow at Princeton CITP

---

Grace Luo

Email: graceluo@berkeley.edu
Website: https://graceluo.net
Advisor(s): Trevor Darrell
Research Blurb: My research is on interpreting and controlling generative models. For example, I've worked on re-purposing image generators for computer vision tasks, and meta-modeling language activations for better LLM probing and steering.
What's next: Research scientist in industry

---

Hanlin Zhu

Email: hanlinzhu@berkeley.edu
Website: https://hanlinzhu.com/
Advisor(s): Stuart Russell, Jiantao Jiao
Research Blurb: My research centers on understanding and improving the reasoning capabilities of large language models (LLMs).
What's next: Member of Technical Staff at OpenAI

---

Haozhi Qi

Email: hqi@berkeley.edu
Website: https://haozhi.io/
Advisor(s): Jitendra Malik, Yi Ma
Research Blurb: Dexterous Manipulation and Robot Learning
What's next: Research scientist at Amazon; Faculty at University of Chicago

---

J.D. Zamfirescu-Pereira

Email: zamfi@berkeley.edu
Website: https://zamfi.net
Advisor(s): Bjoern Hartmann
Research Blurb: My research focuses on effective human-AI co-design. I study the boundaries of language interfaces as a medium for interacting with AI, creating systems that blend language-focused interactions with structured user interfaces that draw on different levels of abstraction. I focus on language-oriented technologies, like LLMs and text-to-image models, that are powerful mediators of design processes. These technologies enable humans to describe their desires at almost any level of abstraction, from high-level goals vaguely specified (“I’d like a game to help my kid learn to read”) to low-level corrections of undesired outputs (“Don’t say ‘I know because I’ve tasted it’ when about a recipe substitution's taste”).
What's next: Assistant Professor, Computer Science, UCLA

---

Jiachen Lian

Email: jiachenlian@berkeley.edu
Website: https://jlian2.github.io
Advisor(s): Gopala Anumanchipalli
Research Blurb: My research focuses on human-centered AI across speech, healthcare, and systems.
Looking for: Look for AI talents to join our startup

---

Josh Kang

Email: minwoo_kang@berkeley.edu
Website: https://joshuaminwookang.github.io/
Advisor(s): John Canny
Research Blurb: I study language modeling and related topics in NLP; specific interests are human user simulation and building conversational, collaborative AI agents.
What's next: AI Scientist at Mistral AI

---

Junhao (Bear) Xiong

Email: junhao_xiong@berkeley.edu
Website: https://www.linkedin.com/in/junhao-bear-xiong
Advisor(s): Jennifer Listgarten, Yun Song
Research Blurb: Junhao (Bear) Xiong is a PhD candidate at UC Berkeley, advised by Jennifer Listgarten and Yun S. Song. His work focuses on machine learning methods for biology, with an emphasis on generative modeling for proteins. Previously, he studied Applied Math and Computer Science at Johns Hopkins.
Looking for: Research scientist

---

Kaylo Littlejohn

Email: kaylo_littlejohn@berkeley.edu
Website: https://kaylolittlejohn.com
Advisor(s): Gopala Anumanchipalli
Research Blurb: My research is focused on speech modeling and natural language processing. I co-led the development of multimodal AI tools to accurately translate brain activity into text, audible personalized speech, and a high-fidelity "digital talking avatar" (Nature 2023, Nature Neuroscience 2025). I am also tech lead for voice modeling at Roblox.
Looking for: Research Scientist / Engineer

---

Kent Chang

Email: kentkchang@berkeley.edu
Website: https://kentkc.org
Advisor(s): David Bamman
Research Blurb: I work on NLP and multimodal machine learning, with a focus on evaluating large language models and building multimodal systems for understanding dialogue, narrative, and social interaction. My research includes benchmarks for LLM memorization, multimodal datasets sourced from feature films and television, and studies of model behavior. I'm interested in bridging computational methods with questions from the humanities and social sciences about whose voices get represented in AI systems, and about AI's broader impact. My work has appeared at EMNLP and ACL, among others.
Looking for: (teaching) faculty, Research Scientist, ML/AI SWE

---

Kevin Black

Email: kvablack@berkeley.edu
Website: https://kevin.black
Advisor(s): Sergey Levine
Research Blurb: I work on large-scale robot learning: including imitation learning, reinforcement learning, generative modeling, real-time control, and whatever else it takes to make robots work in the real world!
What's next: Research Scientist of Physical Intelligence

---

Kunhe Yang

Email: kunheyang@berkeley.edu
Website: https://www.kunheyang.com/
Advisor(s): Nika Haghtalab
Research Blurb: My research focuses on the theoretical foundations of designing and evaluating AI algorithms in environments shaped by human incentives and AI agency. My work spans human-centric policy learning, incentive-aware evaluation, and multi-agent collaboration and information transmission, drawing on tools from machine learning theory and computational economics.
What's next: Postdoc Research at Stanford

---

Lisa Dunlap

Email: lisabdunlap@berkeley.edu
Website: https://lisabdunlap.com
Advisor(s): Joseph Gonzalez, Trevor Darrell
Research Blurb: Auditing generative models.
What's next: Research Engineer at Anthropic

---

Long (Tony) Lian

Email: longlian@berkeley.edu
Website: https://tonylian.com/
Advisor(s): Trevor Darrell, Adam Yala
Research Blurb: My research primarily focuses on developing real-time multi-modal multi-agent systems and parallel reasoning systems through end-to-end RL.
What's next: Member of Technical Staff at Thinking Machines Lab

---

Maulik Bhatt

Email: maulikbhatt@berkeley.edu
Website: https://maulikb.com
Advisor(s): Negar Mehr
Research Blurb: My research develops autonomous robots that can safely coordinate with humans and other robots in shared environments. I build scalable algorithms grounded in game theory and diffusion models that let agents reason about the intent and behavior of others around them. My work spans real-time multi-agent trajectory planning and imitation learning in the presence of multi-modality. I've validated these methods on hardware platforms ranging from quadrotors to manipulators, with the goal of making multi-agent coordination robust, interpretable, and deployable in the real world.
What's next: Joining Toyota Woven's end-to-end autonomous driving team.

---

Michael Psenka

Email: psenka@berkeley.edu
Website: https://www.michaelpsenka.io/
Advisor(s): Aditi Krishnapriyan
Research Blurb: Work in various domains (reinforcement learning, world models, AI+bio/chem), generally working on longer-horizon and out-of-distribution problems in planning and interpolation (e.g. robot manipulation from start state to goal, molecular dynamics of proteins between ground states). My thesis took a variational approach (think calculus of variations) directly from deep generative models of the environment, framing path-finding as minimizing a functional induced by the learned model itself (its score, its critic, or its dynamics). Through my research I've gained insight on how to properly handle dynamics in deep learning systems, and I plan to continue developing systems that are dynamic and adaptive.
What's next: Lead Research Scientist at Baseten

---

Nathan Lichtlé

Email: nathan.lichtle@gmail.com
Website: https://nathanlichtle.com
Advisor(s): Alexandre M. Bayen
Research Blurb: RL for autonomous driving.
What's next: Chief Scientist & Co-founder at Yumi Health

---

Neerja Thakkar

Email: nthakkar@berkeley.edu
Website: https://neerja.me/
Advisor(s): Jitendra Malik
Research Blurb: My research focuses on scaling predictive world models to handle the complexity of in-the-wild motion. Using autoregressive and diffusion frameworks, I develop better representations for real-world prediction and propose methods to efficiently adapt these models to new domains.
Looking for: Research scientist

---

Nikita Mehandru

Email: nmehandru@berkeley.edu
Website: https://n-mehandru.github.io/
Advisor(s): Ahmed Alaa and David Bamman
Research Blurb: My research develops and applies machine learning methods for clinical reasoning and disease progression modeling using unstructured text and time series data from electronic health records. In collaboration with physicians at UCSF, I bridge method development and clinical validation with the intention to build reliable, interpretable AI systems in medicine.
Looking for: Research Scientist

---

Niklas Lauffer

Email: nlauffer@berkeley.edu
Website: https://niklaslauffer.github.io/
Advisor(s): Stuart Russell and Sanjit Seshia
Research Blurb: Niklas's research is focused on AI safety and reinforcement learning, particularly in the area of multi-agent interaction and LM agents. He's worked on enabling adversarial learning in cooperative and mixed-motive settings, solving issues of covariate shift in training LM agents on long-horizon tasks, as well as evaluating safety risks posed by LM agents in multi-agent settings.
What's next: Research Scientist at Google Deepmind

---

Qiyang Li

Email: qcli@berkeley.edu
Website: https://colinqiyangli.github.io/
Advisor(s): Sergey Levine
Research Blurb: Recent progress in robotic manipulation policy learning has been largely driven by (1) the increasing availability of large-scale prior datasets and (2) the success of action chunking, where the policy predicts a short sequence of future actions rather than a single one. However, most action chunking policies are trained via supervised imitation learning, because efficient online self-improvement with reinforcement learning (RL) remains challenging—limiting real-world applicability. My PhD research studied how we could leverage prior data to optimize action-chunking policies with RL, combining empirical results with theoretical insights.
Looking for: Post-doc/research scientist for RL in robotics and LLMs!

---

Sampada Deglurkar

Email: sampada_deglurkar@berkeley.edu
Website: https://sdeglurkar.github.io/
Advisor(s): Prof Claire Tomlin
Research Blurb: My research is in providing safety assurances for AI-enabled autonomous systems, ranging from robots to autonomous vehicles to aviation systems. For this, I have worked with uncertainty quantification for machine learning models, decision-making under uncertainty algorithms, and tools for producing probabilistic guarantees on system operation.
Looking for: Research scientist, Research engineer

---

Vinamra Benara

Email: vbenara@berkeley.edu
Website: https://cs.berkeley.edu/~vbenara
Advisor(s): Ion Stoica
Research Blurb: My research focuses on LLM post-training, including data curation, RLHF, RLVR with VLMs, evaluations, reasoning, agentic workflows, and interpretability. I also have strong expertise in systems infrastructure for distributed computing.
Looking for: Research scientist / Research Engineer

---

Vongani Maluleke

Email: vongani_maluleke@berkeley.edu
Website: https://people.eecs.berkeley.edu/~vongani_maluleke/
Advisor(s): Jitendra Malik and Angjoo Kanazawa
Research Blurb: Vongani Maluleke is a PhD candidate at UC Berkeley (BAIR, advised by Jitendra Malik and Angjoo Kanazawa), where she led the development of MAGNet, a unified multi-agent motion generation framework that supports a wide range of motion generation tasks without retraining or architectural changes, outperforming task-specialized state-of-the-art baselines. She is currently extending this work by deploying it on a Unitree G1 humanoid to make it embody social intelligence. Before her PhD, she was a Senior AI Consultant at Deloitte, awarded Exceptional Performer two consecutive years, leading AI system development across media, telecommunications, retail, and financial services.
Looking for: Research scientist

---

Wei-Jer Chang

Email: weijer_chang@berkeley.edu
Website: https://weijer-chang.github.io/
Advisor(s): Masayoshi Tomizuka
Research Blurb: My research focuses on developing safe and intelligent autonomous systems for complex, human-centered environments. I work at the intersection of machine learning, generative models, and reinforcement learning, with applications in autonomy. My work addresses challenges in multi-agent interaction, interactive human behavior, and long-tail safety-critical scenarios at scale.
Looking for: Research Scientist, Applied Scientist, Roboticist

---

Xiuyu Li

Email: xiuyu@berkeley.edu
Website: https://xiuyuli.com/
Advisor(s): Kurt Keutzer
Research Blurb: My research focuses on developing scalable and self-improving large language model agents, with emphasis on coding agents for complex, long-horizon tasks. This direction builds on my work in parallel reasoning, and on broader expertise in making generative models more efficient in training and inference across language and vision.
What's next: Member of Technical Staff at xAI

---

Yichen Xie

Email: yichenxie0928@gmail.com
Website: https://yichen928.github.io/
Advisor(s): Masayoshi Tomizuka
Research Blurb: My research focuses on building multimodal foundation models and world models that understand and interact with complex physical environments. I aim to develop unified representations across modalities, enabling AI systems to reason over space, time, and dynamics toward general-purpose embodied intelligence.
What's next: Research Scientist at Luma AI

---

Yigit Efe Erginbas

Email: erginbas@berkeley.edu
Website: https://www.linkedin.com/in/erginbas/
Advisor(s): Kannan Ramchandran, Thomas A. Courtade
Research Blurb: My PhD research spans two threads: online learning in large-scale markets, and interpretability of large machine learning models. In the first, I work on sequential decision-making with applications to recommendation, pricing, and assortment selection. My focus is on designing algorithms with provable guarantees for welfare maximization, revenue maximization, and stability. In the second, I develop scalable attribution methods that exploit the sparse, low-degree structure of real-world interactions, using tools from signal processing and information theory. More recently, I have been exploring principled ways to evaluate the faithfulness of model self-explanations.
What's next: Researcher at Hudson River Trading's AI Labs (HAIL)

---

Yiheng Li

Email: yhli@berkeley.edu
Website: https://Yihengli.com
Advisor(s): Masayoshi Tomizuka
Research Blurb: I am working on vision world modeling, with prior experience in diffusion model's efficiency as well as in autonomous driving.
What's next: Research Scientist at Waymo

---

Zhe Fu

Email: zhefu@berkeley.edu
Website: https://fu-zhe.com/
Advisor(s): Alexandre Bayen
Research Blurb: My research focuses on physics-informed learning and control for mixed-autonomy systems, with applications in transportation. I design physics-informed neural networks to learn solutions of nonlinear partial differential equations, enabling accurate and data-efficient prediction of traffic dynamics. Building on these models, I develop both model-based and learning-based control strategies that coordinate automated vehicles to improve system-level performance. My work bridges machine learning, control, and real-world deployment, and has been validated in large-scale field experiments. More broadly, I aim to advance trustworthy, interpretable AI for decision-making in complex, real-world systems.
What's next: I will be an Energy Fellow at Stanford after graduation. Also looking for Faculty, or research scientist positions in AI, control, and autonomy.

---