Welcome to the Sturdy Blog
News and Resources
The latest from Sturdy — product news, insights, and resources.
.png)
The Context Engine
Executive Summary
The Context Engine
The model is not the problem. In every enterprise AI deployment that has hit a production wall in 2026, the failure lives one layer down: in how data is prepared, permissioned, and delivered before the model ever begins reasoning. Model choice has become the wrong question. With Anthropic's Claude surpassing OpenAI in U.S. enterprise adoption (34.4% vs. 32.3%, Ramp AI Index, April 2026), the market has already moved on. The competition has shifted from the Reasoning Engine to the Context Engine.
While nearly every enterprise has deployed frontier models, most are paying a Hallucination Tax they cannot see on their P&L. For an organization with 1,000 knowledge workers, the 4.3 hours per employee per week spent manually verifying AI outputs (Forrester, 2025) equates to approximately $16.8 million in annual salary drain, calculated at a conservative $75 per fully-loaded hour. Multiply that across a global enterprise, and it maps to the $67.4 billion in documented AI hallucination losses recorded in 2024 alone (AllAboutAI, 2025). This is not a failure of the model. It is a failure of architecture.
This paper argues that the next phase of enterprise AI requires a Deterministic Intelligence Layer: infrastructure that normalizes, indexes, and permissions customer data before it reaches the model. Teams replacing token-heavy RAG workflows with deterministic, pre-indexed context are seeing substantial reductions in cost per task while dramatically improving retrieval precision and AI reliability. More importantly, they are crossing the Threshold of Action: the point where AI becomes trustworthy enough to move from surfacing insights to executing workflows.

Section 1
The New Benchmark: Claude's Enterprise Breakout Moment
The AI market just had its crossover moment. As of April 2026, more U.S. businesses pay for Anthropic's Claude than for any other AI model. 34.4% vs. 32.3% for OpenAI, according to the Ramp AI Index, which tracks actual spending across more than 50,000 companies. This isn't a survey about intent. It's purchasing data.
By March 2026, Anthropic was capturing 73% of first-time business AI buyers (Axios, March 2026). A year earlier, one in 25 businesses on Ramp's platform paid for Anthropic. Today, it's nearly one in three.
Enterprise buyers don't switch defaults on a whim. They switch when something is demonstrably working better for the work they actually need done.
The Model Is Not the Problem
Here is the harder truth underneath that adoption story. Despite the crossover, most enterprise AI deployments are not delivering.

Widespread adoption. Widespread underdelivery. Both things are true simultaneously.
The instinct in most organizations is to treat this as a model problem: switch providers, upgrade to the latest version, hire a prompt engineer. None of it moves the needle in any sustained way, because the model is not where the failure lives. Claude is a reasoning engine. A sophisticated one. But a reasoning engine can only reason over what it's given. And in most enterprise deployments, what's given is a mess. Fragments.
The Performance Ceiling
Every technical leader deploying Claude at scale hits the same wall. The demo works. The pilot looks promising. Then it moves toward production, and something breaks. Not catastrophically, but consistently. The AI misattributes an item to the wrong account. It summarizes a customer's history using stale data. It generates an output that sounds authoritative and requires 20 minutes of human verification before it can be trusted.
"Feed a world-class reasoning engine confident, well-structured garbage, and you get the same in return."
This is not a failure of reasoning capability. It is a failure of context architecture. The data required to generate reliable outputs, account history, communications, support activity, call transcripts, and operational metadata typically exists across fragmented systems with inconsistent normalization, disconnected permissions, and no canonical entity resolution layer tying it together.
Context Is the New Infrastructure
The companies pulling ahead in 2026 are not winning because they chose a better model. They are winning because they solved the harder problem underneath it: delivering clean, resolved, permission-aware context before the model ever begins reasoning.
- IT, Data, and Platform Engineering provide the Engine (Claude): a recurring operating expense. World-class reasoning, rented.
- RevOps, Data, and AI Teams provide the Map (the Deterministic Data Layer): a long-term asset. Customer intelligence, owned.
Claude is the current catalyst. The model market will keep moving. New releases, new providers, new pricing. What doesn't move is the underlying problem: fragmented, unresolved, improperly permissioned data. Deterministic context is the durable architecture. The organizations building it now will carry that advantage into every subsequent model generation.
Most organizations already have the engine. What they lack is the map.
Section 2
The Hallucination Tax: Why Fragmented Data Kills AI Performance
If the model isn't the problem, why are so many production-grade AI initiatives hitting a performance ceiling? The answer is the Hallucination Tax.
In 2024, hallucinations cost enterprises an estimated $67.4 billion in global losses (AllAboutAI, 2025). By early 2026, the cost has shifted from outright fabrications to "silent hallucinations": outputs that look structurally perfect but are factually untethered from the current state of the business.
For an organization with 1,000 knowledge workers, the 4.3 hours lost per person per week equates to roughly 223,600 hours of wasted annual productivity, approximately $16.8 million in annual salary drain at a conservative, fully loaded rate. It never appears on the P&L as an AI cost. It shows up as underperformance, missed forecasts, and slower deal cycles.

This forces employees to act as "Human Middleware": the bridge between fragmented systems and the AI that was supposed to make them irrelevant. This tax is the direct result of four specific architectural failure modes.
Failure Mode 1: Retrieval Precision (The Token Tax)
Standard RAG is probabilistic. It retrieves semantically similar fragments, not operational truth. When a sales leader asks, "Why did we lose this seven-figure deal?", the system may surface an old QBR deck instead of the pricing objections in email, the procurement concerns buried in Slack, the legal escalation in Jira, and the product gaps discussed in call transcripts that actually determined the outcome.
Because retrieval is imprecise, teams over-index by stuffing the context window with every possible document to ensure the right one is in there. The result: thousands of reasoning tokens spent filtering noise. A world-class reasoning engine doing the work of a search index.
Failure Mode 2: "Lost in the Middle" (Attention Drift)
Research by Liu et al. (TACL, 2024) demonstrated that accuracy on multi-document reasoning tasks drops by more than 30 percentage points when relevant information is buried in the middle of a long context window. This matters enormously in enterprise environments, where critical signals are scattered across support escalations, pricing discussions, call transcripts, Slack threads, and CRM updates. Simply increasing context size does not solve the problem. In many cases, it amplifies it by forcing the model to attend to more noise.
Failure Mode 3: The Identity Crisis (Entity Disambiguation)
In a fragmented environment, identity is a variable, not a constant. "Jane Doe" in a Zoom transcript needs to resolve to the same Jane Doe in Salesforce, Gmail, Zendesk, Slack, and the CRM activity timeline. Without deterministic entity resolution, the model is forced to infer whether those interactions belong to the same person, account, or buying committee.
Without deterministic entity resolution, the model is forced to reconstruct identity probabilistically. A support escalation tied to one stakeholder, a pricing objection raised in a sales call, and an executive concern discussed over email may be incorrectly assembled into the wrong account narrative entirely.
Failure Mode 4: The Permission Ghost (Unauthorized Surface)
This is the silent killer of enterprise AI programs. Most RAG pipelines lack Source-System Parity. If the AI retrieves a snippet from a private executive email because it was "semantically relevant" to an intern's query, the system has failed regardless of whether anyone noticed.
Incidents like EchoLeak show exactly why retrieval-layer permission enforcement matters. In late 2025, researchers demonstrated a zero-click vulnerability in Microsoft 365 Copilot that could exfiltrate sensitive data from Copilot context without user interaction. No prompt injection required. The retrieval layer was the attack surface.
For most organizations, the permission layer isn't just a technical problem. It is an organizational liability that Legal and Security will eventually force you to solve on a deadline, under pressure, after something has already gone wrong.
The Production Wall
These four failure modes create the Production Wall. A curated demo can appear remarkably accurate. But production environments are not curated. They are noisy, fragmented, and constantly changing, with critical signals distributed across emails, calls, support threads, Slack conversations, and operational systems evolving in real time.
"You cannot solve these four problems by tuning the prompt. You have to solve them by fixing the context."

