Sentra×
LenskartCUSTOMER STORY
Making People More Productive Doesn't Make the Company More Productive.
What happened when we built a world model of a $12B public company from its own records: the whole organization got faster with zero change in individual productivity and we learned what enterprise AI should optimize instead.
PUBLIC RETAILER AND MANUFACTURER · 3,200 STORES ACROSS ASIA AND EUROPE · LIVE SINCE MAY
19B
tokens of operating history compiled into one world model
8 days
from kickoff to live in production
-58%
stalled dependencies across ten departments, in four weeks
170x
faster root-cause investigations, from 3 to 4 days to about 30 minutes
Eight in ten people who use AI at work believe it makes them faster. Yet in 2026 only 6% of organizations surveyed by McKinsey believed AI had a significant impact on their earnings. A year earlier, MIT's Project NANDA put it more bluntly: 95% of enterprise AI pilots produced zero P&L impact.
The people got faster while the company stayed the same. That is not a training problem. It is arithmetic: enterprise work is a relay race, and for four years the industry has bought every runner better shoes while the baton sits on the ground between them.
Sentra's bet is different. Rather than making an individual more productive, we compile every record an organization produces into a continuously updated state ledger, a world model of the company, and reason over it to reveal how the company actually works and optimize it as a single entity. Since May, that is exactly what Sentra has been doing with Lenskart.
“We decided years ago that Lenskart would be AI-first, because serving a billion people takes technology that learns from every interaction. The test I apply to any system is simple: does it help our teams make faster and better decisions for our customers? This one does, and because it understands the company a little better every day, the value compounds.”
01 · THE RELAY
Races are won and lost at the handoff.
When a Lenskart store's power backup failed mid-summer, replacing the battery took three steps: a quote, one approval, and a signature from a commercial manager. Each step was no more than two minutes of actual work. In one instance it sat for weeks, one of hundreds of requests waiting on the same signature, until someone senior noticed and intervened.
Every function runs the same relay. Code goes coder to reviewer to deployer. A legal matter goes associate to partner to client. A payout gates on operations, then compliance, then reconciliation. What actually moves between desks is context: which budget the decision hits, whether there is precedent, who is already waiting. When that reasoning is scattered across tools, documents, and people, the handoff gets lossy, and the battery waits.
The four big enterprise AI bets of the last four years, retrieval, copilots, fine-tuned models, and autonomous agents, look like four strategies. They are one bet: make individuals faster, assuming knowledge work is a collection of solo sprints. The Lean and DevOps literature has measured the truth for decades: the active-work share of elapsed time routinely sits below 20%. The other 80% is dead time, work waiting on context that is missing or wrong.
A 100X TOOL BUYS YOU 2%
100x
make one of ten people a hundred times faster
2%
is how much sooner the task finishes. Make all ten infinitely fast and you still cap at 20%, the entire active-work share.
What a faster desk buys the company
10 desks · active work 20% of elapsed time · speedup on a log scale
It gets worse: speeding up the desks compounds the problem. A tool that drafts memos twice as fast sends twice as many memos to the approval desk. The manager handling two hundred requests now faces four hundred. The bottleneck did not move, the firehose got turned up. The winners will not be the companies that hand every employee a faster assistant. They will be the ones that redesign the workflow around shared context, so the baton stops hitting the ground.
Friction only shows up when everything is read together. Four primitives capture it.
WHY
Root causes
The upstream drivers behind any topic you are looking at.
WHAT
Open commitments
Actions, loops, and deliverables left unresolved, across every channel.
WHERE
Friction points
The dependency halting progress because an overloaded desk does not know it is holding it.
HOW MUCH
Chase load
The repeated follow-ups it took to nudge the work forward.
What one question touches
Root cause · resolved in ~30 min across all 4 planes
“Our goal is to get to the why behind what moved, which no dashboard tells you, because the why lives across multiple structured and unstructured data sources and keeps changing in a fast-moving organization. We are seeing investigation time collapse, but more importantly we are getting to decisions and actions faster, and that raises speed across the whole org.”
02 · THE DATA IS THE MODEL
The LLM is a compiler, not an oracle.
Sentra's memory is non-parametric and symbolic: the knowledge lives in an explicit, governed ledger of facts, and the foundation model is a swappable reasoning engine that runs over it. Upgrading the model is like recompiling a codebase, not retraining an employee: run a better model back over the same record and it extracts more and catches contradictions the last one missed. Models depreciate on roughly a six-month cycle. Memory compounds. Those two should never be the same asset, and every fine-tuning pitch makes them one.
Two models of a company, property by property
Both are trained systems
What's in it
Live in eight days. Four families of record: what was said, what was filed, what was measured, what was computed. The result is not a pile of documents but a live, dense, cross-referenced state of the company, continuously reconciled for consistency, which is how it proactively surfaces contradictions nobody thought to search for, like one data stream reporting a weeks-long absence at a set of sites while another reported normal activity at the same sites on the same dates.
19B
tokens compiled since May
+1.5B
tokens added every week
~4M
atomic fact chunks
757K
resolved entities
~80K
Power BI measures
0
weights retrained
The corpus as it accumulated
May 14 → August 14 audit close · +5B tokens a month
Understanding grows with the record, not the model
Composite score · scored at deployment milestones
Who gets to know
Because the data is the model, access control is structural, not bolted on. If an employee cannot read an email, a ticket, or an accounting entry in the original system, they cannot see anything Sentra learned from it. Permissions are evaluated per fact, against the source's own grants, so the asker is an input to retrieval. There is no executive backdoor and zero privilege escalation. Leaders see their own reporting lines, and only theirs, and anyone can ask the ledger what it holds about them and get the same answer their manager would.
11,000
queries a week from employees and their agents over MCP, mostly to unblock their own work. Any agent an employee already uses can ask the company model a question, with no Sentra-specific integration.
One question, three users, three views
Illustrative supplier · fictional data
The Engram test: the training run wasn't necessary.
In August, a widely shared result argued for fine-tuning: an agent that studies a synthetic law firm into its weights beats a frontier model reading the same corpus cold. We ran Sentra on the same benchmark with no organization-specific training at all. The gap is noise, and the gap is not the finding. The finding is that the training run wasn't necessary, and the benchmark never asks who is allowed to know an answer, where it came from, or what happens when it is wrong.
70.7%
mean criteria pass for Sentra, against 70.1% for the studied model
36%
task all-pass, against 31%
65 min
from ingestion start to queryable, no training run
$0.15
per query on Gemini 2.5 Flash, against the published $0.13
Our own runs, not independently replicated. The results repo has the runs and the full argument →
03 · WHAT HAPPENED AT LENSKART
Nine of ten departments halved their stalled work in four weeks.
The initial scan, across 153 leaders at general-manager level and above, surfaced nearly 900 decisions and handoffs stalled in a single month. About six per leader. The stalls belonged to structural high-fan-in nodes, the desks that thirty different processes all route through, not to poor performers. Once those hubs surfaced, the system compiled the context needed to resolve each item and put it in front of the person holding it. The drag was workflow design, never personal competence.
From mostly wrong to mostly right, and days to minutes
18 weekly executive reviews · human-verified
Stalled dependencies, week one vs week four
Chases per week at ten department heads' desks
205.7
WEEK ONE
87.4
WEEK FOUR
9 of 10 departments cut stalled dependencies by half or more
The tenth cut theirs by 41%
Two drove theirs to near zero
WHAT THE STALLS LOOKED LIKE
A factory compliance drill: minutes of work on a missing system confirmation, stalled nearly two days. A flagship store opening: six days waiting on CAD plans for store sizing. Neither was hard. Both were small tasks sitting with someone who did not know they were on the critical path, which is what expensive stalls almost always are.
THE NEW RITUALS
Weekly reviews that judge systemic clearance instead of individual stack rankings. Focused blocker sessions with every explanation attached: sixteen items triaged in thirty minutes, complex issues resolved in about two, and in one session three critical operational gates cleared on the spot. Every department head now sees their own open queue, so downstream work moves without anyone chasing anyone.
And the control: individual use of AI products did not change across the deployment, and neither did individual work latency. No individual got more productive, but the company did, and all of it came from friction being removed at coordination.
04 · MEASURE FRICTION, NOT PRODUCTIVITY
Enterprise AI is measured backwards.
Companies count output: drafts written, emails sent, logins this week. Adoption dashboards prove that people are generating drafts. Flow time proves whether the company is moving. A friction ledger asks four things of every piece of stalled work:
01
How long did it not move, and what held it?
A pull request waiting on review. A contract waiting on legal. A store opening waiting on drawings.
02
Once it was seen, how long did it take to clear?
A bug fixed, a blocked release shipped, a disputed invoice settled.
03
What did each day cost?
A release slipped, a deal unsigned, a production line idle. The cost of delay.
04
How many pushes did it take?
Reviews re-requested, threads re-sent, meetings called to move work one desk.
Ask any AI vendor one question: where does our work experience friction?
05 · WHAT RUNS ON THE MODEL
One relay, every function.
The productionized shape
Streaming · minutes-scale sync
The model is a substrate: a current, permissioned, cited state of the company. It already powers ad hoc questions, daily digests of stalled items, root-cause analysis, weekly briefs, and role queues where leaders triage work, with reviewers querying the model directly in the middle of cadence meetings. Persistent agents are starting to work the friction term itself: assembling the approval packet before the approver opens the thread, closing loops that already resolved, keeping project state current without a status meeting.
Nothing about this is specific to retail. A legal review, a procurement cycle, a code release, a quarter close, a reorganization: each is a relay, each loses its time in the same place, and each answers to the same four questions. One compiled record of the company answers all of them, because underneath they are the same question, asked of the same reality.
The arithmetic is coming for agents too. An agent network is a relay with no tacit memory to fill handoff gaps, so ambiguity compounds hop to hop. Ten agents, each 100x faster, still hit the 20% ceiling, with ten lossy handoffs in between. Put the same agents on a compiled record of the company and the arithmetic flips: they stop being copilots without a pilot and become what clears the queue.
TL;DR
- Increasing individual productivity does not increase company productivity, because of friction at the handoffs.
- Make one of ten people 100x more productive and the task finishes only 2% sooner.
- Compile the company's own record into a governed ledger and treat the LLM as a swappable compiler.
- At Lenskart, friction fell 58% in four weeks and work sped up with no change in anyone's individual productivity.
- The same model serves every enterprise function, because every function runs the same relay.
- Without a shared model of the company, AI agents inside an enterprise will fail.
- To raise organizational output, measure friction, not individual productivity.
See where your work waits.
From first connector to a live model of the company in days, not quarters. Lenskart was in production in eight.