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 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 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 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.

---

AI ethics boards fail because they are structurally powerless, politically convenient, and strategically misaligned with how real organizations make decisions. They are built to signal responsibility, not exercise it. What actually works is embedding enforceable governance into the operational, financial, and technical machinery of the business—where incentives, accountability, and consequences live.

The Problem: Ethics Boards Were Designed to Fail

AI ethics boards emerged as a corporate response to rising public concern about algorithmic bias, privacy violations, and runaway automation. But their design reflects PR priorities, not governance realities.

1. They Have No Real Authority

Most ethics boards cannot:

• veto a product launch
• halt a model deployment
• demand a redesign
• enforce compliance

 They are advisory bodies—suggestion boxes with better branding. When an AI system poses ethical risk but promises revenue, the board’s recommendations lose every time.

2. They Are Politically Convenient

Ethics boards allow executives to:

• claim oversight
• deflect criticism
• reassure regulators
• signal virtue to investors

 But because these boards rarely publish decisions or dissent, they operate as opaque shields rather than transparent safeguards.

3. They Are Misaligned With Business Incentives

AI systems are deployed because they:

• reduce cost
• increase efficiency
• unlock new revenue streams

Ethical concerns, by contrast, often:

• slow timelines
• increase development cost
• introduce compliance friction

 Ethics boards are structurally positioned to lose every internal battle because they are not tied to the incentives that drive organizational momentum.

4. They Are Too Far From the Technical Reality

Most boards:

• meet quarterly
• review high-level summaries
• lack access to model internals
• rely on presentations curated by the teams they are supposed to oversee

 This is like inspecting a skyscraper by looking at the brochure.

5. They Are Reactive, Not Proactive

Ethics boards typically intervene after:

• the model is trained
• the architecture is locked
• the deployment plan is finalized

By then, the cost of change is too high. Ethical review becomes a rubber stamp.

The Deeper Issue: Ethics Without Power Is Just Theatre

Ethics boards fail because they are built on a flawed assumption: that ethical oversight can be separated from operational decision-making.

In reality:

• AI risk is created during data collection, model design, and deployment.
• Those decisions are made by engineers, product managers, and executives.
• Ethics boards sit outside that chain of command.

This separation guarantees failure.

What Would Actually Work

To make AI governance real, organizations need mechanisms that operate where decisions—and incentives—actually live.

1. Hard Governance: Enforceable Rules, Not Recommendations

Replace advisory boards with bodies that have:

• veto power over high-risk deployments
• mandatory review checkpoints tied to funding gates
• authority to halt non-compliant projects

 If a governance body cannot say “no,” it is not governance.

2. Embedded Ethics: Put Oversight Inside the Workflow

Ethical review must be:

• continuous
• integrated into development pipelines
• tied to CI/CD processes
• enforced through automated checks

 Think of it like security testing: invisible, constant, unavoidable.

3. Align Incentives With Ethical Outcomes

Organizations should tie:

• executive compensation
• product KPIs
• deployment approval
• risk scoring

 to measurable ethical performance. If ethics costs teams time but earns them nothing, it will always lose.

4. Make Ethics a Technical Discipline

Ethics cannot remain abstract. It must be:

• quantitative
• testable
• reproducible
• integrated into model evaluation

This means:

• bias audits
• robustness tests
• privacy leakage assessments
• red-teaming
• adversarial scenario modeling

 Ethics becomes engineering, not philosophy.

5. Transparency as a Default

Real governance requires:

• public reporting of decisions
• documented dissent
• clear criteria for approval
• external audits

 Opacity protects the organization. Transparency protects the public.

6. Regulatory Teeth

Ultimately, internal governance only works when external pressure exists. The most effective ethics boards are those backed by:

• legal requirements
• financial penalties
• regulatory audits
• mandatory disclosures

 Without consequences, ethics is optional.

The Future: From Ethics Boards to AI Risk Committees

The next evolution is not a “better ethics board.” It is a Risk Committee with:

• cross-functional membership
• operational authority
• budgetary control
• integration into product lifecycle
• direct reporting to the board of directors

 This shifts ethics from symbolic oversight to strategic governance.

Why This Matters Now

As AI systems increasingly influence:

• hiring
• healthcare
• finance
• policing
• national security
• global supply chains

 the cost of ethical failure becomes systemic. Organizations can no longer treat ethics as a branding exercise.

The companies that survive regulatory scrutiny, public backlash, and market volatility will be those that treat AI governance as a core business function—not a PR accessory.

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

That is the problem Robotiq built IQ to solve.

Start with a Fit Check, not a site visit

Before any site visit, before any engineering hours, before any quote, IQ asks five minutes of your time.

That is enough to find out whether palletizing fits your floor, what the deployment realistically looks like, and whether the financial return makes sense for your operation, including in 1-shift operations. It is a structured assessment designed to give you a concrete answer at the start of a project rather than at the end of a long discovery process.

If it is a fit, you have a clear path forward. If it is not, you know that too, without having spent weeks finding out.

“Automation does not scale when integration remains manual.” said Samuel Bouchard, CEO of Robotiq.

See your deployment before it happens