Section 3
The Deterministic Intelligence Layer
To climb over the Production Wall, enterprise architecture must evolve. The solution is not a larger context window or a more complex prompt. It is a fundamental shift in how data is prepared for the model. Enter the Deterministic Intelligence Layer: infrastructure that sits between your raw data silos and Claude, acting as the architectural antidote to the four failure modes in Section 2.
The Four Pillars
1. Precision Indexing (Ending the Token Tax)
Instead of relying on similarity search alone, the context layer resolves entities, removes duplication, and prioritizes high-signal interactions before retrieval. The model receives structured operational context rather than raw fragments competing for attention.
In Sturdy-observed deployments, replacing raw context with pre-indexed, distilled payloads has reduced token consumption by 80 to 90% on comparable workflows. Results vary by source data density and baseline architecture. You stop paying for Claude to be a search filter.
2. Signal Distillation (Solving "Lost in the Middle")
Semantic Pruning strips HTML headers, Slack noise, legal footers, and the RE: FWD: RE: reply chains that bury every actual decision in 40 lines of quoted text, distilling threads into thematic buckets: Bug Reports, Feature Requests, Sentiment Shifts. The most critical insights land at the beginning of the context window, bypassing the 30-point accuracy drop documented in long-context research.
3. Deterministic Entity Resolution (Fixing the Identity Crisis)
A Global Entity Map resolves disparate naming conventions into a single, immutable Customer ID. Claude is no longer guessing whether two conversations belong to the same account. It is being told they do.
4. Parity-Enforced Permissions (Exorcising the Permission Ghost)
The retrieval layer enforces source-system permissions before context assembly, so unauthorized records are excluded from the payload sent to the model. This is not a prompt-level instruction that can be overridden or confused. It is an architectural enforcement point that sits entirely upstream of the model.
Security becomes a structural property of the architecture, not a probabilistic instruction to the model. Incidents like EchoLeak show why this distinction matters: when permission logic lives inside the prompt, the retrieval layer remains an attack surface. When it lives at the data layer, it doesn't.
Reference Implementation: Sturdy + Claude via MCP
While the merits of this architecture are clear, building it internally results in years of maintenance debt (see Section 5). Sturdy leverages the Model Context Protocol to serve as the Context Engine for Claude, normalizing, indexing, and permission-stamping your customer intelligence layer across Salesforce, Gmail, Slack, and Zendesk before Claude ever queries it.
Claude provides the Reasoning Layer. Sturdy provides the Memory and Context Layer. Together, they move an enterprise from AI that reads your business to AI that acts on it.

Section 4
What It Unlocks: From Reading to Acting
In 2026, summarization is a commodity. The competitive advantage lies in moving from AI that reads your business to AI that acts on it. This transition requires a fundamental shift in how leadership views the AI stack and who owns what.
- IT, Data, and Platform Engineering provide the Engine (Claude): recurring operating expense. World-class reasoning, rented.
- RevOps, Data, and AI Teams provide the Map (the Deterministic Data Layer): a long-term asset. Customer intelligence, owned, not rented.
When the engine has a perfect map, the Acceleration Gap closes.
RevOps: The Revenue Architect
For the RevOps leader, a deterministic layer turns fragmented operational data into active revenue signals. Instead of building static dashboards that explain why a quarter was missed, RevOps can monitor the commercial signals that actually move deals: pricing hesitation in email, procurement delays, legal friction, competitive mentions, executive disengagement, stalled next steps, and tone changes across active opportunities.
A deterministic context layer resolves those signals to the right person, account, opportunity, and timeline before AI ever reasons over them. That is what turns scattered communication into reliable revenue action.
RevOps stops being a report generator. It becomes the operating system for revenue execution: designing the logic that turns verified commercial signals into coordinated GTM action.
Sales: Instant Account Intelligence
The average sales rep spends roughly 20% of their week on pre-call research. With a deterministic layer, the account briefing is no longer a probabilistic summary. It is a verified snapshot: "The customer's last three support tickets were resolved, but they haven't yet implemented the API update discussed in the March QBR."
Product: The Automated Feedback Loop
Product managers are often the most data-rich but insight-poor employees in the company. A deterministic layer moves PMs from reading feedback to querying insights. Claude analyzes 60 days of feedback across Slack and Zendesk and, with a single prompt, generates a high-fidelity Jira ticket including exact customer quotes, impacted account IDs, and revenue at risk.
Customer Success: Proactive Triage
In CS, latency is the enemy. A deterministic layer allows Claude to perform live triage. When a customer sends a frustrated email, the AI checks contract terms and recent product usage logs before the CSM has finished reading the subject line. It presents a Context-Aware Response ready to send, grounded in verified account data.
"The model you license today is rent. The customer intelligence layer you build is equity. One gets replaced. The other compounds."
Every account signal normalized, every entity resolved, every permission enforced. That accumulates. The organizations building this layer now are building institutional memory that makes every model they run on top of it better.

Section 5
The Build vs. Buy Reality
The instinct for most sophisticated IT and data teams is to build. It is a legitimate impulse. The stack looks deceptively simple: a few API connectors, a vector database, and some chunking logic. In the demo phase, an internal build often feels like the most cost-effective path.

