• Same agent, same tools, same evals. Only the models differed: Gemini 3.5 Flash Lite + 3.8 Flash versus Claude Haiku 5.5 + Sonnet 5.5.
• Claude passed 95% of the customer evals against Gemini's 82%, and had a third as many flaky evals.
• Claude was about 3x faster at p90 (48 s versus 161 s per turn). Gemini made 2.4x more model calls per turn, mostly small routing steps that looped.
• Gemini is cheaper per token but used 3.7x more input per turn, so it cost twice as much: $0.139 versus $0.067 per turn at real Vertex AI EU prices.
• Prompt caching cut Claude's cost per turn by about 60%. Even without it, Claude would still have been cheaper than Gemini without caching.

We run a data-analysis agent in production for our customers. It answers questions like "which deals are stuck in stage three?". Instead of writing SQL from scratch, it calls tools on an MCP server for data. Those tools read a semantic model, the shared definition of each metric.

We started the agent on Gemini and kept it there for a long time. We looked at Claude, but its per-token prices were higher, and with no way to measure quality we had no reason to pay more. That changed once we had evals: automated checks that score the agent's answer to a fixed question. For the first time we could compare models on how well they do the job, not on the price list. So we ran the same agent on Claude to see. The result was not what we expected.

We tested Claude vs Gemini for AI agents the only way that settles it. Same agent, same tools, same evals, 99 turns per model, on 26 October 2026. Short version: for this workload Claude was more accurate, about 3x faster at p90 (the time nine turns in ten finish within), and about half the cost per turn. This post is just the results.

The setup

• One agent, two variants. Same code, same tool set, same instructions. Each variant pairs a small model with a bigger one. The small model handles routing (the short steps that decide what the agent does next) and simple turns; the bigger model handles the rest. Gemini: 3.5 Flash Lite + 3.8 Flash. Claude: Haiku 5.5 + Sonnet 5.5. Both ran with prompt caching, which lets the model reuse the unchanged part of a long conversation instead of re-reading it at full price. The Gemini pair was our production config going into the test.
• Three eval suites, three runs each per variant. The eval system is still a proof of concept. The suites are the customer's own agent evals, a set of shared evals we run on our deployments, and questions real users had asked. A turn is one question through to the agent's final answer, and it usually takes several model calls. Three runs of every suite came to 99 turns per model.
• Writes stubbed. No run touched production data.
• Real prices. Cost comes from our LLM gateway's spend logs at real Vertex AI EU prices.

Is Claude better than Gemini for AI agents? The results

For this agent, yes. Claude passed 95% of the customer evals to Gemini's 82%, ran at 48 s versus 161 s at p90, and cost $0.067 versus $0.139 per turn.

Pass rate across the three suites, averaged over three runs. Gemini is ahead only on the real user questions.

Three of the real user questions, side by side. Here we count tool calls: each time the model asks the agent to run a tool, such as a metric query.

Where the gap came from: accuracy, speed, cost

Accuracy. Gemini missed the same two checks in every run and was flaky on revenue versus order intake. Those are the exact mistakes users had reported before the test, so the evals are catching real behavior. Claude's one steady failure is an eval whose pattern match is too narrow; the answer itself is fine.

Speed. The median turn is close (14 s versus 16 s). The tail is not. Gemini loops: 2.4x more model calls per turn, most of them tiny Flash Lite routing steps that go round again. On top of that, a single Gemini 3.8 Flash call took about 2.6x longer than a Sonnet 5.5 call in our traces. The "explain a deal's progression" row shows both effects at once: 40 tool calls and 209 s to reach the stage Claude identified in 14 tool calls and 51 s.

What one turn costs in time, calls, and tokens. The extra model calls are what drive the latency tail and the token volume.

Cost. Gemini is cheaper per token. It is twice as expensive per turn because it reads 3.7x more input per turn, and every extra model call re-reads the whole conversation. Caching helps both: it saved Claude about 60% and Gemini about 74%. Even so, Claude without caching ($0.175) came in not far above Gemini with caching ($0.139), and far under Gemini without it ($0.536). For an agent, cost per token is the wrong unit. Cost per finished turn is what shows up on the invoice. It is the same lesson we drew about token capital: the budget buys answers, not tokens.

Cost per turn with and without prompt caching. Claude uncached ($0.175) lands close to Gemini cached ($0.139).

No mix wins. The cost breakdown rules out a Gemini-for-routing, Claude-for-reasoning split. Haiku 5.5 is already cheaper than Gemini 3.5 Flash Lite and makes up only 6% of the Claude variant's cost. Sonnet 5.5 is the other 94%, and caching is already on. There is no cheaper piece to swap in.

Caveats

• Claude is not spotless. In one run it sent a read query through the write tool. Writes were stubbed, so nothing happened, but we are adding a line to the tool descriptions and watching for it in production.
• Two customer evals are too strict. Their pattern matches reject answers that are correct. One of them is Claude's single steady failure, so Claude's pass rate is a little lower than its answers deserve. Both models were scored against the same checks, so the comparison holds. We are widening them.
• This is one workload. A data agent that makes many tool calls against a semantic model is not every agentic workload, and the ratios will differ elsewhere. We have argued that the setup around a model matters more than the model itself. On this setup the model still moved eval pass rates by 11 to 13 points, p90 latency by 3x, and cost by 2x.

What we are changing in production

We are switching the agent to Claude by default: Haiku 5.5 for routing and simple turns, Sonnet 5.5 for the rest, caching on. We expected to confirm the cheaper models and move on. Instead, the smaller Claude models made fewer mistakes and needed fewer tokens to finish a task, so they were cheaper too. The test turned "we assume this is right" into numbers we can show a customer who asks why. If you are choosing a model for an agent of your own, copy the shape of the test rather than the winner: the same agent, the evals you already trust, real prices, and cost and latency per turn.

Frequently asked questions

Is Claude better than Gemini for AI agents?

For our agentic workload, yes. On a production data-analysis agent, Claude (Haiku 5.5 for routing, Sonnet 5.5 for the rest) was more accurate, about 3x faster at p90, and about half the cost per turn compared with Gemini 3.5 Flash Lite + 3.8 Flash. Much of the speed and cost gap came from agent behavior: Gemini looped through 2.4x more model calls per turn. Other workloads will differ, so run your own evals.

Is Gemini cheaper than Claude for an AI agent?

Per token, yes. Per turn, no, at least in our test. An agent's cost is tokens per turn times price per token, and Gemini used 3.7x more input tokens per turn (514K versus 140K). It made 16.6 model calls per turn against Claude's 7.0, and each call re-reads the growing context. Per-token price is the wrong unit for an agent; cost per completed turn is what you pay.

How much does prompt caching save on an agentic workload?

On our Claude variant, caching cut cost per turn from $0.175 to $0.067, about 60%. On the Gemini variant it cut cost from $0.536 to $0.139. Caching matters more for agents than for single prompts because every tool call re-sends the conversation so far, and most of it is unchanged.

Would a mix of Gemini and Claude models be cheaper?

Not in our setup. Haiku 5.5 handled routing and simple turns for only 6% of Claude's total cost, and it was already cheaper than Gemini Flash Lite. Sonnet 5.5 made up the other 94%, and caching was already on. There was no cheaper piece to swap in.

Is Gemini better than Claude for AI agents?

Not in our test, but it did three things well. Its median turn was slightly faster than Claude's (14 s versus 16 s). It answered every real user question in every run, where Claude missed one once. And its per-token price is lower, which is why we ran on it in the first place. Its problems were in the tail: looping tool calls that pushed p90 latency to 161 s, and two checks it missed in every run.

How did you measure accuracy for the agent?

With a proof-of-concept eval system: three suites, each run three times per model. One is the customer's own agent evals, one is a set of shared evals we run on our deployments, and one is built from real user questions. Writes were stubbed so no run touched production data. Cost came from our LLM gateway's spend logs at real Vertex AI EU prices.

This article was originally published on the RevOS blog.

RevOS gives your agents one governed view of your CRM, billing and product data, served over MCP. Book a RevOS demo.

In our previous post, we established that the biggest barrier to Revenue AI is not the model. It is the data mess. We introduced the Medallion Architecture not just as a technical pattern, but as an operating model to manage complexity, enforce discipline, and build trust.

This installment turns strategy into execution. A fundamental shift to internalize upfront is that Fabric is SaaS, while much of the classic Azure data stack is PaaS: you provision and tune far less infrastructure, but you must operate within shared-capacity and platform guardrails. In return, Fabric integrates storage, compute, governance, and BI into one managed experience, so architecture decisions move from infrastructure wiring to workspace design, contracts, and operational discipline.

Below is a practitioner-focused blueprint for implementing Medallion Architecture on the Microsoft Fabric stack, emphasizing environment separation, deliberate schema governance, realistic capacity planning, and an architecture that remains operable as teams and workloads grow.

1. The foundation: OneLake and Delta

Most data programs suffer from a "copy-storm": the same dataset is replicated across multiple workspaces, semantic models, and storage locations. Copies break lineage, create inconsistent numbers, and inflate cost.

Fabric's anchor is OneLake, a tenant-wide data lake that acts as a shared storage plane for Fabric engines.

• Unified storage plane: Store data once and access it through multiple engines (Spark, T-SQL, KQL) without creating a second physical copy for each workload.
• Delta as the default table format: Fabric standardizes on Delta Lake, providing ACID transactions, schema enforcement, and time travel. For revenue and finance reporting, these properties are not "nice to have"; they are table stakes.

Design implication: treat OneLake as the system-of-record storage layer, and treat semantic models and reports as consumers of governed tables, not as places to quietly "fix" data.

2. The Medallion blueprint in Fabric

Medallion Architecture is not just about three folders named Bronze/Silver/Gold. The value comes from clear contracts: what each layer guarantees, what it does not guarantee, and who owns it.

In Fabric, the layers are typically realized via separate Lakehouses and/or Warehouses (and often separate workspaces) to enforce isolation, security boundaries, and CI/CD promotion.

Bronze: the raw landing zone

Bronze is your audit trail. Data lands here as close as possible to what the source system emitted.

• Core rule: Bronze is immutable and append-only. No updates-in-place, no "cleanup" that loses the ability to replay history.
• Transformations: Keep them minimal. Acceptable examples include column-name normalization for technical safety, typing of ingestion metadata, and adding load identifiers.
• Replayability: Always preserve enough metadata to reprocess (ingestion timestamp, source extraction watermark, load/run ID, source file name, record hash if needed).

Workspace design: a single Bronze workspace can become a bottleneck and a risk. In practice, consider:

• Multiple Bronze workspaces (by domain such as CRM/ERP/Product, or by business unit), or
• Logical isolation per source/domain within a Bronze workspace (separate Lakehouses, separate folders/tables, separate security groups).

This reduces blast radius and prevents a common anti-pattern: developing ingestion logic directly in a production landing zone.

Silver: the trust layer

Silver is where raw data becomes fit for business use. This is where you standardize entities, enforce integrity, deduplicate, and align definitions.

• Primary goal: create governed, reusable entity tables (e.g., Customer, Deal, Invoice, Subscription) with consistent keys, typing, and history semantics.
• Data quality gates: apply deterministic checks (uniqueness, referential integrity where appropriate, nullability expectations, outlier rules) and route rejects/quarantine for investigation.

Transformation engine choices

Fabric gives you multiple ways to implement Bronze → Silver:

• Spark-based ELT (Notebooks / Spark jobs): Prefer this when you have large datasets, semi-structured data (JSON), complex joins/transformations, heavy dedup logic, or you need scalable compute patterns.
• SQL-based ELT (Warehouse T-SQL, Lakehouse SQL endpoint, views): Prefer this when transformations are mostly relational, the team is SQL-strong, and you value simplicity and governance. SQL-only pipelines are often faster to build and easier to review, but can become limiting when data volume, semi-structured content, or transformation complexity increases.

A pragmatic pattern is to do heavy lifting in Spark where it is justified, and then expose clean relational tables for downstream BI.

Materialized Lakeviews

Materialized Lakeviews can reduce orchestration complexity by letting you declare transformation logic and have the system manage refresh. Treat them as an optimization lever, particularly useful for well-scoped, SQL-friendly transformations, but validate preview limitations and operational behavior (refresh semantics, monitoring, lineage) before standardizing on them for mission-critical pipelines.

Gold: the business and consumption layer

Gold is optimized for consumption: star schemas, curated marts, and metrics defined centrally.

• Contract: Gold is the single source of truth for consumption, meaning business logic lives here, not hidden in individual Power BI files.
• Semantic model discipline: define measures once, define dimensional conformance once, and make it the shared metric layer for dashboards and downstream AI.

Gold in Fabric: Lakehouse vs Warehouse

There is no universally correct choice. Use the engine that matches your workload and team.

• Warehouse (T-SQL): strong for structured BI, governance via explicit DDL, predictable relational modeling, and tighter control over schema and permissions. A good fit when BI is dominant and SQL governance matters.
• Lakehouse (Spark + SQL endpoint): strong for data engineering flexibility, Spark-native transformations, and unified handling of structured and semi-structured data. Often a better fit when engineering workloads dominate and you want end-to-end lakehouse patterns.

Selection criteria:

• Team skills (SQL-first vs Spark-first)
• Transformation complexity and data types (strictly relational vs mixed/semi-structured)
• Governance model (explicit DDL control vs flexible iterative modeling)
• Consumption needs (BI-first vs broader data/ML usage)

3. Environment separation and workspace architecture

A modern data strategy treats data assets like software: you need controlled change, safe testing, and predictable releases.

Dev → Test → Prod separation (minimum viable)

At a minimum, implement Dev → Test → Prod for Silver and Gold.

This prevents:

• Resource contention: development experiments competing with production refresh and dashboard queries.
• Accidental impact on production dashboards: a single inefficient notebook or pipeline can throttle interactive BI.
• Risky schema changes: breaking downstream consumers by evolving tables without validation.

Separating ETL workspaces from BI workspaces

A strong operational baseline is to separate transformation and consumption ownership:

• Bronze/Silver = engineering workspaces (ingestion + curation)
• Gold = consumption workspaces (marts + semantic models + reports)

Benefits:

• Clear ownership and on-call responsibility
• Stronger security boundaries (raw data access vs curated consumption access)
• Reduced operational risk (changes in ETL do not directly disrupt BI artifacts)

Bronze isolation reconsidered

Avoid a single "Bronze (Prod)" workspace becoming a shared playground. Instead:

• Keep production ingestion isolated, and
• Provide dev ingestion patterns either in a Dev Bronze workspace or via parameterized pipelines targeting dev storage locations.