A palletizing project has thousands of moving parts. The floor layout, the product mix and the throughput targets, to name just a few. Getting those details wrong late in a project is expensive in time and money. IQ is built to get them right early.

Once the fit is confirmed, IQ powers the full project from the know-how of over 1,000 Robotiq deployments. It captures what your operation actually looks like, connects the right people at the right moment, and generates a validated Workcell design simulated in your factory environment. Cycle time, reach, payload: every spec confirmed before anything is installed.

The gap between what was promised and what gets delivered on day one closes considerably when the work is done upfront.

Built to scale from the first line

When your first Workcell is running and you are ready to add a second line, the same path applies. No custom engineering from scratch. The know-how that built the first is already in the system.

IQ coordinates every stakeholder: your team, your local partner, Robotiq experts, through a structured digital workflow. Your partner stays central. They bring the local expertise, installation capacity, and ongoing support that keeps your lines running. IQ gives them better information and a repeatable process, so every project moves faster than the last.

"For manufacturers, this means a clearer path to automation: fewer surprises, faster decisions, more predictable performance, and better financial justification, including in many 1-shift operations." said Samuel Bouchard, CEO of Robotiq.

First seen at RUC 2026

IQ made its first appearance at the Robotiq User Conference 2026 in Québec City this week, where selected expert partners experienced it firsthand, generating Workcells and seeing what Automatic Integration looks like on real opportunities. The demonstration showed a full project path: from initial input to a running Workcell in as little as 24 hours.

IQ is available now for palletizing applications. New features will continue to be released over time. Robotiq also plans to extend the same Automatic Integration model to additional robotic applications.

“With IQ, we are moving from manually engineering robotic systems one project at a time to automatically generating workcells from real customer inputs, Robotiq components, AI, and proven know-how from thousands of past projects." said Samuel Bouchard, CEO of Robotiq.

Your project starts here

If palletizing has been on your list and you have been waiting for a clearer path to get started, this is it. The Fit Check takes five minutes, requires no site visit, and gives you a concrete answer on whether automation makes sense for your floor and your financials. No commitment, no engineering hours upfront. Just a starting point that is actually useful.

Check the fit. See the deployment. Know the return. Scale it.

Start your Fit Check at robotiq.com/iq-platform

See IQ on a live palletizing project, June 18

Join Robotiq for a first look at IQ: a keynote from CEO Samuel Bouchard and a live walkthrough on a real palletizing deployment.

Register for the June 18 launch webinar:

• Americas: https://event.robotiq.com/webinar-power-your-factory-with-iq-june-18th-2026-ame
• EMEA: https://event.robotiq.com/webinar-power-your-factory-with-iq-june-18th-2026-emea
  
  

Common questions about IQ and palletizing automation

What is IQ from Robotiq? IQ is an AI-enabled platform that helps manufacturers start and deploy palletizing automation faster. It begins with a five-minute Fit Check to assess whether palletizing is right for a specific operation, then powers the full project from fit to a validated, deployment-ready Workcell design.

How long does it take to get started with palletizing automation using IQ? The first step takes five minutes. The Fit Check requires no site visit and no engineering hours upfront. It gives manufacturers a clear answer on whether palletizing fits their floor and whether the financial return makes sense, including in 1-shift operations.

Does IQ work for manufacturers with multiple production lines? Yes. Once the first Workcell is deployed, the same path applies to every line after it. No custom engineering from scratch. The know-how from the first project is already in the system.

What does a validated Workcell design mean? A validated Workcell design is a deployment-ready palletizing system where cycle time, reach, payload, and all other specs have been confirmed through simulation in the manufacturer's actual factory environment, before anything is installed.

Is IQ available now? IQ is available now for palletizing applications. New features will continue to be released over time. Robotiq also plans to extend the same Automatic Integration model to additional robotic applications.

Ready to see if palletizing automation fits your operation?

? Start your project now with the newly launched IQ platform

The good news: most of these failures follow predictable patterns. Here are five pitfalls we see repeatedly, and how to avoid them, illustrated by how Molino Merano, a historic Italian flour producer, turned a tight floor, a staffing problem, and a growing product line into a 14-month payback.

Pitfall #1: Overestimating installation complexity

A lot of manufacturers never start a palletizing project because they're convinced it will mean months of production downtime, deep integration work, and a long commissioning process. That expectation, more than anything else, is what keeps manual palletizing in place long after it stops making sense.

When the solution is pre-engineered and standardized to connect with an existing line, deployment looks very different. Training is part of the package. The conveyor integration is straightforward. The commissioning period shrinks from months to days. The belief that automation is inherently slow to deploy is worth questioning before it shapes your decision. Part of what makes that possible is having the project information well organized from the start: customer requirements, site constraints, throughput targets, and layout realities all in one place, rather than scattered across emails and spreadsheets. When that groundwork is done upfront, the path from decision to running system gets much shorter.

Pitfall #2: Designing for perfect conditions

Real production floors have tight spaces, ceiling limits, layout constraints, and equipment that was installed a decade ago with no thought for what might come next. A solution engineered for a clean, open layout will always struggle when it meets a real factory.

Hardware that adapts to compact footprints and software that handles changing SKUs are not nice-to-haves. They are what determines whether a system still works two years after installation.