The Four Hidden Engineering Hurdles
1. The Normalization Treadmill
Building a connector to Salesforce is straightforward. Maintaining the logic layer that resolves entity names across Salesforce, Slack, and Zendesk as those systems' schemas evolve is a full-time engineering job. This is Semantic Drift: hundreds of developer hours consumed by maintenance rather than innovation.
2. The Permission Mapping Paradox
Mapping row-level permissions from source systems into an AI context window is one of the most complex security challenges in modern software. Most internal builds rely on prompt-level security, which fails under the weight of incidents like EchoLeak. This isn't a technical trade-off. It is an organizational liability waiting to be forced into crisis.
3. The Latency Wall
A custom RAG pipeline often takes 5 to 10 seconds to fetch and clean data. In Sturdy-observed deployments, pre-indexed deterministic retrieval consistently operates under 1 second on production data volumes, but reaching that benchmark requires specialized search infrastructure expertise that is rarely the core competency of a generalist data team building from scratch.
4. The Token Optimization Tax
Without signal distillation, internal builds routinely pass 3x to 5x more tokens than necessary. Teams save on build costs only to spend twice as much on model API costs.
Where Does Your Engineering Dollar Go?
The strategic question isn't "Can we build this?" It's "Should we own the maintenance of this?"

Competitive advantage does not live in the plumbing. No customer chooses a vendor because their AI has a better Python script for cleaning Slack data.
By offloading the Normalization Treadmill to Sturdy, organizations are promoting their engineering teams from Data Cleaners to AI Product Owners, moving their best people away from the maintenance treadmill and toward the high-value work of building AI that drives revenue.
Buy the plumbing. Build the logic. The teams doing this are shipping revenue-generating AI workflows, while their competitors are still debugging entity-resolution scripts.
Section 6
What to Do Now: The 2026 Roadmap
The Acceleration Gap is not a permanent state. It is a choice of architecture. The move is not to wait for a smarter model. The move is to fix the context. Here are four moves for leadership to take in the next 90 days.
Move 1: Audit Your Retrieval Precision, Not Your Prompts
Most teams spend the majority of their time prompt-tuning errors caused by bad data retrieval. The action: Run a Ground Truth test. Take ten complex customer queries and manually check the data fragments Claude is being fed. If more than 20% of that data is noisy, stale, or misattributed, no prompt engineering will save the deployment. You have a plumbing problem, not a reasoning problem.
Move 2: Isolate a Multi-Source Workflow
The highest ROI for a deterministic layer is found where data is most fragmented. The action: Pick a high-value, closed-loop use case where data lives in at least three systems. For example: the path from customer feedback in Slack and Zendesk to an engineering action in Jira. Solve the context problem here, and you've built a blueprint for the rest of the organization.
Move 3: Enforce Permissions at the Data Layer
Stop treating security as a probabilistic instruction. The action: Move permission enforcement out of the system prompt and into the retrieval infrastructure. Ensure the retrieval layer enforces source-system permissions before context assembly, so unauthorized records never reach the model. The Permission Ghost is exorcised structurally, not instructionally, and the organizational liability is removed before Legal ever has to get involved.
Move 4: Define Where AI Earns the Right to Act
The distance between AI that summarizes and AI that executes is a trust gap, not a technology gap. The action: Build human-in-the-loop approval gates for high-stakes actions. Drafting a renewal contract. Creating a Jira ticket. Sending a support response. Use your deterministic layer to provide the required Confidence Equity. The threshold to target is a sub-5% error rate on AI-generated drafts. That is the point at which approval gates can be safely reduced, and workflows become self-sustaining.
Traditional probabilistic RAG architectures struggle to reach this threshold consistently at enterprise scale. Because probabilistic retrieval introduces entity errors, stale data, and permission noise, error rates on complex multi-source tasks typically stabilize in the 15 to 30% range regardless of prompt quality, even with hybrid retrieval and reranking layers added on top.
A deterministic layer that resolves entities before inference, distills the signal before retrieval, and enforces permissions before the model ever sees the data is the only architecture that makes sub-5% structurally achievable, rather than an occasional lucky outcome.
In Sturdy-observed deployments, teams that reach this threshold have consistently moved to reduced-oversight approval workflows within a quarter. Results depend on workflow complexity and baseline data quality. Reaching the sub-5% Trust Threshold is the definitive signal that an organization has graduated from "AI Experiments" to a Context Engine architecture capable of autonomous action. That is the architectural line between AI that assists and AI that acts.

Conclusion
The Architectural Advantage
Frontier models will continue to improve and commoditize. The durable advantage is no longer the model itself. It is the architecture surrounding it.
The long-term value does not live in another standalone AI interface. Interfaces change too quickly. The durable layer is the operational context infrastructure beneath them.
Organizations that solve deterministic context assembly, entity resolution, permission-aware retrieval, and operational state assembly gain a compounding advantage independent of whichever model, interface, or orchestration layer dominates next year.
Organizations that solve context architecture today are building infrastructure that compounds across model generations. As interfaces evolve and models improve, the operational context layer beneath them becomes increasingly valuable.
"The era of the Context Engine is here. Is your architecture ready for it?"
Executive Summary
The Context Engine
The model is not the problem. In every enterprise AI deployment that has hit a production wall in 2026, the failure lives one layer down: in how data is prepared, permissioned, and delivered before the model ever begins reasoning. Model choice has become the wrong question. With Anthropic's Claude surpassing OpenAI in U.S. enterprise adoption (34.4% vs. 32.3%, Ramp AI Index, April 2026), the market has already moved on. The competition has shifted from the Reasoning Engine to the Context Engine.
While nearly every enterprise has deployed frontier models, most are paying a Hallucination Tax they cannot see on their P&L. For an organization with 1,000 knowledge workers, the 4.3 hours per employee per week spent manually verifying AI outputs (Forrester, 2025) equates to approximately $16.8 million in annual salary drain, calculated at a conservative $75 per fully-loaded hour. Multiply that across a global enterprise, and it maps to the $67.4 billion in documented AI hallucination losses recorded in 2024 alone (AllAboutAI, 2025). This is not a failure of the model. It is a failure of architecture.
This paper argues that the next phase of enterprise AI requires a Deterministic Intelligence Layer: infrastructure that normalizes, indexes, and permissions customer data before it reaches the model. Teams replacing token-heavy RAG workflows with deterministic, pre-indexed context are seeing substantial reductions in cost per task while dramatically improving retrieval precision and AI reliability. More importantly, they are crossing the Threshold of Action: the point where AI becomes trustworthy enough to move from surfacing insights to executing workflows.

Section 1
The New Benchmark: Claude's Enterprise Breakout Moment
The AI market just had its crossover moment. As of April 2026, more U.S. businesses pay for Anthropic's Claude than for any other AI model. 34.4% vs. 32.3% for OpenAI, according to the Ramp AI Index, which tracks actual spending across more than 50,000 companies. This isn't a survey about intent. It's purchasing data.
By March 2026, Anthropic was capturing 73% of first-time business AI buyers (Axios, March 2026). A year earlier, one in 25 businesses on Ramp's platform paid for Anthropic. Today, it's nearly one in three.
Enterprise buyers don't switch defaults on a whim. They switch when something is demonstrably working better for the work they actually need done.
The Model Is Not the Problem
Here is the harder truth underneath that adoption story. Despite the crossover, most enterprise AI deployments are not delivering.

