The Architecture: Queue, Workers, Knowledge Graph

Enterprises do not struggle to give AI systems access to their data. They struggle to do it in a way their security team can approve, their auditors can verify, and their operators can shut off. The distance between a promising agent demo and a production deployment is almost entirely made of those three requirements, and bridging it is an architecture problem rather than a model problem.

This article begins a series that walks through that architecture one piece at a time, following the design I laid out in Intelligent Business: A Modular Approach to AI Integration. The whole system reduces to three pieces of core infrastructure, organized into six layers that keep them safe. This entry is the map. The rest of the series explores the territory.

The event queue

At the center of the system sits a central event queue, and the whitepaper’s analogy is worth developing fully because every later entry leans on it. Think of the queue as a secure message sorting line, with tasks represented as different colored envelopes. Workers watch the line for their assigned colors. When one appears, they open the envelope, attempt the task inside, and report the result back to the line.

Each envelope carries everything required to complete its task: routing labels, instructions, the necessary data, and, critically, the authorization that says which human requested the work. And the envelopes are never destroyed. A message that is missed, malformed, or fails in processing remains on record, where it can be retried, analyzed, and produced as evidence for audit and compliance requirements.

That last property is easy to read past and is doing the most work. Because every task enters the system as a durable, replayable message, the queue is simultaneously the system’s transport and its memory of intent. When someone asks what the system did last Tuesday and on whose authority, the answer is not reconstructed from scattered logs. It is the queue’s contents, replayed.

The workers

Workers claim messages from the queue and complete tasks, and their configurations vary as widely as business requirements do, from subsecond formatting jobs to complex analysis runs. Some workers are AI agents. Many are not, and the design treats this as a feature rather than an accommodation. A serverless function that reformats documents and a scheduled batch job claim tasks from the same queue, and they carry the same identity, permission, and audit requirements as any agent.

This uniformity is one of the framework’s quiet advantages. There is one audit spine for every automation, intelligent or not, which means governance does not fragment into an AI regime and a legacy regime that drift apart. Workers can reach internal and external tools, and they are monitored for resource consumption and error rates, because a worker that fails quietly is a worker that will fail expensively later. The economics of running this fleet, including why metering matters from the first day, get a full entry later in the series.

The knowledge graph

Among the tools available to workers is a connection to permissioned company knowledge graphs. The graph charts the nouns and verbs of the business, each data point a star and each relationship a line in a constellation the system can traverse, and it returns answers that are reliable, recent, and grounded in governed data rather than in a model’s memory. I introduced the concept properly in Knowledge Graphs Explained, and in this architecture it plays a second role beyond answering questions: it is the trusted reference that AI output gets verified against before that output is allowed to matter.

Six layers around three pieces

Queue, workers, and knowledge graph describe what the system does. Deploying them safely requires organizing the machinery into layers, and the framework uses six, each with a discrete function that can be replaced independently as technology changes.

Layer 1, agentic workstations and local memory, is the digital workspace where agents originate: an isolated sandbox with tracked token allocations, where every action is already linked to a named human operator.

Layer 2, the trust and policy boundary, is the gatekeeper. It verifies identity and credentials, enforces policy, and validates every tool invocation, ensuring nothing mutates core data without passing through an audited write path. This layer gets the next entry in the series, because it is where the zero trust discipline lives.

Layer 3, the messaging and execution backbone, is the queue and worker fleet described above, carrying reasoning, tool calls, and events on authenticated infrastructure.

Layer 4, caching and near-edge memory, is the high-speed tier that serves validated answers from semantic cache rather than triggering new inference, which reduces both latency and model spend.

Layer 5, the knowledge, temporal, and audit store, is the durable memory: temporal graphs that remember what was true and when, alongside read-only log storage. This is where compliance becomes a chain of custody rather than a quarterly scramble.

Layer 6, ingestion, discovery, and aggregation, is the foundation that feeds everything above it, governing data intake, decoding, and classification at the source.

A request moves through these layers in a fixed pattern. It originates in an isolated workspace at the untrusted edge, passes the gatekeepers before any action, rides the backbone to either a cached answer, a governed data query, or a predefined automation, and leaves a permanent record in the audit store at every step. The full lifecycle, traced end to end with a worked example, is the finale of this series.

Why the shape holds

The layering is not decoration. It exists to decouple rapid AI innovation from operational risk, so that agents can move quickly inside a structure whose control points are deterministic and strict. It also exists to prevent structural obsolescence: because each layer manages a discrete function, an organization can swap the underlying model, queue technology, or graph store as the market changes without rebuilding the system around it. The tools at every layer are interchangeable. The foundations are not.

The series continues with the trust and policy boundary, where identity, least privilege, and the audited write path get the detailed treatment they deserve. If you are deciding whether this architecture fits your organization, the entry point does not require any of this infrastructure yet. It requires the readiness work described in The First Step Is a Meeting, because every layer above assumes data worth trusting, and that assumption is earned in a conference room first.