W3C Holon Community Group — Inaugural Meeting
Keynote Presentation Transcript
Kurt Cagle
What I wanted to do today was introduce what we’re here for. I want to talk a bit about what the Charter looks like — I’ve sent links into the Charter proposal — but really I want to talk about what a Holon is.
A lot of people have been asking that in various frames. And to be honest, this is my interpretation of an idea that’s been floating around for about 60 years.
What I’d really like to do today is narrow down on a lot of the administrivia and then figure out what we actually want to do as part of this whole process. I’ve got open nominations, but let me do my presentation first, and then we’ll slip back and talk about chartering, nominations, and how we want to work them in.
I’m also doing a recording, and I’ll make sure links to that recording are up and available so that people can take a look at it and get their favourite LLM pointed at it for analysis.
Foreword and Introduction
Back in about 1968–69, Arthur Koestler wrote a series of books, one of which was The Ghost in the Machine. I’ve always loved that particular title, because it captures so much of what we’re talking about when we talk about artificial intelligence — what exactly is the difference between the physical, the grounding, and the metaphysical, the anima that effectively makes up what we as humans can do.
Everyone has gone through the last four or five years of neural nets and large language models, watching them get more and more powerful. But one of the things we’re discovering is that they don’t stay on task terribly well. You have to spend a huge amount of compute power — which translates into money — to manage this. And the challenge is that there’s a lot you can do with this freeform daydreaming, which is really what I consider most LLMs to be. But like any daydream, it’s something you have to impose structure on.
Holons are one way of thinking about that structure.
What Is a Holon?
When we talk about a holon, we’re talking about a notion that’s been around for a long time and can be traced back to various philosophers. The idea, effectively, is that you have systems within systems. You start talking in terms of organisation, geography, medical systems — and a lot of these come down to the fact that systems have a real desire to encapsulate.
Encapsulation means: I have a system that is essentially complete, but I can look at it from the outside. And when I look at it from the outside, it looks different from the way it looks on the inside. Why does it look different?
Koestler answered this. At its core, a holon is something that is simultaneously a complete whole and a part of something larger. He coined the term from the Greek holos, meaning whole, and the suffix -on, meaning a particle or part — the same root we have in the word ontology.
He saw them as Janus-faced entities. You can’t really look at them as one or the other; you have to look at them as both. In The Ghost in the Machine he wrestled with that problem: how do you deal with something that’s both autonomous and dependent at the same time? The answer is that you have to always think of these things as simultaneously both.
You need a name for that. You need a concept for that. And that’s really where holons come in.
Tensegrity and Emergence
A holon can be thought of in terms of two kinds of tensions. This takes us back to R. Buckminster Fuller and his concept of tensegrity — the idea that structures are animated and stay constructed primarily through opposing forces. That’s the same opposing-tendencies idea that Koestler was talking about, and which Feynman was exploring when discussing how particles move in space-time.
We see this notion everywhere: a cell as part of an individual, as part of a team, as part of an organisation, as part of a society. That part of, part of, part of relationship builds into the overall environment. In each case, we’re dealing with a hierarchy of contained systems — a wholarchy — where each level is real in the sense that it’s organisational, but each operates at a different scope.
We’ve been dealing with wholarchies for a long time. We just call them intransitive closures. We call them trees. Each level is equally scoped, and because of that, there isn’t necessarily a top. The biggest container is, in principle, the universe — or the multiverse, if you want to get all Marvel about it. But the important characteristic is: as you get larger, you get more generalised; as you get smaller, you get more specialised.
If you don’t have an absolute top or bottom, you always have to say, this is my boundary. And boundaries become very important when you start talking about holons.
Emergent Properties
Each level brings something new. New properties emerge at each level of the wholarchy — properties that the parts don’t have on their own. Molecules have the concept of whiteness; individual atoms don’t. Hydrogen is volatile, oxygen is highly volatile, but put them together and you get water, the exact opposite of volatility. Neural networks generate thought; individual neurons don’t think. Communities produce culture; an individual genome doesn’t.
This is actually one of my problems with classical inheritance-based views of class hierarchies. Not all class relationships are inheritance relationships. You have holonic boundaries between what is inside a function and what is outside it, and you get an assembly that builds up: function to module to library to application. Each has properties that simply cannot be found in the components — they’re emergent, and they’re emergent in specific ways.
Software is essentially holons by design. Functions, modules, services, applications, platforms — they’re made in units, they’re self-contained, and they’re composable. We’re doing that same thing now at the microservices level, and at the MCP level, with AIs as compositors that pull things together.
Key takeaways:
Wholeness and partness are always relative, never absolute.
New properties emerge at each level of the wholarchy.
Healthy systems balance autonomy and integration — the two must co-exist.
The pattern appears across every domain: nature, organisation, technology.
Why Now?
Why is everyone suddenly talking about holons, context graphs, and all of these pieces?
First, flat knowledge graphs aren’t enough. They’re necessary — they describe what is in the system and how things relate — but they’re not by themselves sufficient. Knowledge graphs don’t represent time very well. We’ve always concentrated on things and treated relationships as relatively static, but if you look at the real world, any relationship carries enormous metadata, and flat graph structures can’t condense all that complexity, nor how those relationships change over time.
I’ve been using the term context graphs primarily as a way of talking about the annotational aspects, including time, that make up the full picture.
Second, the AI integration moment. Everyone is working with LLMs, everyone knows the term hallucination. An LLM is not a database. It’s a giant pattern-matching system built around language, not unlike XSLT or regular expressions — a way of saying that language develops patterns, and those patterns can be used as templates to generate narratives. Because of that, it tends to hallucinate when the scope becomes too large. You need to train it — or constrain it — in such a way that the information you’re dealing with is much smaller and more focused.
RDF 1.2 is working its way through the standards process. SHACL is a constraint language, and constraint becomes very important here — it says what things can and can’t do, and especially what they can’t defines a boundary. MCP is an architecture that allows you to wrap services declaratively so that you can pull information in. These tools make grounding possible.
Third, standards. We create standards because everyone is doing something similar but can’t get a foothold on the foundations until they agree on core terms and definitions. I have my own ideas about what constitutes a holonic system — the HGA, or Holonic Graph Architecture. But that’s not the only idea. A lot of you have come to me, or come to one another, saying we’re developing things that sound increasingly like they overlap. We’re discovering object-oriented programming all over again.
And this is not a moment for a single implementation. The assumption underlying this group is that we’re going to create a pattern and a template that describes the commonality people can utilise, so that when they go and create their own implementations, they can work with one another, connect, and create a network. This is why we’re moving into a federated architecture — shared conventions, messaging, interoperability. The W3C is very good at exactly this kind of definition work.
Lateral Connections
Containment is critical, but so is the notion of lateral connections. If I have things within a holon, they still have to network with one another. Think of rooms connected by hallways or doors. Those connections are not necessarily fixed — if I do a reorg in a company, interactions continue but what I’m interacting with changes. If I remodel a house, how rooms connect changes.
This is really where we start getting into semantic graphs and interrelated concepts. And interestingly, once you get into this in depth, you realise that a property is simply another holon. A property is a set of rules connecting two things, and the connection between them is itself an environment.
Lateral connections allow navigation. This is essentially how the web works. If you have a mechanism that allows these connections, you have a way of navigating across a conceptual information space in a constrained, controllable manner.
Named Graphs as Holons
A holon can be represented as a named graph. When you’re dealing with a holon, you can say: these are the assumptions, the triples, that are of concern to me, and they’re contained within a container — a named graph — that has its own identifier. If you have that identifier, you have a way of identifying that holon.
The named graph is a natural extension of this. It contains information, it creates a boundary, and that boundary has rules about how you cross it — about what it means to move information between this graph and another. We get so hung up on the graphs themselves that we forget: graphs are structures, and those structures imply rules for how you move information from one system to another.
A named graph can be temporal. I can say: I have a named graph, and every event that occurs, the things within that graph will also be affected. That’s a historical record. And if you then say I have containment in the form of the named graph, and I have temporality, then that thing has persistence. It has something that maintains its cohesiveness, and because it’s named, you can refer to it, and if you can refer to it, you can manipulate it.
Agents
Once we take that notion of a temporal named graph, we begin to talk about agents. I want to make this abundantly clear: when I’m talking about an agent in a holonic context, it is not the same thing as the AI agent concept most people are working with. AI agents, at this point, are basically wrapped API calls — orchestrators with some characteristics we associate with agents. But at the graph level, we need to think about it differently.
Agents are nodes within the graph whose state changes over time. They create a trajectory within the holon. The classic example is a player character in a D&D game walking through a dungeon, interacting with monsters, collecting treasure. That’s an agent — it’s changing over time, interacting with other agents. Every monster is an agent. Every interactive object can be an agent.
An agent is an observer. It’s something you can watch and measure within the holon. Each time an agent changes state, it initiates an event. The complete sequence of events for a given agent is its trajectory — its path through state space over time.
What differentiates an agent from a plain entity? Essentially, it’s that with an entity, you don’t care about what it’s doing. All agents are entities in their own right, but the agent has a flag that says: we’re going to track this. It has autonomy, or limited autonomy, and we’re interested in its state changes.
The same entity can exist in multiple contexts simultaneously. An employee may be significant to both an HR holon and an R&D holon, but for entirely different reasons. The HR holon cares about benefits and roles; the R&D holon cares about publications and product integration. Same entity, different contextual representations. This shared referencing across contexts is one of the reasons RDF is such an apt fit for this architecture.
The Four Aspects of a Holon
Every holon consists of four distinct partitions:
1. The Scene Graph The things currently in focus — agents, components, initial information. It’s the starting condition: the knowledge graph of this particular system. Think of it as the cast list and props of a play, or the starting conditions of a game. It’s essentially the stage upon which everything happens.
2. The Event Graph The evolution over time, maintained as an event log. It captures what changes: what a character says, how they move, what they do. More generally, it captures mutations — the agent becoming enlightened, growing frustrated, gaining or losing capabilities. Agents can be invalidated: the orc is dead and won’t get up again unless someone intervenes. There’s also a clock — different systems may have different clocks, but the clock is essentially a generator of events, an agent in its own right.
3. Boundaries Constraints that determine how the system evolves. What can you do? What can’t you do? A person in a play can walk through a door but not through a wall. These are restrictions, not necessarily physical ones. This is where SHACL comes in — not just as a validation standard, but as a mechanism for maintaining boundaries.
A portal is essentially a SHACL constraint that says: you can pass because you have the key; you can’t pass because you don’t. There’s an important distinction in RDF notation: a constraint is a restriction, while a rule is a creation — the generation of new facts.
4. Projection Layers Different views of the same holon, each representing a different observer’s perspective. A projection is a camera or sensor array — a designated observation point. If I have a railway system, a projection might be a map showing where the trains are at a given moment. It’s not a static view; it evolves over time.
Crucially, you never actually see what’s inside the holon — largely because it’s conceptual. What you see is the projection: the effects of the holon, its external representation. A camera is an interface between internal state and external representation, and it’s scoped, persistent, and composable.
There’s a symmetry worth noting: a portal connects two holons; a camera connects a holon and an observer. Both carry the effects of evolution. And federation connects projections, rather than simply merging graphs.
Open and Closed Holons
A holon is either open or closed.
An open holon is still accepting events. It’s a dynamic system, taking signals and converting them to output, validating input, and presenting a dynamic view.
A closed holon is a historical system — a record. This transcript, for example, is a closed holon. The meeting is done. It’s no longer malleable, but we can review it and walk through its key points. A closed holon no longer accepts events.
How Holons Evolve
There are several mechanisms by which holons evolve:
Bayesian priors — actions informed by previous behaviour. Holons use history to anticipate what to do next.
Active inference — measures surprise: the degree to which the expected state differs from the actual state, driving toward reduction of uncertainty. In a simple system, everything eventually becomes fully known. With multiple agents each generating their own surprises, what you get is considerably more volatile — each agent is trying to minimise its own surprise, sometimes at the expense of others doing the same. Any board game is essentially an example of this.
State machines — rule-based transitions: when in state A, go to state B when condition C is met.
External actors — agents controlled from outside, either by a human or another system. The actor drives; the agent is driven.
DataBooks
A DataBook, to use the term generically — I have a specific definition in the architecture documents — is a mechanism where Markdown becomes a substrate. Each document contains a metadata header that describes the provenance and purpose of that document. The header gives you information about what the document contains. Not all DataBooks are holons, but you can represent a holon as a DataBook. It’s a way of putting together narrative, metadata, and code blocks in a consistent way. It’s useful because it becomes a messaging environment — a messaging platform. It’s part of the reason I developed it: I needed a way to talk about messaging between systems.
Grounding LLMs with Holons
My core contention is that a major cause of hallucinations is a lack of scoping. When you try to boil the ocean — make a request across too broad a domain — there are too many possible answers, too many permutations of information. If you can limit that scope, if you can say, these are the things, these are the events under which these things change, then you have a mechanism for controlling how the system operates. You’re grounding it. You’re creating the structure over which the system can then reason.
I ran a simulation back in February called the Straits of Influence — given the geopolitical situations at the time, how would the system evolve? To do that, I had to say: here are the constraints, here are the optimisation parameters, here are the priors and historical evolution. What came out was surprisingly close to what actually happened. When you get all of these things together, you can really harness the power of LLMs to create very focused, reliable outputs.
Holons provide that scope. DataBooks are the mechanism for passing those holons into a system: this is your rulebook, deal with it as you will, but it has to follow these rules. This doesn’t completely eliminate hallucinations, but it goes a long way toward making things much more complete.
The analysis I’ve done suggests that grounding reduces cost by 95–98% compared to using an LLM as a freeform database, because token costs and time costs drop by several orders of magnitude when the LLM is operating only as a transformer against a scoped, structured input rather than as a retrieval system.
HolonBridge
I have another concept called a HolonBridge — still being developed — which is essentially what allows you to create a connection to a persistent store. Right now these are primarily triple stores or RDF stores, but they could be Neo4j or other databases. The key is having a persistent store capable of holding this kind of information. Especially when combined with agentic systems in chat, this allows you to communicate intent to LLMs using holons as a core knowledge base, keeping systems cohesive by always returning to the holon for grounding.
Application Domains
Holons can be applied to: media and gaming, decision support, supply chain management, medical system monitoring, drone and robot traffic management, journalism and education, marketing and market tracking, financial system monitoring, and distributed private data management. The list goes on. Nobody here is going to be able to develop all of these. But there are endless possibilities for how these principles can be applied.
Goals for This Group
To wrap things up, these are the goals I’d like to see for the Holon Community Group:
Refine the models — establish a shared, rigorous definition of holonic architecture.
Establish conventions for messaging and holon-core architecture.
Identify implementations and points of commonality between existing approaches.
Develop the foundations for a federated, distributed data web built on top of the World Wide Web.
The pieces are already in place. We’re not creating new infrastructure from scratch; we’re building augmentative patterns on top of what exists. The focus is on interoperability. RDF 1.2 will likely feature heavily, because it’s very well suited to describing specific data precisely — but that doesn’t preclude other implementations. What we’re doing is establishing the core terminology and conventions.
We’re a community group operating at the sufferance of the W3C. My hope is that down the road, when we have something solid enough, we can pass those parts to the W3C for consideration under due process. Community groups are for getting the actual working of things squared away; then you test it, put more rigorous foundations on it, and seek endorsement.
IP rights are also something we’ll need to hash out. The W3C has core specification norms we’ll probably want to align to, and that’s one of the things to work through in the upcoming meetings.
Proposed Working Groups
I’d like to set up formal working groups around five areas:
Core Architecture — defining the components: scene graph, event graph, boundaries, projection layers, portals, cameras.
DataBook Standard — the document format as a messaging and knowledge substrate.
Network Architecture — how holons integrate with the web and with federated systems.
Validation, Verification, and Security — constraint languages, verification rules, security boundaries.
Industry Utilisation — applied use cases and reference implementations.
If there are areas not covered by these, please bring them up.
Meeting Cadence
I’d like to meet twice a month on alternating Fridays. Given that we have members across Europe, the Americas, and increasingly Asia and India, I’m thinking about a schedule that accommodates different time zones — with a third session as needed to make things accessible to those not covered in the primary block.
Thank you for your involvement. Hopefully we can make something magical.
Transcript of the W3C Holon Community Group inaugural meeting, June 19, 2026. Edited for clarity.