Widespread adoption. Widespread underdelivery. Both things are true simultaneously.
The instinct in most organizations is to treat this as a model problem: switch providers, upgrade to the latest version, hire a prompt engineer. None of it moves the needle in any sustained way, because the model is not where the failure lives. Claude is a reasoning engine. A sophisticated one. But a reasoning engine can only reason over what it's given. And in most enterprise deployments, what's given is a mess. Fragments.
The Performance Ceiling
Every technical leader deploying Claude at scale hits the same wall. The demo works. The pilot looks promising. Then it moves toward production, and something breaks. Not catastrophically, but consistently. The AI misattributes an item to the wrong account. It summarizes a customer's history using stale data. It generates an output that sounds authoritative and requires 20 minutes of human verification before it can be trusted.
"Feed a world-class reasoning engine confident, well-structured garbage, and you get the same in return."
This is not a failure of reasoning capability. It is a failure of context architecture. The data required to generate reliable outputs, account history, communications, support activity, call transcripts, and operational metadata typically exists across fragmented systems with inconsistent normalization, disconnected permissions, and no canonical entity resolution layer tying it together.
Context Is the New Infrastructure
The companies pulling ahead in 2026 are not winning because they chose a better model. They are winning because they solved the harder problem underneath it: delivering clean, resolved, permission-aware context before the model ever begins reasoning.
- IT, Data, and Platform Engineering provide the Engine (Claude): a recurring operating expense. World-class reasoning, rented.
- RevOps, Data, and AI Teams provide the Map (the Deterministic Data Layer): a long-term asset. Customer intelligence, owned.
Claude is the current catalyst. The model market will keep moving. New releases, new providers, new pricing. What doesn't move is the underlying problem: fragmented, unresolved, improperly permissioned data. Deterministic context is the durable architecture. The organizations building it now will carry that advantage into every subsequent model generation.
Most organizations already have the engine. What they lack is the map.
Section 2
The Hallucination Tax: Why Fragmented Data Kills AI Performance
If the model isn't the problem, why are so many production-grade AI initiatives hitting a performance ceiling? The answer is the Hallucination Tax.
In 2024, hallucinations cost enterprises an estimated $67.4 billion in global losses (AllAboutAI, 2025). By early 2026, the cost has shifted from outright fabrications to "silent hallucinations": outputs that look structurally perfect but are factually untethered from the current state of the business.
For an organization with 1,000 knowledge workers, the 4.3 hours lost per person per week equates to roughly 223,600 hours of wasted annual productivity, approximately $16.8 million in annual salary drain at a conservative, fully loaded rate. It never appears on the P&L as an AI cost. It shows up as underperformance, missed forecasts, and slower deal cycles.

This forces employees to act as "Human Middleware": the bridge between fragmented systems and the AI that was supposed to make them irrelevant. This tax is the direct result of four specific architectural failure modes.
Failure Mode 1: Retrieval Precision (The Token Tax)
Standard RAG is probabilistic. It retrieves semantically similar fragments, not operational truth. When a sales leader asks, "Why did we lose this seven-figure deal?", the system may surface an old QBR deck instead of the pricing objections in email, the procurement concerns buried in Slack, the legal escalation in Jira, and the product gaps discussed in call transcripts that actually determined the outcome.
Because retrieval is imprecise, teams over-index by stuffing the context window with every possible document to ensure the right one is in there. The result: thousands of reasoning tokens spent filtering noise. A world-class reasoning engine doing the work of a search index.
Failure Mode 2: "Lost in the Middle" (Attention Drift)
Research by Liu et al. (TACL, 2024) demonstrated that accuracy on multi-document reasoning tasks drops by more than 30 percentage points when relevant information is buried in the middle of a long context window. This matters enormously in enterprise environments, where critical signals are scattered across support escalations, pricing discussions, call transcripts, Slack threads, and CRM updates. Simply increasing context size does not solve the problem. In many cases, it amplifies it by forcing the model to attend to more noise.
Failure Mode 3: The Identity Crisis (Entity Disambiguation)
In a fragmented environment, identity is a variable, not a constant. "Jane Doe" in a Zoom transcript needs to resolve to the same Jane Doe in Salesforce, Gmail, Zendesk, Slack, and the CRM activity timeline. Without deterministic entity resolution, the model is forced to infer whether those interactions belong to the same person, account, or buying committee.
Without deterministic entity resolution, the model is forced to reconstruct identity probabilistically. A support escalation tied to one stakeholder, a pricing objection raised in a sales call, and an executive concern discussed over email may be incorrectly assembled into the wrong account narrative entirely.
Failure Mode 4: The Permission Ghost (Unauthorized Surface)
This is the silent killer of enterprise AI programs. Most RAG pipelines lack Source-System Parity. If the AI retrieves a snippet from a private executive email because it was "semantically relevant" to an intern's query, the system has failed regardless of whether anyone noticed.
Incidents like EchoLeak show exactly why retrieval-layer permission enforcement matters. In late 2025, researchers demonstrated a zero-click vulnerability in Microsoft 365 Copilot that could exfiltrate sensitive data from Copilot context without user interaction. No prompt injection required. The retrieval layer was the attack surface.
For most organizations, the permission layer isn't just a technical problem. It is an organizational liability that Legal and Security will eventually force you to solve on a deadline, under pressure, after something has already gone wrong.
The Production Wall
These four failure modes create the Production Wall. A curated demo can appear remarkably accurate. But production environments are not curated. They are noisy, fragmented, and constantly changing, with critical signals distributed across emails, calls, support threads, Slack conversations, and operational systems evolving in real time.
"You cannot solve these four problems by tuning the prompt. You have to solve them by fixing the context."

