Enterprise Intelligence: What a Customer Needs Before an Agent Acts

I'm exploring how shared business definitions, current evidence and explicit approvals could help customers review a network change before an agent acts.

I’ve been down the Enterprise Intelligence rabbit hole.

I keep coming back to a customer trying to approve a network change. The maintenance plan is in one system, the service dependencies in another, the customer commitments somewhere else. An engineer has to reconcile them before anyone can say whether the change should proceed.

An agent could help with that work. I would want to see which service it identified, which dependency records it used, how old they were, and which rule allowed the recommendation. If two sources disagree, I want the disagreement in front of the approver.

That is the job I have in mind for Enterprise Intelligence: give people and agents a shared, maintained account of the business, with enough evidence and control to support a particular decision.

My interest is in what our customers could reuse after the first agent project. A service definition, an approved policy, or a reviewed operational lesson should be available to the next application without another team reconstructing its meaning.

Start with one decision a customer has to make

Consider a fictional telecommunications operator. A planner wants to take a network link out of service for maintenance tonight. A service appears to have a backup route, so the proposed change looks reasonable.

Before recommending it, the planner needs to establish whether that backup route depends on the same equipment, whether another maintenance job overlaps, and whether any affected service has a commitment that rules out the proposed window.

In this example, both routes pass through a shared component scheduled for maintenance. The topology and change records expose a dependency the initial request did not mention.

The useful response would identify the affected service, cite the relevant records, explain the overlap, and recommend deferring the change until someone resolves the conflict. It would also state where the dependency mapping is incomplete. A missing relationship cannot be treated as proof that no dependency exists.

This gives the customer a bounded problem to evaluate. Can the system assemble a reviewable recommendation faster than the existing process, while finding the conflicts an engineer expects it to find? Can it stop when the evidence is insufficient?

I would measure those questions before claiming any reduction in outages or operating cost. The example here is illustrative; it is not a customer result.

Keep policy, observations and hypotheses distinguishable

For this design, I use four forms of knowledge. Each needs different evidence before it can influence a decision.

Form	Example in the maintenance decision	Treatment
Declared	The approved policy requires a protected service to retain an independent route.	Preserve the owner, version, effective dates and scope.
Observed	A topology record places both routes on a shared component.	Preserve the source, observation time and freshness limit.
Inferred	The proposed change may interrupt both routes.	Show the input records, reasoning method and uncertainty.
Learned	A review of earlier changes suggests an additional dependency check.	Keep it as a candidate until an owner evaluates and approves it.

These labels have to survive retrieval and appear in the response. The policy check must reject a recommendation that violates the approved rule, even if a model predicts low failure risk.

For the maintenance example, graph traversal would find recorded dependencies. A deterministic check would enforce the independence rule. A language model could help interpret the request and explain the result. An optimisation service might later compare feasible maintenance windows.

I would give each of those jobs to a method we can evaluate for it. The language model does not need to calculate everything.

A proposed decision flow. The recommendation includes its evidence and limits; permission to execute comes later.

The knowledge plane has work to do between systems

By knowledge plane, I mean the services that maintain definitions, relationships, source references and decision records, then make them available under access controls.

The architecture below separates that work into responsibilities. It is the sanitised target architecture dated 4 September 2026.

Target architecture, 4 September 2026. “Current” describes the reusable foundation and synthetic demonstration scope, not a deployed customer platform. The target and next-stage boxes do not establish production readiness. Open the image to read the component detail.

In this proposed split, Fabric would hold shared semantics and analytical context. Cosmos DB would serve versioned operational knowledge products and decision records. A Knowledge Gateway would check whether a caller can use a particular product for a particular purpose, and whether its evidence is current enough for the request.

A knowledge product could be as narrow as “the dependencies and active constraints needed to review this service change”. It needs an owner, named sources, a version and a freshness requirement. It also needs a defined response when those sources are unavailable.

There is public product support for parts of this design. Microsoft documents Fabric ontology as entity types, properties, relationships and bindings to business data. Its Real-Time Intelligence documentation describes the event ingestion and querying capabilities relevant to changing operational state.[1][2] Cosmos DB provides an operational document store.[3] Those capabilities still need to be connected and evaluated for the customer’s decision.

The Fabric/Cosmos division is an architecture choice here. It is not a product prerequisite for Enterprise Intelligence, and choosing Cosmos DB does not automatically provide a decision journal or historical replay. Those are application contracts we would have to implement.