Pitfall #3: Not planning for variability

Many manufacturers rarely run one product. They run dozens, and that number tends to grow. A system that handles this year's SKU mix cleanly may struggle badly when a new format gets added or a customer changes their pallet specification.

Building for today's conditions without accounting for tomorrow's variability is a setup for re-engineering costs down the line. Choosing a system with flexible pattern programming, one where operators can make changes on their own, keeps the production line scalable as the business evolves.

Pitfall #4: Starting with the most complex operations

There's a logic to tackling the most complex line first. The biggest bottleneck, the highest labor cost, the most compelling ROI case. But starting with complexity adds complexity. Timelines stretch, scope grows, and the project loses momentum before it ever delivers.

A single, well-scoped project on a line with clear constraints and a realistic payback period does something a complex rollout rarely does: it finishes. This is the foundation of Lean Palletizing — start simple, build operator confidence, create the internal expertise that makes the next deployment faster and easier to approve. Start simple, prove it and then scale.

Pitfall #5: Over-engineering the solution

Customization can feel like thoroughness. The more the system is tailored to your operation, the better it should perform. In practice, highly customized systems take longer to deploy, are harder for operators to understand, and create a long-term dependency on external support for every change.

Standardized automation and proven solutions deliver faster. Operators learn them more quickly, maintain them more confidently, and own them more completely. When someone on the floor can adjust a pallet pattern or troubleshoot a fault without escalating, the system pays back more every single day. The same principle applies to the integration process itself: when the workflow for scoping, validating, and deploying a Workcell is repeatable and structured, partners can move faster and manufacturers face fewer surprises.

How Molino Merano avoided all five

Molino Merano has been producing flour products in the historic town of Merano, in Trentino Alto Adige in northern Italy, since 1985. The company had a floor space problem, a staffing problem, and a product line that kept growing. What they didn't have was time for a 12-month automation project. Here is how they worked through each of these challenges.

What pushed them to act

As the product line expanded, the end-of-line operation started showing the strain. Manual palletizing, where operators lifting and placing every box, shift after shift was slowing throughput and wearing people down. Finding staff for that kind of work was getting harder. And the production floor simply didn't have the space to bring in a traditional palletizer.

What they needed wasn't a large-scale automation project. They needed something that would fit where they had space, go in fast, and work reliably from day one.

What they deployed

Robotiq's cobot palletizing Workcell fit the floor where a conventional system couldn't. No fencing, no area scanners, just a collaborative Workcell that worked safely within the constraints of the existing layout, respecting the actual line rather than requiring the line to change around it. The solution handled multiple SKUs, allowed pallet changes without stopping production, and came with operator training built into the deployment.

What changed

The Workcell was in production within a week of installation.

As the product range had grown, so had the pressure on the team. Automating palletizing meant that pressure didn't have to grow with it. Staffing the end of the line stopped being a recurring problem. Operators moved to other parts of the operation where their time had more value.

But the change that stands out most isn't about throughput or headcount. Before the cobot, the end-of-line team was lifting every box onto every pallet, hundreds of times a day. Back pain was routine and that manual work is gone now. The physical environment at the end of the line is genuinely better, and the team feels it.

Molino Merano even reached a full return on investment in 14 months, across a footprint that fit the floor they actually had.

Questions manufacturers ask before getting started

How long does a palletizing project actually take? Weeks, not months, and the gap is closing. Molino Merano went from installation to live production in under a week. With the right information organized upfront and a structured workflow from scoping to deployment, what used to take months is becoming a matter of days. The timeline depends far more on how well the project is prepared than on the technology itself.

What if our floor doesn't have much space? That's one of the most common constraints, and a good reason to look at cobot solution specifically. They're designed for compact footprints, work without safety fencing, and can be configured around existing equipment rather than requiring the line to move around them.

We run a lot of different products. Can one system handle all of them? Yes, if the system is built for it. The key is flexible pattern programming that operators can manage themselves. If changing a pallet configuration requires a service call, that's a problem at scale.

How quickly will we see a return? It depends on volume, labor costs, and how much downtime the current operation is absorbing. For Molino Merano, with a busy multi-SKU line and real difficulty finding staff, the return came in 14 months.

What happens when something goes wrong? That depends heavily on the system you choose. Standard, pre-engineered solutions are easier to troubleshoot because operators recognize what's happening. Highly customized systems tend to create dependency on vendor support for even basic interventions. Ease of maintenance should be part of the selection criteria from the start.

Get a clear answer instantly:

? Start your evaluation now with the Palletizing Fit Tool

For a CFO or engineering leader, the implication is direct. The route forward is higher information density per episode rather than more robots running for more hours. A single tactile-augmented trajectory carries more training signals than several vision-only runs, particularly for contact-rich and insertion tasks.

Why scale alone breaks the budget

Physical AI does not have an internet to scrape. The largest open real-robot dataset, Open X-Embodiment, aggregates around 1 million episodes from 34 labs.¹ DROID took 50 operators, 18 robots, and 12 months to assemble 76,000 trajectories.² Physical Intelligence's π0 — arguably the most capable open generalist policy to date — required more than 10,000 hours of teleoperated data before fine-tuning.³ These efforts are formidable, and still modest by several orders of magnitude relative to what genuine generalisation requires.