Section 3
The Deterministic Intelligence Layer
To climb over the Production Wall, enterprise architecture must evolve. The solution is not a larger context window or a more complex prompt. It is a fundamental shift in how data is prepared for the model. Enter the Deterministic Intelligence Layer: infrastructure that sits between your raw data silos and Claude, acting as the architectural antidote to the four failure modes in Section 2.
The Four Pillars
1. Precision Indexing (Ending the Token Tax)
Instead of relying on similarity search alone, the context layer resolves entities, removes duplication, and prioritizes high-signal interactions before retrieval. The model receives structured operational context rather than raw fragments competing for attention.
In Sturdy-observed deployments, replacing raw context with pre-indexed, distilled payloads has reduced token consumption by 80 to 90% on comparable workflows. Results vary by source data density and baseline architecture. You stop paying for Claude to be a search filter.
2. Signal Distillation (Solving "Lost in the Middle")
Semantic Pruning strips HTML headers, Slack noise, legal footers, and the RE: FWD: RE: reply chains that bury every actual decision in 40 lines of quoted text, distilling threads into thematic buckets: Bug Reports, Feature Requests, Sentiment Shifts. The most critical insights land at the beginning of the context window, bypassing the 30-point accuracy drop documented in long-context research.
3. Deterministic Entity Resolution (Fixing the Identity Crisis)
A Global Entity Map resolves disparate naming conventions into a single, immutable Customer ID. Claude is no longer guessing whether two conversations belong to the same account. It is being told they do.
4. Parity-Enforced Permissions (Exorcising the Permission Ghost)
The retrieval layer enforces source-system permissions before context assembly, so unauthorized records are excluded from the payload sent to the model. This is not a prompt-level instruction that can be overridden or confused. It is an architectural enforcement point that sits entirely upstream of the model.
Security becomes a structural property of the architecture, not a probabilistic instruction to the model. Incidents like EchoLeak show why this distinction matters: when permission logic lives inside the prompt, the retrieval layer remains an attack surface. When it lives at the data layer, it doesn't.
Reference Implementation: Sturdy + Claude via MCP
While the merits of this architecture are clear, building it internally results in years of maintenance debt (see Section 5). Sturdy leverages the Model Context Protocol to serve as the Context Engine for Claude, normalizing, indexing, and permission-stamping your customer intelligence layer across Salesforce, Gmail, Slack, and Zendesk before Claude ever queries it.
Claude provides the Reasoning Layer. Sturdy provides the Memory and Context Layer. Together, they move an enterprise from AI that reads your business to AI that acts on it.

Section 4
What It Unlocks: From Reading to Acting
In 2026, summarization is a commodity. The competitive advantage lies in moving from AI that reads your business to AI that acts on it. This transition requires a fundamental shift in how leadership views the AI stack and who owns what.
- IT, Data, and Platform Engineering provide the Engine (Claude): recurring operating expense. World-class reasoning, rented.
- RevOps, Data, and AI Teams provide the Map (the Deterministic Data Layer): a long-term asset. Customer intelligence, owned, not rented.
When the engine has a perfect map, the Acceleration Gap closes.
RevOps: The Revenue Architect
For the RevOps leader, a deterministic layer turns fragmented operational data into active revenue signals. Instead of building static dashboards that explain why a quarter was missed, RevOps can monitor the commercial signals that actually move deals: pricing hesitation in email, procurement delays, legal friction, competitive mentions, executive disengagement, stalled next steps, and tone changes across active opportunities.
A deterministic context layer resolves those signals to the right person, account, opportunity, and timeline before AI ever reasons over them. That is what turns scattered communication into reliable revenue action.
RevOps stops being a report generator. It becomes the operating system for revenue execution: designing the logic that turns verified commercial signals into coordinated GTM action.
Sales: Instant Account Intelligence
The average sales rep spends roughly 20% of their week on pre-call research. With a deterministic layer, the account briefing is no longer a probabilistic summary. It is a verified snapshot: "The customer's last three support tickets were resolved, but they haven't yet implemented the API update discussed in the March QBR."
Product: The Automated Feedback Loop
Product managers are often the most data-rich but insight-poor employees in the company. A deterministic layer moves PMs from reading feedback to querying insights. Claude analyzes 60 days of feedback across Slack and Zendesk and, with a single prompt, generates a high-fidelity Jira ticket including exact customer quotes, impacted account IDs, and revenue at risk.
Customer Success: Proactive Triage
In CS, latency is the enemy. A deterministic layer allows Claude to perform live triage. When a customer sends a frustrated email, the AI checks contract terms and recent product usage logs before the CSM has finished reading the subject line. It presents a Context-Aware Response ready to send, grounded in verified account data.
"The model you license today is rent. The customer intelligence layer you build is equity. One gets replaced. The other compounds."
Every account signal normalized, every entity resolved, every permission enforced. That accumulates. The organizations building this layer now are building institutional memory that makes every model they run on top of it better.

Section 5
The Build vs. Buy Reality
The instinct for most sophisticated IT and data teams is to build. It is a legitimate impulse. The stack looks deceptively simple: a few API connectors, a vector database, and some chunking logic. In the demo phase, an internal build often feels like the most cost-effective path.

The Four Hidden Engineering Hurdles
1. The Normalization Treadmill
Building a connector to Salesforce is straightforward. Maintaining the logic layer that resolves entity names across Salesforce, Slack, and Zendesk as those systems' schemas evolve is a full-time engineering job. This is Semantic Drift: hundreds of developer hours consumed by maintenance rather than innovation.
2. The Permission Mapping Paradox
Mapping row-level permissions from source systems into an AI context window is one of the most complex security challenges in modern software. Most internal builds rely on prompt-level security, which fails under the weight of incidents like EchoLeak. This isn't a technical trade-off. It is an organizational liability waiting to be forced into crisis.
3. The Latency Wall
A custom RAG pipeline often takes 5 to 10 seconds to fetch and clean data. In Sturdy-observed deployments, pre-indexed deterministic retrieval consistently operates under 1 second on production data volumes, but reaching that benchmark requires specialized search infrastructure expertise that is rarely the core competency of a generalist data team building from scratch.
4. The Token Optimization Tax
Without signal distillation, internal builds routinely pass 3x to 5x more tokens than necessary. Teams save on build costs only to spend twice as much on model API costs.
Where Does Your Engineering Dollar Go?
The strategic question isn't "Can we build this?" It's "Should we own the maintenance of this?"

Competitive advantage does not live in the plumbing. No customer chooses a vendor because their AI has a better Python script for cleaning Slack data.
By offloading the Normalization Treadmill to Sturdy, organizations are promoting their engineering teams from Data Cleaners to AI Product Owners, moving their best people away from the maintenance treadmill and toward the high-value work of building AI that drives revenue.
Buy the plumbing. Build the logic. The teams doing this are shipping revenue-generating AI workflows, while their competitors are still debugging entity-resolution scripts.
Section 6
What to Do Now: The 2026 Roadmap
The Acceleration Gap is not a permanent state. It is a choice of architecture. The move is not to wait for a smarter model. The move is to fix the context. Here are four moves for leadership to take in the next 90 days.
Move 1: Audit Your Retrieval Precision, Not Your Prompts
Most teams spend the majority of their time prompt-tuning errors caused by bad data retrieval. The action: Run a Ground Truth test. Take ten complex customer queries and manually check the data fragments Claude is being fed. If more than 20% of that data is noisy, stale, or misattributed, no prompt engineering will save the deployment. You have a plumbing problem, not a reasoning problem.
Move 2: Isolate a Multi-Source Workflow
The highest ROI for a deterministic layer is found where data is most fragmented. The action: Pick a high-value, closed-loop use case where data lives in at least three systems. For example: the path from customer feedback in Slack and Zendesk to an engineering action in Jira. Solve the context problem here, and you've built a blueprint for the rest of the organization.
Move 3: Enforce Permissions at the Data Layer
Stop treating security as a probabilistic instruction. The action: Move permission enforcement out of the system prompt and into the retrieval infrastructure. Ensure the retrieval layer enforces source-system permissions before context assembly, so unauthorized records never reach the model. The Permission Ghost is exorcised structurally, not instructionally, and the organizational liability is removed before Legal ever has to get involved.
Move 4: Define Where AI Earns the Right to Act
The distance between AI that summarizes and AI that executes is a trust gap, not a technology gap. The action: Build human-in-the-loop approval gates for high-stakes actions. Drafting a renewal contract. Creating a Jira ticket. Sending a support response. Use your deterministic layer to provide the required Confidence Equity. The threshold to target is a sub-5% error rate on AI-generated drafts. That is the point at which approval gates can be safely reduced, and workflows become self-sustaining.
Traditional probabilistic RAG architectures struggle to reach this threshold consistently at enterprise scale. Because probabilistic retrieval introduces entity errors, stale data, and permission noise, error rates on complex multi-source tasks typically stabilize in the 15 to 30% range regardless of prompt quality, even with hybrid retrieval and reranking layers added on top.
A deterministic layer that resolves entities before inference, distills the signal before retrieval, and enforces permissions before the model ever sees the data is the only architecture that makes sub-5% structurally achievable, rather than an occasional lucky outcome.
In Sturdy-observed deployments, teams that reach this threshold have consistently moved to reduced-oversight approval workflows within a quarter. Results depend on workflow complexity and baseline data quality. Reaching the sub-5% Trust Threshold is the definitive signal that an organization has graduated from "AI Experiments" to a Context Engine architecture capable of autonomous action. That is the architectural line between AI that assists and AI that acts.