A practical layout (expanded from the original 7-workspace idea) is:

• Bronze: Prod (and optionally Dev/Test by domain) or domain-isolated Bronze Lakehouses
• Silver: Dev / Test / Prod
• Gold: Dev / Test / Prod
• Optional Self-Service: separate workspace + capped capacity for exploratory BI

4. Capacity planning and the reality of contention

Fabric capacity is shared compute. Multiple engines (Spark, pipelines, SQL queries, semantic model refresh) can contend on the same capacity.

Why small capacities often fail in team settings

For individual experimentation, small SKUs may work. For team-based development, F2 is usually insufficient once you introduce:

• Spark notebooks
• concurrent pipelines
• multiple developers running queries and refreshes

As a practical baseline, consider F4 or higher for Dev, and size upward based on concurrency and Spark usage.

Understanding contention behavior

Fabric uses capacity management mechanisms that can feel non-intuitive: intensive bursts can push the capacity into a state where subsequent workloads are slowed or throttled. The operational takeaway is simple:

• Isolate Dev from Prod so experimentation cannot degrade production dashboards.
• Schedule heavy workloads (batch refresh, large Spark jobs) to avoid peak BI usage.
• Monitor and iterate sizing: treat capacity as an operational SLO, not a one-time procurement decision.

Cost control: Dev capacities can often be paused when not in use (nights/weekends), while Prod capacity should be sized for stable, optimized workloads.

5. CI/CD, infrastructure as code, and notebooks

Fabric provides native Git integration and Deployment Pipelines to promote content across environments.

• IaC mindset: treat Lakehouses, Warehouses, notebooks, pipelines, and semantic models as versioned artifacts. Review changes in pull requests.
• Promotion discipline: use Deployment Pipelines to move from Dev → Test → Prod and to swap environment-specific parameters (connections, workspace IDs, endpoints).

Notebooks: powerful, but require discipline

Notebooks are often the most productive tool for complex transformations and debugging. They also introduce operational risks if teams do not enforce software engineering discipline.

Best practices:

• Keep notebooks modular (functions/utilities, clear entry points)
• Add basic testing/validation steps (row counts, expectations, schema checks)
• Enforce code review through Git PRs
• Separate exploratory notebooks from production pipelines (different folders, different policies)

If your team is SQL-centric and your transformations are straightforward, a SQL-first approach can reduce operational complexity. If your datasets and transformations are complex, notebooks can be the right tool, provided you govern them like code.

6. Schema evolution and contract management

Schema handling is where many Fabric implementations drift into brittleness.

Ingestion convenience vs governance

• "Merge schema" / automatic schema evolution can be convenient for ingestion, especially when sources add columns frequently.
• Explicit DDL (declared schemas, controlled changes) provides stronger governance, better predictability, and clearer contracts for downstream consumers.

Recommendation: choose deliberately per domain.

• For volatile sources, allow additive column evolution in Bronze, but stabilize in Silver with explicit schemas.
• For governed domains (finance, revenue recognition), prefer explicit schema control earlier.

Additive-only policy (with versioning)

In Silver and Gold, treat tables as data products with consumers.

• Prefer additive-only changes (new columns, new tables) over breaking changes.
• If a breaking change is required, version it (e.g., revenue_v2, customer_status_v2) and run parallel for a migration window.

This prevents downstream dashboards, metrics, and AI agents from silently changing behavior.

7. Governance, naming, and AI readiness

Governance is not just compliance. It is correctness at scale.

• Lineage and auditability: integrate with Microsoft Purview to trace KPIs from Gold back to Bronze.
• Naming conventions: use human-readable names in Gold and semantic models (e.g., Customer Name, Invoice Amount, Churn Risk Score). Avoid cryptic abbreviations.
• Descriptions and metadata: add column and measure descriptions consistently.

Why this matters:

• Better semantic naming and descriptions improve Copilot interactions, data agents, and future AI-assisted querying.
• Clear semantics reduce the risk of misinterpretation when users (or AI) explore the model without deep tribal knowledge.

This is the same governed foundation that lets an agentic data engineering workflow operate safely: a coding agent that inherits clear naming and lineage makes fewer wrong guesses than one pointed at an ungoverned schema.

A governed Gold layer is also the foundation for assessing whether your data is ready for machine learning, the predictive use cases that motivate this architecture in the first place.

8. Start small, scale fast (without over-engineering)

You do not need a multi-year program to get value, but you also should not blindly copy a reference architecture.

Avoiding over-engineering

• Medallion is a pattern, not a law. Adapt it to your org size and maturity.
• Teams migrating from SQL Server should evaluate whether Spark/lakehouse complexity is justified for the current scope.
• If your workloads are small, relational, and BI-dominant, you may get most of the benefit with a SQL-governed Warehouse-centric approach.

A 12-week execution cadence

• Weeks 1-2: Select 1 to 2 high-value decisions and define metrics and contracts.
• Weeks 3-6: Implement Bronze → Silver ingestion patterns with quality gates.
• Weeks 7-9: Build Gold marts and semantic models (Direct Lake where appropriate).
• Weeks 10-12: Harden with monitoring, CI/CD, and schema governance.

Closing thought

Implementing Medallion Architecture in Fabric is like organizing a professional kitchen:

• Bronze is the delivery dock where raw ingredients arrive.
• Silver is the prep station where ingredients are cleaned and standardized.
• Gold is the pass where finished dishes are plated for customers.

The point is not to overcomplicate the kitchen. The point is to enforce separation of concerns so that consumption is safe, repeatable, and trusted, while engineering can evolve the system without breaking the business.

This article was originally published on the RevOS blog.

Building this on Fabric yourself? RevOS can take the revenue data layer off your plate: governed metrics, ready for your agents. Book a RevOS demo.

• Gartner predicts 40% of enterprise apps will feature AI agents by 2026, up from under 5% in 2025, while over 40% of agentic AI projects will be canceled by the end of 2027.
• The platform landscape splits into three tiers: cloud-native suites (Salesforce Agentforce, Microsoft Copilot, ServiceNow), vertical specialists (Sierra AI), and open-source frameworks (LangGraph, CrewAI).
• GSI deployments cost $500K to $5M+; boutique AI firms start around $150K/yr and move faster.
• The leading failure mode is agents guessing at metric definitions, returning confident answers that don't match your official reports.
• A semantic layer connected via an MCP server is the fix: agents query governed definitions rather than computing metrics on the fly from raw tables.

Gartner predicts 40% of enterprise applications will feature task-specific AI agents by 2026, up from under 5% in 2025. In the same window, over 40% of agentic AI projects will be canceled before they deliver value. Rapid adoption and widespread failure are happening simultaneously.

The failure rate is the more important number. Enterprise AI agents are not failing because the models are bad. They are failing because the data infrastructure underneath them was never designed to support autonomous reasoning at scale.

This guide covers the enterprise AI agent landscape: the platforms, the rollout services, realistic pricing, and the data prerequisites most deployment guides skip entirely.

What are enterprise AI agents?

An enterprise AI agent is an autonomous software program that perceives data from business systems, reasons toward a goal, and takes multi-step actions without a human approving each step.

That last part is what separates agents from chatbots. A chatbot responds to a prompt. An agent pursues a goal: it breaks the goal into steps, calls the right tools in the right order, handles errors, and reports back when the work is done.

As an example: an agent monitoring customer health scores might detect that a customer's product usage has dropped below a threshold, check the AE assigned to the account, find an open slot in their calendar, and schedule a follow-up call, all without human intervention. At scale, that loop turns lagging indicators into proactive interventions before churn happens.

Enterprise AI agents generally fall into four types:

Most enterprise deployments start with task agents (lowest risk, fastest ROI) and layer in orchestrators as confidence builds.

What is agentic AI?

Agentic AI is AI that acts over multiple steps toward a goal, rather than just generating a response to a single prompt.

The three defining properties:

1. Planning: the agent breaks a goal into a sequence of steps and decides the order.
2. Tool use: the agent calls external services: APIs, databases, search engines, internal systems.
3. Memory: the agent tracks what happened in prior steps and adjusts its next action accordingly.

The shift from generative AI (produce text) to agentic AI (take action) is why enterprises are investing heavily, and why the failure rate is high. Generating a draft proposal is low stakes; you can review it before it goes anywhere. Booking 200 follow-up calls based on a miscalculated health score is not.

The enterprise AI agent platform landscape

The platform market is consolidating around three tiers.

Tier 1: Cloud-native suites

These platforms live inside tools enterprises already use and fit existing procurement contracts.

Salesforce Agentforce is the clearest signal of where Tier 1 is heading. Agentforce 2.0 achieved 83% autonomous resolution of customer service queries. Salesforce reported $800M ARR from Agentforce in its FY2026 Q4 results, with 8,000 Agentforce deals closed. Pricing is Flex Credits at $0.10/action, dramatically cheaper than early per-conversation models.

Microsoft Copilot Studio and Azure AI Foundry give enterprises an agent builder inside the Microsoft 365 stack. If your data is already in Azure, the integration lift is low. If it isn't, you are building custom connectors.

ServiceNow embeds agents into ITSM and HR workflows. Strong for internal operations; weaker for customer-facing or revenue use cases.

Tier 2: Vertical specialists

Sierra AI builds agents purpose-built for enterprise customer experience. The company's $950M raise at a $15B+ valuation in May 2026 signals that vertical depth (knowing the domain, edge cases, and compliance requirements) beats horizontal platforms for high-stakes interactions. Sierra's pricing starts around $150K/year.

Tier 3: Open-source frameworks

LangGraph, CrewAI, AutoGen, and Semantic Kernel give engineering teams full control over agent architecture: orchestration logic, tool integrations, memory systems. No license cost. High engineering cost. Best for teams that need something Tier 1/2 platforms don't offer, or that want to avoid vendor lock-in.

Two self-hosted frameworks worth naming inside this tier: OpenClaw, a community-driven, edge-deployed agent gateway built for omni-channel use cases (Telegram, WhatsApp, Discord); and Hermes Agent, a terminal-native orchestrator built for engineering pipelines, with persistent memory, real Bash execution, and hierarchical sub-agent delegation. Both are fully self-hosted with no license fee, and both can connect to a governed data source over MCP rather than each requiring its own custom integration. If you plan to run Hermes in production, we wrote up what breaks when you run Hermes Agent on Kubernetes and a setup that survives it.

The practical tradeoff: Tier 1 is faster to pilot and easier to govern; Tier 3 is more flexible and cheaper at scale if you have the engineering team. Most enterprises start at Tier 1 and build Tier 3 agents for custom use cases. Anthropic's own first-party surfaces (Claude Code, Claude Cowork, Claude Tag, and its several scheduled-automation "Routines") sit alongside this landscape rather than inside any one tier; see our guide to navigating the Claude ecosystem if that's the specific stack you're evaluating.

Enterprise AI agent rollout service providers

Buying a platform is not the same as deploying it. Most enterprises engaging seriously with AI agents are also engaging a services partner for the integration work, change management, and ongoing model tuning.

Global SIs: Accenture, IBM, Deloitte, Capgemini

The large system integrators bring a reliable playbook: stakeholder alignment, risk assessment, integration with legacy ERP and CRM, a globally distributed delivery team, and governance frameworks for regulated industries.

The cost matches the scale. A full GSI-led deployment runs $500K to $5M+ depending on scope, with timelines of 6 to 18 months. That pricing reflects the overhead of the engagement model: senior partner time, change management documentation, compliance reviews, and global delivery coordination.

If your deployment involves deep SAP or Oracle integration, enterprise-wide change management across regions, or a regulated industry where you need a Big Four name in the liability chain, a GSI is the right fit.

When should you use a global SI versus a boutique AI firm?

Boutique AI firms specialize in a vertical (GTM, finance, supply chain, HR) and deliver faster pilots at lower cost. A typical boutique engagement starts around $150K/year for a managed build-and-operate model.

The tradeoff: boutiques move faster (6 to 8 weeks to a working pilot is common) and their domain expertise is often deeper within their vertical. The risk is capacity: a boutique that runs your pilot may not scale globally.

For most B2B SaaS revenue operations use cases, a boutique specialist will deliver a better outcome faster than a GSI. GSIs earn their premium in global, multi-system, regulated deployments where brand liability and delivery footprint matter.

Why enterprise AI agent projects fail

Just 15% of IT application leaders are considering, piloting, or deploying fully autonomous AI agents, according to a September 2025 Gartner survey. Of those that do proceed, Gartner predicts over 40% will be canceled by end of 2027.

The leading cause is not model quality. It is data.

The hallucinated-metric failure mode

An enterprise AI agent is given access to raw tables: CRM records, warehouse data, support tickets. A stakeholder asks: "Which accounts are at risk this quarter?"

Without a governed definition of "at risk," the agent computes one on the fly. It might derive churn probability from usage data using a formula it infers from the table schema. That formula will not match the formula your data team uses. The number will be fluent, confident, and wrong. The underlying mistake is letting a probabilistic model do deterministic work; this post explains where to draw the line.

When this happens at scale (and it does), the result is the worst possible outcome: stakeholders who received a confident wrong answer from an expensive agent deployment. That is the project that gets canceled.

The fix is not a better model. It is a better modern data strategy for the AI age: specifically, one that includes semantically governed data, with metric definitions and business logic that live in a shared layer agents can query, rather than locked inside individual dashboards or analyst notebooks.

What data infrastructure do enterprise AI agents need?

Three components are non-negotiable.

1. A governed data warehouse

Your agents need a structured, queryable source of truth. Schema documentation, access controls, and a version-controlled transformation layer (dbt or equivalent) are the baseline. Without this, you have nowhere stable for agents to query.

2. A semantic layer

A semantic layer is a governed translation layer between raw data and business meaning. It defines your metrics (ARR, churn rate, customer health score) once, in one place, so every system (reports, dashboards, agents) uses the same formula. It's the right structure for governed metrics specifically; see our comparison of semantic models, knowledge graphs, RAG, and other ways to structure data for AI agents for the cases where a different approach fits better.

Without a semantic layer, agents make up metric definitions. With one, they query a verified library and return numbers that match your board deck. This is the single highest-leverage infrastructure investment for any enterprise AI agent deployment. It's also the governed "numbers half" of what many teams now call a company brain: a shared context layer every agent draws on.

3. An MCP server

The Model Context Protocol (MCP) is an open standard that lets AI agents connect to data sources through a single interface. Instead of building a custom connector for every agent-data pair, you run one MCP server, and every compliant agent can query it.

The architecture:

• Agent (any compliant client: GPT-4o, Claude, Gemini)
• MCP server
• Semantic layer (Cube, RevOS, or equivalent)
• Data warehouse (BigQuery, Snowflake, Redshift)

In this stack, agents always query governed definitions rather than raw tables. The hallucinated-metric problem is structurally eliminated.

How to evaluate your enterprise AI agent stack

Step 1: Audit your data readiness

Before evaluating platforms, assess whether your data can support an agent. Can you produce a reliable customer health score programmatically, not from a dashboard but from a query? If not, agents will fail at that task regardless of which platform you buy.

If the answer is no, the path forward is getting AI-ready data in place first: clean schemas, governed metric definitions, and a semantic layer to expose them.

Step 2: Map your use cases by risk tier

Low-risk tasks (draft an email, summarize a call transcript) can run on any LLM with minimal infrastructure. High-risk tasks (update the CRM, trigger a customer communication, close a renewal) require strict semantic grounding and audit logging.

Start with low-risk tasks. Build confidence in your data infrastructure before putting agents on high-stakes workflows.

Step 3: Evaluate platform fit, not features

The feature set of Tier 1 platforms is roughly equivalent. The differentiator is fit: which platform connects cleanly to your existing stack, and which integrates with the semantic layer you need to govern agent outputs?

Step 4: Choose a services model that matches your internal capacity

If you have a data team that can own the semantic layer, a boutique AI firm running the agent deployment typically delivers better ROI than a full GSI engagement. If you don't have that internal capacity, choose a services partner who will build and operate the semantic layer for you.

RevOS agents are built on this model: the semantic layer and MCP server are included in the platform, so agents return governed answers from day one. The RevOS semantic model handles the definition layer, so your agents don't have to guess.

Step 5: Define success metrics before you deploy

The most dangerous agent project is one with no failure criteria. Before deployment, define: what does a wrong answer look like, and how will you detect it? What is the acceptable error rate for autonomous actions?

Without a clear success definition, a project that produces 30% wrong answers gets declared a success because it automated 70% of the manual work. That 30% erodes trust over time.

The bottom line

Enterprise AI agents are real, they work, and the market is moving fast. The platforms are maturing, the services ecosystem is established, and pricing is more accessible than it was 18 months ago.

The variable that determines whether your deployment succeeds is not which LLM you pick or which platform you license. It is whether your data infrastructure can support autonomous reasoning: specifically, whether your agents can access governed metric definitions through a standard interface rather than guessing at business logic from raw tables.

The semantic layer plus MCP server is the architecture that makes agents trustworthy. Without it, you are building on sand.

This article was originally published on the RevOS blog.

Most agent projects fail on the data, not the platform. RevOS gives your agents one governed commercial context across CRM, billing, product usage and support, with every action permissioned and audit logged. Book a RevOS demo.

Most data platforms don't fail because of the tooling. They stall because raw, messy inputs are rushed straight into analytics, teams patch problems locally in spreadsheets, and every dashboard bakes in a different "truth".

At RevOS, we believe that without a deliberate data strategy, your revenue operations are paying a hidden tax on speed, trust, and outcomes.

In this series, we break down how to build a data foundation that actually works. Implementation comes later, starting with Microsoft Fabric, but first, we must establish the strategy.

Here is why you need to stop chasing tools and start designing your data architecture.

🎥 Want the deeper walkthrough? Watch the on-demand webinar Turn Data Silos into Trusted AI-Ready Data Products for a step-by-step look at fixing this before it derails your AI roadmap.

The high cost of the "copy-storm"

The current state of data in many scaling SaaS companies is defined by silos. Marketing has their extracts, Sales has Salesforce reports, and Finance has their spreadsheets.

When these teams try to collaborate, they run into the "copy-storm" anti-pattern. Datasets are replicated across multiple workspaces "for convenience," severing lineage and inflating costs. The result?

• Trust deficit: If revenue shows three different numbers across three different departments, the only thing everyone agrees on is to question the dashboard.
• Operational drag: Every new initiative begins by re-creating the same data pipelines, stretching time-to-value from weeks to quarters.
• AI hallucinations: AI models trained on inconsistent inputs behave unpredictably. If your data foundation isn't grounded, your AI agents will hallucinate, not help. That grounding is exactly what separates a demo from a system you can trust. See our deep dive on agentic data engineering for how that trust actually gets built.

Research suggests that:

📢 80% of business leaders don't trust their data because it is scattered and poorly managed.

You cannot build a revenue engine on shaky ground.

The strategic fix: the Medallion Architecture

To fix this, we advocate for a data strategy based on the Medallion Architecture. While often described as a technical pattern, it is actually an operating model for managing complexity at scale.

It forces a separation of concerns that turns a sprawling set of pipelines into a system with clear roles:

• Bronze (the raw truth): This is where data arrives as-is. It is immutable and preserves history. If you need to audit what happened, you go here.
• Silver (the trusted layer): This is where "data from Salesforce" becomes "data fit for business use". Here, we de-duplicate, standardize types, and enforce business rules. Crucially, changes here should be additive only: we never break the contract promised to downstream users by deleting columns they rely on.
• Gold (the business layer): This is the curated zone. Data here is aligned to specific outcomes, like gross margin or churn risk, so analytics and AI lean on shared, governed definitions.

By adopting this structure, you ensure that Silver guarantees trust, while Gold guarantees alignment with business outcomes.

The business case: why do this now?

Implementing a structured data strategy isn't just about "cleaner tables." It is about revenue productivity.

1. The single source of truth is no longer optional. A unified semantic layer ensures that core business concepts are defined once and reused everywhere. This eliminates the variance caused by one-off transformations inside individual reports.

2. AI readiness. Your data needs to be ready for machine learning. A well-governed Gold layer shortens the last mile for ML and LLM features without turning your platform inside out. It allows you to move from noisy data to confident, real-time decisions.

3. Cost and risk control. Uncurated, compute-heavy transformations that multiply across tools are a financial drain. A structured approach allows you to control costs by running heavy transforms once per layer, rather than re-wrangling data for every specific query. Governance also becomes embedded in the architecture, allowing for automated lineage tracking and "just-enough-access" security policies.

The business case: the actual numbers

When data is siloed, you aren't just losing visibility; you are losing money. Based on recent strategy assessments of mid-market SaaS organizations, we have quantified the financial impact of shifting from chaotic silos to a governed Medallion Architecture.

Here is what that impact looks like on the P&L:

1. Unlocking "hidden" revenue (top-line growth). Most SaaS companies sit on a goldmine of cross-sell opportunities they simply cannot see because product usage data is disconnected from CRM data. By unifying these sources into a Gold layer, the revenue implications are immediate:

• The wallet share gap: In a portfolio analysis of 1.5M active users, unifying usage data with billing records allowed the company to detect subtle wallet-share declines before the contract renewal. Predictive intervention here was projected to reduce churn by 1%, protecting an estimated mid-five-digit monthly recurring revenue (MRR).
• Targeted expansion: Instead of "spray and pray" marketing, a unified data estate allowed for an outbound campaign targeting 1,000 specific customers based on actual feature usage gaps. With a conservative 10% opportunity rate and a moderate uplift, this single data-driven play generated high-four-digit net new MRR immediately.
• The RevOS impact: Organizations that align their commercial architecture in this way typically see 19% faster growth and an 18% increase in Net Revenue Retention (NRR).

2. Eliminating the manual tax on talent (bottom-line efficiency). Data silos force high-value employees to do low-value work. Without a Silver layer to standardize data, your most expensive people waste time wrangling spreadsheets.

• Sales productivity: When sales reps have to manually cross-reference billing systems to check for upsell eligibility, they lose selling time. Our research indicates that automating these insights saves 10% of each sales rep's time, effectively unlocking 2 full-time employees (FTEs) of productivity in a 20-person team.
• Engineering waste: We frequently see engineering teams bogged down by ad-hoc data requests from the business (e.g., "Can you run a query to see who used feature X?"). In one case study, automating self-service reporting eliminated 500 manual requests per year. At 2 hours per request, that is 1,000 hours (0.5 FTE) of engineering time returned to product development.

3. Innovation and new business models. A structured data platform doesn't just optimize existing processes; it creates new products.

• Monetization: Once your data is structured and governed in a Gold layer, it becomes a product in itself. Companies are successfully launching usage-based API monetization strategies, selling data insights back to their customers as a premium tier, a business model impossible to execute with fragmented data. That same governed Gold layer is the foundation of what's now being called token capital: a proprietary AI asset a company owns, not just spends on.
• AI readiness: You cannot build a "revenue brain" on shaky ground. A reliable Gold layer allows you to deploy AI agents that can answer complex financial questions without guessing, driving pipeline velocity up by 25%. That Gold layer is also the prerequisite for enterprise AI agent deployments; without it, even the most capable agent returns unreliable answers. The connection itself usually runs over an MCP server (in practice, an MCP server for data fronted by your semantic model), so the agent queries governed metrics by name instead of guessing at raw tables.

4. The cost of risk. The most expensive data problem is the one that lands you in legal trouble.

• Compliance and trust: Manual data exports are a security nightmare. We have observed cases where manual CSV handling led to data from the wrong customer being sent to an external party. A governed architecture with automated row-level security (RLS) and sensitivity labels prevents this by design, supporting compliance with strict regulations like the EU Data Act.

The verdict: You don't need magic to grow. You need your revenue team to see who is using the product, your engineers to stop writing ad-hoc SQL, and your AI to stop guessing. That requires a strategy.

What's next?

A strategy is only as good as its execution. Part 2 of this series turns it into a technical blueprint: Implementing the Modern Data Strategy: Microsoft Fabric Blueprint covers how to use OneLake and Direct Lake mode for a unified setup where you don't need to move data.

Building a Medallion Architecture is a journey, but you don't have to walk it alone.

This article was originally published on the RevOS blog.

RevOS gives revenue teams the governed data foundation this series describes, without building it from scratch. Want to see it on your own data? Book a RevOS demo.

• A company brain is a shared context layer that holds what your company knows, so any AI agent or teammate can use it. That includes documents, decisions, definitions, and live business data.
• Every company brain has two halves: a knowledge half (docs, conversations, decisions) and a numbers half (metrics, entities, and records from your business systems). Most tools cover only one.
• There are six common approaches: enterprise search, AI wikis, DIY RAG on a vector database, knowledge graphs with an ontology, AI memory layers, and a data platform with a semantic layer and MCP.
• Search, wikis, RAG, and memory layers are built for the knowledge half. Knowledge graphs, ontologies, and semantic layers add the structure the numbers half needs to answer metric questions consistently.
• MCP (Model Context Protocol) is becoming the common way to plug any of these approaches into Claude, ChatGPT, Copilot, or your own agents.
• The hard part is upkeep, not setup: stale content, drifting permissions, and conflicting definitions are what make a company brain fail.

A company brain is a shared context layer that holds what your company knows, so any AI agent or teammate can use it. That covers documents, conversations, decisions, definitions, and live business data. The underlying problem is an old one. In a 2023 Gartner survey, 47% of digital workers said they struggle to find the information or data they need to do their jobs. AI agents have the same problem, and unlike a new hire they rarely know when to ask. As we argued in our guide to enterprise AI agents, an agent without shared company context will guess, and guesses do not scale.

The term itself is new. In US search-volume data we pulled from Google Ads for this article, searches for "company brain" went from about 10 a month in January 2026 to about 590 a month by summer. Vendors now define it to fit what they sell: Slite calls it a context layer, Sentra calls it governed memory, and Colrows says the data layer decides everything. Each of them describes a real part of the problem, though none describes all of it.

So which kind of company brain do you actually need? This guide compares the six main ways to build one, with the same strengths-and-limits treatment for each. It also defines the related terms you will run into: context layer, knowledge graph, ontology, semantic layer, and MCP.

What is a company brain?

A company brain is a shared context layer that holds what your company knows, so any AI agent or teammate can use it. It answers two kinds of questions:

• "What do we know?" For example: what our refund policy is, why we chose this vendor, how we onboard enterprise customers.
• "What is true right now?" For example: last quarter's net revenue retention (revenue kept from existing customers, including upgrades and churn), which accounts are at risk, how many active users a customer has.

A company brain is not the same as:

• A wiki. A wiki stores pages people write. A company brain makes those pages, and much more, usable by an AI agent.
• An AI knowledge base. A help-center or FAQ store that an AI answers from. It is one source for the knowledge half, not the whole brain.
• A search index. Search finds relevant documents. A company brain also has to know what your terms mean and which number is the right one.
• A data catalog. A catalog lists your tables and who owns them. A company brain has to answer the question, not point to where the answer might live.
• A personal "second brain". A second brain is one person's notes app (Obsidian, Notion). A company brain is shared, governed, and permission-aware. "Governed" here means each definition has an owner, there is one agreed version, and access follows your rules.

Two things changed recently. Companies have learned that AI fails without good context. In 2025, Gartner predicted that organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026. A shared interface also exists now. The Model Context Protocol (MCP) lets one context layer serve Claude, ChatGPT, Copilot, and custom agents at the same time. (If MCP is new to you, start with what an MCP server is.)

Company brain vs context layer, knowledge graph, and ontology

These terms overlap, and vendors use them loosely. The table shows how they relate.

Put simply, the context layer is the goal and MCP is how agents reach it. Knowledge graphs, ontologies, semantic layers, and RAG are different ways to build it.

An ontology and a semantic layer solve a similar problem from different directions. An ontology defines what things are ("a customer is an organization with at least one active contract"). A semantic layer defines how things are measured ("net revenue retention is this calculation over these tables"). Both stop an AI model from inventing its own definitions.

The two halves of a company brain

Most company-brain guides focus on documents, Slack threads, and meeting notes, which covers only half the job.

Picture two questions a sales leader might ask an AI agent on the same morning:

1. "What did we promise Acme in the renewal call?"
2. "What was net revenue retention for mid-market last quarter?"

The first is a knowledge question. The answer lives in text: a call transcript, an email, a CRM note. Finding the right passage and summarizing it works well.

The second is a numbers question. The answer is a calculation over records in your CRM, billing system, and product data. There is no paragraph to retrieve. Say the agent writes its own database query against raw tables. It has to guess which table holds revenue, how to treat downgrades, and what "mid-market" means. It may get a different answer every time.

So a working company brain has two halves:

• The knowledge half: docs, conversations, decisions, policies. Best served by search, wikis, RAG, and memory.
• The numbers half: metrics, entities, records. Best served by structured models: knowledge graphs, ontologies, and semantic layers over governed data.

Most of the trade-offs between the six approaches below come down to which half each one serves.

