Welcome Back to XcessAI

Imagine asking your company's AI a simple question:

"Which customers are most exposed if our German plant shuts down for two weeks?"

All the information exists.

But the answer exists in the relationships between the information.

That distinction may become increasingly important as companies move from AI assistants that find and summarise information toward AI systems expected to understand how businesses actually work.

The technology behind that transition has been around in various forms for decades: graphs.

What is changing is that large language models are making graphs easier to construct, query and use. Meanwhile, approaches such as GraphRAG are combining the reasoning capabilities of LLMs with structured representations of entities and their relationships. Microsoft describes GraphRAG as an approach that combines text extraction, network analysis, LLM prompting and summarisation to create and reason over knowledge graphs.

The result could become an important new layer of enterprise AI.

Welcome to graph engineering.

Bottom line: Most enterprise information is stored as documents, tables and records. But businesses themselves operate as networks of relationships.

Orders affect cash flow.

Risks propagate through all of them.

Traditional search and RAG are good at finding information that looks semantically similar to a question. Graph-based systems add something different: they explicitly represent what is connected to what.

For CFOs and business managers, this matters because many of the questions that actually drive decisions are relational.

Not:

"What does this supplier contract say?"

But:

"Which products, customers and forecasts are affected if this supplier fails?"

That is a graph question.

Forget AI for a moment.

A graph is simply a way of representing things and the relationships between them.

Suppose we have:

Customer A → buys → Product X

Product X → manufactured at → Factory B

Factory B → depends on → Supplier C

Supplier C → located in → Taiwan

These "things" are usually called nodes or entities.

The connections are called edges or relationships.

Once information is represented this way, software can traverse the connections.

Ask: Which customers depend indirectly on Supplier C?

The system can follow:

Supplier C → Factory B → Product X → Customer A

Now imagine that instead of four nodes, your organisation has millions.

Customers. Employees. Products. Suppliers. Contracts. Invoices. Factories. Projects. Regulations. Risks. Bank accounts. Competitors. Documents.

And relationships connecting all of them.

You have effectively created a map of the business.

Traditional corporate systems generally organise information into tables.

A customer record might tell us that Alpha generates £12m of revenue in the UK industrial segment, while Beta generates £8m in German consumer markets.

That's extremely useful.

But suppose the CFO asks: "Which of our ten largest customers depend on products containing components sourced from suppliers with more than 50% exposure to China?"

Now we're moving through several layers.

Customer → Order → Product → Component → Supplier → Geography.

A relational database can absolutely perform these queries. Graph databases do not magically replace SQL.

The difference is that graphs make relationships and traversal first-class features of the data model.

That's particularly useful when the number and variety of connections become large or when the questions weren't completely anticipated when the database was designed.

For AI, that becomes very interesting.

We've discussed RAG before in XcessAI.

Retrieval-Augmented Generation solves an important problem.

Instead of expecting an LLM to know everything, you retrieve relevant information from your own data and put it into the model's context.

Imagine asking: "What is our termination clause with Supplier C?"

A traditional RAG system searches your documents, finds the relevant contract paragraphs and gives them to the LLM.

Excellent use case.

But now ask: "What are the biggest operational consequences if we terminate Supplier C?"

Much harder.

The answer may require information from dozens or thousands of places.

The supplier contract. Purchase orders. Bills of materials. Factory records. Alternative suppliers. Customer commitments. Inventory. Forecasts. Emails. Risk reports.

Traditional semantic retrieval might find documents containing words similar to "Supplier C" and "termination".

But the real question isn't primarily about textual similarity.

It is about relationships and consequences.

Microsoft highlights precisely this limitation: conventional RAG can struggle with questions requiring a holistic understanding of an entire dataset rather than retrieval of a handful of relevant text chunks.

That's where graphs start becoming powerful.

A knowledge graph combines data with explicit meaning.

Instead of simply storing: "Factory Manchester"

the system understands:

Manchester → IS_A → Factory
Manchester → PRODUCES → Product X → SOLD_TO → Customer B → GOVERNED_BY → Contract 123
Manchester → OWNED_BY → Company A

Now the AI isn't merely searching for words.

It has access to a structured representation of how these entities relate.

And critically, the graph can connect information originating from completely different systems.

ERP. CRM. HR. Procurement. SharePoint. Emails. Contracts. Market data.

