The enterprise knowledge layer: Operating Structure

Neo4j principal consultant Jesús Barrasa published the first chapter of a series building an enterprise knowledge layer, modeling AcmeBank's operating structure as a graph to answer accountability questions such as who is responsible for SMB lending. The article details the design of business units, teams, roles, and people in Neo4j, addressing the challenge that enterprise knowledge often lives in people's heads or stale documents, which AI agents need to execute processes.

The enterprise knowledge layer: Operating Structure Principal Consultant, Neo4j 16 min read Business units, teams, roles, reporting lines. The structure behind the work, built as a graph you can load, query, and explore. New to the enterprise knowledge layer? Jesús Barrasa has written the manifesto . The knowledge layer for enterprise AI – Neo4j Graph Intelligence Platform https://neo4j.com/blog/agentic-ai/enterprise-knowledge-layer/ This is the first chapter of the enterprise knowledge layer: a series that builds a complete knowledge layer end to end, one layer per chapter, with the design thinking, the data, the model, and the code. This chapter builds the foundation: the operating structure. Who is accountable for SMB lending? The question sounded harmless. Rosa Delgado, AcmeBank’s head of Risk & Compliance, was walking a lending review and asked who was accountable for SMB lending. Three answers came back within a minute. - Callum Ashworth, who runs SMB Banking, said it sits with him. - Someone from Operations said it had been Eleanor’s until January, but then she left. - A third voice suggested it was really Credit Risk’s call anyway. Three answers. All plausible. None of them usable in a review that needed one name to register risk’s ownership. Someone opened the org chart to settle it. It was a slide deck, last edited before the operating-model refresh. Eleanor was still on it. And this is just one of many examples where enterprise knowledge isn’t retrievable or actionable. The pattern is always the same: the organisation knows the answer, but the answer lives in people’s heads and stale slides or hidden behind complex systems. And this is just the tip of the iceberg, if we want to build agents that can do work, execute a process rather than just answer questions about it, they need exactly what that review needed: who’s responsible for what, who to hand off to, who to escalate to when something’s off. If the team couldn’t get a straight answer, an agent has no chance. This article is the first of the series : the operating structure of the enterprise knowledge layer, modelled as a graph at our fictional bank. AcmeBank and all names, characters, organisations, systems, and events in this series are entirely fictional By the end you’ll have an understanding of what this layer is, how to design it and, as an example, AcmeBank’s business units, teams, roles, and people loaded into Neo4j, which will help you in answering Rosa’s question with one simple query. Here’s the shape of what’s ahead: - Meet the bank - What this layer is - How to design it - What it’s worth to the business - What lives in it - The build Meet the bank AcmeBank is a mid-size retail and SMB bank that grew through acquisitions and it wants what most enterprises want right now: AI that does real work. Agents that answer customers, move cases along, help approve loans. It has the ambition and the budget. What it doesn’t have is a business representation that AI can actually understand, because nothing was ever fully consolidated, and different systems and different terminology coexist across the organisation. Acquisition on top of that history explains most of the challenges organisations are facing today: systems that all spell “customer” differently, a definition of churn nobody agrees on, and a loan approval process that lives in three people’s heads. The bank has six business units: Retail Banking, SMB Banking, Operations, Risk & Compliance, Data & Technology, and Marketing. What this layer is Why a using graph network at all for the operating structure? Because an operating structure is one. Units contain teams, roles report to roles, people fill roles, and almost none of it is neatly one-to-one. In a relational store you reconstruct that shape with join tables and recursive queries; in a graph you just store the shape and navigate it. When the questions are “who’s accountable, through whom, since when”, the answer is a graph. The operating structure layer answers one family of questions: who and what? Which units exist, which teams sit inside them, which roles are scoped where, who fills them, and who reports to whom. Every organisation already has this information. What it usually doesn’t have is this information in a form that can be queried . An org chart in a slide deck is meant to become stale data: it was true the day someone exported it, it drifts from reality immediately, and the only interface it offers is “look at it”. A live graph of the same facts is live context. There is a single, time-stamped version that serves both humans and agents needs from an operational structure. An agent that acts inside your business needs to know whose authority it acts under, who owns the thing it’s about to touch, and where to escalate when it’s unsure. All of that resolves to operating structure. You can’t govern agents with a stale slide. How to design it So how does this layer get fed, and who consume it? The diagram above is the whole chapter in one diagram. On the left sit your systems of record : Workday, BambooHR, your identity provider, or whatever else you run. What crosses into the graph is a mapping, not a mirror: HR rows come in through governed ingestion and become the things we modelled in this chapter, roles, teams, reporting lines, validity dates. The middle box is where the governance lives , and it’s doing four jobs on every write. - Scheduled sync or change capture gets the data in, per source, at whatever cadence each source deserves. - Entity resolution collapses one person with three spellings into one person in the graph. - Provenance gets stamped at write time: source, extraction date, confidence, so six months from now “where did this come from?” is a property lookup rather than a large research project. - And every write is validated against a graph schema we will set later. Writes that don’t fit are rejected. That last one matters more than it looks: it’s the difference between a graph you trust and a graph you check. The data then gets into your knowledge layer, the graph itself, and this chapter fills only the first layer but we will cover the data model later in this article. The dashed box underneath is the rest of the series: processes, ontology, data products, physical systems, tools and agents all attach to the structure we’re loading today, in the same graph, through the same governed write path. The payoff is on the right , and it’s the reason this is one graph rather than three exports. Agents will call this layer as tools and feed their traces back into it, though that story belongs to chapters 06 and 07. People and applications ask it who owns what, right now or as of any date. And audit gets the question this whole chapter has been circling: who was accountable, and when. Same graph, same path, three very different readers. What it’s worth So what does this buy the business? If you’re the person funding this layer, here are three key returns: Ownership clarity, on demand. Every review, audit, and incident at a large organisation starts with some version of Rosa’s question, and the cost of answering it from heads and slides is measured in meetings. A queryable structure turns “who’s accountable for X” from a discussion into a lookup, and “who was accountable for X last year” from an argument into a two-row, instant result from your agent. A precondition for governed AI. The moment agents act inside your business, “whose authority, what scope, where to escalate” stops being an org-design nicety and becomes a control requirement. Those answers have to be machine-readable, current, and trustworthy, a slide is neither. This layer is not the whole of AI governance, but no AI governance works without it. Tribal knowledge, made visible. AcmeBank’s org chart didn’t blink when Eleanor left; the graph shows a closed interval, a named successor, and a start date. What it can’t yet show is what she knew, the loan approval process that partly left with her. Making that explicit is the next layer of the architecture, and the fact that a structure graph can point at the gap is itself worth having: you can’t manage the knowledge you can’t see leaving. How it connects This layer is the top of our enterprise knowledge stack, so nothing sits above it. Everything sits below. In the next article Processes , work starts flowing through this structure: - processes hang off the business functions we just loaded, - tasks get performed by the roles, - handoffs and escalations run along lines this graph already knows. Further down the article series, tasks will read data products, which is the moment structure, work, and data become one connected model. The units, business functions, and roles we shipped today are the anchor points for all of it. What lives in it? Organisation AcmeBank , the company. BusinessOrganisation covers the bank’s divisions and its teams. Each carries validity dates, and PART OF relationships nest them into the hierarchy. BusinessFunction names what a unit does: - SMB Lending, - Payments Operations, - Credit Risk, and so on. Functions attach to units via HAS FUNCTION , and they’ll become the hooks that later chapters hang processes on. Role is a position, not a person: “Head of SMB Lending” with a title and a seniority . Roles are SCOPED TO an organisation and REPORTS TO other roles. The reporting lines live here, between roles, not between people, and that’s deliberate. More below. Person is a human being with a name , a title , and a status of active or inactive. People fill roles via FILLED BY , belong to organisations via MEMBER OF , and lead them via LEADS . Four key decisions This business operations layer looks trivial but is where org modelling most often goes wrong and here are four key decisions from production experience: Model to the depth you’ll maintain. AcmeBank’s graph goes from the, then six bank , then twelve units , and stops. No sub-teams, no dotted lines, no matrix overlays. The temptation is to mirror the HR system verbatim, and we’ve watched that fail everywhere it’s been tried: the HR extract is a system of record for payroll, not for teams meaning , and a graph that copies its every cost-centre quirk will become harder to query and maintain. Model the structure people and agents actually reason about, and stop one level before you’d start guessing. Model roles, not people, as the load-bearing nodes. Reporting lines connect roles. Task & Process ownership from the next article onward will connect to roles. People connect to roles through FILLED BY relationships . This is what makes the model scale: AcmeBank’s graph has about 30 roles and about 60 people, and if the bank had 60,000 employees the schema wouldn’t change at all. Only the roster gets longer, because a role like ‘SMB Loan Underwriter’ is one node filled by however many people hold it. When someone joins, leaves, or moves, you update FILLED BY edges — which can also capture timeframes; the structure stays put. If your org model needs redrawing every time a person changes desks, you’ve modelled people, not structure. A Role is an abstraction that both humans and agents can fill. Notice that FILLED BY edge points at a Person here, and the schema quietly allows something else in that position too. Later in the series, agents will fill roles through exactly the same relationship, with the same validity dates and the same reporting context. That single design choice, encoded in the schema itself, is what lets agents in part 7 inherit accountability instead of duplicating it. Put validity dates only where history is a real question. It’s tempting to timestamp everything, and I’ve seen where that leads: a model where every edge carries dates and becomes harder to maintains or uses any of them. AcmeBank puts validity on the three relationships a reorganisation would redraw: which org is part of which PART OF , where a role is scoped SCOPED TO , and who fills it FILLED BY . The dataset uses one uniform date, defaulted to the bank’s last operating-model refresh. One asymmetry worth noticing: Relationships without validity dates hold current facts only, so when a fact stops being current, the edge goes away. History lives exactly where we decided history lives, and nowhere else. Building this architecture Time to create our knowledge layer. The requirement: Neo4j 2026.02 or later, Enterprise Edition and Cypher 25. One concept we will be using deserves a proper introduction: graph types . A graph type is a schema you can enforce in the database itself: which node types exist, which properties they carry, and which relationships are allowed between which entities. See the graph types documentation https://neo4j.com/docs/cypher-manual/current/schema/graph-types/ for the full picture. Everything in this article is loadable, it ships with: 01-create-graph-type.cypher https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter1/01-create-graph-type.cypher , the series graph type Neo4j 2026.02+ Enterprise Edition 02-load-data.cypher https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter1/02-load-data.cypher , this chapter’s dataset. 03-queries.cypher https://github.com/msenechal/enterprise-knowledge-layer-series/blob/main/chapter1/03-queries.cypher , every query you can run against this graph to get value from this layer and answer the initial question. In order, execute: Run the graph type 01-create-graph-type.cypher on an empty database, then load the data 02-load-data.cypher . The graph type is the contract for the whole series, and every chapter will add to it. And here is what the graph looks like once loaded: The full dataset is composed of 18 business organisations, 10 functions, 32 roles and 58 people, which can easily scale up following the same model. Asking it questions Before we start, all the queries below are available in the same repository in the chapter1 03-queries.cypher Now the payoff. Rosa’s question, the one that got three answers in the meeting: who is accountable for SMB lending today. One row: Head of SMB Lending, Yusuf Rahman, active. One name against one line of the risk register. That’s the whole chapter in a single query result and this is a simple graph traversal an agent can span as we will demonstrate towards the latter chapters of the series. And the part the slide deck could never do, the history: who has held this role, and when? Two results: - Eleanor Fairbairn, inactive, 2023–01–01 to 2026–01–01; - Yusuf Rahman, active, 2026–01–01 and open. The org chart forgot Eleanor the day someone deleted her box. The graph remembers exactly what she held and exactly when she stopped holding it, which is the difference between an org chart and an organisational memory. Reporting chains are a traversal, trivial for graphs, very hard for other technologies, Here is for example the chain of command above the SMB Loan Underwriter team : SMB Loan Underwriter team’s chain comes back in one hop-list: Head of SMB Lending = Head of SMB Banking = Chief Executive Officer. The same query works from any role at any depth, which is what “queryable structure” means in practice. And one forward-looking example, phrased the way an agent would need it: “I’m about to act on an SMB lending matter; whose authority applies and where do I escalate?”. An agent that can ask it before acting is governable. An agent that can’t is guessing. What’s next Here’s the question today’s graph still can’t answer, and it’s the one the meeting actually needed: who owns the loan approval Process ? Not the unit, not the role scope, the process itself: the sequence of tasks, who performs each step, where the handoffs are, and where it stalls when Eleanor’s know-how is missing. Ownership of work belongs to the process layer, and that’s in the next article: Processes. How the work flows, task by task, handoff by handoff, in the same graph you just loaded. As a next step before then, I suggest you try two things. First: swap AcmeBank’s units, teams, and roles for a slice of your own organisation, load it, and run the reporting-chain query. If it comes back clean, you’ve just built something your slide deck could never be. Then give the layer its first agent. The official Neo4j MCP server https://neo4j.com/docs/mcp/current/ connects any MCP-capable client, Claude, Cursor, VS Code, take your pick, straight to your database. Point it at your graph, run it read-only, and ask Rosa’s question in plain English: who’s accountable for SMB lending? Then ask who held the role before them, and watch it use the validity dates without being told they exist. No Cypher query to know on your side, no special prompting, just an agent reading structure you built. Articles 06 and 07 of the series will explain tools and agents properly, but this is the fastest way I know to feel the difference between an org chart and an organisational memory. Resources: The knowledge layer for enterprise AI – Neo4j Graph Intelligence Platform https://neo4j.com/blog/agentic-ai/enterprise-knowledge-layer/ GitHub – msenechal/enterprise-knowledge-layer-series: Repository holding all the assets for the Medium series of articles on enterprise knowledge layer design and build https://github.com/msenechal/enterprise-knowledge-layer-series The enterprise knowledge layer: Operating Structure https://medium.com/neo4j/the-enterprise-knowledge-layer-operating-structure-93f5a68f94cf was originally published in Neo4j Developer Blog https://medium.com/neo4j on Medium, where people are continuing the conversation by highlighting and responding to this story.