Six approaches to building a company brain

1. Enterprise search (Glean and similar)

What it is. Enterprise search connects to your apps (Google Drive, Slack, Jira, Salesforce, Confluence) and builds one index across them. An AI assistant on top answers questions by retrieving the most relevant documents and messages. Glean is one of the best-known products in this category.

Strengths. Fast to roll out, because it uses content you already have. Respects the permissions of each source app. Good at "where is the doc about X?" and "summarize what we know about Y."

Where it breaks. Search finds text. It does not define your business terms or calculate metrics. If three dashboards show three different revenue numbers, search will happily find all three.

Best fit. Large companies with knowledge scattered across dozens of tools, where the main pain is finding things.

2. AI wiki and knowledge management (Notion AI, Confluence with Rovo)

What it is. Your wiki or docs tool adds an AI assistant that answers questions from the pages you have written. Notion AI, Atlassian's Rovo on top of Confluence, and Slite all take this approach. This is the core of the "AI knowledge management" category.

Strengths. The content is curated. People wrote these pages on purpose, so quality is often higher than raw chat history. Easy to adopt if your team already lives in the wiki.

Where it breaks. It only knows what someone wrote down, and pages go stale. Atlassian's own research found that leaders and teams waste 25% of their time just searching for answers. That is a reminder that a wiki alone does not fix findability. (Atlassian sells Confluence, so read that figure as a vendor's survey.) Wikis also hold few live numbers.

Best fit. Teams with a strong documentation habit who want AI answers over their existing pages.

3. DIY RAG on a vector database

What it is. You build the pipeline yourself. Documents are split into chunks and turned into embeddings, which are numeric representations of meaning. The embeddings go into a vector database. When a question comes in, the closest chunks are retrieved and the model answers from them.

Strengths. Full control over sources, models, cost, and where data lives. No vendor lock-in.

Where it breaks. Everything a product would handle is now yours: connectors, permissions, refresh jobs, chunking strategy, and evaluation. Retrieval by similarity is weak on numbers and on questions that span records. Many DIY efforts stall. Slite surveyed 149 teams, and of the teams that had tried to build their own company brain, 55% gave up. (Slite sells a competing product, and only part of that sample had tried a DIY build, so treat this as a signal.)

Best fit. Engineering-heavy teams with unusual data, strict hosting needs, or a product that needs RAG anyway.

For a deeper technical comparison of RAG with other ways to structure data, see our guide to how semantic models, knowledge graphs, and RAG compare as ways to structure data for agents.

4. Knowledge graph with an ontology

What it is. You model your business as entities (customers, contracts, products, people) and the relationships between them. The ontology defines which entities and relationships are allowed. The knowledge graph stores the actual data. Palantir's Foundry, for example, is built around what it calls the Ontology, a model of an organization's objects and links.

Strengths. Structure helps AI accuracy on business questions. In 2023, researchers at data.world, a data catalog vendor built on knowledge graphs, tested GPT-4 on business questions. It answered 16% correctly when querying SQL tables directly, and 54% when the same data was modeled as a knowledge graph. The study is small, uses older models, and comes from a vendor that sells knowledge-graph tools. Still, it suggests that explicit structure helps more than asking a model to infer it.

Knowledge graph vs RAG. RAG retrieves text that looks similar to the question. A knowledge graph follows explicit links between records. So RAG suits "what does this document say?", while a graph suits "how does this customer connect to that contract and that support ticket?" Many teams use RAG for documents and a graph or semantic layer for connected records.

Where it breaks. Graphs are expensive to build and maintain. Someone has to design the ontology and keep it accurate as the business changes. That is a real ongoing cost, and it is overkill for simple lookups.

Best fit. Large organizations with complex, connected domains (supply chains, regulated industries) and the team to maintain an ontology.

5. AI memory layer

What it is. Instead of indexing everything up front, a memory layer learns as agents and people work. It stores facts, preferences, and decisions from conversations and tasks, then feeds them back as context. Sentra, Supermemory, and the open-source cognee are examples.

Strengths. Memory layers target a gap that MIT NANDA's July 2025 report on enterprise AI, The GenAI Divide, described directly: "most GenAI systems do not retain feedback, adapt to context, or improve over time". (The report calls its findings preliminary.)

Where it breaks. Memory is only as good as what it captures, and it is hard to audit. When two conversations disagree, who decides which remembered "fact" is correct? Governance and permissions differ widely between products. Memory also does not calculate metrics.

Best fit. Teams running many agents on ongoing work, where carrying context between sessions matters most.

6. Data platform with a semantic layer and MCP

What it is. This approach builds the numbers half. Data from your CRM, billing, and product systems flows into a warehouse. A semantic layer defines your metrics and entities once (revenue, churn, active customer), so every AI agent uses the same definitions. An MCP server exposes those governed definitions to any agent. When an agent asks for net revenue retention, it picks a defined metric. It does not write its own query from scratch. Tools in this space include the dbt Semantic Layer, Cube, and RevOS.

Strengths. Answers to numbers questions stay consistent. In 2026, dbt Labs compared its semantic layer with text-to-SQL, where the AI writes its own database query. With Claude Sonnet 4.6 and some light modeling, accuracy rose from 90.0% with text-to-SQL to 98.2% with the semantic layer. The authors noted a more useful difference: "With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message." (dbt sells a semantic layer, and the test set is small.) For a company brain that difference matters, because an error gets noticed and a plausible wrong number usually doesn't.

Where it breaks. It does not read your docs, Slack, or meeting notes. It answers "what is true in our data?", not "what did we decide and why?" It also needs your data pipelines to be in shape. In a Harvard Business Review Analytic Services survey sponsored by Cloudera, only 7% of respondents said their organization's data was completely ready for AI.

Where RevOS fits. RevOS bundles this half into one managed platform. It syncs data from tools like HubSpot, Salesforce, and Stripe into a managed warehouse. It defines metrics once in a semantic layer (RevOS calls it the semantic model). A built-in MCP server for data then serves those metrics to Claude, ChatGPT, or Copilot, and to RevOS's own agents, which run natively in your Microsoft Teams or Slack. It sits next to enterprise search or your wiki rather than replacing them.

Best fit. B2B companies whose most important AI questions are about revenue, customers, and product usage, and who want those answers to match across every agent and dashboard.

What breaks in a company brain

Keeping a company brain accurate after launch is harder than setting it up. In Slite's survey, only 19.6% of respondents said they have a company brain that works flawlessly. Slite itself calls that figure a ceiling. The survey also pointed to upkeep, not technology, as the main reason DIY builds were abandoned. The same failure modes show up in every approach:

• Stale content. Pages, embeddings, and memories age. Without owners and refresh jobs, the brain confidently repeats last year's pricing.
• Permissions that drift. An agent must not show salary data to someone who could not open the source file. Every approach needs to inherit or enforce source-system permissions.
• Conflicting definitions. If "active customer" means three things in three places, no amount of retrieval fixes it. Define it once, in an ontology or a semantic layer, and make every tool use that definition.
• No evaluation. Few teams test whether answers are correct. Keep a set of real questions with known answers and rerun them after every change.
• Siloed sources. Data that never reaches the brain cannot inform it. In the same HBR Analytic Services survey, the top obstacle to AI readiness, cited by 56% of respondents, was siloed data and difficulty integrating sources.

How to build a company brain: a practical setup

To build a company brain, list the questions it must answer. Then pick one tool for documents and decisions and one governed layer for business metrics. Define key terms once, and expose both through MCP so every agent reads the same context. Few products cover both halves well today, so most teams combine two.

1. List the questions. Write down 30 real questions your teams and agents need answered. Sort them into knowledge questions and numbers questions. This tells you which half matters more.
2. Pick a knowledge-half tool. If your content is spread across many apps, start with enterprise search such as Glean. If your team already writes good docs, use your wiki's AI, such as Notion AI or Rovo. Build RAG yourself only if you have a strong reason.
3. Pick a numbers-half tool. Put your business data in one governed place and define key metrics and entities once, in a semantic layer or ontology. Options include the dbt Semantic Layer, Cube, or a bundled platform such as RevOS.
4. Agree on definitions. Write down what "customer", "active", "churn", and "pipeline" mean. Use the same definitions in both halves.
5. Connect everything through MCP. Expose both halves as MCP servers so Claude, ChatGPT, Copilot, and your own agents all read the same context.
6. Set owners and tests. Give each source an owner. Rerun your question set on a schedule and after every change.

Start with one team and its questions, cover both halves for that team, and expand once the answers hold up.

Which company brain approach should you choose?

Most teams will combine approaches rather than pick one. Search, wikis, RAG, and memory serve the knowledge half of a company brain. Knowledge graphs, ontologies, and semantic layers give the numbers half the structure it needs, and MCP connects both to the agents you run.

If your most important AI questions are about revenue, customers, and product usage, the numbers half is where to start. See how the RevOS semantic model gives every agent one governed view of your business data.

Frequently asked questions

What is a company brain? A company brain is a shared context layer that holds what your company knows, so any AI agent or teammate can use it. It covers documents, conversations, decisions, definitions, and business data. Instead of each AI tool guessing from scratch, every agent draws on the same agreed context about how the business works.

How do you build a company brain? List the questions it must answer. Use enterprise search, a wiki, or RAG for documents and decisions. Use a semantic layer or ontology over your business data for metrics. Define key terms once, enforce the same permissions as your source systems, and expose both halves to your AI agents through MCP. Then assign owners so the content stays current.

What is the difference between a company brain and enterprise search? Enterprise search (for example Glean) indexes your existing apps and returns the most relevant documents and messages for a query. A company brain is broader. It is the full context layer an AI agent relies on, which can include a search index but also definitions, decisions, memory, and governed business metrics. Search is one way to build part of a company brain, not the whole thing.

Is a company brain the same as a wiki or AI knowledge base? No. A wiki or AI knowledge base stores pages that people write, and an AI answers from those pages. A company brain uses that content as one source, but it also needs live business data, agreed definitions of terms, and permissions that follow your source systems. A wiki is one input to a company brain, not the whole brain.

Is a company brain the same as a data catalog or semantic layer? No. A data catalog lists your tables and who owns them, but it does not answer business questions. A semantic layer defines business metrics such as revenue and churn once, so every tool calculates them the same way. A semantic layer is one part of a company brain, the part that covers numbers. The brain also needs the knowledge half: documents, conversations, and decisions.

What is the difference between a company brain and RAG? RAG (retrieval-augmented generation) is a technique: it finds text passages that match a question and hands them to an AI model. A company brain is the whole context layer. Many company brains use RAG to serve documents, but RAG alone does not define business terms, calculate metrics, or manage permissions.

What is a context layer? A context layer supplies the business context an AI model needs to give correct, company-specific answers. That includes what terms mean, how metrics are calculated, who can see what, and what was decided. Context layer and company brain describe the same idea. Context layer is the more technical name.

What is the difference between a knowledge graph and an ontology? An ontology is the schema. It defines the types of things in your business (customer, contract, product), their properties, and how they may relate. A knowledge graph is the data: the actual customers, contracts, and products stored as connected nodes that follow that schema. The ontology keeps the graph consistent as it grows.

Knowledge graph vs RAG: which is better for a company brain? RAG retrieves text passages that look similar to a question. It is quick to set up and works well for documents. A knowledge graph stores explicit entities and relationships, so it handles questions that follow connections across records. Many teams use RAG for documents and structured models for data.

How does a company brain connect to Claude or ChatGPT? Through MCP (Model Context Protocol), the open standard for connecting AI assistants to external tools and data. Glean, Notion, Atlassian Rovo, and several memory and data platforms now offer MCP servers. Once your company brain runs one, Claude, ChatGPT, Copilot, or a custom agent can query it without a custom integration for each tool.

This article was originally published on the RevOS blog.

Want to see this on your own revenue data? Book a RevOS demo.

Key takeaways

• I passed practice exams for the DP-700 (Microsoft Fabric Data Engineer Associate) at 80-90%+ accuracy, then failed the real exam by 30 points.
• The gap wasn't knowledge. It was studying for recognition (matching a question to a memorized answer) instead of retrieval: reasoning from requirements to a conclusion under exam-like pressure.
• Cognitive science backs this up. Retrieval practice (being tested) builds durable, transferable knowledge better than restudying does, especially over time, a finding known as the testing effect.
• On the retake, I changed almost nothing about what I knew and everything about how I engaged with the material: reasoning from constraints instead of matching keywords, and moving fast instead of perfecting every answer.
• The same gap shows up in technical interviews, system design reviews, and picking up a new tool on the job. Recognizing an answer is the easy part; retrieving and applying it under pressure is the actual skill.

When I joined RevOS earlier this year, part of my probation period was agreeing to get the DP-700 certification, Microsoft's Fabric Data Engineer Associate exam. I was excited. I'd passed certification exams before, I had some data engineering background, and I gave myself a month to prepare.

Ten weeks and dozens of practice tests later, I sat the real DP-700 exam confident I'd pass. I didn't. I found out afterward that the problem was never how much Fabric I knew. It was that I had spent ten weeks training the wrong skill.

How I prepared

My real gap going in was practical: I'd only recently started using Fabric, and while I had some data engineering experience, I knew how steep this learning curve could get. I lined up a mix of theory and practice:

Theory

1. The Microsoft Learn DP-700T00-A course
2. Aleksi Partanen's DP-700 exam-prep series on YouTube
3. Fabric's official documentation

Practice

1. Microsoft's DP-700T00-A practice labs
2. Microsoft's practical assessments
3. Certiace's DP-700 exam practice questions

I gave myself a month, then extended it by six weeks once I realized how much ground Fabric actually covers. Data engineering, real-time analytics, governance, and lifecycle management are each their own discipline with their own tools and patterns. Trying to get comfortable with all of them in four weeks had been wishful thinking.

I diversified my practice as I went. Microsoft's own practical assessments were reassuring (I consistently cleared the 80% pass threshold) but also a little unsettling, because the questions felt easier than what other candidates described from the real exam. So I added Certiace, a third-party practice platform with tougher, more scenario-based questions. It recalibrated me. I regularly finished Certiace mock exams above 90%, sometimes recognizing the right answer before I'd even finished reading the question.

By exam day, I felt ready. In hindsight, that confidence was measuring the wrong thing.

The first attempt

I sat the exam, worked carefully through it, and looked up anything I was unsure of. DP-700 is open-book to Microsoft Learn and Fabric documentation, so that's allowed. But the questions were a different animal from my practice sets: long, scenario-based, with several almost-identical answer options that all sounded technically correct.