If volume is the only lever, data collection cost scales linearly with fleet size and operating hours. Multiplied across 10,000 robots, that is a capital expense in the hundreds of millions of dollars before a single model has been trained.

Better sensing multiplies every robot hour

Studies of imitation learning show that robot policies improve as more training environments and objects are added to the dataset.⁴ Vision-language-action models follow the same pattern, but each new data point in robotics produces a smaller performance gain than in language modelling, a consequence of data quality heterogeneity and the scarcity of action-labelled contact-rich interactions.⁵

For a budget owner, this is the core economic insight. A shallower scaling coefficient means brute-force volume buys less performance per episode in physical AI than it does in language. Quality of data therefore matters more. Investing in better sensing hardware early is a multiplier on every hour of robot time that follows.

The Video Tactile Action Model (VTAM) put a concrete number on the multiplier, tactile-augmented policies outperformed vision-only baselines by 80% on contact-rich tasks, from just 10 minutes of teleoperation per task (covered in detail in our previous post).⁶ Well-instrumented end-effectors lead to richer episodes, which means fewer demonstrations needed, which lowers compute per training run, which speeds up iteration, which shortens time to deployment. Each link has a measurable saving.

Additional to tactile sensing, a Robotiq end-effector emits several synchronized data streams per operation cycle — force, torque, position, velocity, and gripper state — each a separate signal the policy can use to disambiguate what is happening at the contact point. Every episode produces more training signals.

What this means for the budget

A well-instrumented end-effector is an investment with a calculable return. Teams that treat instrumentation as the foundation of their data strategy ship sooner and at lower total cost. Teams that defer the investment pay for it twice, once in rebuilt datasets, and once in delayed time to production.

Talk to our technical team about sensor integration for your manipulation pipeline and learn more about how Robotiq can enable your application.

¹ Open X-Embodiment, arXiv:2310.08864 — approximately 1.0 × 10⁶ real-robot episodes spanning 22 embodiments and 500+ skills.

² DROID, arXiv:2403.12945.

³ Physical Intelligence, π0: A Vision-Language-Action Flow Model for General Robot Control.

⁴ Lin et al. (2024), Data Scaling Laws in Imitation Learning for Robotic Manipulation.

⁵ Sartor and Nießner (2024), scaling-law analysis of vision-language-action models and proprioceptive policies. See also Kaplan et al. (2020), Scaling Laws for Neural Language Models, and Hoffmann et al. (2022), Training Compute-Optimal Large Language Models ("Chinchilla").

⁶ Video Tactile Action Model (VTAM), arXiv:2603.23481.

IQ is the platform Robotiq built to change that. It captures the information behind a palletizing project, structures it, and generates a validated Workcell design based on your actual operation. The result is a deployment-ready Palletizing Workcell with predictable performance from day one and a financial case you can stand behind before committing to anything.

What manufacturers can do directly in IQ

The Fit Check: filter fast, move on what matters

The first step in IQ is the Fit Check. It is a high-level assessment designed to give a fast, honest answer on whether a palletizing application is worth pursuing, without overwhelming you with technical questions upfront.

In five minutes, the Fit Check tells you whether the application is viable, whether the business case holds, and what the deployment path looks like. It is the preferred entry point for any new project because it filters out unfit applications early, so time and resources go toward the opportunities that are genuinely worth it.

The Fit Check looks at what matters most at this stage: production volumes, labor context, package types, and basic site constraints. It is built for speed over precision, giving your team and your partner a shared starting point before the first conversation even happens.

The Simulator: see the Workcell before it exists

Once the project data is in, the Simulator generates a validated Workcell design in your actual factory environment. Cycle time, reach, payload, pallet configuration, conveyor layout, every performance indicator is confirmed through simulation before a single component ships.

This is where the promise of predictable performance becomes concrete. The Simulator validates the design across your full product mix, including multiple SKUs, different box sizes, and varying throughput targets. If something doesn't work, you know it before deployment, not after.

The output includes an automation preview, a personalized report, and an ROI projection showing your estimated payback period based on your actual inputs.

What your partner brings to the project

Missing or wrong information is one of the most common reasons palletizing projects slow down or have to be redone. Waiting for information after the fact, rework on the design, imprecise simulation results, inaccurate pricing on components like conveyor length; the consequences compound quickly and quietly, often only showing up late in the project when they are expensive to fix.

Your local Robotiq partner works with you through every step using the full set of IQ tools, capturing the right information at the right moment so none of that happens. Each tool feeds directly into the Simulator and the Workcell design you receive.

Voice Capture: nothing gets lost between the call and the proposal

During the qualification call, your partner uses IQ's Voice Capture feature to guide the conversation and extract the information that matters. Business case elements, application details, site constraints, potential risks, and next steps are all captured in real time.

In a traditional process, critical details get lost between a phone call and a proposal. A constraint mentioned in passing. A throughput target that wasn't written down. Voice Capture structures that conversation and turns it into actionable project data, so the qualification call actually moves the project forward rather than creating more follow-up.

