The Agentic AI Operating System — EY's Blueprint, Translated to SMB Scale

What EY Actually Built

EY's internal disclosure describes a unified agentic AI platform — branded EYQ — deployed to its global professional workforce as secure enterprise chat, domain assistants, governed prompt tooling, and a controlled environment for safe generative AI experimentation across service lines. The product detail matters less than the architectural intent: turn AI from a per-team tool into shared organisational capability. The connective tissue is what distinguishes EYQ from any individual AI feature. Anyone can adopt ChatGPT; only an organisation that built the connective tissue can deploy hundreds of coherent agentic workflows on top of it.

The interesting question for SMB owners is not “could we afford to build EYQ?” — the answer is obviously no. The interesting question is “what is the connective tissue actually made of?” — because the answer is “four small components, none of which are expensive at SMB scale.” The rest of this article is what those four components look like for a 10-100 employee business.

Component 1: The Shared Knowledge Layer

Every AI agent needs facts. Where the facts live, and how the agent retrieves them, is the single most consequential architectural choice. At enterprise scale, this becomes a vector database fed by content pipelines from dozens of systems. At SMB scale, the shared knowledge layer is much simpler — a Notion or Confluence workspace with three structured sections: company facts (services, pricing, policies, FAQs), operational SOPs (how each workflow runs, who owns what, escalation paths), and customer-facing language (approved phrasing, brand voice, what we do and do not say).

Crucially, the knowledge layer is the source of truth — not the agent's memory and not the model's training data. Agents pull from the knowledge layer at run time. When facts change, you update the knowledge layer once and every agent gets the new fact on its next call. Without this single-source pattern, each agent ends up with its own divergent picture of the business, and the resulting inconsistency is the second-most-common cause of agent deployment failure after vague success criteria.

Component 2: The Prompt and Policy Registry

The second component answers the question “how does each agent know how to behave?” At EY scale, this is a governed prompt and policy library with version control, role-scoped access, approval workflows, and audit logging. At SMB scale, it is a single repository — usually a private Git repo, a structured Notion section, or a tool like PromptLayer — that stores the live prompts each agent uses, the policies that constrain behaviour (tone, escalation rules, do-not-say lists, compliance constraints), and the version history.

The discipline is treating prompts the way you treat code. They are versioned. Changes are reviewed. The current production version is unambiguous. Nobody edits the prompt directly inside the agent UI and hopes for the best. This sounds like overhead; the first time an agent says something embarrassing in production and you need to know exactly what prompt was live at that moment, the registry repays its setup cost ten times over.

Component 3: The Orchestration Layer

The orchestration layer is what makes “multiple AI features” into a coherent system. It is the workflow engine that decides which agent runs when, what each agent passes to the next, where human review enters the loop, and how exceptions are handled. At enterprise scale, this is often custom-built. At SMB scale, off-the-shelf workflow tools — n8n (self-hosted or managed), Make, Zapier with its native agent capability, or workflows built directly on top of HubSpot, ClickUp, or Slack — handle the orchestration well enough for the next several years of growth.

The key architectural rule is that the orchestration layer is the integration layer. Agents do not call each other directly. Agents send their output to the orchestration layer, which routes it to the next step. This indirection is what lets you swap one agent for another, add monitoring, insert human review, or rebuild a step without rebuilding the whole pipeline. Direct agent-to-agent calls feel simpler in week one and become painful in month six; orchestration-layer routing is one extra hop that pays back permanently.

Component 4: The Monitoring and Review Layer

The last component answers the question that ultimately decides whether the system survives: “how do we know it's working?” At enterprise scale, this becomes an observability stack with model-quality metrics, latency monitoring, drift detection, and human evaluation pipelines. At SMB scale, it is much simpler: a dashboard tracking the day-90 metric you set as the definition of done, a log of agent decisions for the previous seven days, an error-routing pathway for cases the agent cannot handle, and a weekly 15-minute review where the owner of each workflow looks at recent runs and decides if anything needs attention.

The monitoring layer is the least exciting of the four components and the one SMBs most consistently underbuild. The pattern is predictable: the agents work, the dashboard is on someone's to-do list, three months pass, an incident happens, no one was watching, and the project loses the executive sponsor's confidence. Build the dashboard in week one alongside the first workflow. Hold the weekly review even when nothing has gone wrong. The monitoring layer is what converts a working system into a durable one.

How to Build It — A Realistic SMB Sequence

When Not to Build the Architecture

If you are running a single one-workflow AI experiment to prove whether AI fits your business, do not build the agentic AI OS. The architecture is overhead until it is load-bearing — which means until you have two or more workflows that depend on shared facts, governed behaviour, or coordinated action. The right test: if a fact about your business changes (a new product, a new policy, updated pricing), how many separate places does that fact live? If the answer is one (a single Notion page), you have shared knowledge. If the answer is “in each agent's system prompt,” you do not, and the second workflow will pay the cost.

Frequently Asked Questions