I answered every question. I failed anyway: the pass threshold is 700 out of 1,000 points, 70%, and I landed 30 points short.

Thirty points is a strange number to sit with. It's close enough to feel like bad luck, far enough to know it wasn't. I'd proven the exam was passable. I just hadn't figured out what I was actually being tested on.

Why practice tests didn't prepare me

Looking back at what went wrong, four things stood out:

• Theory versus practice. I'd focused on learning Fabric's architecture and features, not on applying them to messy, real-life scenarios. Theory matters, but DP-700 tests how you'd handle a specific situation with specific constraints: the gap between watching driving tutorials and actually driving.
• Mindset. I stressed over unfamiliar questions instead of expecting them. Even experienced candidates report hitting confusing questions on DP-700. That's the nature of the exam, not a sign you're unprepared.
• The open-book trap. Being allowed to look things up in Microsoft Learn sounds like a safety net. In practice, the documentation is enormous and its search is mediocre, so leaning on it costs real exam time, and I leaned on it far more than I needed to.
• Time management. Around 40 questions in 100 minutes sounds generous. It stops feeling that way when you're 40 minutes from the end with 20 questions and a case study still to go. I spent my first 12 minutes on 3 questions before I course-corrected, and that early pace never fully recovered.

Every one of those was a symptom. The actual cause was one thing: I had trained recognition, not retrieval.

