The System Around the Model: Ahmed Bashir on Enterprise AI’s Missing Infrastructure

1. Guest Background

In this Eye on AI episode, host Craig S. Smith asks why enterprise AI can look convincing in a demonstration yet struggle to deliver returns inside an organization. His guest, Ahmed Bashir of DevRev, answers through an infrastructure argument: the model needs a system capable of finding information, preserving its meaning and permissions, and supporting consequential actions. The supplied guest background identifies his organization but does not specify his current job title.

Bashir’s account of his engineering experience helps explain that emphasis. He recalls studying database internals, including System R, buffering, transformation, and query optimization. Later, he says, he spent approximately twelve and a half to thirteen years at Apple and belonged to the founding team that launched iMessage and iCloud. He describes being the sole backend engineer for iCloud’s backup and restore feature. These are his recollections in the interview, rather than independently verified biographical findings.

He subsequently became involved in DevRev’s startup work, describing the combination of a model layer and a memory layer as central to enterprise AI. He presents shared memory as a multiyear engineering investment. That background gives his argument a coherent perspective, but also a commercial context: this is an experienced practitioner explaining an architecture his company sells. The episode is valuable for understanding that architecture and its proposed mechanisms, while its product and performance claims still require scrutiny.

2. What the Episode Covers

Bashir begins with “redigitization,” an idea he illustrates through music. A compact disc already contained digital content, yet portable listening, shuffle, and playlists called for a different organization of that content. His point is about fitness for a new use: possessing digital information does not mean possessing the representation that a new computing experience needs. He extends the analogy to cloud applications, APIs, microservices, and the movement of operational data into analytical environments. For AI, he argues, information must become available for indexing, joining, relating, and excluding as part of producing useful searches, answers, and actions.

The architecture he describes has three parts. Existing business systems hold the information; reasoning models perform inference; between them sits a layer of semantics, orchestration, and governance that he calls shared memory. Its job includes connecting information across tools and departments and preserving the business relationships that make records intelligible. Memory here means considerably more than retaining a conversation. It also includes the controls under which information can be used.

According to Bashir, those connections must support both reading and writing, because an answer may lead to an action in a source system. They must also retain existing identities and permissions. His example of one tool potentially containing seven permissioning systems illustrates accumulated software complexity; it is not a claim that every enterprise application has that configuration.

Computer is DevRev’s product expression of this approach. Bashir describes a conversational interface backed by a visible catalog of records, lists, dashboards, and citations. Team members can participate in conversations together, while a canvas can accept PDFs and hold generated presentations, spreadsheets, or websites. Artifacts can become part of the catalog and be shared. These are capabilities described by the guest, not reliability findings established by the interview.

Enterprise Bench supplies the evaluation counterpart. Bashir objects to treating use of a leading model as sufficient evidence of a leading enterprise AI system. He separates task complexity from enterprise complexity: even a relatively ordinary business question can become difficult when its evidence is scattered across tools, versions, roles, and permissions. The episode therefore investigates the conditions surrounding reasoning, rather than assuming that stronger reasoning alone settles the deployment problem.

3. Core Views: Reasoning, Examples, and Limits

The strongest analytical move in Bashir’s argument is to change the unit being evaluated. Enterprise Bench, he says, requires a system to locate, validate, join, structure, and understand information before completing a task. The benchmark evaluates the entire agent harness, including data management and model interaction. There is a practical reason for that choice: a model can reason competently over an incomplete selection of records and still produce an inadequate answer. Evaluating the reasoning component in isolation cannot reveal every failure introduced before the model receives its context.

Bashir uses the relationship between a CPU and RAM to explain why improving one component may leave another bottleneck intact. A faster processor cannot always compensate for insufficient memory because the components serve different functions. Applied to enterprise AI, the analogy supports examining model capability and information infrastructure separately. It does not establish a mathematical equivalence between computer memory and enterprise shared memory, nor demonstrate that a particular vendor’s architecture is the only workable solution. Its value is diagnostic: ask which part of the system is limiting the outcome before buying more capability elsewhere.

The reported benchmark results are striking but narrower than a general claim about business performance. Bashir says Computer achieved 50 percent higher accuracy than Claude Code when both used the same Opus-family model. He separately reports approximately 75–80 percent fewer tokens on average. He explicitly describes the accuracy improvement as a relative delta; it should not be rewritten as a gain of 50 percentage points. The relevant interview passages do not supply absolute accuracy, sample size, complete configurations, or statistical uncertainty. Holding the model constant makes the surrounding system worth investigating, but does not by itself control differences in tools, preparation, prompting, or stopping behavior. The figures remain vendor-reported comparisons, not a demonstrated return available to every enterprise.