Conclusion
The Architectural Advantage
Frontier models will continue to improve and commoditize. The durable advantage is no longer the model itself. It is the architecture surrounding it.
The long-term value does not live in another standalone AI interface. Interfaces change too quickly. The durable layer is the operational context infrastructure beneath them.
Organizations that solve deterministic context assembly, entity resolution, permission-aware retrieval, and operational state assembly gain a compounding advantage independent of whichever model, interface, or orchestration layer dominates next year.
Organizations that solve context architecture today are building infrastructure that compounds across model generations. As interfaces evolve and models improve, the operational context layer beneath them becomes increasingly valuable.
"The era of the Context Engine is here. Is your architecture ready for it?"
Our articles

Video: Sturdy featured on CS Insider
Our customers are telling us what they want and need every day - with nearly every message. Customers give us information to run our businesses better, predict churn, capture references, get in front of renewals, prioritize features, and more. Until now this data has been trapped and left to decay in dozens, if not hundreds of data silos.
This week SturdyAI is in the spotlight at CS Insider, a community comprised of all things customer success, curated for busy professionals. In this short video, we walk through how SturdyAI is helping businesses detect signals that empower teams to preempt risks and discover opportunities that impact the bottom line.
Highlights
- Analyze customer communication channels like tickets, email, chat, and voice for valuable insights.
- Accelerate data into action so stakeholders can quickly act on what’s most urgent.
- Tap into and leverage a valuable new data set that you’re likely ignoring today.
Interested in finding what's hiding in your customer communication data? Get in touch with us.

Sturdy announces Slack integration
Slack has become the de facto tool for internal communications for many teams. By shifting internal communications out of inboxes and into channels, teams can work more collaboratively while reacting to critical issues in real-time. This is why we are excited to announce that SturdyAI is now integrated with Slack. Now teams that rely on Slack to collaborate can create custom channels to receive important signals from SturdyAI.
For those less familiar with SturdyAI, we’ve built a product that analyzes business language(support tickets, emails, customer chat sessions, video and phone call transcriptions, etc.) for important signals that impact the bottom line. For example, when a user asks, “Can I have a copy of our contract?” in a support ticket, our product instantly recognizes this as a potential cancellation signal, flags it, and alerts the team in charge of triaging accounts. Today, our AI today recognizes 7 distinct signals, with dozens more currently in development. And the cherry on top is that SturdyAI gets smarter with every message.
Here’s how it works.
Step 1
First, a customer communicates with their vendor via email, support ticket, chat or recorded call. Below is an example of a ticket submitted through a ticketing system.

Step 2
Next, SturdyAI ingests and analyzes the ticket in real-time looking for important signals. In this ticket, there is a critical issue. The customer, Brightlight, is asking for a copy of their contract. This is a clear signal that this customer may be at risk. Furthermore, the customer is indicating that they have purchased a product that may have similar features reinforcing the urgency of this message. Below is the original ticket that SturdyAI analyzed and applied the Strong Churn signal.

Step 3
Now that SturdyAI is integrated with Slack, critical signals are “chirped” into Slack channels. SturdyAI’s customers create their own Slack channels to receive critical signals. Integrating SturdyAI takes minutes. When SturdyAI is integrated with Slack, critical signals are “chirped” into Slack channels. SturdyAI’s customers create their own Slack channels to receive critical signals. We've seen some great use cases already. Here are a few of our favorites.
#competitor-mentions
#customer-references
#executive-change
#feature-request
In this example, we’ve created a “Churn Alerts” channel. These customized channels provide teams and leaders with real time visibility into critical customer issues so the right people can take action before it’s too late. Below is a screenshot of our churn-alerts channel and the alert that was triggered by the original message that this customer sent about requesting a copy of their contract.

Why now?
Integrating with Slack was moved to the top of our feature roadmap as the pandemic has created new challenges for our customers related to remote operations. Less in person attendance by customer-facing teams means widening internal communication gaps at each stage of the customer lifecycle. Plus, integrating with Slack just isn't that hard. In the coming weeks, we will continue to refine the integration and, ultimately, the user experience making it easier for users of Slack to get mission-critical signals from customers in the apps that they use most.

Infographic: Creating a Self-Sustaining Customer Reference Funnel with SturdyAI
Customers willing to serve as references for your solution often make the difference between opportunities that result in closed/won or closed/lost. However, harvesting these references can be challenging, time-consuming, and resource-intensive. While critical to the bottom line, the responsibility for gathering new references often falls on marketing and product management teams who may not be as close to the individual users as their counterparts in sales, support, and customer success. This compounds the complexity of gathering new references.
While customer reference software platforms are often good at providing a go-to location to request references and to find approved reference content, they lack functionality to build a sustainable customer reference pipeline. Continuously building a pipeline of references is a key use case and value proposition for SturdyAI.
Using AI and machine learning while leveraging your existing tech stack, SturdyAI empowers customer reference teams to automatically capture authentic referenceability signals from everyday communications with your customers. It's automated lead generation for your customer reference program.


