VYUHAMThe Agentic Enterprise
08 / 11 · The Enterprise Intelligence Factory
The Agentic Enterprise · Section 08

The Enterprise Intelligence Factory

The frontier model should solve the unfamiliar problem. The enterprise should not pay it forever to solve the familiar one.

Ravneet Grewal · Working draft v0.1 · August 2026

As I started thinking about larger agentic systems, I kept coming back to a question that had less to do with agents and more to do with where their intelligence came from.

If every enterprise uses the same frontier models for every problem, where does the enterprise's own intelligence compound?

There were two practical reasons this bothered me. The first was economics. Why should an enterprise keep paying frontier-model economics to solve the same bounded domain problem again and again? The second was sovereignty. Some enterprise data, policy and operating knowledge should remain private, and some of the intelligence created from that experience should become an asset of the enterprise rather than a transient prompt sent to somebody else's model.

Those two concerns led me toward what I think of as an Enterprise Intelligence Factory.

The frontier should solve the unfamiliar problem

Frontier models are extraordinarily useful because they give an enterprise access to broad, general reasoning without having to build that intelligence itself. I do not see that disappearing. Novel problems, ambiguous situations and unfamiliar domains will continue to justify the strongest available models.

But a mature enterprise should not treat every problem as novel forever.

If an ABU repeatedly sends the same class of work to a frontier model, receives similar reasoning, applies the same policies and reaches similar outcomes, that repetition is information. It is evidence that some of the cognition may now be well understood enough to become a more specialized capability.

The frontier model should solve the unfamiliar problem. The enterprise should not pay it forever to solve the familiar one.

The replacement does not always need to be another model. The enterprise may discover that a smaller private model is sufficient. It may fine-tune a domain model. It may create a specialist agent with narrower context and tools. It may encode a deterministic rule. Or it may decide that the repeated pattern is stable enough to deserve a small software service.

The important idea is that repeated cognition should have a path toward becoming reusable enterprise intelligence.

Private AI is more than a privacy architecture

I initially approached private AI partly through the obvious concerns: sensitive enterprise data, regulated information, model access boundaries and the desire to run some intelligence inside infrastructure the enterprise controls.

Those concerns are real, but they are not the whole argument.

Private intelligence can also become part of the enterprise moat. If two competitors use the same frontier model, the model itself is not a meaningful differentiator between them. What can differentiate them is the operating knowledge they accumulate, the semantics they have certified, the examples they have validated, the policies they have encoded, the specialist models they have tuned and the machine organization they have built around those assets.

That is why I do not think the Agentic Enterprise should be architected around a particular model provider. The harness should be stable while the intelligence underneath it remains replaceable.

A simple extraction role might run on an inexpensive model. A difficult contract analysis might justify a stronger frontier model. A high-volume classification task might eventually move to a privately tuned small model. A narrow policy decision may become deterministic. The ABU should consume the level of cognition the work requires rather than treating one model as the architecture.

From model routing to an intelligence supply chain

Once model choice becomes a runtime and economic decision, the enterprise starts to resemble an intelligence supply chain.

At one end is frontier intelligence for novelty. Behind it are private and specialized models for recurring domains. Alongside those are deterministic services, semantic systems, policy engines and agents that package particular kinds of reasoning. The harness decides which of these resources belongs in the current business objective.

The Intelligence Factory is the part of the enterprise that improves this supply over time.

It should be able to ask questions such as: which problems are consuming the most frontier inference? Which tasks are repeated with low variation? Where do human reviewers consistently reach the same conclusion? Which patterns are stable enough to become regression tests? Which knowledge should be promoted into shared context? Which recurring reasoning can be moved into a smaller model or deterministic implementation without losing quality?

That creates a different kind of learning loop. The enterprise does not only learn facts. It learns how much intelligence a problem actually requires.

The factory can produce more than models

The part that interests me most is what happens when the output of the Intelligence Factory is not a model at all.

Suppose an ABU encounters a need repeatedly. Agents reason through it successfully, but the same sequence keeps consuming inference, tool calls and time. At some point the right response may be to turn the learned pattern into software.

This is where agentic software development starts to merge with the Agentic Enterprise.

The pattern could look like this:

Repeated need → pattern recognized → reusable capability proposed → software generated → tests generated and executed → security and policy checks → governed promotion → capability registered.

The agents do not get to invent and deploy arbitrary production software because they feel like it. The build still needs requirements, tests, security checks, authority and promotion controls. But the economics of creating verified software may fall enough that the expected lifetime of a software component becomes a design variable.

Software may become more disposable

Infrastructure already went through a version of this transition. Servers were once physical assets that organizations named, maintained and kept for years. Virtualization and cloud infrastructure progressively made compute instances easier to create, replace and retire.

I think portions of enterprise software may follow a similar path.

Today we tend to treat applications as long-lived assets because software is expensive to create. The cost of requirements, design, development, testing, deployment and maintenance encourages longevity. If agentic development can produce small, verified capability implementations much faster, some software may instead exist for the duration of the need it serves.

I use the term ephemeral software for this possibility.

An enterprise sees a recurring need. The Intelligence Factory generates a bounded implementation. The implementation passes its tests and controls, becomes an approved realization of a capability, performs the work, and remains available as long as the business need exists. If the need disappears, the enterprise can retire the component after checking dependencies and preserving the required evidence.

This does not mean every application becomes disposable. Systems of record, core transaction platforms, regulated stateful systems and externally contracted interfaces have strong reasons to remain durable. The nearer-term opportunity is likely to be smaller capability implementations around those durable systems: adapters, decision services, specialized APIs, transformations and narrow pieces of operational logic.

The important change is that software lifetime no longer has to be assumed to be long simply because software was expensive to create.

Experience becomes an enterprise asset

This brings the Intelligence Factory back to the question of moat.

If the enterprise only consumes frontier intelligence, every interaction is useful but little of the operating advantage necessarily compounds inside the enterprise. A stronger architecture captures what has been learned and progressively turns that learning into assets the enterprise can reuse.

Those assets can take several forms:

Knowledge that becomes part of the ABU's current operating context.

Semantics that make enterprise data and concepts more precise and executable.

Models that specialize recurring cognition and keep more intelligence private.

Agents that package specialist roles, tools and context.

Software that compiles a repeated reasoning pattern into a cheaper and more deterministic capability.

That is why I call it a factory rather than simply model operations. The goal is not to fine-tune models for its own sake. The goal is to convert enterprise experience into increasingly reusable forms of intelligence and execution.

The factory closes another loop

There is a connection here to SDAL.

An ABU senses repeated work and changing conditions. It decides that the current way of solving a problem is expensive, slow or unnecessarily general. The enterprise acts by producing a new specialized implementation. Then that implementation becomes part of what the ABU can discover and use in the future.

The organization has not simply learned a better answer. It has changed the machinery through which future answers are produced.

That is an important property of the Agentic Enterprise I am trying to describe. It should not remain a static collection of agents connected to increasingly capable models. It should be capable, under governance, of improving its own supply of knowledge, intelligence and software as repeated experience reveals what should become reusable.

The next problem follows immediately. As the number of agents, capabilities and generated implementations grows, somebody has to know what all of those machine actors are doing.

Distributed software created the need for observability. Distributed cognition creates the same need, with an additional question: not only what called what, but under whose authority and for what purpose.

Reference

  1. Sequoia Capital, “Services: The New Software,” March 5, 2026. sequoiacap.com