As of 5 September 2026, the reference work behind this post includes a read-only implementation candidate. I am not presenting it as a production deployment or evidence of customer benefit. Fabric IQ and ontology are still labelled preview in Microsoft’s documentation; capability availability, capacity, region and access requirements need confirmation during solution design.[1][4]

Systems of record would retain their authority. If a service commitment changes, the correction belongs in its owning system. The knowledge plane must carry that change into the affected products, including invalidating an earlier recommendation when necessary.

An ontology gives the maintenance decision a vocabulary: service, route, component, change window and commitment. It defines the relationships we intend to query and binds those definitions to records.[1]

The operations team may use “service” for a technical service; the account team may mean a contracted customer offering. Giving both records the same label would conceal the difference. The model needs two explicit concepts and a relationship between them, with an owner responsible for the mapping.

That ownership has a cost. Someone must resolve disputed definitions, maintain source bindings and review changes when systems evolve. A central team cannot plausibly settle every domain’s vocabulary. My preference is a small shared set of identifiers and concepts, with domain teams owning the detail and explicit mappings at the boundaries.

For the first maintenance decision, I would resist modelling the whole operator. Start with the concepts required to establish route independence and change overlap. Add the next concept when a decision needs it.

The potential benefit comes on the second use. If incident triage needs the same service-to-component relationship, its team should be able to reuse the approved definition and mapping, subject to its own access and freshness requirements. That reuse is something to demonstrate, not assume.

Preserve what was known when the decision was made

Now take a case where the planner’s records show an independent backup route. The planner receives a recommendation to proceed at 10:00. At 10:12, a corrected topology record arrives. It says the backup route had depended on a shared component since 09:30.

Using only the latest record, a later review could make it look as though the planner ignored evidence available at 10:00. In this example, the correction was not available then.

The design needs to retain both when the relationship applied in the network and when the platform recorded it. These are the two axes of a bitemporal model, here called valid time and recorded time.[5] The journal also needs the exact evidence and policy versions used for the recommendation, so a reviewer can reconstruct that earlier view.

The correction should trigger a fresh assessment of any still-pending recommendation that depended on the old topology. The earlier recommendation must remain inspectable, but its old approval should no longer permit execution.

This creates storage, retention and privacy work. The customer needs to agree how long decision evidence is retained, who can read it, and how corrections and deletions affect the journal. “Keep everything forever” would be a poor default.

Approval and learning need their own controls

The first deployment I would propose stays read-only. It can identify the shared dependency, recommend deferral, or ask an engineer to resolve the missing evidence. It cannot change the network.

If a customer later wants execution, I would separate the action controller from the reasoning agent. The controller would check the approved command, target, evidence version, conditions and expiry before calling the operational system. A changed target or an expired approval would require a new decision.

The same care applies after the work. If an engineer resolves the conflict and a revised change succeeds, that outcome can support a candidate lesson. One successful change does not establish that the procedure is safe across other services, topologies or conditions.

Proposed later-stage flow. A successful outcome can prompt a review; it cannot approve its own lesson.

A reviewer would need to establish what happened, whether the action plausibly contributed to the result, where the lesson applies, and what evidence would contradict it. Approved learning would become a new version with a source and an owner. Inconclusive outcomes would remain inconclusive.

This is one of the reasons I keep exploring Enterprise Intelligence. There is useful work between a completed incident review and the next agent that needs the lesson. I want that transfer to preserve the conditions under which the lesson was learned.

What I would ask a customer to prove first

The first pilot needs one recurring decision, one accountable owner and a small set of authorised records. Together, we would establish a baseline using representative cases, including cases where the right response is to stop.

For the maintenance example, the evaluation would include an independent route, a shared dependency, an overlapping change, an unresolved service identity, stale topology, a late correction and a caller without permission to see the affected service.

An engineer would specify the expected disposition and supporting evidence for each case. We could then compare the assisted process with the existing process on time to a reviewable recommendation, evidence completeness, conflict detection and inappropriate recommendations. Needless abstentions count too; a system that always refuses is unlikely to help the planner.

The cost assessment needs to include source integration, ontology stewardship, runtime services and the human work of resolving exceptions. If an existing query and a maintained runbook solve this decision reliably, I would use those before proposing another platform.

Once the first decision works, I would test reuse with a second workflow, such as incident triage. Can it consume the same approved service definitions and dependencies without rebuilding the mapping? Does that shorten delivery while preserving access boundaries?

Before enabling any action, I would ask the team to replay the late-correction case: show the evidence available at 10:00, show why the 10:12 update invalidates the pending recommendation, and show that the old approval can no longer execute it.