3D Scan: put away the measuring tape

On site, your partner scans the full environment using LiDAR (Light Detection and Ranging) and IMU (Inertia Measurement Unit) technologies on an iPhone Pro. Ceiling height, obstacles, conveyor positions, aisle widths, floor space, all of it captured in one pass, connected directly to the Simulator.

The 3D scan removes one of the most common sources of project delay and rework: missing or inaccurate site measurements. When the wrong conveyor height goes into a design, or a structural beam isn't accounted for, the project has to go back to square one. The scan closes that gap. What used to require hours of manual measurement and follow-up visits gets done in a single pass on site.

Keyframes within the scan allow your partner to reference specific points in the environment later, effectively letting them go back on site without a return visit.

File Capture: use the data you already have

Product information doesn't need to be re-entered manually. Your partner can upload TOPS files for the most accurate product data, pull box sizes from a photo of an existing pallet, or import a spreadsheet for multiple SKUs at once. Business card information is extracted automatically.

This matters because incomplete or inaccurate product data is one of the most common reasons Workcell designs have to be revised. File Capture pulls the information directly from the source, reducing manual entry and the errors that come with it.

The financial case, built from real data

The ROI calculator in IQ surfaces the payback period and total projected savings based on your actual operation: labor costs, number of workers, number of shifts, production volumes, and product mix.

For manufacturers running a single shift, the financial case for automation has historically been harder to build. IQ is specifically designed to surface that answer early, before engineering hours are committed. If the return is there, the calculator shows it. If the project scope needs to change to make the numbers work, you find that out at the start, not at the end.

By the time your Workcell design is validated, the performance and the return are both confirmed. That is what makes the decision straightforward.

See IQ on a real palletizing deployment, June 18

Reading about IQ is one thing. Seeing it work on a real project is another.

On June 18th, Robotiq will walk through IQ live on a real palletizing deployment. In 45 minutes, you will see the full path from first inputs to a validated Workcell, and walk away knowing exactly what this means for your next project.

This is the clearest way to understand what IQ does for your operation before committing to anything.

✔ See the Fit Check in action on a real application
✔ Watch the Simulator generate a validated Workcell live
✔ Get the financial case confirmed in real time

Register for the June 18 launch webinar:

? 11:00 AM EST | 8:00 AM PST → Register here: https://hubs.la/Q04kLFbT0
? 2:00 PM CET → Register here: https://hubs.la/Q04kM3ff0

Robotiq has released the digital twin of its TSF-85 tactile sensor in NVIDIA Isaac Sim, the first industrial-grade tactile sensor digital twin shipping on a commercial collaborative gripper. Tactile sensing promises to accelerate robotics, but its adoption has been limited by the lack of data from industry-ready hardware and accurate simulations. Model builders can now train contact-rich manipulation policies in simulation, then run them on the same physical sensor designed to operate reliably on the factory floor.

Most tactile sensors rely on a deformable contact interface. The very property that gives them sensitivity is also what makes them difficult to simulate. Deformable body simulation is technically demanding, and that is one reason accurate tactile digital twins have lagged behind in the Physical AI stack. The TSF-85 digital twin is built around that constraint. It generates synthetic tactile maps through a custom Isaac Sim UI panel, visualizes them in real time, runs data generation at the simulation refresh rate, and exports to HDF5 for downstream training pipelines.

The TSF-85 digital twin was developed by the CoRo Lab (Laboratoire de commande et de robotique) at École de technologie supérieure (ÉTS) in Montréal, a long-time research partner of Robotiq — a collaboration led by Associate Professor Jean-Philippe Roberge and doctoral researcher Berith Atemoztli De la Cruz Sánchez.

The simulation method behind the digital twin is documented in two peer-reviewed publications cited in the GitHub repo. The first, published in Frontiers in Robotics and AI (2025), draws on a dataset of 53,400 real-world tactile maps to train, validate, and test each simulation pipeline — achieving up to 97% Structural Similarity Index Measure (SSIM) for the hyperelastic model and 90% SSIM for the elastic model on 12 unseen objects. A companion paper at ICCRT 2025 releases an open dataset of 46,200 real and synthetic tactile samples, including data collected using a 2F-85 Robotiq gripper and synthetic samples generated in NVIDIA Isaac Lab.

Simulation accuracy matters, but it only helps if the real sensor remains stable over time. The TSF-85 has been tested through 2.3 million cycles at maximum gripper force, with no significant variation in the output of the tactile signals. This means models trained on its tactile data can continue to rely on consistent signals for edges, shapes, textures, and geometry even after demanding real-world use.

Robotiq has been the go-to components provider for both academic research labs and industrial production for more than a decade. That dual footprint is exactly the bridge Physical AI requires: research-grade flexibility and industrial-grade reliability in the same hardware platform.

The digital twin supports NVIDIA Isaac Sim 5.1 and is available now on GitHub: https://github.com/Lab-CORO/TSF-85. Learn more about Robotiq's physical AI stack at https://robotiq.com/physical-ai

SEL designs, develops, and manufactures digital products and systems that protect, automate, and control critical infrastructure in over 170 countries. With a mission to make electric power safer, more reliable, and more economical, quality and repeatability are non-negotiable at SEL. When a recurring ergonomic problem started putting operators out of action, they turned to Robotiq to fix it and what started as one workcell became something much bigger.

