A Product and Operating Framework for the Next Generation of Enterprise Software
Most companies today are approaching AI the wrong way.
They are experimenting with isolated use cases. A chatbot here, a summarization workflow there, an AI assistant layered onto existing software, or a collection of disconnected copilots spread across the organization. Some of these projects create value. Many do not. But the larger problem is structural.
Most organizations are treating AI as a feature layer, when AI fundamentally changes how software systems, operational workflows, and organizational intelligence should be designed. The companies that ultimately win with AI will not simply have better prompts or larger model budgets. They will build richer operational intelligence systems, tighter feedback loops, continuously evolving semantic and workflow layers, and AI-native workflows that systematically capture and improve organizational knowledge over time.
The long-term advantage will not come from AI alone. It will come from building systems that continuously compound intelligence.
Over the last several years at Perch, we have been building AI-native analytical systems for large-scale sales, service, and contact center organizations. This work forced us to rethink many assumptions about product design, analytics, operational systems, and AI itself. What follows are the most important lessons we have learned so far.
1. The Biggest AI Failure Mode: Isolated Use Cases Without an Intelligence Foundation
The most common mistake organizations make is treating AI as a collection of disconnected features. Each initiative, automating call summaries, generating dashboards, building a chatbot, layering AI onto support tickets, may make sense in isolation. But without a shared intelligence foundation underneath, the organization eventually hits the same wall: inconsistent definitions, fragmented context, brittle workflows, duplicated logic, poor explainability, and AI systems that cannot reason consistently across the business.
We learned this repeatedly building Perch. At first glance, many operational problems appear to be analytics problems. The deeper issue is almost always that the underlying operational systems were never designed to support structured reasoning in the first place. CRMs, dialers, CCaaS systems, workforce tools, and marketing platforms capture activity, but they do not encode customer journeys, operational workflows, decision frameworks, causal relationships, or the semantics required for reliable analysis and AI reasoning.
Even basic terms like contact rate, conversion, active lead, opportunity, save, and retention risk often mean different things across teams, systems, and workflows. Without a shared semantic and operational foundation, AI systems cannot reliably reason about the business.
This is why we became increasingly focused on building more than AI features. We built customer journey models, semantic layers, operational ontologies, analytical frameworks, workflow intelligence, and continuously evolving business context systems. The AI sits on top of these layers. The real leverage comes from the intelligence infrastructure underneath.
2. Compounding Intelligence Requires an Agentic System to Manage It
The real competitive advantage in AI comes from proprietary operational data, workflow intelligence, semantic structures, organizational memory, feedback loops, and continuously evolving ontologies that capture how the business actually operates.
The real moat is not the model. The moat is the accumulated operational intelligence surrounding the model.
But this intelligence cannot remain static. Businesses evolve constantly. Outreach strategies change, compensation structures change, staffing models change, organizational structures change, products change, market conditions change, and new operational edge cases emerge all the time. If the intelligence system does not evolve alongside the business, the AI gradually becomes less useful and less accurate. A static knowledge layer does not just stop adding value. It actively misleads, because it confidently applies yesterday's assumptions to today's reality.
This became a major design principle behind our knowledge management platform, built to continuously codify operational and analytical intelligence into the system. Initially, we thought the primary challenge was automating analysis. Over time, we realized the much bigger challenge, and the much bigger opportunity, was continuously building and maintaining a structured understanding of how businesses operate. That process itself became an AI system.
The platform continuously ingests and synthesizes signals from across the operational environment: product usage and analytical workflows, user interactions with the AI system, recurring investigations and monitoring patterns, analyst feedback and corrections, client conversations and meeting transcripts, onboarding sessions, operational playbooks, configuration changes, and evolving workflow definitions.
Here is the insight most AI product thinking misses. Managing a continuously evolving intelligence layer is itself an agentic problem. The signals that require updates arrive from dozens of sources simultaneously: analyst corrections mid-session, onboarding call transcripts, schema changes in source systems, configuration edits, recurring monitoring patterns that reveal unstated assumptions, client conversations that surface new operational context. Routing each signal to the right layer of the ontology, checking it against prior assumptions for conflicts, deciding whether to propagate an update or surface it for human review, preserving lineage so you know why a rule exists. That is not a workflow a human team can run at the velocity a live system requires.
This also clarifies an important architectural distinction. The agent managing the intelligence layer is doing a fundamentally different job than the agent answering analytical questions. The analyst agent is a reasoning agent. Its job is to answer why contact rate dropped this week. The knowledge management agent's job is to answer what should be updated, in which layer, given what was just learned, and whether it conflicts with anything already known. Most AI product architectures either collapse these two roles or ignore the second one entirely. Separating them turns out to matter enormously, because the failure modes are completely different and the humans who need to review and approve outputs are different too.
Over time, the system compounds. Workflows become smarter. Benchmark models improve. Operational edge cases become encoded. Organizational memory deepens. The AI system becomes increasingly aligned with how the business truly operates. That compounding operational intelligence is ultimately far more defensible than the underlying model itself.
The diagram below illustrates the core architecture of an AI system built to compound intelligence. It is deliberately generalized. The structural relationships hold across domains, but the specific agents, knowledge layers, ontology models, and workflow definitions within each zone are where the real implementation work happens, and where platforms differentiate.
3. Capturing Tribal Knowledge Is a Product Design Problem
A major shift in AI product design is that software now needs to systematically capture human reasoning itself.
Much of an organization's most valuable operational intelligence has never been written down. It lives in meetings, in analyst workflows, in manager judgment, in the decisions experts make so quickly they cannot fully explain them. A senior contact center analyst looking at a close rate dip does not consciously walk through a checklist. They scan five dimensions in a specific sequence that took years to develop, and they do it faster than they could narrate it. That instinct is real, it is valuable, and traditional software systems are completely blind to it.
AI changes the economics of capturing this knowledge. But here is something we learned that is not obvious. Experts often cannot accurately articulate their own expertise when asked directly. Human introspection degrades at the micro-decision level. When you ask someone to explain why they looked at lead source before agent performance, they will give you a reasonable-sounding answer that may not reflect what actually drove the decision. The stated reasoning is a reconstruction, not a recording.
What does capture the underlying reasoning system is behavioral evidence: the actual sequence of pivots, the dimensions checked in order, the filters applied without explanation, the corrections made when an AI gets it wrong. These behavioral traces encode expert reasoning in ways that direct questioning cannot fully surface.
This has real product design implications. The systems that win will be designed to observe how experts actually navigate and investigate data, not just to ask them how they do it. At Perch, we instrument joint analysis sessions between senior and junior analysts, moments where explanations are already being produced for a human audience, and use those conversations as structured inputs to the system. The product opportunity is being present in knowledge transfer moments that already exist, rather than creating new ones.
We also found that some of the most important operational nuances were things experts never thought to mention because they seemed obvious. Why a dialer migration invalidated year-over-year contact rate comparisons. Why deadline-driven enrollment psychology at an education client makes standard seasonality assumptions break down. Why certain cohorts at a home services client behave differently because of how lead assignment works. None of this was documented. All of it is now encoded as permanent analytical guardrails in the system.
The goal is no longer just usability. It is continuously teaching the system how the organization thinks.
4. Trust Is Infrastructure, Not a Feature
One topic comes up in every client conversation about AI: trust. Most AI discussions frame trust as a compliance problem, with governance policies, audit trails, and explainability requirements layered on top of a deployed system. In practice, trust is an operational requirement. AI systems fail in use when people cannot validate outputs, understand the reasoning, inspect the evidence, reproduce conclusions, or identify uncertainty.
Humans themselves are not inherently trusted inside organizations. Analysts, managers, and operators all work within review systems, approval chains, and validation workflows. A large percentage of enterprise analysis is, in effect, trust-building infrastructure around prior decisions. AI systems are no different. The question is not whether to build trust infrastructure. It is whether to build it intentionally or let it break down in production.
The companies that succeed with AI design trust directly into the product. At Perch, every insight the analyst agent produces has to clear what we internally call the believability rules. Every performance claim must reference a baseline, such as contact rate is 51.3%, down from 56.4% last month and below the 55% target, rather than a number in isolation. Every finding must state magnitude in business terms, such as a 1-point close rate decline on 6,955 opportunities represents approximately 70 lost sales, rather than a directional signal alone. Every directional finding must explicitly flag uncertainty when data is partial or volume is low. And the system must distinguish confirmed root causes, where the driver has been traced through the data, from hypothesized ones, where it has not.
These rules exist because we learned the hard way that an AI insight without a baseline, a magnitude, and a confidence level is not actually an insight. It is a guess that looks confident. Analysts will not act on guesses. They will act on findings they can defend in a meeting.
The same logic applies to how the system learns. When the analyst agent observes a pattern that should permanently change how a client's analyses are run, it does not silently update the rule. It proposes the update, routes it to an analyst for confirmation, and only writes it into the client's permanent diagnostic graph after approval. The AI is allowed to learn. It is not allowed to learn unilaterally. That distinction turns out to matter enormously for whether operators trust the system over time.
5. Building AI Systems Requires a Different Kind of Product Leadership
One of the most important lessons from building AI systems is that the product function has to operate differently. Not just incrementally differently, but structurally differently.
In traditional software, product, domain, and engineering could operate largely in sequence. Product defined requirements, engineering built to spec, QA validated behavior, and the system shipped. That worked because the logic was deterministic. If you tested it, you knew what it would do.
AI systems break that model in several ways.
The system is probabilistic and cannot be fully tested before production. You can validate in staging, but you cannot fully anticipate how a probabilistic system will behave across the distribution of real inputs, real users, and real edge cases. The only environment where the system actually compounds is production. That means the bias has to shift toward deploying to a sub-segment of real users early and iterating fast, treating production as the primary learning environment rather than the final destination. Product has to be comfortable operating that way, and has to build the evaluation criteria and success metrics that make fast iteration disciplined rather than chaotic.
Engineering can move faster than ever, which means product is now the bottleneck. AI-assisted development has fundamentally shifted where execution slows down. The constraint is no longer engineering capacity. It is product judgment: what to build, in what sequence, how to evaluate whether it is working, and what good looks like in a probabilistic system. Product has to keep pace with that speed or become the drag on the organization.
The intelligence layer degrades by default. Classical software does not handle inputs it was not built for. It errors, crashes, or produces null outputs. AI systems can be worse. They handle unfamiliar inputs confidently and produce plausible-sounding results that are simply wrong. As the business evolves, as workflows change, source systems change, and org structures change, the intelligence layer silently drifts out of alignment with reality. This makes ongoing knowledge and requirements management a permanent product function rather than a one-time setup. Someone has to own the continuous work of keeping the intelligence layer accurate as the world changes underneath it.
UX is now an intelligence extraction system, not just a task completion interface. Every correction an operator makes, every escalation, every override is a signal about where the system's reasoning fails. Good product design builds the right friction to capture those signals systematically, through structured review flows, correction mechanisms, and approval chains, because those moments of human judgment are what the system learns from. Most teams treat this as an afterthought. The teams that get it right treat it as core product architecture.
You still need product, and the reason matters. An AI engineer and a domain expert working together can automate a specific, narrow task well. They can extract an unstructured document, evaluate its content, and trigger an escalation. That is real value. But it is a disconnected moment rather than a system. Who receives that escalation? What do they do with it? What should the system learn from how they respond? How does that feed back into how the next document is evaluated? Without someone holding the end-to-end workflow in mind, connecting each step to the next, sequencing the roadmap so the intelligence compounds in the right direction, you get a set of narrow automations with limited and uncorrelated impact. No compounding. The product function is what turns isolated AI capabilities into a system that actually changes outcomes over time.
The organizational implications of this, how product teams need to be structured, what profile of PM works in this environment, how the relationship between product, domain, and engineering evolves, deserve their own treatment. But the starting point is recognizing that the product function is not optional in AI systems. It is more important than it has ever been.
6. Agentic AI Breaks Your Business Model, Intentionally
Most organizations treat AI as a product problem. The harder transition, and the one most companies underestimate, is that agentic AI also breaks the assumptions your business model was built on.
Seat-based pricing assumes value is delivered through access. A user has a license, they use the software, they renew. Agentic systems deliver value differently, through decisions made, workflows executed, and outcomes improved. That is a fundamentally different contract with the customer, and it changes nearly everything downstream.
Consumption and outcome-based models align pricing with value delivery in a way seat licenses never could. But they also introduce new risks. Revenue becomes harder to forecast. Customers want proof of outcomes before they expand. Sales motions shift from selling access to selling ROI. Onboarding becomes a value realization problem rather than just a technical setup problem. Customer success has to instrument usage and outcomes in ways most CS teams are not built for.
Product sits at the center of this transition because product defines what a unit of value actually is. What counts as an outcome? How is it measured? How does the system surface proof of value in a way customers can see and act on? These are not pricing questions or finance questions. They are product questions. And getting them wrong, building an agentic system without a clear value measurement architecture, means you cannot monetize what you built, no matter how well it works technically.
The organizations that navigate this well treat the business model transition as a product problem from the start. They instrument value delivery into the product itself. They design onboarding around time-to-first-outcome rather than time-to-configuration. They build CS workflows that proactively surface usage and impact data rather than waiting for renewal conversations to prove ROI. And they align product, sales, finance, and customer success around a shared definition of what the product actually delivers, before they price it rather than after.
Closing Thought
The companies that win with AI will not simply deploy more models. They will build richer operational memory, stronger semantic foundations, tighter feedback loops, continuously evolving ontologies, AI-native workflows, and systems that compound organizational intelligence over time.
But compounding intelligence does not happen on its own. It requires an agentic system whose explicit job is to manage the intelligence layer itself: ingesting signals from across the business, routing updates to the right parts of the ontology, surfacing conflicts for human review, and keeping the system accurate as the business changes underneath it. That is not a solved problem. It is one of the most important and underappreciated frontiers in AI product design.
The model is only one layer. The real opportunity is building systems that continuously learn how the business actually works, and the agentic infrastructure to keep that learning current, consistent, and trustworthy.
The organizations that build these systems will improve continuously. The rest will keep deploying disconnected AI tools and wondering why transformation never arrived.
Shantanu Dhaka is Chief Product Officer at Perch Insights, where he leads product strategy for an AI-driven analytics platform built for contact-center sales and service programs.