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
Product Update! Sturdy now integrates with Jira
We’re making it easier than ever to turn customer feedback into action while saving businesses hundreds of thousands of dollars per year. With Sturdy’s new Jira Connect, any AI-powered Signal in Sturdy can be automatically logged in Jira—helping teams capture, prioritize, and resolve issues faster than ever.
Sturdy for Jira is a Game Changer
Every team needs to know more about their customers.
Turn customer feedback into valuable Jira content automatically. Sturdy’s AI accurately detects feature requests, bug reports, and other critical product feedback. Customizable agents then deliver this context-rich intelligence to a configurable staging area in Jira with all relevant user and account details, such as segment, ARR, and more. The content is objectively summarized automatically. From there, assigning it to an epic, task, sprint, or release is just one click.
Productivity Gains that Move the Needle
Businesses are unknowingly spending hundreds of thousands of dollars per year on something as simple as manually logging Jira issues. A single customer-facing rep wastes nearly 87 hours annually on repetitive data entry—scaling up to a staggering $354,200 per year for a team of 100 reps. By integrating Sturdy’s AI-driven automation, businesses can reclaim thousands of hours, improve productivity, and reinvest those savings into growth and innovation—all while ensuring more accurate, real-time data flows into Jira effortlessly.
Align product teams with customer reality.
By centralizing AI-powered insights in Jira, Sturdy ensures that product and engineering teams get a complete, objective picture of what’s working, what’s broken, and what needs to be built—without relying on anecdotal feedback. Customer-reported issues appear in Jira moments after they happen, ensuring your product and engineering teams stay ahead of emerging trends and critical bugs—without the lag of traditional reporting.
Effortless setup, immediate impact.
Sturdy’s turnkey integration takes minutes to configure. Once connected, your team gains instant access to context-rich, structured feedback—helping you make faster, data-driven decisions that improve customer satisfaction.
Want to get started? Click the 'Schedule Demo' button at the top of the page.
Product Update! Sturdy Now Analyzes Customer Slack Channels
We’re making it easier than ever for teams to tap into the power of customer conversations. With this integration, Sturdy’s AI-driven insights—trained to spot key behaviors and trends unique to your business—are now right where your team works. That means more proactive decisions, better collaboration, and a serious productivity boost.
Here’s how Sturdy works with Slack.
- Get the right insights, right in Slack. Sturdy delivers AI-powered Signals where your team already works, flagging risks, expansion opportunities, and other key moments in real-time. No more digging through conversations—just actionable insights when you need them.
- Stay on top of every conversation. If your team works asynchronously in Slack channels, it’s easy for important feedback to get lost. Sturdy keeps you ahead by surfacing critical insights before they slip through the cracks.
- Act fast, not after the fact. Whether it’s a service risk, a feature request, or a potential upsell, Sturdy helps teams spot and respond to what matters—without disrupting their workflow.
Seamless sync with your tools. Sturdy doesn’t just stop at Slack. Insights discovered in customer Slack channels automatically flow into Jira, CSPs, CRMs, and other systems, ensuring the right teams get the right info—without extra work.
.png)
He doesn’t talk much, but when he does, you’d better listen.
He doesn’t talk much, but when he does, you’d better listen.
Quote from C-3PO, Star Wars: A New Hope
A few days ago, I spoke to a business leader, and they asked, "How would Sturdy work for customers who never contact us?"
"Do you know who those customers are?"
"No idea."
"Would you like to?"
“Dark Customers.” It is almost impossible to source this list. Your customer might be dark to five silos, and bright in just one.
(By the way, there is a little-known filter in the Accounts page of Sturdy that lets you sort by “Last Inbound.” Check it out. You can see the last time any customer sent you an inbound message.)
Let’s be fair. In a recurring-revenue business, a lack of inbound contact isn’t necessarily bad. Sometimes your customers don’t feel the need to chat with you, but they like you just the same.
But, here’s the cool thought. What should happen when a Dark Customer suddenly reaches out?
For example, Acme Corp sends an email to your CS team for the first time in 18 months. What needs to happen next?
I would want to know. So, we’re working on that. Naming such a signal is a bit tricky, if you have ideas, let us know.
Software is no longer the end product—intelligence is
The future doesn’t belong to systems that store data and automate workflows—it belongs to those that synthesize information, surface insights, and drive action.
The days of bouncing between screens, hunting for information, and manually aligning teams? Numbered.
Every day, we are getting closer to a workplace where:
-Knowledge workers won’t be glorified data entry clerks. Technology will finally do the heavy lifting, freeing them to focus on strategic work. These people will be responsible for outcomes without being encumbered by the tedium. As a result, we will need fewer people to acquire and keep our customers.
- Every team continues to work on their screen of choice, but the data they have access to will be aggregated across every system. They may be on different screens, but everyone will be on the same page. The next era is about alignment, automation, and AI-driven decision-making.
- There will be a fundamental shift in the tech business model. Businesses won’t pay for ‘seats’—they’ll pay for intelligence. The old model of software—charging for logins, licenses, and user seats—is dying. No one wants to pay for access to another tool; they want outcomes, insights, and automation that drive real impact. The solutions that deliver intelligence over any interface will define the next era of technology.
The shift is happening—those who embrace it will lead, while those who resist will be left behind. The future belongs to businesses that trade inefficiency for intelligence, that replace busywork with impact, and that empower people to think, create, and drive outcomes—not just enter data. Innovation doesn’t wait.
Usage data alone won’t predict churn
I've seen a slew of new AI companies doubling down on analyzing usage data as the silver bullet for predicting churn. It’s an attractive idea—track how often customers log in and how many features they use, and you’ll magically, often with some proprietary algorithm, you'll know who’s at risk and who’s primed for expansion.
That’s not how reality works.
Usage data alone is riddled with false positives, often creating a distorted view of account "health." A customer heavily engaging with your product isn’t necessarily satisfied—they might be struggling and frustrated. A drop in product usage doesn’t automatically signal churn risk—perhaps the customer has completed implementation and is now deriving value without needing to log in frequently.
🚨 High Usage ≠ HappinessCustomers with high usage might actually be frustrated and, therefore, a risk. Why are they opening support tickets and emailing their CSMs?Are they engaging because they love the product—or because they can’t figure something out? What are they saying? What’s the context?
⚠️ Low Usage ≠ Churn RiskThe modern technology landscape isn’t about engagement for engagement’s sake—it’s about delivering value with minimal friction. ✔️If your product makes life easier, customers shouldn’t need to use it constantly.
✔️Instead of measuring time spent, measure outcomes.
✔️Instead of chasing logins, track behaviors.This requires context—something raw usage data doesn't provide.
📉 Usage ≠ RenewalsIn SaaS, high usage doesn’t guarantee a renewal.Renewals are driven by:
✔️ Perceived value (or lack thereof)
✔️ ROI & business impact
✔️ Alignment with evolving needs
To truly predict and drive retention, track the right contextual signals like:
✔️ Contract issues
✔️ Bi-directional responsiveness and closed-loop resolutions
✔️ Budget and procurement discussions
✔️ Expansion/contraction language
✔️Change order requests
Look for specific context beyond sentiment.
🔍 No Context, Limited InsightsUsage data doesn’t explain why something is happening. Why did usage drop?
⁉️ Did the customer stop needing what you sold them, or are they trialing a competitor?
⁉️ Have users given up on your solution and found a workaround?
⁉️ Is usage dropping in specific customer segments (e.g., corporate accounts)?
You won’t find these answers in product telemetry alone.
Companies that get this wrong focus heavily on usage metrics and then wonder why their churn predictions fail.
The ones that get it right combine usage data with contextual signals—the insights that explain the "why."
Real-world signals tell you how customers feel and what they need, not just which buttons they click and how often.
If your account management strategy is built purely on tracking usage and opinions, you’re looking at a puzzle with half the pieces missing.
The Four Horsemen of Customer Churn
Our data scientists have combed through mountains of unstructured customer usage data to crack the code on proactively identifying accounts that are a churn risk. After analyzing thousands of signal combinations, we found that four key indicators—Budget Issues, Unhappiness, Value Issues, and Urgency—are the ultimate predictors of revenue risk.
Nearly every B2B tech and services company sees the same pattern: when these signals align, it’s time for action.
Hold on, what is unstructured usage data? It’s the raw, untamed data that tells you what customers are *really* doing and saying—not just what they’re willing to admit in a survey or conveyed by numbers of daily average logins (also critical but lacking context). Here are the harbingers of risk; when combined, they are what the team needs to act on right now. 🧯
1️⃣ Budget Issue: This signals a customer struggling to justify the cost, possibly due to tighter budgets or a perceived lack of value.
2️⃣ Unhappy: Customer dissatisfaction can stem from unmet expectations, unresolved issues, or lack of engagement.
3️⃣ Value Issue: If a customer doesn’t see the ROI, they’ll start questioning the worth of your service.
4️⃣ Urgent: An urgent flag indicates an immediate problem that requires rapid action. They are expressing a need to engage with a teammate now.
.png)
Improving Revenue Retention in 2025
If improving revenue retention is a key priority in FY25, here is some food for thought. If you believe data is the essential foundation for improving retention, imagine the possibilities with 50-100x more data about your customers. Here’s the thing: Every business has this customer data, but 99% of businesses are sleeping on a data set that could change their business. It’s the unstructured data that’s sitting in ticketing systems, CRMs, chat systems, surveys, and the biggest silo by volume - corporate email systems. Most of us still rely on structured data like usage, click rates, and engagement logs to gauge our customers' health. However, structured data provides only a partial view of customer behavior and revenue drivers. Unstructured data—like customer emails, chats, tickets, and calls —holds the most valuable insights that, when leveraged, will significantly improve revenue outcomes.
Why Unstructured Data is Essential for Revenue GrowthImproving Customer Retention: Unstructured data helps businesses identify early warning signs of dissatisfaction, allowing them to create proactive interventions before customers churn. Repeated mentions of poor experiences, response lags, product-related frustration, and more in call transcripts, cases, and emails indicate potential churn risks. By identifying these trends while they are trending, businesses will improve retention.
Fueling Product Innovation: Let’s face it: Our customers bought a product or service. Post-sales teams don’t develop products and are limited in what they can directly impact. Product teams need more unbiased, unfiltered contextual customer data, and they need it consistently. Unstructured data provides real-time feedback on how customers use products and services. Businesses can analyze customer feedback from multiple channels to identify recurring requests and pain points. This data fuels product innovation and informs customer-led roadmaps that lead to higher engagement rates and more profound value. Developing products that directly respond to customer feedback leads to faster adoption, better advocacy, and a competitive advantage.
Identifying Expansion Opportunities: Unstructured data reveals customer needs and preferences that structured data often overlooks. Businesses can uncover untapped expansion opportunities by analyzing email, chats, and case feedback. These insights help identify additional products or services that interest customers, leading to new upsell or cross-sell possibilities. To drive immediate improvements in revenue retention, the key isn't pouring resources into complex churn algorithms, chatbots, or traditional customer success platforms—it's being more creative with the data you're already collecting. Start listening more closely to your customers, identify the patterns in their pain points, and share this knowledge with your peers who can improve your offerings. This is the year to start thinking outside of the box.
Burton's Broken Zippers
Last year, I bought a pair of ski pants and the zipper fell out on the first chair lift. I called Burton, and they offered an exchange. New pants, first chair, same problem. Support informed me that I was required to return the pants for repair. The repairs would be completed after ski season. For the inconvenience, Burton offered me a 20% discount on my next purchase of skiwear. The next time I am in the market for skiwear that I can't wear during ski season, I will use that coupon.
I started my first business over 25 years ago. Since that day, I have lived in an almost constant state of fear that somehow, somewhere, things would get so broken that we'd treat a customer like this.
Let's be clear, no one who runs a business wants stuff like this to happen. Yet, it happens all the time.
If you run a software company, your engineering team will have usage tools and server logs to tell you when your product is "down" or running slowly. They can report which features are being used and which ones aren't. You'll learn that certain features in your product cost more to run than others, maybe because of a bad query, code, or something else. And you'll know what needs to be upgraded.
However, every time a customer contacts a business, they are "using" (or "testing") your product. If you sell ski pants, your product is ski pants, and your customer service team. If you sell software, your product is your tech and your customer service.
Yet, your customer-facing teams have very poor usage data, if any at all. Which feature of our service gets used the most (billing, success, support)? What are the common themes? Is one group working more effectively than the others? Does a team need an upgrade?
(BTW, what costs more, your AWS bill or your payroll?)
The reason your customer-facing teams don't have usage data is because this data is "unstructured," and it is everywhere. Imagine if your engineering team needed to check 50 email inboxes, 1,000 phone recordings, a CRM, and a ticket system to get your product usage statistics.
That's where your customer-facing teams are today. Until you can get answers from these systems as easily as an engineer can, you’ll continue to churn, annoy customers, and try to hire your way out of a retention problem. It won’t work.
Navigating AI Ethics
The question is no longer about whether you will use AI; it’s when. And no matter where you are on your journey, navigating the ethical implications of AI use is crucial. Ethical AI is not just a buzzword but a set of principles designed to ensure fairness, transparency, and accountability in how businesses use artificial intelligence. In the case of Sturdy, we’ve made ethical AI a core commitment. These principles guide our every move, ensuring AI benefits businesses without crossing the line into unmitigated risk.
What Is Ethical AI?
Ethical AI refers to developing and deploying AI systems that prioritize fairness, transparency, and respect for privacy. For businesses, this means using AI to make smarter decisions while ensuring that the data and technologies used do not cause harm or reinforce biases. The importance of this cannot be overstated—AI has the potential to either empower or exploit, and ethical guidelines ensure we remain on the right side of that divide.
Sturdy’s Commitment to Ethical AI
Sturdy's approach to AI revolves around several inviolable principles:
- Business-Only Data Use: Sturdy’s AI systems focus solely on improving how businesses make decisions. They don't delve into personal data or manipulate information for other purposes. The data processed by Sturdy comes from business sources like support tickets, corporate emails, or recorded calls—never from personal channels.
- No Ulterior Motives for Data: The data collected by Sturdy is knowingly provided by our customers, and the company doesn't use this data for any purpose beyond what's agreed upon. This ensures transparency and trust between the platform and its users.
- Privacy and Protection: One of the most critical aspects of Sturdy’s approach is its commitment to not allowing any entity—whether a business or government—to use its technology in ways that violate privacy. If a client were found to be doing so, Sturdy would terminate the relationship.
- No Deception: Our product is engineered to prevent deception. It never manipulates or deceives users, ensuring that the insights drawn from AI are used to enhance business practices rather than exploit loopholes.
Human Oversight and the Role of AI
At the core of Sturdy’s AI principles is the belief that AI should not replace human decision-making but augment it. Our Natural Language Classifiers (NLCs) are built to detect risks and opportunities based on the probability that a conversation indicates a particular issue. For example, when a customer complains about a "buggy" product, Sturdy’s AI might tag it as a "Bug" and label the customer as "Unhappy." However, humans remain in control—analyzing the situation and deciding the best action.
Final Thoughts
Sturdy's approach to AI exemplifies how businesses can responsibly use technology to drive growth and improve operations while safeguarding ethics. They demonstrate that AI doesn’t need to infringe on privacy or replace human decision-making. Instead, AI should be a tool that empowers teams, ensures transparency, and upholds ethical standards. Navigating the ethics of AI is not just a challenge—it’s an ongoing commitment, and Sturdy is setting a new standard for how it should be done.
You have been paywalled
(The image attached to this post is not entirely accurate but read on, and I’ll explain)
I’ve been spending a lot of time on Sturdy’s brand message lately. Part of this process entails interviewing folks from various walks of life about the current state of their businesses, their teams, and the companies they invest in.
The recurring theme: Sales Leaders aren’t having a good time right now. But you knew that already. I want to talk about what you don’t know.
After one of my interviews, I received a text with a quote by the former CEO of Swedish Airlines, Jan Carlzon.
An individual without information can’t take responsibility. An individual with information can’t help but take responsibility.
There are many different “things”’ that impact revenue: bad service, confusing products, poor response times, overselling, bug reports, price, whacky renewal processes, etc. You already knew this.
You know a lot about economic conditions, because that information is widely, and publicly available. You probably know a fair amount about “Sales Things” because your team is talking about “percent to goal” in almost every meeting, and there are a lot of discussions about what’s working and what isn’t. And, you likely review almost every deal in your pipeline.
What would happen if the opportunities in your pipeline were randomly placed in your ticket systems, CRMs, and a smattering of email inboxes? Knowing what was working with sales would get more difficult, if not impossible.
Today, the issues that affect service, product, marketing, etc., are randomly smattered across every customer-facing system in your business. The only way you “know” they happen is if someone else decides they are important enough to log or forward.
How do you get the information you need to make an impact?
Where is the information your product team needs to know?
Where is the information that your pricing team needs to know?
Where is the information that your renewals team needs to know?
If your Product Marketing Manager wants to know how their new pricing plan is working, what would inform that? A pretty good source—I’d argue the best source—of that information is sitting in emails, tickets, and call transcripts. But, if you are a Product Marketing Manager, you don’t have access to tickets, call transcripts, or customer emails.
You’ve been paywalled.
If you want to know what features to fix, there’s a data point in your Support Chatbot. When your Renewals Manager needs information on an account , they need to scroll through tickets and ask a few people, “What’s going on with this account?”
As a result, every business has smart people who rely on other people to log things, categorize things, and forward things. This is why our teams have logins to systems they seldom use - so they can find a “thing” they might need.
The irony is that the information you need to know to do your job effectively is harder to source than the information about things you can’t control.
You probably know the inflation rate. If you don’t, you can discover it in one search.
Your VP of CS probably doesn’t know “What’s the most common source of customer frustration in the last 90 days?” Why? Because that information is splashed across your business in a host of silos that VP can’t access. Imagine trying to do that job, without that answer.
Imagine if that VP could answer that question in one search, using what customers are actually saying to every person in your business.
This paywalling has made our businesses fragile and slow. The hints of the B2B slowdown were arriving at our doorsteps in emails and tickets for months. “We’re cutting costs”. “Procurement wants a discount.” Why didn’t we see this coming? Because we weren’t looking for it, and couldn’t find it.
Time to get faster, and sturdier. You have smart people who can take responsibility. Bust the paywalls and give them information they need to react and act.
Do that hard things,
Steve