The graph becomes a kind of connective tissue between enterprise data silos.

This is where graphs meet generative AI.

GraphRAG combines graph structures with retrieval-augmented generation.

Microsoft's implementation, for example, uses LLMs to extract entities and relationships from source documents, creates a knowledge graph, identifies clusters or "communities" within it and generates summaries of those communities.

When someone asks a question, the system can retrieve not only relevant text but relevant structures of relationships.

That changes what can be asked.

The LLM then receives a much richer representation of the problem.

Microsoft's newer integrations explicitly allow agents to retrieve relevant subgraphs and traverse connected entities rather than working only with isolated chunks of text.

That's the conceptual leap.

RAG retrieves information.

GraphRAG can retrieve relationships between information.

There is another important distinction.

Some questions are local.

You start from an entity and explore its neighbourhood.

Other questions are global.

These questions require understanding patterns across the dataset.

Microsoft's GraphRAG architecture specifically distinguishes these kinds of searches. Its graph is organised into hierarchical communities, allowing an AI system to reason at different levels of abstraction rather than simply retrieving the nearest matching chunks.

For management, that is potentially significant.

Because senior executives disproportionately ask global questions.

This is where graph engineering moves from computer science into management.

Consider the CFO's world.

Revenue connects to customers. Customers connect to contracts. Contracts connect to pricing. Pricing connects to products. Products connect to factories. Factories connect to assets. Assets connect to capex. Products also connect to suppliers. Suppliers connect to currencies. Currencies connect to hedges. Employees connect to cost centres. Cost centres connect to budgets. Everything connects.

Yet finance systems frequently present these relationships through separate reports.

The CFO receives the output as:

Excel. PowerPoint. ERP reports. BI dashboards. Emails.

The management team then performs the graph reasoning manually.

Someone says: "Why did Germany miss the forecast?"

And humans mentally traverse the organisation.

Germany missed because Customer A delayed an order. Customer A delayed because Product X wasn't available. Product X wasn't available because Factory B had downtime. Factory B had downtime because Component C wasn't delivered. Component C wasn't delivered because Supplier D had a problem.

Management is already doing graph reasoning.

We just don't call it that.

Now imagine representing the business explicitly.

Revenue → Customer → Product → Factory → Supplier.

Then connect:

Customer → Contract → Pricing | Product → Margin → Forecast | Supplier → Currency → Hedge | Factory → Energy → Commodity Price | Employee → Cost Centre → Budget | Debt → Interest Rate → Covenant

Suddenly questions become possible such as:

Those aren't simply database queries.

They are management questions about dependencies.

This could eventually change management reporting.

Dashboards mostly show what happened.

Revenue ↓ 7%.

Margin ↓ 120bps.

Working capital ↑ £40m.

A graph can help organise the relationships around why it happened.

Revenue ↓ → Volume ↓ → Customer A orders ↓ → Product availability ↓ → Factory utilisation ↓ → Component shortage ↑ → Supplier disruption

A graph doesn't automatically prove that this chain is causal. But it gives humans and AI systems a structure for tracing dependencies, testing hypotheses and connecting evidence.

The management report starts moving from a collection of numbers toward a map of the business system.

This is perhaps the most important part.

Putting everything into a graph does not automatically create intelligence.

Someone has to decide what the relationships mean.

Is:

Customer → Product

a purchase? An enquiry? A contractual commitment? A forecast? A historical transaction?

Those are completely different relationships.

Similarly:

Supplier → Product

could mean:

approved supplier, current supplier, sole supplier, historical supplier, potential supplier.

This is why graph engineering matters.

It involves designing how the business should be represented.

Microsoft's own work on GraphRAG emphasises that different domains require different entity and relationship definitions. A graph useful for news analysis has a fundamentally different structure from one designed for chemistry.

The same applies inside a company.

A manufacturing graph looks different from an insurance graph.

And a CFO's financial graph looks different from an engineer's product graph.

There is a technical word business leaders should know:

Ontology.

It sounds academic, but the concept is simple.

An ontology defines what kinds of things exist in your business and how they are allowed to relate.

For example:

Customer. Product. Supplier. Factory. Contract. Employee. Risk

Then:

Think of the ontology as the grammar of your company's knowledge.

The better that grammar, the more reliably machines can reason across it.

This is one reason graph engineering is partly a business problem rather than an IT problem.