A second important distinction concerns the transition from analysis to execution. Bashir offers ticket clustering, financial-report correlation, and assessments of unsuccessful deals as examples of impressive demonstrations. Synthesizing large amounts of material can be useful even before a system is permitted to change anything. Whether an organization will let the same system update its CRM, status page, or financial records is a further question. He attributes that trust gap to governance, orchestration, and semantic understanding. The episode makes that explanation plausible as an architectural diagnosis, but does not establish the entire causal chain through detailed deployment evidence.

His pagination example makes the information problem especially concrete. Imagine 100,000 accounts returned 50 at a time. After finding something relevant, how does an agent know whether the next page contains a decisive record? Add several systems and the stopping decision must cover all of them. Continuing consumes tokens; stopping prematurely risks omission. Relevance and completeness are different properties, and finding the former does not establish the latter.

Bashir’s proposed response is to move suitable context-building work into databases and CPU-based queries, leaving the model to reason over the resulting material. Databases already provide relationships, indexes, joins, exclusions, aggregation, and projection. Reusing those mechanisms can avoid making a model repeatedly rediscover structured relationships. But deterministic execution does not establish that the source data is complete, that mappings are correct, or that the query expresses the right business scope. A further boundary comes from the benchmark itself: Bashir says it currently includes only L1 and L2 tasks. Its reported performance therefore cannot establish the reliability of the higher-autonomy actions discussed in the interview.

4. Learning and Application

A useful application of the interview is to specify the evidence pathway before optimizing the answer. Take Bashir’s unsuccessful-deal analysis example. A team could first identify which accounts, records, and documents are relevant, which systems contain them, how they connect, and whose permissions govern access. Only then would it define the synthesis expected from the model. This recommendation follows from his shared-memory architecture and the benchmark’s requirement to find and validate information. It makes the preparation stage something that can be inspected, rather than an invisible prelude to a polished response.

Retrieval also needs an explicit scope and stopping rule. A pagination-based agent should not be accepted merely because it discovered plausible supporting records. Reviewers need to know what population was searched and what remains unexamined. Where completeness cannot be established, the result should be framed as a conclusion about the inspected material. That boundary may reduce the apparent ambition of an answer, but it makes its actual evidential reach clearer.

For a pilot or procurement comparison, separate accuracy, token consumption, and business completion. The episode’s token reduction claim is a reason to request a controlled comparison, not a substitute for one. Ask for absolute baselines, representative tasks, access settings, tool configurations, and failure cases. Fewer tokens alone do not establish ROI: the practical assessment must also account for the work needed to prepare and operate the system. Preparing such a comparison takes effort, but prevents a narrow configuration advantage from becoming an unsupported business promise.

Bashir’s autonomy framework offers a way to stage acceptance criteria. L1 concerns search within one domain; L2 adds cross-domain relationships and synthesized answers; L3 concerns actions within a domain; L4 completes a job through actions across domains. Since the benchmark described in the episode covers only the first two, strong search results should not automatically authorize the latter two. A system might initially propose a CRM change for a responsible person to inspect. Expanding autonomy would then depend on evidence about the action itself, rather than the fluency of its explanation.

Connector reviews should likewise examine more than successful reads. Bashir’s state-and-city example shows why a value can look reasonable in isolation yet be invalid in combination with another field. Before writing, check identity, permissions, dependent fields, permissible values, and allowed state transitions. A bidirectional connection supplies a route for action; it does not establish that every action through that route is valid. Visible assignees, priorities, source records, and clickable citations can help reviewers inspect the concrete objects involved. Computer’s catalog and canvas suggest this direction, although generating or sharing an artifact still needs different acceptance criteria from changing an operational record.

Finally, assign work according to its requirements. Repeated joins and aggregations with a defined scope are candidates for database execution; interpretation and synthesis can then go to the model. Bashir’s database category includes transactional, analytical, semantic, vector, and graph-oriented systems, so this need not mean forcing every task into one storage design. The governing boundary remains the same: repeatable queries do not make unreliable inputs reliable. Checking sources, transformations, and access conditions is part of applying his argument, rather than simply adding a component called memory.

Source

• Original episode: Why Enterprise AI Isn’t Delivering ROI | Ahmed Bashir, DevRev