A repetitive task becomes a real problem

As SEL's production volumes increased, tasks that were once manageable became real ergonomic challenges. One product in particular, the 700 series, required operators to drive 8 screws on the rear panel, repeatedly reaching up to grab a tool and tighten screws all day long.

With hundreds of units moving through the line each day, operators were manually driving 4,000 screws daily. The repetition might sound routine on paper, but the physical toll was anything but. Within two years, three operators suffered rotator cuff injuries, a clear sign that the cumulative strain was significant and only getting worse.

SEL needed a solution, and it had to check several boxes at once. It had to eliminate the repetitive ergonomic risk causing these injuries. It had to integrate quickly, without the long deployment cycles typical of traditional automation projects. It had to be easy enough for SEL's own engineers to operate without specialized robotics training. And critically, it couldn't be a one-off fix. SEL needed something that could scale to other products and applications beyond this single use case.

Starting small, thinking big

SEL acquired their first Robotiq Workcell, specifically building a Screwdriving Workcell integrated with a UR cobot. The ease of implementation, particularly thanks to the Robotiq URCap software, meant a working program was running within days.

For Tyler Marines, Development Lead Engineer at SEL, that early experience stuck with him:

"It was very, very cool to be able to get a robot, get a screwdriver, and solve a problem without breaking the bank."

That first success on the 700 series rear panels didn't stay contained to one workcell. SEL's automation program expanded quickly with the addition of more cobot components. The Screwdriving Workcell, including feeders for high-volume screw supply, is now used across multiple product lines. The team added Adaptive Grippers (2F-85 and 2F-140) for pick & place of circuit boards and parts. A tool changer from TripleA enabled multi-component cells, letting a single robot switch between tasks.

What began as a single pilot cell became a coordinated, multi-cell automation program, and the results went beyond ergonomics. Since deploying the solution, SEL has recorded zero customer feedback or returns related to screwdriving.

The results by the numbers

1.4 million screws automated yearly. What once required operators to hand-drive 4,000 screws across hundreds of units each day is now fully automated. The single most physically demanding manual task on the line has been removed entirely.

3 to 0 rotator cuff injuries. After 3 cases in two years, automating the repetitive manual assembly movements eliminated the ergonomic strain that had been building as production volumes increased. This was the problem SEL set out to solve, and it's been solved.

27 active stations across the facility. From 1 pilot cell to 27 production stations, what started as a single Screwdriving Workcell has grown into a multi-cell automation program with Robotiq products ranging from grippers to screwdrivers.

Why Robotiq and why it scaled

A few factors explain why SEL's relationship with Robotiq grew from a single Workcell into a facility-wide program.

Rapid time to value. A working automation Workcell using Robotiq cobot components was running within 3 months. The URCap integration with Universal Robots made programming fast and accessible for SEL's internal engineers.

Full ROI within one year. Factoring in hardware costs and the financial impact of ergonomic injuries, SEL recouped their investment within twelve months.

Low barrier to entry. The price of a Robotiq Workcell allows teams like SEL's to acquire one and start experimenting internally, reducing the barrier to proving ROI before committing to a larger-scale deployment.

Easy operator training. New operators were able to be quickly trained on the use of Robotiq cobot components and Workcell. The ease of use reduced training time and reliance on specialized knowledge.

Could your line benefit?

SEL's story isn't really about screws. It's about what happens when a manufacturer takes a recurring ergonomic problem seriously and finds a tool that's accessible enough to start small, fast enough to show value quickly, and flexible enough to grow well beyond its original use case.

If your team is doing repetitive assembly, pick & place, or parts handling, Robotiq cobot components are built to grow with you, from a single pilot cell to a full multi-cell automation solution.

Beyond traditional automation: The Screwdriving Workcell and Physical AI

The Screwdriving Workcell isn't limited to traditional automation applications. As physical AI continues to reshape manufacturing, structured and repeatable tasks like screwdriving are among the first to benefit from AI-driven robot intelligence, enabling cobots to adapt, learn, and perform with even greater precision and flexibility on the factory floor.

If you're exploring how physical AI can be applied to your assembly operations, the Screwdriving Workcell is a strong starting point. Explore more about physical AI here.

Founded in 2014 and based in Valréas, in the Provence region of southeastern France, Bulles Création is an 8-person company that offers bottling services for local winemakers while also developing its own sparkling beverages, including wine and non-alcoholic options like kombucha.

The challenge: growing demand, an aging line, and a physically demanding job

Bulles Création built its business on flexibility, bottling for local winemakers while developing its own effervescent drinks. But as demand grew, the company's production tools couldn't keep up. Its packaging line was capped at 1,500 bottles an hour.

The bottleneck wasn't just speed. It was also the toll manual palletizing took on operators. Every day, workers handled cartons of 6 or 12 bottles weighing up to 20 kg, stacking them at a pace of roughly 4.5 cartons a minute. That added up to 4 to 5 tonnes lifted per day.