Create a self-sustaining customer reference funnel
It’s impossible to overstate the value of customer references. Whether you have $1m or $100m in ARR, when your customers demonstrate how they’re using your solutions, future customers see themselves in these examples bringing to life the value of your offerings. A strong reference from a current customer is so powerful that it can even transcend fierce competition, the norm for most of us in the rapidly maturing B2B SaaS industry.
Unfortunately, the reality is that even the most enamored customers aren't likely letting anyone else know about you. In studies from two industries, only 10% of the “promoters” in NPS surveys actually referred profitable business. Plus, executing a customer reference program takes lots of discipline and resources. For these reasons, we decided that this is a problem worth solving.
It has taken us over a year but we’ve cracked the code and productized a scalable way to harvest more customer references. Fortunately, we didn’t need to look very hard to find the signals that lead us to believe a customer is referenceable. The answers were right under our noses all along in the day to day interactions that our teams have with customers. That’s right, customers are signaling their willingness to provide references, testimonials, positive reviews and the like every day.
Here’s how it works. We’ve built technology that detects items of importance like customer references (among other things) in customer-to-business communications (email, support tickets, video conferences, etc.). For example, when a customer responds to an email or support ticket with, “I can’t thank you enough --- you just saved me so much time! You’re the best!”, Sturdy will instantly recognize this as a potential reference signal, flag it, and alert the appropriate person or team. We’ve even set up integrations with Slack and Teams so when a potential customer reference is detected, Sturdy chirps the notification right into a #customer-reference channel. Say hello to a self-sustaining customer reference funnel.

Getting started is easy.
Set up takes less than an hour for most operations / IT teams. We installed the Sturdy Salesforce.com app from the AppExchange (this is in private beta at the moment and we are accepting new users weekly here). Next, we synced our customer success and support teams’ email accounts (we use Gmail but we have an Outlook integration as well) with Sturdy’s email ingestion API. Once connected to the data sources where customers communicate with us, the rest is really easy. Time to value is a matter of days and weeks. And, there is no significant change management required. Turn it on and let the machine run. The cherry on top is that the AI gets smarter with every customer message.
1. Log into Sturdy (if you have a Slack or Teams integration you can skip step 1) and select the “Reference” signal. Sturdy will immediately surface any customer communications that contain potential references. Screenshot below.

Below is an example of a customer reference signal that I found this morning. Note that I have a privacy feature enabled here that anonymizes the data for the purposes of privacy and compliance.. In this message, Henry Goldberg is effusive in his praise for the product and the level of service provided to him.

2. Next, Sturdy alerts our customer marketing team of a new potential reference. Upon receiving this signal, our team will gather some information about the account and the user and determine what type of reference we want to ask for (peer-to-peer, review, case study, referrals, testimonial, etc) and who will make the request. Here’s another example of a customer all but volunteering to be a reference. Based on the anonymized aggregate data of our B2B SaaS customers, we've found that >1.5% of all customer communications include a customer reference signal.

3. The final step is to reach out to the customer with your “ask”. Every team is going to have some nuance here. We use a couple of different “plays”. Our favorite is the progressive / multi-step “swag+” play. When our team receives a reference signal, our CS and support teammates are empowered to ask our customers for an address where we can send a care package of swag. A few days later, we let the customer know that their Sturdy swag is on the way and then we ask if the customer would consider serving as a reference. Our success rate when using this play is nearly 100%.
Creating a self-sustaining customer reference funnel starts with consistently detecting the right signals and getting your customers’ voice to the right people at the right time. These signals are pure gold to every customer marketing team. The best part is that unlike traditional, resource -intensive customer reference strategies, Sturdy makes it virtually automatic. Turn it on and let it rip. Get a steady stream of potential customer references delivered in Slack, email or via dashboard - however you choose.
Want to get more customer references?
If this sounds interesting, our enterprise beta program is in full swing. If you are interested in creating an automated customer reference funnel, here is a link to register for our public beta program.

Net dollar retention - a SaaS metric juggernaut
The SaaS industry is still roaring towards ubiquity. Blissfully’s 2020 SaaS Trend Report notes that overall spend per organization on SaaS-based products is up 50%. However, the report also notes that this is down from previous years, and the growth rate seems to be slowing. This gradual slide has the industry turning its attention to optimizing for customer retention and leveraging existing customers for substantive growth.
Anymore, churn is just SaaS slang. Churn as a metric is confusing and ambiguous. There are too many ways to calculate customer and revenue churn. Analysts and investors have been increasingly skeptical of churn rate calculations for years. Anymore they just want a raw data dump from companies so they can run their own math.
“There are too many darn ways to calculate churn. That makes it ambiguous.” - Dave Kellogg
The focus is on net dollar retention (NDR)?
NDR has emerged as one of the top SaaS metrics that matter. NDR takes into account upgrades, downgrades, and churn to quantify how much recurring revenue from current customers you retained across a defined period of time. There are two hugely important questions that NDR can answer.
- Is your product delivering the value promised during the sale?
- Are your customers growing with you or without you?
What makes net retention so powerful is that for most companies, it’s cheaper to sell to existing customers than to sell to new logos. This makes net retention the most cost efficient way to accelerate revenue growth.
Calculating net dollar retention.
If your NDR is over 100%, this means that an increase in revenue is attributable to your existing customers. Here’s how to calculate NDR.
(Starting MRR + expansion — downgrades — churn) / Starting MRR = NDR
Let’s say you start the month at $100,000 in recurring revenue (MRR). Over the month it added $25,000 in expansion revenue, has $10,000 in downgrades and another $5000 in churn. ($100,000 + $25,000 — $10,000 — $5000)/$100,000 = 110% NDR. Your MRR is $110,000 with an NDR of 110% This is good. Essentially, your upgrades / upsells lifted your revenue despite losses.
What good looks like.
At least 100% is considered a good NDR rate for SaaS businesses selling to the SMB market. Selling to smaller accounts naturally yields a lower NDR. SMB clients are less financially stable, ripe for acquisition, and have smaller budgets. A good enterprise NDR is 130%. As with many SaaS metrics there are other things to consider. For example, Workday’s NDR is 100% but gross retention is 95%. Either Workday is very good at selling the “whole” deal or their product footprint presents limitations.
Here are some examples of net dollar retention rates for some interesting SaaS and SaaS-enabled companies.

Caring about net dollar retention.
NDR provides a revenue-based view of customer retention. NDR is increasingly important as you scale from a small to medium-size business and beyond. For example, a $5m business that churns 20% can replace that $1m with net new business when it’s growing +50% a year. But when a $30m business needs to replace $6m this becomes insurmountable especially if the growth rate is slowing.
The effects of NDR compound with time. It’s either additive or punitive with every customer that you acquire. This means that small upticks in NDR can add up to very large differences in total revenue over multiple years. For example, assume a business had $10 in revenue last year and consistently generates 20% of revenue from new customers. Improving the NDR from 95% to 105% may sound meager, but over five years the business will gain another $5m in revenue.
Lifting NDR and a plug for Sturdy as a solution to help.
How can you start identifying more opportunities to grow and deliver value? Here are two ideas that sound great in articles and when delivered by panelists at conferences. First, hire a great team of CSMs who are well enabled and know your customers intimately. Second, develop more premium services to sell your customer base. Frankly, these are right answers but they take a lot of time, resources and change management to create an enduring impact.
Now consider this. What if you had a “tool” that could analyze customer emails, tickets and conversations for important signals that are typically related to predicting churn? Maybe something that can listen for suggestions about features and products that might accelerate value capture and lift revenue? What if you could get started with such initiatives without major upfront investments in data infrastructure or change the way your teams work? We might know of such a tool. Hit us up. We’d be just as happy to talk about NDR and our experiences over the years tracking this SaaS metric juggernaut.