IT can build the infrastructure. But management knows what the relationships actually mean.

Businesses aren't static.

Customer A used to buy Product X.

Supplier B became sole source in January.

Employee C was responsible for Division D until March.

Contract E expires next year.

A useful enterprise graph therefore needs to understand not only:

What is connected?

but:

When was it connected?

This becomes critical in financial analysis.

Ask: "Why did margins deteriorate between Q2 and Q4?"

The AI needs the graph as it existed during those periods, not merely today's organisational structure.

Temporal graphs, versioning and event models therefore become increasingly important as graph systems move into serious enterprise applications.

For a CFO, perhaps the most important question isn't: "What does the AI think?"

It is: "Why does the AI think that?"

Suppose an AI tells you: "Customer A represents a material liquidity risk."

You should be able to trace:

Risk conclusion

→ cash-flow forecast

→ customer receivable

→ invoice

→ ERP record

→ source transaction.

This is provenance.

Every important relationship should ideally retain evidence of where it came from.

That makes graph-based AI potentially valuable for high-trust enterprise environments.

Instead of an answer appearing magically from a language model, management can potentially inspect the chain of evidence supporting it.

That doesn't eliminate hallucination or bad data.

But it gives governance somewhere concrete to operate.

And this brings us to what may be the next evolution.

You probably don't want to send the company's entire knowledge graph to an AI model every time somebody asks a question.

You want the system to construct the relevant subgraph.

If the CFO asks: "Why is working capital deteriorating in Brazil?"

the system might dynamically assemble:

Brazil → customers → receivables → overdue invoices → payment terms → inventory → suppliers → purchase orders → FX → forecasts.

Then add: permissions, source documents, timestamps, provenance, and perhaps confidence levels.

That becomes the context supplied to the model.

This connects graph engineering directly to something we've discussed before in XcessAI:

context engineering.

The model provides reasoning.

The graph provides structure.

The context system decides which part of that structure the model needs right now.

This technology should not be applied to everything.

If you want to ask: "Summarise our travel policy."

You probably don't need a knowledge graph.

Ordinary RAG is likely sufficient.

Graphs become more valuable when questions involve:

multiple entities + multiple systems + multiple relationships + multiple steps.

Typical enterprise use cases include supply-chain dependencies, fraud networks, customer relationships, regulatory obligations, corporate ownership, IT infrastructure, research, product dependencies, organisational knowledge and financial risk.

Microsoft itself notes that GraphRAG should be used purposefully and highlights dataset scale, duplicate information and tolerance for hallucination as considerations when deciding whether it is appropriate.

Graph engineering isn't the replacement for RAG.

It is another tool in the architecture.

You probably shouldn't call the CIO tomorrow and demand a "company knowledge graph."

That risks producing a very expensive technology project looking for a problem.

Start with a management question.

For example: "If a major supplier fails, can we identify the complete EBITDA and cash-flow exposure within minutes?"

Then work backwards.

What entities are required?

Supplier. Component. Product. Customer. Contract. Factory. Inventory. Forecast.

That narrow graph can solve a real business problem.

Then expand.

This is likely a much better approach than attempting to model the entire company on day one.

Over the past year, we've discussed several layers of enterprise AI in XcessAI.

Models gave us intelligence.

RAG gave models access to knowledge.

Memory gave AI continuity.

MCP gave AI access to tools and systems.

Agents gave AI the ability to act.

Graph engineering adds something different:

relationships.

And relationships are where much of business reality lives.

A company isn't simply a collection of documents and databases.

It is a network.

People depend on people.

Products depend on suppliers.

Customers depend on products.

Cash flows depend on customers.

Strategies depend on assumptions.

Risks propagate through connections.

Perhaps enterprise AI won't truly understand a business until it can understand that network.

The first generation of enterprise AI has largely been about making corporate information searchable.

Ask a question. Find the relevant documents. Generate an answer. Useful.

But management rarely operates through isolated pieces of information.

Managers ask:

Those are questions about relationships. And that is why graph engineering could become an important layer in the enterprise AI stack.

Not because every company needs an enormous knowledge graph. Not because GraphRAG replaces databases, search or traditional RAG.

But because the questions that matter most to management often don't live inside individual documents.

They live in the connections between them.

Until next time,
Stay adaptive. Stay strategic.
And keep exploring the frontier of AI.

Fabio Lopes
XcessAI