Recognition is what a flashcard trains. You see a question about low-code transformations and your brain immediately says "Dataflow Gen2" (Fabric's low-code transformation tool), because you've matched the pattern before. That works on practice tests built around the same handful of scenarios. It falls apart on a question like:

"A company has business analysts maintaining daily CSV transformations. Which approach best satisfies maintainability requirements?"

Recognition alone doesn't answer that. You have to reason: "business analysts" signals a preference for low-code over hand-written pipelines, Dataflow Gen2 handles CSV sources well, so it fits the stated requirement better than the alternatives. That's retrieval: reconstructing an answer from constraints, not recalling one from memory.

This distinction isn't just my own theory. Cognitive scientists Henry Roediger and Jeffrey Karpicke showed in a now-canonical 2006 study in Psychological Science that being tested on material (retrieval practice) produces meaningfully better long-term retention than restudying the same material, a finding they call the testing effect. The advantage grows the longer the delay before you actually need the knowledge. Their finding cuts against instinct: restudying can feel more effective in the moment, which is exactly the trap. Recognition feels like mastery. Only retrieval proves it. Psychologists call the gap between the two the illusion of competence.

My practice tests weren't teaching me to retrieve. They were teaching me to recognize a smaller set of question shapes than the real exam actually contains.

What I changed for the retake

I didn't relearn Fabric. I changed how I engaged with what I already knew.

Instead of asking "What's the correct answer?" while studying, I started asking: "What requirement is this question actually implying? Why this answer instead of another technically valid one? What trade-off does each option make, and does it contradict the stated constraints?" That single shift reshaped the rest of my preparation. I was reasoning from workload, constraints, and intended architecture instead of matching keywords to memorized labels.

I also changed my exam strategy. Rather than trying to perfect every answer, I moved quickly through the ones I wasn't sure about: read the scenario, identify the real requirement, weigh the trade-offs, commit, and flag it for review if genuine doubt remained. When I circled back to flagged questions, I unmarked more than half of them within seconds, a level of trust in my own reasoning I didn't have on my first attempt.

The second attempt

The questions weren't easier. They just weren't unfamiliar anymore. I'd already met Microsoft's style of scenario-writing once, and instead of treating every ambiguous case as something to research, I accepted the ambiguity as part of the format and reasoned my way through it.

I still finished the standalone questions with only about ten minutes to spare before the case study. DP-700 is genuinely time-intensive, no matter how well you manage it. But I reached the case study locked-in instead of rattled, and I still checked Microsoft Learn a few times to confirm syntax details in PySpark (Spark's Python API) and KQL (Fabric's query language for real-time data), not to discover concepts I'd never seen.

This time, I passed.

I don't think I learned dramatically more Fabric between attempts. I closed a few real knowledge gaps, but the bigger change was learning to use the knowledge I already had, under the same time pressure and ambiguity the exam actually tests.

Why this matters beyond a Microsoft exam

The recognition-versus-retrieval gap isn't specific to DP-700, or to certifications at all. It's the same reason a candidate who "knows" a system-design pattern cold on paper can freeze the moment an interviewer changes one constraint. Reading about a design, or recognizing it in someone else's diagram, isn't the same skill as reasoning through your own from scratch. It's why engineers can follow a tutorial confidently and still stall the first time they have to adapt it to a real, messier codebase. We lean on that same reasoning-under-constraint muscle when we design agentic data pipelines that have to hold up in production, not just work in a demo. Recognizing that a pattern exists somewhere is nowhere near the same as knowing when it actually applies.

Recognizing an answer is the first step. Being able to explain it, justify it, and apply it to a problem you haven't seen before is what actually demonstrates understanding: on an exam, in an interview, or in a Fabric deployment you're responsible for keeping correct.

Failing my first DP-700 attempt didn't feel like progress at the time. But it's the reason I rebuilt how I study at all, and that ended up mattering a lot more than passing on the first try would have.

Frequently asked questions

Why did I fail the DP-700 exam if I passed all my practice tests?

Practice tests mostly reward recognition: matching a question to an answer you've seen before. The real DP-700 exam tests retrieval: reasoning from a scenario's requirements and constraints to the best answer, often among several technically valid options. Passing practice tests proves you can recognize correct answers, not that you can reason your way to one under pressure.

Is the DP-700 exam hard?

Yes. Most candidates describe DP-700 as moderately to significantly harder than typical certification exams, especially for anyone without hands-on Microsoft Fabric experience. The questions are longer and more scenario-based than most study guides prepare you for, and several answer options are often technically plausible, so you have to reason about which one best fits the stated requirements instead of just recalling a fact.

What is the DP-700 passing score?

According to Microsoft's own DP-700 study guide, you need at least 700 out of 1,000 points (70%) to pass. Microsoft doesn't publish an official pass rate, so treat any specific pass-rate number you see online as an unverified community estimate, not an official figure.

How long should I study for DP-700?

There's no universal number; it depends on your hands-on Fabric experience. I planned for one month, then extended to about ten weeks once I realized Fabric's breadth (data engineering, real-time analytics, governance, lifecycle management) needed more than theory to cover. Budget more time for practice and scenario reasoning than for reading documentation.

What's the difference between recognition and retrieval when studying?

Recognition is realizing you've seen something before: a question triggers a memorized answer, the way a flashcard does. Retrieval is reconstructing an answer from first principles: weighing requirements, constraints, and trade-offs to reason your way to a conclusion, even on a question you haven't seen phrased exactly that way. Exams and real jobs test retrieval; most casual studying only trains recognition. Learning-science research calls the resulting mismatch the illusion of competence: mistaking a familiar-feeling answer for real understanding.

Do practice tests actually help you learn?

Yes, but the mechanism matters. Taking a test is itself a form of retrieval practice, and cognitive science shows retrieval practice builds more durable, transferable knowledge than re-reading or restudying does. But if your practice tests are too similar to each other, or you review answers by re-reading rather than re-attempting cold, you end up training recognition instead: passing the practice test without building the reasoning skill the real exam requires.

Does this recognition-versus-retrieval problem apply outside of certification exams?

Yes. It's the same failure mode behind confidently-prepared candidates freezing in technical interviews or system design reviews. Reading about a topic (or recognizing it when you see it) feels like mastery, but only reasoning through unfamiliar, constrained problems under pressure actually builds and proves the skill.

Viktor Goloubovsky is a data engineer at RevOS, where the team spends a lot of time thinking about the difference between data that looks right and data that's actually correct, a distinction that, it turns out, applies to how you study for an exam too.

This article was originally published on the RevOS blog.

Curious what Viktor's team builds? RevOS is a governed data layer that lets AI agents answer revenue questions from trusted numbers. Book a RevOS demo.

• Agentic data engineering uses autonomous AI agents to build and maintain data pipelines from plain-English intent, not line-by-line code written by hand.

• The bottleneck isn't the model's intelligence. It's the control layer around it: the grounding that tells the agent which answer is right, and the controls that catch a wrong one before it ships.

• A governed semantic layer lifts text-to-SQL accuracy from about 51% to over 90%, proof that context, not capability, decides whether an agent's SQL is correct.

• Trust comes from the workflow: the agent ships changes as a pull request that passes tests and CI before a human merges it. It fails at review time, not in production.

• The data engineer's job shifts from writing every transformation to defining intent, reviewing diffs, and governing what the agent is allowed to do.

The project has been on the roadmap for two quarters. Cohort retention. Lead scoring. LTV by channel. Every week without it costs something concrete: a board question you can't answer, a campaign you can't attribute, a churn signal you caught too late.

So you did what any technical operator would do in 2026: you opened ChatGPT, or Claude, and asked it to write the SQL. And it did. Beautifully. The queries ran, the numbers came back, the charts looked clean. Then someone asked whether the retention number was actually right, and you couldn't say. No lineage, no tests, no agreed definition of what "active" even meant. Just fluent SQL nobody had verified. Looking great and being right, it turns out, are very different things.

That gap, between an AI that can write data code and an AI you can trust to ship it, is the whole story of agentic data engineering. This guide explains what the term means, how the workflow actually works, the tools that make it possible, and the part most vendors skip: how you let an agent touch production data without getting burned.

What is agentic data engineering?

Agentic data engineering is the practice of using autonomous AI agents to design, build, and maintain data pipelines from natural-language intent, instead of an engineer writing every transformation by hand, with limited human oversight. The agent plans the work, writes the code (ingestion, SQL, tests), runs it, checks the result, and corrects itself; a human reviews and approves the final change.

The key word is agentic. A plain AI assistant answers a question and stops. An agent works toward a goal across many steps on its own: it perceives the state of your data, reasons about what to do next, takes an action, reads the outcome, and loops until the goal is met. Researchers call this the perceive → reason → act → learn loop. In data engineering, that loop looks like: explore the warehouse, write a transformation, run the tests, read the failures, fix them, and present the finished change for review.

This is the shift from doing the "how" by hand to specifying the "what" and reviewing the result. You stop writing every line of SQL and start describing the metric you need, then the agent does the building. The promise is real, but so is the catch, which is the rest of this article.

Agentic vs. traditional data engineering, and vs. automation and copilots

Three things get confused with agentic data engineering. They're not the same.

A scheduler repeats what you already decided. A copilot autocompletes while you stay in control. An agent takes a goal ("build me a weekly cohort-retention model") and figures out the steps itself, including the ones you didn't anticipate. That autonomy is what makes it powerful, and exactly why the controls around it matter so much.

One more term to untangle: agentic analytics. The two are siblings, not synonyms. Agentic analytics works on the serving side: it asks questions of data that already exists (the BI and query layer). Agentic data engineering works one layer down: it builds and maintains the pipelines and models that produce that data in the first place. You need the engineering layer to be sound before the analytics layer can be trusted.

How agentic data engineering works

Under the hood, an agentic workflow runs your raw data through the same stages a human data team would, building an AI data pipeline driven by intent instead of tickets:

1. Ingestion. Source data lands in your warehouse from your apps, CRM, product database, and third-party tools. Connectors like Airbyte or Meltano handle the extract-and-load so the agent has raw tables to work from.

2. Transformation. The agent writes the models that turn raw tables into clean, business-ready ones, typically as dbt models in a layered (bronze → silver → gold) structure, with tests attached.

3. Semantic layer. Cleaned tables still don't know what your business means by "active user" or "qualified lead." A semantic layer encodes those definitions once, so every query, human or agent, uses the same math. (We go deep on this in what a semantic layer is and why it matters, and on how it compares to knowledge graphs, RAG, and plain markdown + grep as ways to structure data for an agent.)

4. Serving. The finished metrics are queried by dashboards, notebooks, or, increasingly, by other AI agents over a protocol like MCP (the Model Context Protocol), which lets an agent ask your data questions in a structured, governed way.

You describe the metric; the agent explores the lakehouse, writes the dbt model, builds the semantic overlay, and runs the tests. That's the happy path. Now the part that decides whether any of it is trustworthy.

Why the model isn't the bottleneck: it's the control layer

If you've already pointed an AI coding agent at a data problem and watched it produce confident garbage, you've met the real bottleneck. It isn't the model. It's the control layer the model works against.

So what is a control layer? A control layer is the software around an AI model that makes its output safe to ship in production: the grounding that tells the agent which answer is right (your lineage, business semantics, and access policies) and the controls that catch a wrong answer before it lands (validation loops, data contracts, CI/CD, and an audit trail). A model writes code; the control layer decides whether that code is safe to merge.

The intuition is simple: the model is only the engine. Impressive on a workbench, but useless until it's bolted into the rest of the car: a chassis, wheels, a steering wheel, pedals to control the power, and a dashboard that shows what's actually happening. The control layer is the rest of the car.

Put a generic agent and an agent with a control layer side by side:

That gap is measurable. Snowflake put a number on it: on text-to-SQL (natural language to SQL), a general-purpose model (GPT-4o) scored just 51% on their internal evaluation, while grounding the same task in a governed semantic model pushed accuracy past 90% on real-world queries, nearly 2× single-shot GPT-4o. The difference between a wrong query and a right one is almost entirely context, not capability. That's also why data readiness (clean, tested, well-defined inputs) matters more than which model you pick.

The market already senses this. In Cleanlab's 2025 survey of 1,837 engineering leaders, only ~5.2% run AI agents in production. dbt's 2026 report found 72% of practitioners want AI-assisted coding but only 24% trust it to manage pipelines. METR's 2025 study even measured experienced developers running 19% slower with AI on familiar code while feeling faster. The appetite is real; the reliability isn't, because the control layer isn't there.

One principle decides everything downstream: the agent fails at review time, not in production.

What it looks like in practice

Theory is cheap; here's a concrete worked example. At RevOS we built exactly this control layer, so the abstract pieces above have real names. What you install is a packaged offering: a set of APIs, a command-line interface, documentation, and curated agentic skills, wrapped in a dev container you open in your IDE (Visual Studio Code or similar) and drive with Claude Code (or a coding agent of your choice). There's no new UI to learn; it lives where you already write code.

revos init scaffolds a working project (medallion dbt models, semantic cubes, and sample data) that your agent can explore from minute one.

Under that surface, RevOS wires together a best-of-breed stack (automated data ingestion, dbt for transformation, Cube.dev for the semantic layer, Git for versioning, BigQuery as the warehouse), so your agent starts with your schema, your models, and your definitions instead of a blank file. You describe the metric you need; the agent explores your lakehouse, writes the dbt model, and builds the semantic overlay. (For the full product view, see how RevOS helps you build a revenue or growth data layer without hiring a data engineer.)

Then the part that earns trust: when the agent finishes a model, the control layer doesn't accept it on faith. Validation loops run. Primary-key and unique-constraint checks fire. YAML data-contract enforcement kicks in. The change moves through the same Git CI/CD pipeline as your application code and lands on your desk as a pull request with a diff. When the agent gets it wrong (and it will), you catch it in the PR, not at 3 a.m. in a downstream dashboard.

The trust problem: governing an AI agent on production data

The single hardest question in agentic data engineering is the one most marketing pages dodge: how do you let an autonomous agent near production without it doing something irreversible?

The answer is workflow, not faith. Three controls do the heavy lifting:

• Changes ship as pull requests. The agent never writes directly to production. It proposes a diff that runs through tests and CI; a human reads it and merges it. This is the concrete meaning of "fails at review time." A wrong model is a red check on a PR, not a corrupted table.

• Permissions are scoped and time-bound. The agent gets exactly the access a task needs, for as long as the task takes, not standing admin rights. Mutating actions in production (schema changes, deletions, permission grants) keep a human in the loop by design. Scoping is only half the job: the agent also needs an identity distinct from the authority it borrows, so that who acted and who permitted it stay separable after the fact. See AI agent identity.

• Every action is audit-logged. An immutable trail of what the agent did, when, and why means you can answer "what changed?" after the fact. That's the difference between a controlled system and a black box.

Why be this strict? Because verbal guardrails don't bind an agent; technical ones do. The widely reported case of an AI agent wiping a live production database during a code freeze is the cautionary tale: it had every capability to help and none of the controls to be safe. Autonomy should scale as trust accrues, never the other way around.

Will AI agents replace data engineers?

Short answer: no. They change the job. The "AI data engineer" worth imagining is a tooling shift, not a headcount replacement. The work that agents absorb is the repetitive build work: boilerplate models, test scaffolding, documentation, the tenth slightly-different staging table. What they don't absorb is judgment: deciding what a metric should mean, whether a result is plausible, and what the agent is allowed to touch.

So the role moves up the stack. Less time typing SQL; more time defining intent, reviewing the agent's pull requests, and owning the semantic layer and governance that keep the agent correct. The scarce, valuable skill becomes knowing what "right" looks like, which is exactly the skill a generic model lacks. Put simply, an AI data engineer doesn't replace the human one; it hands the human a faster, more reviewable way to work. (For the bigger picture of how AI reshapes data work, see our take on modern data strategy in the age of AI.)

That same shift, from recognizing a familiar pattern to reasoning through an unfamiliar one, is why the scarce skill is so hard to fake or shortcut. One of our engineers hit this exact wall studying for a Microsoft Fabric certification: passing every practice test only taught him to recognize answers, and the real exam tested whether he could reason his way to new ones.

What tools power agentic data engineering

There's no single product called "agentic data engineering." It's a stack, and you can assemble it from best-of-breed parts:

• Ingestion: Airbyte, Fivetran, or Meltano move raw data into the warehouse.

• Transformation: dbt is the de facto standard for version-controlled, tested SQL models.

• Semantic layer: Cube.dev (or dbt's own semantic layer) encodes business definitions so queries stay consistent.

• Warehouse / lakehouse: BigQuery, Snowflake, Databricks, or an open table format like Iceberg or Delta.

• Version control + CI/CD: Git plus a pipeline that runs tests on every change. This is what makes the PR-review safety model possible.

• The agent: a coding agent like Claude Code (a data engineering agent once it's pointed at your warehouse), connected to your data and tools through MCP, that actually writes and runs the work.

The agent is the smallest piece. The other five are the control layer, and they're what separate a fun demo from something you'd trust with a board number. Tools that bundle these into one governed workflow (RevOS pre-wires dbt, Cube.dev, BigQuery, and Git behind a Claude Code agent) save you from stitching them together yourself, but the architecture is the same whether you buy it or build it. Claude Code itself is only one surface in a growing family. If you're also weighing Claude Cowork, Claude Tag, or one of Anthropic's several "Routines" for scheduling this kind of work, see our map of the Claude ecosystem.

Where agentic data engineering is headed

The category is young and moving fast, and the direction is clear: data engineering is going AI-native, with pipelines built around agents from the first commit rather than retrofitted onto a hand-built stack. A few specifics worth watching:

• More backends and open formats. Iceberg and Delta are pulling the warehouse and the lake together, which gives agents one consistent surface to work against.

• Broader warehouse support. Today many agentic tools are warehouse-specific; expect coverage to widen across Snowflake, Databricks, and Microsoft Fabric.

• Open connectivity and semantic standards. Frameworks like Meltano for ingestion, and competing semantic-model languages, are converging toward portability, so your definitions aren't locked to one vendor.

• Agents querying agents. As MCP matures, the consumer of your data layer is increasingly another AI agent, not a human in a dashboard. That raises the bar on governance, because the semantic layer is now the contract between machines. Governance is only half the picture, though. The agent also has to stay reliably running, and what breaks when you deploy a self-improving agent like Hermes Agent to Kubernetes is its own reliability problem.

The throughline: the model gets cheaper and smarter every quarter, but the value keeps moving to the control layer around it. Whoever owns clean, governed, well-defined data wins, which is why we've argued the real AI advantage is your data, not the model, and why that data, once captured as decision traces in a governed semantic model, becomes what's now being called token capital.

Getting started

You don't need to adopt the whole category at once. The fastest way to feel the difference is to put an agent on a stack it already understands and ask for one real metric.

The idea of giving Claude Code a structured dbt/Cube/BigQuery environment makes a lot of sense. The predefined context, conventions, and architecture should help generate more accurate and consistent results than a generic AI coding assistant.

What stood out to me most was the focus on combining AI with a well-defined data framework rather than just code generation. That feels like a meaningful differentiator. For teams that need a revenue or growth data layer but don't yet have a dedicated data engineer, this could significantly accelerate implementation and reduce complexity while still allowing for human oversight where needed.

Vira Slipchenko, Data Analyst, Fin-Navi GmbH

The reproducible version with RevOS: install the CLI and run revos init. You land in a working project preloaded with sample datasets and models, so there's something real to point your agent at from minute one. Ask it to explore the sample lakehouse and build your first model. From install to a production-ready model is an afternoon, not a quarter. The full set of agent capabilities, skills, and interfaces is on the free plan (up to 1 GB of storage), so trying it costs you an afternoon and nothing more.

npm i -g @revos/cli
revos init

The zero-to-scheduled-action walkthrough lives at cli.revos.dev. Try it out today.

Frequently asked questions

What is agentic data engineering?

Agentic data engineering is the practice of using autonomous AI agents to design, build, and maintain data pipelines from natural-language intent, instead of an engineer writing every transformation by hand. The agent plans the work, writes the code (ingestion, SQL, tests), runs it, checks the result, corrects itself, and a human approves the change.

How is agentic data engineering different from traditional data engineering?

Traditional data engineering is task-driven: a person writes each pipeline, query, and test step by step. Agentic data engineering is intent-driven and autonomous: you describe the outcome you want, an AI agent plans and executes the steps and validates its own work with limited human oversight, and you review the result. The shift is from doing the "how" by hand to specifying the "what" and approving the diff.

What's the difference between an AI copilot and an AI data agent?

A copilot suggests code one line at a time while you stay in the driver's seat. An agent works toward a goal across many steps on its own: it explores your data, writes a model, runs tests, reads the errors, and fixes them in a loop. A copilot autocompletes; an agent completes a task.

Will AI agents replace data engineers?

No. They change the job. Agents handle the repetitive build work (boilerplate models, tests, documentation), while engineers move up to defining metrics and intent, reviewing the agent's pull requests, and governing what it's allowed to touch. The scarce skill becomes judgment about what is correct, not typing SQL faster.

How accurate is AI at writing SQL?

A general-purpose model writing SQL from a raw schema is unreliable: GPT-4o scored about 51% on Snowflake's internal text-to-SQL evaluation. Grounding the same task in a governed semantic model pushed accuracy past 90%. The difference between a wrong query and a right one is almost entirely context, not the model's raw capability.

What tools power agentic data engineering?

A typical stack pairs automated ingestion (Airbyte, Meltano), a transformation framework (dbt), a semantic layer (Cube.dev), a warehouse (BigQuery, Snowflake, Databricks), version control and CI/CD (Git), and a coding agent (Claude Code) connected to your data through MCP. The agent writes and runs the transformations; the rest is the control layer that keeps its output correct and safe.

Is it safe to let an AI agent work on production data?

It is safe when autonomy is earned, not granted by default. Permissions should be scoped and time-bound, every action should land in an immutable audit log, and mutating actions in production (schema changes, deletions, permission grants) should keep a human in the loop. Changes arriving as a reviewable pull-request diff mean mistakes surface at review time, not in a live dashboard.

Do AI data agents need a semantic layer?

They work far better with one. A semantic layer encodes your business definitions (what "active user", "revenue", or "churn" actually mean) so the agent doesn't have to guess them from raw column names. It's the single biggest lever on accuracy: the same model that guesses against a raw schema becomes reliable when it queries a governed semantic model.

How do I get started with agentic data engineering?

Start small on a stack the agent already understands. With RevOS you install the CLI, run revos init, and land in a working project preloaded with sample data, dbt models, and a semantic layer, then point a coding agent at it and ask for your first metric. From install to a production-ready model is an afternoon, and the free plan (up to 1 GB) makes trying it cost nothing but time.

This article was originally published on the RevOS blog.

Want to see this on your own data? Book a RevOS demo.

What should your CRM say happened?

Last modified by Alex, because you asked for it? Last modified by Renewal Agent, because the agent performed the operation? Or Renewal Agent, on behalf of Alex, because both facts matter?

This looks like a UX detail. It isn't. It's the question of AI agent identity, and the honest answer is the third one. Almost no enterprise system has a place to put it.

What is AI agent identity?

AI agent identity is the practice of giving an AI agent its own distinct, verifiable identity in your systems. That identity is separate from the human who asked it to act, and separate from the shared service account it might otherwise borrow. It exists so every action the agent takes can be attributed to it specifically.

The hard part is what the definition leaves out, so let's name it immediately:

• Identity answers who performed this operation? Call that the actor.

• Authority answers whose permissions allowed it to happen? Call that the authority.

A principal, in identity terms, is any entity a system can authenticate and grant rights to. For a human user, the actor and the authority are the same principal, so enterprise software only ever built one field. A user authenticates, the user has roles, the user performs an action, the audit log records the user. One principal, start to finish.

An agent breaks that. Consider two chains that produce an identical database write, both routed through the Model Context Protocol (MCP):

Alex            ->  Renewal Agent  ->  MCP  ->  HubSpot
Renewal policy  ->  Renewal Agent  ->  MCP  ->  HubSpot

In both, the Renewal Agent is the actor. In the first, a person is the authority. In the second, running at 03:14 with nobody at a keyboard, the authority is an organizational policy and the permissions granted to the agent itself. Same actor, same write, completely different accountability. A system with one field cannot tell them apart.

Hence the argument of this piece: every production agent should have an identity, but not every agent should have its own authority. Those are two separate decisions. Conflating them produces both of the common failure modes: agents that vanish behind a human's name, and agents handed far more power than the job needs.

Enterprise software was built for one kind of actor

Identity systems have spent decades getting good at people. Then they added a second category, applications and service accounts, for machines running predefined operations. That gave us a clean two-box model: humans who decide, and software that executes.

The second box is now enormous. Palo Alto Networks' 2026 Identity Security Landscape surveyed 2,900+ cybersecurity decision-makers and reports that machine identities outnumber humans 109:1. Treat that as directional rather than precise, since the publisher sells identity security. The industry's name for that box is "non-human identity," and the operational concern behind it is sprawl: thousands of long-lived credentials nobody owns or rotates.

Agents don't fit either box. An agent can reason, choose which tools to call, decide which records to modify, and initiate a sequence nobody specified. That's the human box. It also needs machine credentials, deterministic policy, and tight privilege scoping. That's the service-account box.

Should an AI agent be a service account or a user account?

Neither, exactly. Treating an agent as a service account gets you credential hygiene but loses the fact that it made a choice. Treating it as a user account gets you attribution but quietly grants it a person's entire authority. Both are the one-principal model straining against a two-principal reality.

Actor and authority are two different things

Once you separate actor from authority, a lot of confused arguments resolve.

"Just let the agent use the user's OAuth token" is the most common shortcut. It's a statement about authority that accidentally destroys the actor. The agent gets the right permissions and becomes invisible in the process, because every action it takes is indistinguishable from the human's own. That's tolerable when the agent is summarizing a report. It's misleading when the agent decided something at 03:14.

The mechanics for keeping both facts already exist in the identity world. OAuth's on-behalf-of flow and RFC 8693 token exchange let one principal act with another's authority while remaining distinguishable, carrying a subject and an actor in the same token. What's been missing isn't cryptography. It's the enterprise convention of using it for agents, plus the fields in downstream systems to record the result.

Microsoft's own guidance frames this as a question any agent identity model has to answer: was the action performed on behalf of a user or by the application itself? That's the actor/authority distinction in a vendor's words, and it's a question your CRM's Last Modified By field structurally cannot answer.

Five models of agent autonomy

"AI agent" describes deployments so different that one identity policy can't cover them. Sorting by autonomy rather than architecture gives five models, and the amount of visible identity each needs rises as you go down the list.

1. The invisible assistant. The agent searches, summarizes, or drafts using the user's permissions. From the business application's point of view the human is still the actor, and that's fine. For low-risk assistance, inventing a separate principal adds governance overhead with nothing to govern.

2. The named capability. The organization creates a recognizable "Renewal Agent" or "Research Agent." People invoke it, and it still runs on the invoking user's authority. The agent has a product identity without becoming an independent employee. Most internal AI tooling lives here, and most of it should.

3. The delegated agent. The agent has its own identity and acts under someone's delegated authority, so the system can record subject: Alex, actor: Renewal Agent. I'd expect the bulk of enterprise agent activity to land here, because it's the first rung that survives an audit: you can reconstruct both who wanted the work and what performed it.

4. The autonomous agent. Its own identity and its own constrained permissions. It monitors, decides, and acts on organizational policy rather than waiting for a person to ask. Nobody is present, so borrowing a human's authority isn't just imprecise, it's a fiction.

5. The digital coworker. The agent becomes an organizational participant with its own account and presence, and colleagues interact with it roughly as they would another team member. Identity here is not optional: the agent needs a first-class organizational account, because other people will address it, assign it work, and expect its actions to be attributable the way a colleague's are.

The five models aren't competing standards to pick between. They're rungs, and the useful principle is directional: the more independently an agent acts, the less acceptable it becomes for it to hide behind a human identity.

How six platforms handle agent identity today

Here's what makes this architecture rather than opinion. Six platforms have taken up the same distinction, in different idioms, with no shared standard between them.

So the accurate scorecard is three platforms recording both principals today, two addressing the authority half, and the protocol maintainers naming both while the work is still in flight. Microsoft, Google and GitHub arrived at the same two-principal structure without coordinating on a standard, and the MCP maintainers independently named it as the gap to close. Four arrivals at one structure suggests the distinction is being forced by the problem rather than chosen as a fashion.

Agent permissions are an intersection, not an inheritance

Once agents are identifiable principals, a second assumption breaks: if I can do it, should every agent I use also be able to do it?

Clearly not. A chief revenue officer can view every opportunity, change ownership, approve discounts, delete records, and export customer data. A pipeline-analysis agent invoked by that executive needs to read opportunities, update a few fields, and create tasks. Nothing else.

So the mental model isn't agent permissions = user permissions. It's closer to:

effective permissions = user authority ∩ agent permissions ∩ workflow policy

An intersection, not an inheritance: three constraints that all have to permit an action, rather than one grant flowing downhill.

This isn't hypothetical. ServiceNow ships it: agents run as a "Dynamic user" which inherits the permissions of the invoking user, and role-masking minimizes the roles an agent can execute to a subset of the invoking user's roles. That's the invoking user's authority intersected with an agent-specific grant, and on current releases it's a required configuration, not advisory.

There's a broader shift hiding in this. Traditional role-based access control asks what can this user do? Agentic systems have to ask something richer: what can this agent do, under this user's authority, through this tool, to this resource, in this context, right now? That's a policy problem, and the policy cannot live inside the agent, because a prompt-shaped guardrail is a suggestion. Rules that live in the layer the agent has to query hold; rules that live in the prompt are one clever injection away from a leak.

Why MCP authorization is now an agent identity problem

The Model Context Protocol is becoming a common interface between agents and enterprise tools, which makes it where identity assumptions get tested. An agent might soon execute a chain like agent -> MCP server -> CRM -> billing system -> another agent.

The naive implementation propagates a user's bearer token down that whole chain. The specification forbids it, in normative language: clients must not send tokens to an MCP server other than ones issued by that server's authorization server, and servers must only accept tokens valid for their own resources. Tokens have to be validated as issued specifically for that server as the intended audience (RFC 8707).

Audience-binding is a good rule. It solves the confused-deputy problem, where a service with broad permissions is tricked into using them on a caller's behalf. It does not solve the identity problem, and the maintainers say so. Their roadmap is unusually direct: MCP authorization assumes a person with a browser at consent time, while increasingly the caller is an agent, a cloud workload with its own identity, acting for a user who isn't present, or spawning sub-agents that should get narrower authority than their parent. They call for "an opinionated way for MCP servers to be reached by agents through their own identity or a user-delegated identity."

That's both principals, named by the people who maintain the protocol, listed as unfinished work.

The practical failure is familiar to anyone who has wired one up against real data. Row-level security is the database rule that decides which rows a given user is allowed to see. Skip identity propagation and it silently stops applying, because the server never passed the calling user's identity through, so every caller sees everything. MCP doesn't eliminate the identity problem. It makes solving it unavoidable.

From audit log to action graph

Traditional audit logs record a fact: Alex changed field X from A to B at 14:32. One actor, one action, one timestamp.

That shape can't hold an agent's work. For an autonomous action, the questions that matter form a chain: Who triggered this? Which agent decided to act? What context did it use? Which policy authorized it? Was human approval required? Which tool did it invoke? What did it change? What happened as a result?

Answer those and you no longer have a log. You have a graph, with nodes for principals, agents, policies and tools, and edges for delegation and causation. This is where agent observability stops being a debugging convenience and becomes the accountability record.

The closest thing shipping today is GitHub's commit trail: Copilot is the author, the delegating human is the co-author, the commits are signed so they appear as "Verified," and each commit message links to the agent session logs. Actor, authority, integrity and provenance: four facts on one object, in a system nobody would describe as an identity platform.

Which agents do we employ?

So the question enterprises need to answer isn't which AI agents do we allow? It's: which agents do we employ, who is responsible for them, what authority have we delegated to them, and can we reconstruct every consequential action they take?

We spent decades building identity systems on the assumption that meaningful business actions trace back to a human. Agents break that assumption by adding a second principal the schema never had room for. Getting this right means knowing more than which model generated a response. It means knowing who asked, which agent acted, under whose authority, what it was permitted to do, what it did, and why. That's what accountability looks like when humans and agents work the same jobs.

This article was originally published on the RevOS blog.

Want to see this on your own revenue data? Book a RevOS demo.

The honest answer is that there is no single best way to structure data for an AI agent. Five real approaches are in production use today: semantic models, ontologies and knowledge graphs, retrieval-augmented generation (RAG), plain markdown files searched with grep, and open knowledge formats. Each one solves a different failure mode. Pick the wrong one for your question, and the agent doesn't fail loudly. It fails quietly, returning a fluent, confident, wrong answer, because the model was never the bottleneck. The data it was handed was.

This guide walks through all five, with the evidence for when each one works, so you can match the structure to the question instead of the vendor pitch.

What "structuring data for AI agents" means

Structuring data for an AI agent means organizing information so the agent can find the right fact, definition, or document reliably. The alternative is guessing from raw, unlabeled data and getting it wrong in a way that sounds right. Enterprise AI agents don't fail because the underlying model is weak. They fail because nobody told the agent what "active customer" means, or where the answer to a specific question lives.

This is a data problem before it's a prompting problem. A model handed a clean, governed definition of a metric will use it. A model handed a pile of raw tables and no context will invent a plausible-sounding calculation instead, and you won't find out until someone checks the number in a meeting.

The five ways to structure data for an AI agent

1. Semantic models

A semantic model (or semantic layer) defines your business metrics and entities once: "monthly recurring revenue," "active customer," "churn rate," with the exact tables, joins, and filters behind each one. The agent queries the metric by name instead of writing SQL against raw tables from scratch.

This is the highest-leverage fix for a specific, common failure: an agent guessing at a business definition and getting a number that sounds right but isn't. In dbt Labs' 2026 benchmark, agents querying a semantic model hit 98.2%-100% accuracy on a set of business questions, against 84.1%-90.0% for the same models writing raw text-to-SQL against the full schema. The same benchmark also compared today's models to a 2023-era model doing raw text-to-SQL, and found accuracy nearly doubled over that 2.5-year gap, from 32.7% to 64.5%. That's real model progress. But even the best 2026 model still trailed the semantic-model number. That's the more direct evidence: the gap between a wrong query and a right one comes from what the agent is grounded against, not from how capable the underlying model is.

Semantic models are the right call when the question is a recurring business metric that many tools and many agents will ask about repeatedly, where "everyone gets the same number" matters. They're the wrong call for a one-off question about a single document, or for connecting facts across entities the model was never designed to relate.

A semantic model also earns its keep in a way the other four approaches don't automatically match: define the metric once, and any AI agent can query it through MCP (the Model Context Protocol, an open standard for connecting agents to data sources), instead of every team building its own bespoke retrieval or graph layer to answer the same question. That turns the semantic model from a one-off project into shared infrastructure: a governed layer other agents can read from directly, rather than a definition locked inside one team's dashboard.

You don't need a specific vendor to get this. dbt and Cube will both get you a semantic layer. What matters more than which tool you pick is treating the metric definition as the thing worth getting right once.

2. Ontologies and knowledge graphs

A knowledge graph stores entities (people, accounts, products, contracts) and the explicit relationships between them, instead of flat tables or blocks of text. An ontology is the schema that defines what those entities and relationships are allowed to mean, so the graph stays consistent as it grows. Together, they let an agent traverse connections that a keyword or embedding match would miss entirely, such as "which accounts does this contact influence, and which of those accounts churned within six months of a support escalation?"

This is where GraphRAG earns its name: retrieval that queries a knowledge graph, plus generated summaries of clusters of related entities, instead of a flat vector index. Microsoft's 2024 research found GraphRAG held a 72% win rate on comprehensiveness and a 62% win rate on diversity over plain vector RAG. Its top-level summaries also needed over 97% fewer tokens than summarizing the source text directly. A separate, independent 2025 systematic evaluation of RAG versus GraphRAG found that adding selection and integration strategies on top of graph retrieval improved the best baseline by 1.1% to 6.4% on a multi-hop reasoning benchmark. That's a real but more modest gain than the headline GraphRAG numbers alone suggest, and a useful reminder that the retrieval technique matters as much as the graph itself.

Knowledge graphs cost more to build and maintain than the other four approaches. Someone has to model the entities and relationships, and keep the ontology honest as the business changes. That cost is worth paying when the questions genuinely require multi-hop reasoning across connected entities. It's overkill for a question that boils down to "look up this one fact."

3. RAG (retrieval-augmented generation)

RAG retrieves the most relevant chunks of text, usually by embedding similarity in a vector database, and hands them to the model as context before it answers. It's the fastest approach to stand up: chunk your documents, embed them, index them, and you have a working system in an afternoon.

RAG is the right default for fact lookup across a large, loosely structured document set: contracts, support tickets, product docs, meeting notes. It's the wrong tool when the answer requires connecting several facts across different documents (that's the knowledge-graph case above), or when the "fact" is a governed metric that should have one certified answer everywhere (that's the semantic-model case).

There's also a subtler trap: more retrieved context is not automatically better context. 2025 research from Chroma, testing 18 frontier models including GPT-4.1, Claude Opus 4, and Gemini 2.5, found that accuracy degrades non-uniformly as input length grows. Even a single distractor passage measurably hurt performance relative to a cleaner baseline. Models sometimes did worse on logically well-structured long context than on the same information shuffled. The finding has been corroborated widely enough that it's a fair rule of thumb: precision in what you retrieve beats volume, every time.

Some teams get real gains combining approaches: retrieving with a vector index, then using graph relationships to check or expand the answer. AWS's 2024 case study with Lettria reported up to 35% improvement in answer precision when graph-based retrieval was layered on top of vector RAG, evaluated across finance, healthcare, aeronautics, and legal use cases.

4. Plain markdown + grep

The least glamorous option, and the one no infrastructure vendor will ever recommend to you, because none of them sell it: put your data in plain markdown files, organized sensibly, and let the agent search them with grep or another full-text tool. No embeddings, no vector database, no graph to maintain.

This works better than it sounds for a small, well-organized internal corpus: think hundreds of files, not millions. Coding agents already do this constantly. A well-structured repository of markdown docs, read directly by an agent with a file-search tool, is often faster to build and easier to reason about than standing up retrieval infrastructure for a corpus that would fit on a laptop. It's the same instinct behind emerging patterns like llms.txt and skill-file conventions: plain, greppable text, organized by a human who knows the content, beats a half-tuned vector index over the same material.

There's a maintenance upside here that's easy to undervalue. Markdown files live in version control like everything else you write. Every change is a diff a human can read, review, and revert, with no embedding pipeline to rerun, no index to rebuild, no vector database to keep in sync with the source of truth.

The approach breaks down exactly where you'd expect: once the corpus gets large enough, or the phrasing gap between a query and the right document gets wide enough, that keyword matching starts missing things a semantic or graph-based search would catch. That's the signal to graduate to RAG or a knowledge graph, not a reason to skip markdown plus grep as a legitimate starting point.

5. Open knowledge formats

Open knowledge formats, such as schema.org, JSON-LD (JSON for Linking Data), and RDF (Resource Description Framework), structure data using a shared, public vocabulary instead of a format only your own systems understand. Where the first four approaches structure data for your agents to read, open formats matter when the data needs to be readable by agents you don't control: a customer's AI assistant checking your product's pricing, a search engine's AI Overview summarizing your documentation, or a partner's agent pulling structured facts from your public site.

This is a different job from the other four, and it's easy to conflate them. A semantic model, knowledge graph, or RAG index is internal infrastructure serving your own agents. Open formats are a publishing choice, closer to how you already mark up a webpage for search engines, except the audience reading that markup increasingly includes an AI agent instead of only a crawler. If your data only needs to serve your own team's agents, this is the one approach on the list you can reasonably skip.

The five approaches at a glance

Which one should you use?

Match the structure to the question, not the vendor pitch. In practice, that means asking what kind of question the agent needs to answer:

• "What's our [metric]?" a recurring, governed business number. Use a semantic model.

• "How does X connect to Y, and what does that chain imply?" multi-hop reasoning across entities. Use an ontology or knowledge graph, optionally with GraphRAG-style retrieval.

• "What does this document say about...?" fact lookup across a large corpus you didn't write by hand. Use RAG.

• "What's our process for...?" a corpus small enough that you know roughly where the answer lives. Plain markdown plus grep is often faster to build and equally reliable.

• "Can an agent I don't control read this?" a partner's, customer's, or a search engine's AI. Use open formats.

Most production systems combine two or three of these rather than picking exactly one: a semantic model for metrics, RAG for contracts and support tickets, and grep-searchable internal docs for team runbooks, all read by the same agent. The mistake isn't picking one approach. It's assuming one approach has to cover every question.

How this plays out in practice

Take a Revenue Operations team building one agent to help with renewals. In a single conversation, that agent might field five different kinds of questions, and each one wants a different structure behind it.

"What's this account's net revenue retention?" is a governed metric with one correct calculation. The agent should query a semantic model, not write its own SQL against raw subscription tables and hope it matches finance's number.

"Who at Acme Corp reports to whom, and which of them also sits on the renewal decision?" is a multi-hop question across people, roles, and accounts. That's a knowledge graph question. A flat table or a text search won't trace the reporting chain.

"What did the contract say about the renewal notice period?" is one fact, buried in one document, out of thousands of contracts. RAG retrieves the relevant clause without anyone having to read every file.

"What's our internal playbook for a renewal at risk?" points to a few dozen well-organized runbook documents the team wrote and knows by heart. Plain markdown plus grep finds the right one in milliseconds, with zero infrastructure to maintain.

"Does our public pricing page make sense to the customer's own AI assistant?" is an agent-you-don't-control question. That's the open-format case.

No single approach on this list answers all five. That's the real argument for treating "how do I structure my data for AI agents" as a portfolio decision, not a one-time architecture choice.

The migration path tends to run in one direction. Teams start with markdown plus grep because it's the fastest thing that works. They move pieces of it to RAG once the corpus outgrows keyword search. They add a knowledge graph only once they hit a specific class of question, usually a multi-hop one, that RAG keeps getting wrong. Few teams start with a knowledge graph on day one, and that's a reasonable default: build the structure your current questions require, and add more only when a real question exposes the gap.

Context engineering vs. prompt engineering

Everything above is an exercise in what's now being called context engineering: deciding what information reaches the model's context window, in what form, and how much of it. That's distinct from prompt engineering, which is how you phrase the instructions in a single message. The distinction matters because a perfectly worded prompt can't fix a model that was handed the wrong facts, or too many of them.

However you structure your data (semantic model, knowledge graph, RAG, or a markdown file) the same discipline applies. Give the agent exactly the facts it needs to answer the question, not everything you have.

Conclusion

Five real approaches, five different jobs. A semantic model for governed metrics. A knowledge graph for multi-hop reasoning. RAG for fact lookup across a big corpus. Plain markdown and grep for a small one. Open formats for the agents you don't control. The vendors selling each piece will tell you theirs is the answer. It usually isn't, not on its own. Start from the question your agent needs to answer, and the right structure follows from that, not from whichever infrastructure happens to be easiest to sell you.

This article was originally published on the RevOS blog.

Want to see this on your own revenue data? Book a RevOS demo.

Kubernetes is the obvious destination and the least documented one. There's no official Helm chart. The container image's init sequence needs root in a way that collides with a standard restricted pod security context. Its state model assumes a single writer. And the reload story that works fine in a terminal has no equivalent your GitOps controller can call.

None of that is a reason to avoid Hermes on Kubernetes. It's a reason to know the constraints before you write the manifest. Below: what genuinely breaks, what only looks like it breaks, and a reference deployment to start from.

Tested against: Hermes Agent v2026.8.27 · official image nousresearch/hermes-agent · Kubernetes 1.31+ · containerd 2.x. Hermes ships releases every few days. Before you copy anything below, check it against the version you're actually deploying, and pin that version.

Is there an official Helm chart for Hermes Agent?

No. Nous Research's own documentation covers install.sh, Docker and Docker Compose, and Nix packages. Kubernetes never comes up as a deployment target. That gap is filled entirely by the community, and the three charts that fill it don't agree on much:

• ultraworkers/hermes-agent-helm-chart: the most feature-complete option: renders a Deployment, PVC, Secret, Service, Ingress, and an Istio VirtualService, plus an "operator-ready" mode defining a HermesTenant CRD. It's also the only one that encodes the single-writer rule as a hard constraint.

• jyje/hermes-agent: listed on Artifact Hub as a verified publisher, distributed over an OCI registry, with multi-arch images and example ArgoCD manifests. It tracks upstream Hermes releases more closely than the other two.

• duyet/hermes-agent: the simplest of the three, splitting persistence into separate data and workspace volumes, with an optional Prometheus ServiceMonitor. Not a verified publisher, so read the templates before trusting the defaults.

None of the three is backed by Nous Research. Read the templates end to end before you apply one, and expect to override the security context.

Hermes Agent is stateful: define your persistence boundary first

This is the decision everything else hangs off, so make it before you pick a chart.

Hermes keeps all of its mutable state (configuration, MEMORY.md, USER.md, session history in a local SQLite database, and every learned skill) under HERMES_HOME. In the official image that's the /opt/data volume, which the Docker docs call "the single source of truth for all Hermes state."

So the accurate invariant is not "Hermes can't scale." It's:

Treat each HERMES_HOME as a single-writer state domain.

You can run many Hermes instances in one cluster. What you must not do is put two active pods behind the same mutable state and assume Kubernetes has handed you horizontal scaling. Nothing arbitrates concurrent writes to that SQLite database and those Markdown files.

In practice, for any deployment with persistence enabled:

• replicaCount stays at 1.

• strategy.type must be Recreate, not RollingUpdate, a rolling update deliberately runs the old and new pod together, which is exactly the two-writer window to avoid.

• ReadWriteOnce is the sensible guardrail on the PVC. RWX isn't automatically unsafe (the invariant is one active writer, not one mount) but RWO enforces it at the storage layer instead of trusting your deployment config.

Need Hermes for more than one team or tenant? One release per tenant, each with its own volume. Any chart that doesn't enforce this is a data-corruption risk waiting for a bad rollout.

Why the official image fights runAsNonRoot

The common shorthand, "Hermes has to run as root," is wrong, and the precise version matters when you're arguing with a platform team about a Pod Security Standard exemption.

The official image uses s6-overlay as its init system. s6-overlay's /init runs as root so it can chown the volume on first boot, then drops to the hermes user via s6-setuidgid for the main program and all supervised services.

So the agent process itself does not run as root. Only the bootstrap does. But that's still enough to break a restricted security context: a pod spec with runAsNonRoot: true or a non-zero runAsUser blocks the sequence before the agent ever starts, and you get something close to:

/package/admin/s6-overlay/libexec/preinit: fatal: /run belongs to uid 0 instead of 1000,
has insecure and/or unworkable permissions, and we're lacking the privileges to fix it.
s6-overlay-suexec: fatal: child failed with exit code 100

One detail worth getting right, because published examples routinely get it wrong: the hermes user is UID 10000, not 1000. Set fsGroup: 1000 and the volume ends up owned by the wrong group.

A reasonable starting security context:

podSecurityContext:
  runAsUser: 0
  runAsNonRoot: false
  fsGroup: 10000
  fsGroupChangePolicy: OnRootMismatch
  seccompProfile:
    type: RuntimeDefault
securityContext:
  allowPrivilegeEscalation: true
  readOnlyRootFilesystem: false
  runAsNonRoot: false
  capabilities:
    drop: ["ALL"]
    add: ["CHOWN", "SETUID", "SETGID"]

That is meaningfully narrower than a privileged pod: every capability is dropped and only the ones the bootstrap needs come back. Treat the exact capability list as a starting point to verify against your image version, not a universal recipe. Start from drop: ["ALL"], add back only what your logs prove necessary, and re-test on version bumps.

If your cluster enforces the restricted Pod Security Standard, this workload needs a namespace exemption. Forcing the official image to start non-root isn't a setting you've missed, it wasn't built for that.

What Hermes can hot-reload, and what it can't

The claim that Hermes has "no hot-reload" is false, and the real limitation is more interesting.

Hermes documents three reload commands: /reload-mcp (reload MCP servers from config.yaml), /reload-skills (re-scan for newly installed or removed skills), and /reload (reload .env variables into the running session).

The runtime can absolutely pick up new MCP servers and skills without a restart. The gap is the interface:

Hermes can hot-reload MCP servers and skills interactively, but doesn't expose the same lifecycle through its admin API.

That's the actual Kubernetes problem:

ConfigMap updated -> kubelet syncs file into the pod -> no reconciliation hook -> nothing happens

The file changes on disk. Nothing tells the process. Your options:

1. Restart the workload. kubectl rollout restart deployment/hermes-agent. Blunt but declarative, and with Recreate you're accepting a brief outage anyway. Wire a checksum annotation over the ConfigMap into the pod template so the rollout fires automatically on config change, the standard Helm checksum/config pattern.

2. Drive the runtime reload path from a sidecar or an operator with a channel into the agent. Workable, but you're building the missing hook yourself.

Until an HTTP reload endpoint exists upstream, option 1 with a config checksum is the pragmatic default.

Resources, probes, and graceful shutdown

Three things almost every Hermes-on-Kubernetes writeup omits.

Resources. Nous Research's Docker documentation recommends a minimum of 1 GB memory and 1 CPU core, with 2-4 GB memory and 2 cores recommended. Browser automation (Playwright/Chromium) is the most memory-hungry feature, so budget above that range if the agent drives a browser. Set a memory limit, but consider leaving CPU unlimited, agent workloads are bursty, and CPU throttling shows up as mysteriously slow tool calls rather than a clean failure.

Probes. The gateway listens on port 8642. The Dockerfile ships no HEALTHCHECK and no EXPOSE instruction, so you're defining this yourself. A tcpSocket probe against 8642 is the portable choice. The one that matters most is the startupProbe: first boot does volume chown work and profile reconciliation, and a liveness probe with a short threshold will kill the pod mid-bootstrap and loop forever.

Graceful shutdown. Hermes is stateful, so SIGTERM handling isn't academic. Give it room with terminationGracePeriodSeconds: 30, and test what actually happens to in-flight agent runs, SQLite session writes, and open gateway connections when a pod is evicted. Node upgrades and spot reclaims will do this to you eventually, and Recreate means no second pod is covering the gap.

Two security boundaries, not one

Most Kubernetes writeups on agents cover pod security and stop. For an agent that executes code, that's half the problem.

Boundary 1, pod security. Root init, capabilities, seccomp, filesystem, service account. Covered above.

Boundary 2, agent execution. What the model can actually run, and what it can reach. This is the one that should worry you more, because the pod is the blast radius.

Hermes has real defences here:

• Credential filtering. execute_code blocks environment variables whose names contain KEY, TOKEN, SECRET, PASSWORD, CREDENTIAL, PASSWD, or AUTH. MCP stdio subprocesses receive only a short safe list of variables.

• The bypass is explicit. Variables declared by a skill or listed in env_passthrough skip those filters. That's the mechanism to audit.

• Approval checks are skipped in container backends. Hermes skips dangerous-command approval in the docker, singularity, modal, daytona, and vercel_sandbox backends, on the reasoning that "the container itself is the security boundary." In a Kubernetes pod that assumption is load-bearing: whatever your pod can reach, prompt-injected code can reach.

• SSRF protection exists, and is disableable. Web tools block RFC 1918 ranges and loopback by default. In a cluster, RFC 1918 is your service mesh, your databases, and the kubelet.

Which leads to the control most often missing: default-deny egress. An agent that browses the web and calls tools is not a normal web app, and "what can this pod reach?" is a more consequential question than which Linux capabilities it holds. Start from deny-all and allow only what's needed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: hermes-agent-egress
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: hermes-agent
  policyTypes: ["Egress"]
  egress:
    # DNS
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
    # HTTPS to the internet, minus internal ranges
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
              - 169.254.169.254/32   # cloud instance metadata
      ports:
        - protocol: TCP
          port: 443

Blocking 169.254.169.254 matters especially: on a node without IMDSv2 enforced, an agent that can reach instance metadata can often reach the node's IAM role.

On credentials: because the agent has terminal access, anything in its environment is potentially readable by it. On EKS, use IRSA or EKS Pod Identity rather than static access keys in a Secret. Elsewhere, External Secrets Operator, Vault, or Sealed Secrets all keep plaintext keys out of Git. And scope the IAM role tightly: the agent's permissions are the agent's capabilities.

A minimal deployment that actually works

Pinned, single-writer, probed, and resource-bounded. Adjust the storage class and image tag, and read it before you apply it.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: hermes-agent-data
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hermes-agent
  labels:
    app.kubernetes.io/name: hermes-agent
spec:
  replicas: 1
  strategy:
    type: Recreate          # never two writers on one HERMES_HOME
  selector:
    matchLabels:
      app.kubernetes.io/name: hermes-agent
  template:
    metadata:
      labels:
        app.kubernetes.io/name: hermes-agent
      annotations:
        checksum/config: "REPLACE_WITH_CONFIGMAP_CHECKSUM"
    spec:
      serviceAccountName: hermes-agent
      terminationGracePeriodSeconds: 30
      securityContext:
        runAsUser: 0
        runAsNonRoot: false
        fsGroup: 10000
        fsGroupChangePolicy: OnRootMismatch
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: hermes-agent
          image: nousresearch/hermes-agent:v2026.8.27   # pin it; never :latest
          args: ["gateway", "run"]
          ports:
            - name: gateway
              containerPort: 8642
          envFrom:
            - secretRef:
                name: hermes-agent-secrets
          securityContext:
            allowPrivilegeEscalation: true
            readOnlyRootFilesystem: false
            runAsNonRoot: false
            capabilities:
              drop: ["ALL"]
              add: ["CHOWN", "SETUID", "SETGID"]
          resources:
            requests:
              cpu: "500m"
              memory: 2Gi
            limits:
              memory: 4Gi
          startupProbe:
            tcpSocket:
              port: gateway
            periodSeconds: 5
            failureThreshold: 60
          readinessProbe:
            tcpSocket:
              port: gateway
            periodSeconds: 10
          livenessProbe:
            tcpSocket:
              port: gateway
            periodSeconds: 20
            failureThreshold: 3
          volumeMounts:
            - name: data
              mountPath: /opt/data
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: hermes-agent-data
---
apiVersion: v1
kind: Service
metadata:
  name: hermes-agent
spec:
  selector:
    app.kubernetes.io/name: hermes-agent
  ports:
    - name: gateway
      port: 8642
      targetPort: gateway

Pair it with the NetworkPolicy above, a Secret (ideally rendered by External Secrets or Sealed Secrets rather than committed), and a ConfigMap for config.yaml if you're managing MCP servers declaratively.

Production checklist

• Image tag pinned to a specific release, never :latest

• replicas: 1 and strategy.type: Recreate, with one HERMES_HOME per instance

• PVC is ReadWriteOnce, and the storage class supports that access mode

• fsGroup: 10000 matches the image's hermes user

• Capabilities start from drop: ["ALL"], with additions verified against your image version

• Namespace exemption in place if you enforce the restricted Pod Security Standard

• startupProbe generous enough to survive first-boot volume work

• terminationGracePeriodSeconds set, and eviction behaviour tested against in-flight runs

• Memory limit sized for browser automation if skills use it

• Default-deny egress NetworkPolicy, with instance metadata (169.254.169.254) blocked

• No static cloud credentials in Secrets, use IRSA / Pod Identity / Vault / External Secrets

• env_passthrough and skill-declared variables audited, they bypass credential filtering

• Config changes trigger a rollout (checksum annotation) or a deliberate reload path

Where this connects to governed data

Everything above keeps Hermes Agent alive and contained. None of it says whether the answers it produces are correct, that depends on what it's allowed to read and how well-defined that data is. The same discipline that makes an agent's infrastructure trustworthy (scoped permissions, no unmanaged state, changes that go through review) reappears in agentic data engineering, where an agent's output earns trust through layered checks rather than raw model capability. Point an agent like this at real business data instead of chat platforms and a semantic layer is what stops it guessing at what "revenue" or "active customer" means.

This article was originally published on the RevOS blog.