The deck we used to raise money for Sturdy
The idea for Sturdy was born from asking this all too common question far too many times, “What is going on with Customer X?” And many times over the years we have griped, “How is it the 21st Century and we need to get 5 different people in a room to login to 5 different apps in order to know whether a customer is happy or not?”
This is why every SaaS company has a “Top Customer List”. At Newton, our previous company that was acquired by Paycor in late 2015, we had a rule, “Whenever someone on this list contacts us for any reason, let So-and-So know.” If you think about it, such lists admit a fundamental failure of running a modern business...you only have the time and resources to listen to your most valuable customers (which means you most often ignore the rest).
This was our first slide...

Our earliest decks talked about, “getting your data in one spot”. But that wasn’t the problem we were trying to solve (wanting to see all the data in one spot is a symptom, not a solution). The problem wasn’t really a communication problem, it was a mining and refining problem. When a customer requests a copy of her contract, that message must get forwarded to the Saves Team - immediately.

Our “Aha” moment was when we realized that our customers are telling us what they want and need everyday. They give us information to run our businesses better, to predict churn, to capture references, to get in front of renewals, to prioritize features, yet this data is trapped and decaying in dozens, if not hundreds of data silos.
A big problem is that our customers are giving us this information in Slack, Email, Salesforce, Webinars, Training Sessions, Zoom calls, etc.. And the only way we utilize this information is if someone manually identifies, records and escalates it.
Remember when we said it was the 21st century? We still manually identify, capture and route feature requests. And bug reports. And cancellation requests. And sometimes this means that we don’t always see the signal, or we forget to log it, or when we route it, no one pays attention.
But these signals are immensely valuable. For example, reducing churn from 10% to 9% in a $10 million ARR business means that every customer is worth $17k more in lifetime value (500 customers, $20k annual contract value). And reducing churn in this example is just saving 5 customers.

Obviously we should do everything possible to mine our customer communications, and yet many companies know more about their anonymous website visitors than their own paying customers. Almost every company has a way to track and monitor its website visitors, and almost zero have any way to monitor and monetize the happiness of their actual customers.
Here’s a challenge...Answer this: If your company was about to lose a customer, who would be the best person to save that customer? What metrics would you use to support your answer? Most companies have no data to answer this question.
Or, how many times did a customer say, “You guys are great!” last month? How many times were those happy customers converted to references? And how many of those references are delivered to your sales team to help them close new business?
Again, it's the 21st century. Yet we have no analytic capacity or automation as it relates to customer feedback or happiness. But don’t despair. You're not alone.

We realize the challenges are great. But in this area, failure is truly unacceptable. To have a truly operationalized customer focused company, you need to mine these communications, without bias and without manual data entry. You need something that never gets tired, that doesn’t need training, and that gets better the more you grow and the more you throw at it. And most importantly, you can’t wait until the quarterly business review is complete to triage a churning customer.
And that’s why we started an AI company. But not just any AI company and not just for the sake of using AI.

We aren’t here to reinvent and change the way teams or companies work. And that is what is so exciting about what we do. Sturdy is the force multiplier for your business. If you already have a cutting edge BI tool, we just give it better data. If you have a killer CX app, we make it more insightful. If you have a great Customer Success, Account Management, Operations, Marketing, and Product teams, we make them more efficient and provide them with better data.

Sturdy is open
Sturdy has developed a BI product that analyzes customer communications, detects important signals, and empowers teams with real-time data to act on situations with speed and intelligence.
We’re thrilled to announce the launch of Sturdy, a ground-breaking business intelligence platform that leverages advanced data science in order to detect items of importance in customer-to-business communications.
In simple terms, Sturdy helps people at B2B SaaS businesses leverage a data set that is hiding in plain sight - data that your customers want you to use.
Trapped in communication layers, and across teams, are critical signals like, point of contact changes, potential references, churn likelihood, and competitor mentions. These signals gather digital dust in email accounts, ticketing systems, transcriptions, chat software, and CRMs - until Sturdy.
Customer-to-business communication data is an untapped data frontier. Massive value is realized when the data is aggregated, analyzed, refined, and redeployed. Sturdy was created to empower teams to act on mission-critical situations with speed and intelligence.
If you wanted your team to capture 10 new referenceable customers, what would need to happen? Or, how many of your customers got a new Point of Contact last month? Which customers asked for their Renewal Data this week?
As a leader you want to manage risks and capitalize on opportunities (we call them “signals”). Signals are sitting in email accounts, videoconferencing transcripts, chat logs, and buried in ticketing systems. They are manually captured, if at all, and then data-entered into spreadsheets and other systems. And you have to create, enforce and constantly train people on rules that change the way your teams work.
Not to mention, there is no analytical capacity.
The idea for Sturdy came from building, bootstrapping, and scaling successful SaaS businesses. We founded SturdyAI to empower businesses to solve problems that we faced as entrepreneurs and executives. Before SturdyAI, the capture of these signals has been inconsistent, fragile and inefficient.
We’re experienced executives and engineers. We believe that every business has revenue and earnings potential trapped inside of its communications systems.
In mid-2020, Sturdy received an investment from Super{set}, a team that has created $1.2b in exits. This accelerated our product development and commercial efforts. Partnering with Super{set} was natural. We share the belief that “data is the new oil” and that refining data defines the new basis of competition across sectors and problem spaces.
Many of us worked together at Newton Software. This is a company that we bootstrapped, scaled and sold to Paycor, one of the largest independent HCM companies in the world. At Newton, we lived by some simple rules. We live by these rules at Sturdy.
- If you make a mistake, tell someone right away. We’ll fix it.
- We design technology that we want to use.
- We sell software how we’d want to buy it.
- We support our software the way we would want to be supported.
- We do things the right way, not the easy way.
- We don’t take shortcuts.
We’re energized and ready to roll. Let’s talk.
We’re encouraged by the feedback and results from early customers using Sturdy. And, we’re fired up to help businesses preempt customer issues before they spiral and seize revenue opportunities in time to improve this quarter’s results.
What will you find in your data?
Click here to get access and see for yourself.

Your customers are already telling you what's going to happen.
Connect what customers say to why your numbers move. Contextual revenueintelligence, ready for any LLM — or running natively in Ask Sturdy from day one.