"Labor shortages, physical strain, the need to boost productivity... this automation project aimed to provide an effective answer to several challenges shared by many food and beverage companies."
Bruno Quenin, co-manager of Bulles Création

On top of the space and labor constraints, Bulles Création needed a solution flexible enough to adapt palletizing to its film-wrapping step, rather than a rigid, single-purpose setup.

To address it, the company invested more than €1 million to rebuild its bottling line and automate nearly all of it. The turning point came at the Prod&Pack trade show in November 2024, where Bulles Création's leadership met Isycod, Robotiq's integration partner for southeastern France.

The solution: a compact Workcell built for a tight production floor

Space was the deciding constraint. Bulles Création's production floor is tight, and a traditional industrial robot, with the heavy safety fencing it requires, simply wasn't an option.

The company turned to the PE20, Robotiq's automated Palletizing Workcell built around a UR20 collaborative robot from Universal Robots.

"It's the compactness, the ease of use, and the ability to adapt to multiple carton and pallet formats, all while meeting the specific constraints of our production site, that led us to choose the Robotiq Palletizing Workcell very quickly."
Bruno Quenin, co-manager of Bulles Création

Isycod completed the integration at the end of the line, which required smart sequencing of the carton flow through an autonomous roller conveyor with three buffer zones. The system automatically spaces cartons apart to prevent collisions and keeps the cobot fed in real time.

One distinctive piece of the project was the integration of two film wrappers directly into the Workcell. That let the line run palletizing, wrapping, and pallet evacuation to shipping as one continuous sequence, with no manual handling in between. The hard part wasn't software, it was mechanical. Isycod had to fit those film wrappers to the Robotiq standard without resorting to major software changes.

That's also where Robotiq's software earns its keep. Operators configure, adjust, and launch palletizing recipes on their own, with no advanced robotics or programming skills required. Switching between carton or pallet formats is just as fast, letting operators reconfigure the line themselves without calling in outside help.

Equipped with a 3 kg Robotiq vacuum gripper built for heavy cartons, the cobot now handles cartons weighing up to 20 kg, putting the UR20's 25 kg payload to work. Running at a steady 4 cycles per minute and backed by native sensitivity sensors that trigger an instant stop on contact, the cell operates safely without a safety cage.

The results: capacity doubled, with room to grow

One year after automating its line, Bulles Création is already seeing the payoff.

• Cadence doubled: the company now produces around 2,500 bottles per hour, up from 1,500
• Headroom for growth: the new line can reach up to 4,500 bottles per hour, giving the business a long runway to scale
• Fewer missed opportunities: Bulles Création can now meet stronger demand, take on new volumes, and expand its client portfolio instead of turning down production for lack of capacity
• Better working conditions: manual palletizing, and the musculoskeletal disorder risk that came with it, has been removed from the job
• Higher-value work: operators freed from palletizing now contribute to R&D on new in-house products

"Today, I don't understand why everyone isn't doing this. Collaborative palletizing has genuinely helped us. This project shows exactly how small and medium-sized French food and beverage companies can modernize their production tools to become more competitive, grow their order book, and become more attractive employers."
Bruno Quenin, co-manager of Bulles Création

A model for small manufacturers

Bulles Création's story is a reminder that automation doesn't require a large footprint or a large team to pay off. With the right partner and the right cobot, an 8-person company can rebuild its end-of-line, double its output, and give its people better, safer work to do.

Want to see if collaborative palletizing fits your production floor? Try our Palletizing Fit Check to confirm feasibility, or explore the PE20 Palletizing Workcell for yourself.

Not sure if palletizing automation is right for you? Start with IQ.

One of the biggest barriers manufacturers face before investing in automation is uncertainty. Will it fit in my plant? Will it handle my products? Will the numbers actually work for my operation? These are fair questions, and they deserve real answers before any commitment is made.

That is exactly what Robotiq IQ is built for.

IQ is Robotiq's AI-enabled platform designed to take manufacturers from first question to deployment-ready Workcell faster and with greater confidence. It is not a sales tool. It is an engineering and business validation platform that gives you the information you need to make an informed decision.

That leaves a harder question. If a tactile sensor is now a requirement, what should it actually measure, and how do you build one that survives an industrial deployment? This is the engineering problem the TSF-85 was designed to answer.

Slow industrial adoption is not a hardware-maturity problem; capable tactile hardware has existed in labs for decades. It is an interpretation problem. With cameras, resolution, frame rate, and dynamic range map predictably onto performance. Tactile sensing has no equivalent consensus on what signals a useful sensor must capture, at what bandwidth, or at what resolution. That ambiguity carries a cost: a team planning hundreds of thousands of grasps needs confidence that the sensor is capturing the right physical phenomena.

Rather than derive that specification from first principles, Robotiq reverse-engineered it from the system that already manipulates better than any robot ever built: the human hand.

Borrowing the Spec From Human Physiology

The human hand is the best-characterized model of dexterous manipulation available. Johansson and Vallbo's 1979 study classified its mechanoreceptors into two functional modes. Slowly adapting (SA) units encode sustained pressure, edges, and skin stretch. Fast-adapting (FA) units respond to dynamic events such as vibration and contact transients. The two are not redundant: human grasp control is event-driven, with FA afferents triggering fast slip correction while SA afferents maintain the contact map that regulates grip force.

