When Intelligence Becomes a Feature
When Copilot gets more capable than ever, where should enterprise AI use cases live?
Copilot is getting more powerful.
Things that recently looked like reasonable internal AI projects are beginning to look more like features: searching a collection of documents, summarizing a report, answering a question from company knowledge.
None of these capabilities have become unimportant. They have simply become much easier to assume.
This leaves a slightly uncomfortable question for anyone who has spent time building them:
What exactly did we build?
What should we build?
Consider a typical internal document assistant.
A team connects reports and internal data, adds retrieval, gives an LLM some instructions, perhaps adds tools and a review interface, then spends a while making the whole thing reliable enough to use.
There is real work in this. There is often real value too.
But the application contains several things that are easy to mistake for one thing.
Part of it is the capability itself: retrieving the right information, reading it, comparing it, producing an answer. The rest is everything around that capability: what the information represents, how different sources relate, where the result belongs, and what happens after it is produced.
When the first part was difficult, the distinction did not matter much. Making one task intelligent was already a substantial engineering problem.
As that becomes cheaper, the distinction becomes harder to ignore.
A large class of AI use cases can be described as improvements to a local transformation — a report becomes a summary, a question becomes an answer, a dataset becomes an analysis. The details vary, but the structure is similar: take a bounded piece of work and make the transformation faster, easier, or more capable.
It is useful to think of each of these as a node in a larger system.
For a while, the node itself was expensive. Now imagine that every node suddenly becomes quite good.
The surrounding organization does not automatically become a coherent system. The result of one task still has to mean something to the next.
This becomes clearer with data.
Suppose information about the same model lives in a registry, a code repository, validation reports, monitoring results, issue records, and approval systems.
Each source may be perfectly usable on its own. A capable model may even be able to read and query all of them.
But consider a different question. A model changes. Which governed model does that change belong to, and which validation assessed that version? Which findings remain relevant, what happened in monitoring afterwards, and what was eventually approved?
The problem is not access. The six sources contain different representations of something that has never quite been represented as one thing.
Connecting the data changes that. A model can become an object with implementations, validations, findings, monitoring results, owners, and decisions attached to it.
The result is not simply a larger dataset, or a better retrieval layer over six smaller ones. It is a different representation of the business.
A sufficiently capable agent could reconstruct parts of that representation at runtime, and sometimes that is exactly the right thing to do. But runtime stitching remains probabilistic, repeatedly inferred, and harder to audit consistently; a shared representation can make important relationships more deterministic, persistent, and auditable.
The distinction matters when a relationship is not merely useful context for answering a question, but part of the state on which reporting, monitoring, approval, or control depends.
The value is not in making fragmentation easier for a model to navigate. It is in deciding which relationships should no longer be reconstructed at all.
Processes have a similar problem. Enterprise work tends to inherit the boundaries of the organization that built it.
One process detects a change, another assesses its impact, a third gathers evidence; someone performs an analysis, a reviewer makes a decision, and an issue appears in another system, followed eventually by an approval somewhere else.
It is easy to add intelligence locally — evidence collection gets an agent, analysis gets another, the review receives an AI-generated summary.
Each node becomes faster while the output still crosses the old boundaries in roughly the old way. A result is exported, re-entered, and interpreted again because the next process does not inherit the state of the previous one.
At that point the expensive part may no longer be performing the work but composing it.
If an impact assessment already determines which evidence matters for validation, there is little reason to rediscover that context later. If a review changes the state of an object, downstream processes should not have to reconstruct the decision from a document.
Several workflows may turn out to be different views of one underlying process, separated mostly by the systems and teams through which it happens to pass. (BTW It also saves tokens)
Linking those processes is less about letting an agent walk through more steps than about asking whether the steps were represented as separate processes for a good reason in the first place.
This suggests a simple picture: as intelligence at individual nodes becomes cheaper, more of the interesting work moves to the edges between them.
But the picture breaks if we take it too literally.
An API is an edge; so is an ETL job, or a workflow that copies a field from one system into another. A large enterprise can have an impressive number of edges without becoming noticeably more coherent.
Connecting the existing graph is not the same thing as designing a better graph.
Two systems may contain different views of the same business object; two workflows may be separate only because different teams built them. A long chain of handoffs may contain no meaningful business distinction at all — it is simply the historical path by which the process accumulated.
In those cases, architecture may add a connection. It may also remove three.
The question is not how to connect more things, but what should have been one thing, what should remain separate, which state should persist across boundaries, and which outputs should be produced once rather than reconstructed at every downstream step.
What began as an edge problem has turned into a system design problem.
None of this is a new ambition in enterprise software. Master data programs, canonical models, and enterprise ontologies have tried for decades to establish shared objects across fragmented systems, often with mixed results.
The difficult part was rarely drawing the clean model on a whiteboard. It was resolving entities across inconsistent sources, extracting structure from documents, maintaining mappings as systems changed, and keeping the representation aligned with an organization that refused to stay still.
What is different now is that the same intelligence making local applications cheaper can also make some of that work cheaper. Entity resolution, extraction, and reconciliation are themselves transformations that models are increasingly good at assisting.
Intelligence therefore pushes in both directions: it reduces the scarcity of capabilities built on top of fragmented systems while lowering some of the cost of repairing the fragmentation underneath them.
Software has gone through versions of this shift before. Capabilities that once consumed large amounts of engineering effort gradually became ordinary infrastructure.
Storage, databases, networking, deployment, authentication: each can still be difficult, and each still matters, but most applications no longer derive their identity from implementing them from first principles.
When a lower layer becomes easier to assume, engineering does not disappear. The useful design problem moves upward.
Intelligence may be becoming another such layer.
Reading, generating, calling tools, and performing increasingly complicated local transformations are becoming things a system can start with rather than things every application has to invent for itself.
If that continues, asking where to add AI becomes a little like asking where to add a database. Sometimes it is still the immediate implementation question. It is rarely the most interesting description of the system.
A better question is what we would design differently if the intelligence were already there.
Return to the document assistant.
If its only durable structure is a prompt, a retrieval pipeline, and a chat interface around a capability that Copilot eventually provides directly, then perhaps the application really does disappear. There is nothing particularly tragic about that.
But suppose building it forced several disconnected records to become one representation of an underlying object — that information could now survive from one process into the next, that repeated reconstruction disappeared, and that workflows once treated independently became parts of one system.
Then the AI feature was not the most important thing that was built. It was the reason we finally looked at the system around it.
When intelligence becomes a feature, the question is what architecture intelligence should live in.