That physiology hands engineers a concrete target. A tactile sensor for dexterous manipulation must capture static pressure distribution and dynamic contact events, ideally through the same sensing element over the same region, plus a channel for fingertip orientation to interpret the pressure map correctly.

One Dielectric for Three Modalities

The TSF-85 uses capacitive sensing, chosen for the fingertip: no imaging cavity or degrading elastomer like optical sensors, no ferromagnetic constraints like magnetic ones, and manufacturable at industrial scale and cost. The engineering challenge was fitting two distinct capacitive circuits onto a single 22 mm × 37 mm PCB layer without crosstalk.

The static circuit is an array of 28 taxels in a 4×7 grid, mapping pressure across the contact surface as the SA analog. The dynamic circuit is a single taxel around the array's perimeter, sharing the same dielectric but measuring capacitance change up to 1,000 Hz, spanning both fast-adapting bands. Running both through one shared dielectric eliminates the registration errors and inter-layer crosstalk that plague designs built by stacking separate sensor layers. An integrated IMU completes the picture, supplying fingertip orientation and an independent second source of vibration data.

Built to Survive an Industrial Deployment

Accelerated testing beyond 2 million grasp cycles on an uneven surface shows stable response with no meaningful degradation. Sensor-to-sensor and taxel-to-taxel variance is handled with a simple calibration routine that applies a known load and computes the gain that aligns each output, which brought 37 sensors into alignment at 500 counts under a 100 N load. Because the response exhibits hysteresis, the sensor is optimized for contact detection and orientation estimation rather than absolute force.

Read the Full Engineering Breakdown

The full article goes deeper, covering the complete mechanoreceptor-to-modality mapping, the layered sensor construction, the cycle-testing and calibration data, and the decade of research validating grasp stability prediction, slip classification, in-hand object recognition, and dynamic re-grasping.

Read the full article on Tech Brief.

Ready to take the next step?

Talk to our technical team about tactile integration for your manipulation pipeline and learn more about how Robotiq can enable your application.

With the purchase, Digital Workforce expands agentic AI and virtual customer service agents to its process automation and orchestration. Digital Workforce can now transform and orchestrate customer service processes more extensively.

• Built for regulated industries. Banking, insurance, and the public sector require control, compliance, and data governance that are core to Digital Workforce’s business.
• One managed service. Customer service processes are offered service as software. Customers have one contract, with a single point of accountability across the services and technologies.
• Scales with demand. Customer service keeps pace while staying personal. Customers get faster service, and organizations can provide premium service without growing the team.
• Voice is ready also for the Nordics. Automation meets people in natural spoken conversation, also in Nordic languages.

Around 30 customer contracts and the team of 8 people transfer to Digital Workforce with the business.

Jussi Vasama, CEO of Digital Workforce, comments:

“I am excited for this major accomplishment and the potential it opens for our customers. Digital Workforce is built on two things: productized services and deep industry understanding. We use both to orchestrate complex business processes for large enterprises, the public sector, and regulated industries. These organisations now want to transform their operations and disrupt the way they collaborate with their customers. Agentic AI and voice are key technologies in delivering premium interactions.”

Jari Annala, Founder and CEO, Front AI, comments:

“We built a strong agentic AI business, with our customers at the heart of it. Digital Workforce is the right new home for it. Our customers keep the same team and the same service, now with deep automation and process orchestration expertise behind them. Our people gain a stronger platform to apply their expertise. We are proud of what this team achieved, and confident that agentic AI will go far as part of Digital Workforce.”

Media enquiries

Digital Workforce Services Plc
Jussi Vasama, CEO
Tel. +358 50 380 9893

Laura Viita, CFO
Tel. +358 50 487 1044
Investor relations | Digital Workforce

The post Digital Workforce expands use of agentic AI and acquires Agentic AI for customer service business from Front AI Oy appeared first on Digital Workforce.

Each major technological revolution reshapes human value systems. Agriculture redefined survival. Industry redefined productivity. The internet redefined connection. But artificial intelligence — especially in its agentic, generative, and autonomous forms — is doing something unprecedented: it is redefining meaning itself.

For the first time, machines are not just accelerating human work; they are participating in the creation of ideas, narratives, strategies, designs, and decisions. They are entering the domains we once believed were exclusively human — creativity, interpretation, judgment, and imagination.

This shift forces a deeper question than “What jobs will AI automate?” It asks: What will humans choose to value when intelligence is abundant, accessible, and externalized?

This article explores how AI is reshaping our sense of purpose, creativity, and significance — and what the future of meaning might look like in an age where machines and algorithms mirror our minds.

1. Work: When Productivity Is No Longer the Point

For centuries, work has been the primary source of meaning. It structured identity, social status, and personal worth. But AI is destabilizing the idea that meaning comes from labour.

AI is dissolving the scarcity of capability.

Tasks that once required years of training — coding, design, analysis, writing, modeling — can now be performed by systems that learn faster, scale infinitely, and never tire. Productivity is becoming a commodity.

This creates a paradox: If machines can do the work, what does work mean?

Three emerging shifts are already visible: