DEV Community: RevOS

Why I Failed the DP-700 Exam, and How I Passed It

RevOS — Mon, 26 Oct 2026 10:47:03 +0000

By Viktor Goloubovsky, data engineer at RevOS

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

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

Practice

Microsoft's DP-700T00-A practice labs
Microsoft's practical assessments
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.

What Is an MCP Server? A Complete Guide to Model Context Protocol

RevOS — Fri, 23 Oct 2026 11:57:56 +0000

Key takeaways

An MCP server is a standardized connector that lets any AI agent access live data, tools, and services through the Model Context Protocol: a single open standard rather than a custom integration per tool.
MCP stands for Model Context Protocol, an open specification originally developed by Anthropic. It lets AI models request context, run tools, and read resources in a consistent, structured way.
Unlike a REST API, an MCP server speaks AI natively: it exposes tools (actions), resources (data), and prompts (reusable templates), not raw HTTP endpoints the model has to interpret.
For data teams, an MCP server is how you give an AI agent governed access to your warehouse, semantic model, and business metrics without writing a custom integration for every AI tool in your stack.
RevOS ships an MCP server as its consumption layer, so Claude, Cursor, or any MCP-compatible agent can query your certified revenue metrics by name, without building the integration yourself.
An MCP server acts on behalf of the user. Its access is established with either a shared secret token or a user-friendly OAuth flow, so the agent inherits the user's own permissions and can only reach data that person could already see.

Your AI assistant sounds confident. It answers in complete sentences, cites figures, and explains its reasoning. The only problem: those figures came from data you pasted into the chat ten minutes ago, or from the model's training data, which ended months before your most recent quarter.

An MCP server is what changes that. It is the connection between an AI agent and live data: the layer that lets Claude, Cursor, or any AI tool reach into your database, query your business metrics, or trigger an action in an external system, on demand, without you lifting a clipboard.

What is an MCP server?

An MCP server is a program that exposes data, tools, and actions to AI agents through the Model Context Protocol. The AI agent connects to it, discovers what it can access, and issues requests. The server handles the rest: querying the underlying system, enforcing permissions, and returning results in a format the model can use.

In practice it works like this. An AI agent running in Claude or Cursor wants to know your pipeline coverage for Q3. Without an MCP server, it cannot look that up; it only knows what is already in its context window. With an MCP server connected to your data warehouse, it sends a request to the server, which runs the query and returns the answer directly into the agent's working memory.

💡 In one sentence: an MCP server is the standardized interface that lets an AI agent reach beyond its context window and interact with live data, tools, and services, on its own, without a human copy-pasting or writing custom integration code.

The protocol was designed specifically for AI agents, not for humans or traditional software. That distinction matters: an MCP server does not expose raw HTTP endpoints for a developer to call in code. It exposes things an AI model can discover and use autonomously.

What does "MCP" stand for?

MCP stands for Model Context Protocol. It is an open specification originally developed by Anthropic, released in late 2024, and now supported across the broader AI ecosystem, including Cursor, Windsurf, Microsoft Copilot, and dozens of open-source agent frameworks.

"Model context" describes exactly what it provides: context for the model. An AI model's intelligence is bounded by what is in its context window: the text, documents, and conversation history it can see. The protocol is the mechanism for expanding that window dynamically, by fetching exactly the information the agent needs at the moment it needs it.

How does an MCP server work?

The architecture has three components: a host, a client, and a server.

The host is the AI application the user interacts with: Claude Desktop, Cursor, or a custom agent you built. It manages one or more client connections.
The client runs inside the host and maintains a one-to-one connection to a specific MCP server. Each tool or data source you connect gets its own client.
The server is the program that exposes the actual capabilities: the tools, resources, and prompts an AI agent can use.

When you start a session, the client and server negotiate capabilities (each announces what it can offer), and the agent can begin using whatever is available. The transport layer for local servers is typically standard I/O, a subprocess the host spawns. Remote servers communicate over HTTP, which allows for streaming responses.

The three things an MCP server can expose

Every MCP server exposes capabilities through one or more of three primitives:

Tools are actions the agent can invoke: running a query, calling an API, submitting a form. A tool has a name, a description, and a schema for its inputs and outputs. The agent reads the description and decides whether to call the tool. For example: a run_metric_query tool that accepts a metric name and a date range and returns the result.

Resources are data the agent can read: documents, files, database records, live feeds. Unlike tools, resources are meant to be retrieved and placed into context, not acted on. For example: a configuration file, a record from a CRM, or a page from a knowledge base.

Prompts are reusable templates: predefined instructions or question formats the user or agent can invoke to trigger a specific behavior. For example: a "summarize this quarter's revenue trends" prompt that the agent knows how to fill in and execute against the data.

MCP server vs. API: what is the difference?

The comparison comes up constantly because both connect software to external systems. They are genuinely different things, and the difference is worth understanding clearly.

	REST API	MCP server
Designed for	Developers calling it from code	AI agents using it autonomously
Discovery	API docs you read; no self-description at runtime	Agent queries the server for its capability schema at runtime
Interaction model	Request-response, stateless per call	Stateful session with capability negotiation
What it exposes	HTTP endpoints (GET /users, POST /orders)	Tools, resources, and prompts
Who decides what to call	The developer writing the code	The agent, based on the task

The practical consequence: connecting an AI agent to a REST API requires a developer to write integration code (parsing the response, deciding which endpoint to call for which question, handling errors). Connecting an agent to an MCP server requires configuring the server once. After that, the agent figures out what to call on its own.

This is why "MCP server vs. API" is slightly a false framing. Many MCP servers are thin wrappers around existing REST APIs or databases. The MCP layer is what makes those systems usable by an AI agent without custom integration work per tool.

Why AI agents need MCP servers

An AI agent without external connections is like a brilliant analyst in a locked room. They can reason, synthesize, and explain, but only from the materials already in the room. Every question that requires live data forces you to carry that data in from outside: by pasting, uploading, or writing custom code to fetch it.

MCP removes that constraint. When an agent has access to an MCP server, it can:

Ask a question that requires live data and retrieve it on the spot
Chain multiple tool calls across a task: look up a number, compare it to last quarter, then check which segment drove the change
Take actions in external systems, not just read from them
Operate over time, with memory of what it retrieved earlier in the session

The reason MCP matters more than ad-hoc custom integrations is standardization. Without a common protocol, every AI agent needs a custom integration for every tool it might use, and every tool needs to know about every agent format. With MCP, any server that speaks the protocol works with any client that speaks it. One integration per tool; one client per agent.

MCP servers for business data: the use case most guides miss

Most writing about MCP servers focuses on developer tools: GitHub repositories, code files, terminal commands, Slack messages. That is the first wave of adoption, and it is real. But it is not where the highest-value use case lives for most B2B SaaS companies.

The highest-value use case is giving an AI agent access to business data: revenue metrics, pipeline health, customer retention signals, product usage patterns. This is the data that drives decisions, and it lives in places an AI agent currently cannot reach: your data warehouse, your CRM, your billing system.

The problem with connecting an AI agent directly to a database is not the connection; MCP makes that technically straightforward. The problem is the layer above it.

If your AI agent can query your data warehouse directly, it will write its own SQL to answer your questions. Sometimes it guesses correctly. More often, it misses a filter, joins the wrong table, or defines "churn" differently than your finance team does, and returns a confident, specific, wrong answer. You have no way to tell which kind of answer you received.

This is where the semantic layer comes in. A semantic layer defines your business metrics once (the exact SQL, the correct joins, the approved filters) and serves them to whatever is reading your data. When your MCP server sits on top of a semantic layer instead of raw database tables, the AI agent does not write SQL. It requests a certified metric by name: "net revenue retention, last quarter, EMEA segment." The semantic layer returns the one correct calculation. The agent cannot hallucinate a definition it never had to invent.

📊 The pattern that works: raw warehouse tables feed a governed semantic model, and an MCP server exposes that model to AI agents. The agent asks for metrics by name. The semantic layer enforces the definitions. The warehouse returns the data. No custom SQL, no invented business logic, no reconciliation meeting.

What you can actually ask an AI agent with a data MCP server

With a well-structured data MCP server connected to a semantic layer, a RevOps analyst or data engineer can ask questions that previously required an analyst queue:

"What is pipeline coverage for Q4 by segment, compared to this time last year?"
"Which accounts had a significant drop in product usage in the last 30 days?"
"What drove the change in net revenue retention from last quarter to this quarter?"
"Show me the top 20 accounts by expansion opportunity, using our current scoring model."

Each of these questions requires multiple joins, specific metric definitions, and knowledge of your data model. A data MCP server with a semantic layer underneath handles that translation: the agent selects from defined metrics, not from raw columns.

This is what a modern data strategy for the AI era looks like in practice: not a dashboard refresh cycle, but an AI agent that can answer these questions on demand, with the same definitions your best analyst would use, whenever someone needs to know.

MCP vs. RAG: a quick distinction

These two come up in the same conversations, and they are genuinely different.

RAG (Retrieval-Augmented Generation) works by taking a question, searching a vector index of documents, pulling the most relevant text chunks, and loading them into the model's context window before it answers. It is a text-retrieval technique, best for unstructured content like documentation, support tickets, or contracts.

MCP is a protocol for tool use and live data access. The agent does not search a vector index; it calls a specific tool or reads a specific resource. For structured data, MCP with a semantic layer is more accurate than RAG because you are retrieving an exact metric definition, not approximating from text.

In practice, many production systems use both: RAG for knowledge retrieval (documentation, policies, unstructured records) and MCP for live, structured data (metrics, operational data, actions). They are complementary, not competing.

What to look for in a data MCP server

Not all MCP servers for data are the same. When you are connecting an AI agent to business-critical metrics, a few things matter beyond "does it work."

Governed metric definitions. If the MCP server exposes raw SQL access, every agent call is a potential metric definition problem. Look for servers that sit on top of a semantic layer, so the agent picks from certified metrics, not from tables.

Row-level and column-level access control. An AI agent inherits the permissions of the person using it. If access control is not enforced at the data layer, a user can ask the agent for data they should not see. Access rules defined on the semantic model propagate to every tool that queries through it, including the agent.

Predictable, auditable behavior. When an executive asks "where did this number come from?", you need an answer. A data MCP server that routes through a governed semantic model gives you one: the metric name, the definition version, the underlying query, all traceable. Getting your data ready for AI agents starts with that kind of auditability.

Transport and authentication. For production deployments, remote MCP servers run over HTTP. Confirm the server supports proper authentication (OAuth, API keys, or session tokens) before connecting it to sensitive data.

How is an MCP server secured?

Connecting an AI agent to your business data raises an obvious question: what can it actually see, and who said it could? The answer comes down to identity. A well-built MCP server never holds a blanket key to everything. It acts on behalf of a specific person, and it is bound by that person's existing permissions.

There are two common ways that identity gets established: a shared secret token, or an OAuth flow.

Shared secret tokens

The simplest approach is a static credential (an API key, a personal access token, or a bearer token) that you paste into your client's configuration. The agent presents that token on every request, and the server trusts it.

This is the default for local MCP servers. The Model Context Protocol authorization spec expects local (stdio) servers to read credentials from the environment rather than run a login flow, so a token in a config file or environment variable is exactly the right tool. It is fast to set up, with no redirect screens or consent prompts.

The tradeoff is bluntness. A shared secret identifies a connection, not a person. One key maps to one fixed set of permissions, it tends to be long-lived, and it sits in plaintext wherever you stored it. If it leaks, whoever holds it inherits whatever that key could do, with no per-user attribution and a manual rotation to clean up. For a single developer wiring up a local tool, that is fine. For a team querying sensitive revenue data, it is not enough.

OAuth: acting on behalf of the user

The better pattern for remote, multi-user servers is OAuth. Instead of pasting a secret, you click "Connect," authenticate with your normal login, and approve a consent screen that spells out exactly what the agent is allowed to do. The MCP server receives a short-lived, scoped access token (no long-lived secret ever lands in your config), and that grant can be refreshed or revoked at any time.

The MCP authorization spec is built on OAuth 2.1 for HTTP-based servers. The client requests access on behalf of the user, the server validates every token and confirms it was issued specifically for that server, and the flow uses PKCE so the authorization code cannot be intercepted and replayed. The upshot for you is simple: the agent inherits your identity. Every query it runs executes as you, so it can only ever reach data you were already allowed to see.

🔒 This is why identity matters more than any network firewall here. If the agent runs as the user, your existing access controls (roles, row-level and column-level security defined on the data) do all the work automatically. The agent cannot become a backdoor to data the person behind it could never open themselves.

This is the model RevOS uses. Rather than handing every user a static key, the RevOS MCP server uses a user-friendly OAuth flow: each person connects with their own identity, and the governed semantic layer enforces exactly the permissions they already have. The agent answers questions, but it answers them as you.

Risks worth understanding

Even with clean authentication, a handful of MCP-specific risks are worth knowing before you connect a server to sensitive data:

Token passthrough. The spec explicitly forbids an MCP server from forwarding the caller's token to an upstream API. If the server needs to call another service, it must obtain its own token for that service. Passing tokens through blurs the trust boundary and invites the next problem.
The confused deputy. A server that proxies requests to other systems can be tricked into using its own privileges on behalf of an attacker. Strict redirect-URI validation, per-client consent, and verifying that a token was issued for this server are the standard mitigations.
Prompt injection and tool poisoning. Malicious instructions hidden in a tool's description or in the data it returns can hijack the model. This is an LLM-trust problem rather than an auth problem, and it is mitigated by sanitizing inputs and pinning tool definitions so they cannot silently change after you approve them.
Over-broad scopes. Request only the permissions the task needs. The principle of least privilege keeps the blast radius small if anything does go wrong.
Audit logging. You need to know who asked the agent for what. A production MCP server should log authentication and every tool invocation to storage you can trust.

None of this is exotic. It is the same identity-and-access discipline you already apply to dashboards and BI tools, extended to the agent that now queries on your behalf.

Frequently asked questions

What is the difference between an API and an MCP server?

A REST API exposes HTTP endpoints designed for a developer to call from code. An MCP server exposes tools, resources, and prompts in a structure AI agents understand natively, so the model can discover what is available, decide what to call, and handle the result autonomously. APIs are for developers. MCP servers are for AI agents.

Is an MCP server a real server?

Yes. An MCP server is a real process running on a machine, locally or in the cloud, communicating over a transport layer (standard I/O for local processes, HTTP for remote ones). What makes it an MCP server is the protocol it speaks: the Model Context Protocol message format, capability negotiation, and the tools, resources, and prompts it exposes.

Why would I need an MCP server?

When you want an AI agent to access live data or perform actions autonomously. Without one, the agent only knows what is in its context window. With an MCP server connected to your data sources, it can query your database, pull your business metrics, or trigger actions on demand. For data teams, this is how you stop manually copying numbers into chat and let the agent retrieve them itself.

Does ChatGPT use MCP?

Yes. ChatGPT can connect to MCP servers as custom connectors, and Claude, Cursor, Windsurf, and many open-source agent frameworks support MCP natively too. The RevOS MCP server, for example, can be added in either Claude's or ChatGPT's connector settings.

What is MCP in agentic AI?

In agentic AI, MCP is the communication layer between an agent and the tools and data it operates on. Agentic systems plan and act across multiple steps; MCP standardizes how they access external capabilities at each step. The agent discovers what tools are available, calls them as needed, and acts on the results, all through one protocol, without needing a custom integration for every tool.

What is an MCP server in simple terms?

An MCP server is a plug-in slot for AI agents. Just as a USB port lets you plug multiple devices into a computer through one standard interface, an MCP server lets an AI agent connect to multiple data sources and tools through one standardized protocol. Instead of asking you to paste in a spreadsheet, the agent queries the server directly and gets the answer itself.

Can you host your own MCP server?

Yes. The Model Context Protocol is an open standard with official SDKs in Python, TypeScript, and Java. You can build and host an MCP server for any data source or tool you control. Local servers run as a subprocess over standard I/O. Production servers run as HTTP services. Many teams start with an open-source MCP server for a common tool and build custom ones for proprietary data.

What is the difference between MCP and RAG?

RAG searches a vector index of documents and pulls relevant text into the model's context window. MCP is a protocol for live tool use and data access: the agent calls a specific tool or queries a specific resource. For unstructured content like documentation, RAG works well. For structured business data like metrics and operational records, MCP with a governed semantic layer is more accurate because the agent retrieves exact definitions instead of approximating from text.

How is an MCP server secured?

Through identity. An MCP server authenticates the caller, usually with one of two mechanisms: a shared secret token (an API key or bearer token you configure, the norm for local servers), or an OAuth flow (where you log in and approve scopes, the norm for remote, multi-user servers). With OAuth the server acts on behalf of you specifically, so the agent inherits your permissions and can only reach data you are already allowed to see. The Model Context Protocol authorization spec is built on OAuth 2.1 for HTTP-based servers.

The bottom line

An MCP server is the layer that closes the gap between an AI agent's intelligence and the live data it needs to act on. For development teams, it unlocks code-aware agents. For data teams, it unlocks something more significant: an AI that can answer business questions from your actual data, with the same metric definitions your analysts use, without a custom integration per tool.

The protocol is open, the ecosystem is growing fast, and the infrastructure already exists to build this, or to get it bundled. RevOS ships an MCP server as the top layer of its data platform, on top of a governed semantic model, so any MCP-compatible agent can connect and query your certified metrics by name from day one.

If you are evaluating what it takes to give AI agents access to your business data, start with the semantic layer: that is the governed layer your MCP server should expose. The MCP server is the interface. The semantic layer is what makes the answers trustworthy.

This article was originally published on the RevOS blog.

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

Claude Code, Cowork, Tag, and Routines: A Practitioner's Map to the Claude Ecosystem

RevOS — Thu, 22 Oct 2026 10:26:35 +0000

Key takeaways

Claude Code isn't one app. It's a single agent engine behind a terminal CLI, IDE extensions, a Desktop tab, and Claude Code on the web. Your CLAUDE.md and MCP servers travel with you across all of them.
Claude Cowork runs the same engine inside a sandboxed desktop (and now web/mobile beta) workspace, organized around local folders and a background planner called Dispatch, but it doesn't read your Claude Code CLI's ~/.claude setup.
Claude Tag puts Claude in your team's Slack channels under the organization's own shared credentials, not any one person's. That's the real difference from Cowork and Code, which stay private to you.
"Routines" names at least three unrelated things: cloud-run Claude Code Routines, local Desktop scheduled tasks, and Slack-native Claude Tag routines. They don't share a task list.
The organizing question isn't "which tool is smartest". It's whose credentials run the work, and who gets to see it.

Anthropic didn't ship one Claude product this year. It shipped four, and gave three of them names that sound like they should mean the same thing. Ask a few people on your team "what's the difference between Claude Code and Claude Cowork?" and you'll get a different answer each time. Mention "the Claude routine" and you still don't know whether they mean a cron job in the cloud, a task running on their laptop, or something set up entirely inside Slack.

This is a Claude Cowork vs. Claude Code question, but it's bigger than those two. By the second half of 2026 there are four surfaces worth knowing apart:

Claude Code: a coding agent you drive from a terminal, an IDE, or a browser.
Claude Cowork: an agentic workspace for outcome-oriented work on your files.
Claude Tag: Claude working inside your team's Slack channels.
Routines: a word Anthropic uses for at least three unrelated kinds of scheduled automation.

None of this is a rebrand of the others. Each is a different envelope around the same underlying agent, built for a different job. Here's the map.

Claude Cowork vs. Claude Code: the quick answer

Surface	Runs on	Who sees the work	Best for
Claude Code	Your credentials, your machine or your own cloud session	Just you	Hands-on coding in an existing repository
Claude Cowork	Your credentials, a sandboxed workspace	Just you	Outcome-oriented work on local files, no terminal needed
Claude Tag	Your team's shared credentials	Everyone in the Slack channel	Shared work the team should see and steer
Routines (any form)	Whichever surface created them	Depends on the form	Unattended, scheduled, or triggered work

The row that matters most for the rest of this guide: whose credentials run the work, and who can see the result. Claude Code and Cowork stay private to you. Claude Tag is visible to a whole channel by design. Routines run unattended. Keep that distinction in mind; it explains more about which tool to reach for than "how technical is the user" does. Plenty of engineers live in Cowork, and plenty of non-engineers now trigger a Claude Code Routine without ever opening a terminal. That question also generalizes well past Claude: every agent should have an identity, but not every agent should have its own authority.

Prefer video? Here's the whole map in one walkthrough:

Claude Code: your terminal, your checkout

Claude Code is an agent that reads your codebase, edits files, runs commands, and works with your existing dev tools. The important thing to understand is that "Claude Code" isn't a single app. It's one engine behind several surfaces: the terminal CLI, extensions for VS Code and JetBrains, a Code tab inside the Claude Desktop app, Claude Code on the web, and mobile. Your CLAUDE.md project memory, your settings, and your connected MCP servers (the standard way Claude reaches outside tools and data) work the same way across every one of them, because they all talk to the same underlying engine.

In practice, that means you can start a task in the terminal, hand it off to the web version so it keeps running after you close your laptop, or pull a cloud session back down locally when you want hands-on control again. It's designed to be extended: project memory, reusable skills, hooks that run on specific events, and a headless mode (claude -p) for piping output into scripts or CI pipelines.

Who it's for: developers and engineering teams working inside an actual repository, with their own credentials and their own machine (or a cloud session tied to their own account).

Sample use cases:

claude "write tests for the auth module, run them, and fix any failures": a self-contained coding task run start to finish.
Piping log output through Claude Code for anomaly triage: tail -200 app.log | claude -p "flag anything unusual".
Starting a long refactor on Claude Code on the web, then pulling it down locally once it's ready for a closer look.

Is Claude Code just Cursor?

This comes up constantly, and the answer is no. They solve overlapping problems with different shapes. Cursor is a fork of VS Code: the AI lives inside the editor, suggesting and applying changes as you work, one file at a time. Claude Code is terminal-native and session-based: you describe an outcome, and the agent plans, edits multiple files, runs commands, and reports back, with or without an editor open at all.

This isn't a fringe question. Stack Overflow's 2025 Developer Survey found 84% of respondents were using or planning to use AI tools in their development process, up from 76% the year before, and 50.6% of professional developers already use one daily. It's the default way most teams now write code. Among developers who'd tried an autonomous coding agent specifically, the same survey found adoption split across ChatGPT (81.7%), GitHub Copilot (67.9%), and Claude Code (40.8%): evidence that most teams aren't choosing one tool and stopping, they're running several. The "Where Cursor still fits" section below covers how that plays out day to day.

If your team already links agentic tools to a real project, see how we structure data so AI agents can query it reliably. The agent is only half the story; what it can actually read matters just as much.

Claude Cowork: same engine, different envelope

Claude Cowork is easy to misread as "Claude Code for non-engineers," and that undersells it. Cowork runs the same agentic engine that powers Claude Code, inside the Claude Desktop app, without opening a terminal, but it's organized around a different unit of work. Instead of a git checkout, you point it at Projects: local folders paired with standing instructions and a project-scoped memory that stays on your machine. Instead of responding turn by turn, Claude works toward a described outcome and you check back once it's done.

The piece that makes Cowork genuinely different from "Claude Code with a nicer UI" is Dispatch, a background planner that splits a multi-step brief into subtasks and routes each one to the surface that fits: knowledge-work pieces stay in a Cowork session, coding pieces get handed to a Code session. Ask Dispatch to "summarize the open reliability-tagged issues and draft a status update," and it can pull that off from your phone while your desktop does the actual work.

Two things worth knowing before you reach for it:

It's not desktop-only anymore. Cowork is generally available on macOS and Windows via Claude Desktop, and now in beta on web and mobile for Pro, Max, and Team plans (Enterprise, where an admin turns it on). On web and mobile, local file access and connectors still run through your desktop app in the background, so your computer has to be on.
It doesn't inherit your Claude Code CLI setup. Cowork loads skills, plugins, and connectors from your claude.ai account settings, not from your terminal's ~/.claude directory. If you've spent time tuning Claude Code locally, none of that carries over automatically. It's a genuinely separate configuration surface, and it's the single most common trap for people who assume "same engine" means "same setup."

Who it's for: anyone doing file-and-document-heavy work who doesn't want to open a terminal, including engineers, since Dispatch explicitly hands coding subtasks to a Code session on their behalf.

Sample use cases:

Point Cowork at a folder of contracts and have it produce a comparison spreadsheet with working formulas.
Kick off a Dispatch request from your phone ("summarize this week's open threads and draft the team update") and find it done when you're back at your desk.
Have it work alongside Claude in Chrome (Claude's browser extension for driving a live website) to complete a task that needs more than local files.

For the bigger idea behind letting an agent own more of a workflow end to end, see our piece on agentic data engineering. Cowork's Dispatch model and the "describe the outcome, review the result" pattern it uses show up there too, just applied to data pipelines instead of documents.

"@claude" in Slack: Claude Tag, not the old Slack integration

If your team already has Claude working inside Slack, it's worth checking which version you're on, because there are two live right now with genuinely different account models.

Claude Tag (currently in public beta) is Claude working in your team's Slack channels under the organization's own shared credentials, not any individual's Claude account. An admin sets it up once per channel at claude.ai/admin-settings/claude-tag, and after that, anyone in the channel can just tag @Claude with no setup of their own. Each thread spins up a fresh, sandboxed working session (built when the thread starts, released when it goes quiet) running on the same engine as Claude Code on the web. It posts a live checklist as it works, and anyone in the thread can redirect it by replying, without re-tagging it.

That's the real distinction from Cowork and Code: this work is visible to the whole channel by design, and it's billed against the organization's own usage balance, not any one person's plan. It's currently available on Team and Enterprise plans. Pro and Max plans still use the older, individually authenticated Slack integration, which runs under each person's own account and their own limits. Anthropic is retiring that older integration for Team and Enterprise workspaces in favor of Claude Tag. There's no public cutover date, so ask your account team rather than assuming a timeline.

Who it's for: teams that want shared, visible work a whole channel can watch and steer: incident triage, decision threads, or status rollups that shouldn't live in one person's DMs.

Sample use cases:

Tag @Claude in an incident channel to investigate a latency regression against the morning's deploy and open a PR.
Turn a sprawling decision thread into a clean doc or a tracked ticket.
Ask it to pull together the state of a project across a dozen open threads and a launch plan in Drive.

We cover where this fits alongside other agent categories in our rundown of enterprise AI agents, if you're mapping this against a broader agent rollout.

"Routines" means three different things: pick the right one

This is the part of the ecosystem most likely to get someone confused mid-conversation, because Anthropic uses the word "Routines" for at least three separate mechanisms, and none of them share a task list with each other.

Claude Code Routines (cloud, research preview): a saved Claude Code configuration (a prompt, one or more repositories, and a set of connectors) packaged once and triggered automatically. It runs on Anthropic-managed cloud infrastructure, so it keeps working with your laptop closed. Triggers combine three ways on a single routine: on a schedule (hourly up to weekly, or a custom cron), via a direct API call to the routine's own endpoint, or from a GitHub event (a pull request opening, a release publishing). This is the mechanism actually behind this post: a GitHub label triggered a Claude Code Routine that researched, drafted, and validated the draft you're reading.
Desktop scheduled tasks (local): created from the same "Routines" panel in the Claude Desktop app, but choosing "Local" instead of "Cloud." These run on your own machine, with real local file access, only while your computer is on and the app is open.
Claude Tag routines: a completely separate, Slack-native idea. Standing work you set up in plain English inside a channel, like "every weekday at 9am, check the linked tickets in this channel and post a one-line status." No cron syntax, no dashboard; you just ask, and manage it later by tagging Claude again.

Who it's for: anyone who wants Claude to do something without a person kicking it off in real time: an engineer scheduling nightly checks, or a channel that wants standing status updates with nobody assigned to remember it.

The practical takeaway: if a teammate says "I set up a routine," ask where. A cloud routine keeps running when their laptop is shut. A local one doesn't. A Slack routine only exists inside that one channel. They're three different systems that happen to share a name.

Sample use cases:

A weekly GitHub-triggered routine that reviews every pull request against a house style guide before a human looks at it.
A nightly local task that reorganizes a folder of downloaded reports, useful only while your machine is actually on.
A Slack routine that watches a pull request and pings the channel the moment it merges.

Where Cursor still fits

None of this makes Cursor obsolete. The "which one wins" framing that dominates most comparison posts online misses how teams actually use these tools together: most professional developers now use more than one AI coding tool, per the adoption figures above, rather than settling on a single winner. Cursor's strength is still the in-editor, keystroke-level loop: inline suggestions and quick edits while you're heads-down in one file. Claude Code's strength is the session-level agent loop: describing an outcome and letting it run across files, tests, and commands with less of your attention.

Worth knowing if you're evaluating either company's staying power: SpaceX fully acquired Cursor's parent company, Anysphere, in an all-stock deal finalized on August 14, 2026, per an SEC Form 8-K filing, as reported by Yahoo Finance. Cursor now operates as part of SpaceX's newly formed "SpaceXAI" division rather than as an independent startup. That's a genuinely new fact worth factoring into a build-vs-buy decision, separate from which tool writes better code today.

Most teams we talk to don't pick one. They keep Cursor open for fast, in-file edits and reach for Claude Code (or Cowork, for the non-coding half of the job) when a task is big enough to hand off entirely.

How RevOS uses this stack

We're not writing this as outside observers. RevOS's own CLI is built specifically to be driven by AI coding agents like Claude Code and Cursor. That's a deliberate design choice, not an afterthought, because the whole point of the product is letting an agent build your data layer from plain-English intent instead of hand-written pipelines.

And the meta-example: this very post exists because of a Claude Code Routine. A label on a GitHub issue triggered a cloud routine that researched the keywords, pulled the competitive landscape, drafted this MDX file, and ran it through a validation pass: the same "Routines" mechanism described two sections up, running unattended against our own content pipeline. It's the clearest sample use case we have, because you're reading its output right now.

Frequently asked questions

Is Claude Code just Cursor with a different name?

No. Cursor is a fork of VS Code with AI features built into the editor UI. Claude Code is a terminal-native agent that can also run inside an IDE, a desktop app, or a browser tab, the same engine either way. The practical difference is where you spend most of your time: inside an editor loop (Cursor) or handing off a full task to an agent that plans, edits, and runs commands across a session (Claude Code).

Who should use Claude Code?

Developers and engineering teams working inside an existing repository who want to hand off a whole task, not just one line of autocomplete, and get back a plan, edited files, and a report. It fits equally well driven from a terminal, an IDE, a desktop app, or piped into a script or CI job.

What is Claude Cowork?

Claude Cowork is an agentic workspace built on the same engine as Claude Code, designed for outcome-oriented work on local files and folders (contracts, spreadsheets, research) rather than a git checkout. You describe the outcome you want and check back once it's done, instead of responding turn by turn.

Is Claude Cowork free?

No. It's available on paid Claude plans (Pro, Max, Team, Enterprise), with no separate free tier, though it's included at no extra cost once you're on one of those plans.

What is an agentic workflow?

An agentic workflow is a task an AI agent completes by looping through perceive, reason, act, and check steps on its own, rather than answering one prompt and stopping. In the Claude ecosystem, that loop is the same whether it runs in a terminal, a desktop workspace, a Slack thread, or on a schedule. The surface changes, the underlying agent doesn't.

Can you give an example of an agentic workflow?

A concrete one: "write tests for the auth module, run them, and fix any failures." The agent explores the codebase, writes the tests, runs the suite, reads the failures, edits the code, and reruns the tests, looping until they pass, without a person approving each individual step along the way. A single prompt in, a working result out.

Is ChatGPT an agentic AI?

It can act agentically when it uses tools, browses, or runs code across multiple steps, but its default chat mode is single-turn. "Agentic" describes a mode of operation (planning and acting toward a goal across a session), not one specific product. Claude Code, Cowork, and Claude Tag are all built around that agentic loop by default.

Is Cursor AI better than Claude Code for coding?

Neither wins outright. They're shaped for different moments. Cursor is strongest for in-editor, keystroke-level suggestions while you're heads-down in one file. Claude Code is strongest for session-level work: describing an outcome and letting an agent plan, edit multiple files, run commands, and report back. Most teams we see run both rather than standardizing on one.

What are the most common Claude Code use cases?

Writing and fixing code inside an existing repository, running and interpreting test suites, reviewing pull requests, and automating routine engineering chores like dependency bumps or log-triage scripts piped through claude -p. Teams also use it for tasks that don't look like coding at all (refactoring config files, writing docs from a codebase, or scripting one-off data cleanups) because the same agent that edits code can just as easily edit text.

This article was originally published on the RevOS blog.

RevOS works inside Claude, ChatGPT, Slack and Teams, so agents answer from the same governed revenue data. Want to see it on your own data? Book a RevOS demo.

Agentic Data Engineering: How AI Agents Build Data You Can Trust

RevOS — Tue, 20 Oct 2026 10:21:36 +0000

Key takeaways

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.

	What it does	Who decides the steps
Static automation (cron, Airflow DAGs)	Runs a fixed sequence someone wrote in advance	A human, ahead of time
AI copilot (autocomplete in your editor)	Suggests the next line or block while you drive	A human, line by line
AI agent	Pursues a goal across many steps, adapts to what it finds	The agent, within your guardrails
Traditional data engineering	A person hand-builds each pipeline, query, and test	A human, step by step

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:

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.
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.
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.)
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:

	Generic AI agent	Agent with a control layer
Starts from	A blank file: no schema, no definitions	Your schema, dbt models, and business definitions
Picks the right answer by	Guessing, fluently	Grounding: your lineage, semantics, and access policies
Catches a wrong answer with	Nothing; it ships	Validation loops, PK/unique checks, data contracts, CI/CD
Mistakes surface	In production, in a downstream dashboard	At review time, as a pull-request diff
In production it acts	Unsupervised	Scoped, time-bound, human-in-the-loop, fully audit-logged

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.

AI Agent Identity: Who Acted, and Under Whose Authority?

RevOS — Fri, 16 Oct 2026 08:21:20 +0000

Suppose you tell an agent: move Acme to At Risk, create a task for the account owner, and prepare a renewal plan. The agent does exactly that.

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.

Platform	How it treats actor and authority
Microsoft Entra Agent ID	Ships both principals. Two explicit modes: autonomous access (rights given directly to the agent identity) and delegated access (acting on behalf of human users). For agents created in Copilot Studio, it also records the user who created the agent as its sponsor.
Google Cloud Agent Identity	Ships both principals, a layer lower. Each agent gets a strongly attested cryptographic identity based on the SPIFFE standard. Not a shared service account: not impersonable, no long-lived keys. Supports an agent using its own identity, and acting for a specific user.
GitHub Copilot coding agent	Ships both principals as two fields on one object: commits are authored by Copilot, with the human who started the task marked as the co-author. Neither identity disappears.
Salesforce Agentforce	Addresses authority, not attribution. Every agent is associated with a running user that determines what it can access. Whether standard audit fields name the agent is a separate, open question.
ServiceNow	Addresses authority by constraining it. Agents run as a dynamic user inheriting the invoking user's permissions, with role-masking limiting them to a subset of that user's roles. The intersection model, shipped and mandatory.
Model Context Protocol	Names both principals, and lists the work as unfinished. The spec forbids token passthrough, while the roadmap states that MCP authorization assumes a person with a browser at consent time, and calls for agents to be reachable through their own or a user-delegated identity.

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 Best Way to Structure Data for AI Agents

RevOS — Wed, 14 Oct 2026 10:03:35 +0000

Ask five vendors how to get your data ready for an AI agent, and you'll get five different answers, and every one of them will happen to be whatever that vendor sells. The graph-database company says knowledge graph. The vector-database company says RAG. The semantic-layer company says semantic model. None of them is lying, exactly. Each one is describing the one tool in their own box.

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

Approach	Best for	Setup cost	Maintenance	Sharpest weakness
Semantic model	Governed business metrics, repeated questions	Medium: model the metrics once	Medium: update as metrics evolve	Doesn't help with unstructured documents
Ontology / knowledge graph	Multi-hop reasoning across connected entities	High: model entities and relationships	High: keep the ontology honest	Expensive for simple lookup questions
RAG (vector search)	Fact lookup across a large, loosely structured corpus	Low: chunk, embed, index	Low to medium: re-index as content changes	More context isn't automatically more accurate
Plain markdown + grep	Small, well-organized internal corpus	Very low: organize files sensibly	Low: no infrastructure to run	Breaks down as the corpus grows or gets ambiguous
Open formats (schema.org, JSON-LD)	Data read by agents you don't control	Low to medium: markup your public content	Low: mostly set-and-forget	Doesn't structure data for your own internal agents

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.

AI Trends 2026: Self-Service BI Is Becoming Agentic

RevOS — Thu, 08 Oct 2026 11:16:44 +0000

The way people get answers out of company data is changing faster than the data stacks underneath them. For twenty years the answer to "why did that number move?" was a dashboard someone built in advance. In 2026, increasingly, the answer is an agent that goes and finds out.

Among the AI trends 2026 has surfaced, that is the one worth paying attention to. Not "companies are using more AI" (they are) but something more specific: self-service business intelligence is becoming agentic, and the constraint on whether it works has moved from the model to the data foundation underneath it.

The adoption numbers are already there. According to Google Cloud's ROI of AI Report, 52% of executives report their organizations are deploying AI agents in production, and 88% of agentic AI early adopters are already seeing positive ROI. What those numbers hide is how much of the work is data architecture rather than prompting. To build a trustworthy modern data strategy for the age of AI, you have to change how machines get meaning out of your warehouse, not just how they get access to it.

The four generations of self-service analytics

It helps to see where agentic analytics sits in a longer arc. Self-service BI has been reinvented roughly every decade, and each generation moved the work around rather than eliminating it.

Generation	Interface	Who does the thinking
1. Dashboards	Pre-built reports	Humans anticipate the question and build the answer in advance
2. Self-service BI	Filters, dimensions, drag-and-drop	Business users slice pre-modelled data themselves
3. Natural-language analytics	A chat box over the warehouse	An LLM turns a sentence into SQL; the user hopes it is right
4. Agentic analytics	An agent with tools and governed context	The agent investigates, validates, and follows up on its own

The fourth generation is not a nicer chat box. The difference is that an agent doesn't just answer the question you asked, it runs the next three queries a good analyst would have run, checks its own result, and tells you what it found.

The infrastructure for that is already being built at scale. According to customer usage data compiled by Databricks, multi-agent workflows have grown by 327% year over year, and supervisor agents coordinating networks of specialized subagents now account for 37% of all agent usage.

The next generation of self-service BI isn't another dashboard

The promise of self-service BI was always straightforward: let business users answer their own questions without waiting on the data team.

The interface kept getting easier. The underlying limitation never moved. Someone still had to anticipate the question, model the data, build the dashboard, define the metrics, and teach the user where to look. "Self-service" in practice meant "self-service, within the boundaries of what a data engineer already imagined you'd ask."

Agents change that equation. Instead of navigating dashboards, a sales leader can ask:

Why did expansion ARR drop in DACH this quarter? Which accounts caused it? What changed in their product usage in the months before the contraction?

No dashboard answers that question, because it isn't one question, it's an investigation. An agent can run that investigation dynamically: pull the metric, decompose it by account, join in product usage, look at the period before the drop, and come back with a narrative.

But only if it understands what "expansion ARR," "DACH," "account," and "product usage" mean inside your business. That is the whole problem.

Why raw text-to-SQL breaks agentic analytics

When teams build their first internal analytics agent, the instinct is to connect it straight to the warehouse: hand the model database credentials, write a prompt, and let it generate SQL.

This is where most projects stall. Direct text-to-SQL has three systemic weaknesses:

Schema complexity. A typical enterprise warehouse has hundreds of tables, column names like usr_act_v2, and three fields that all look like they might be revenue. A model guessing at what those mean will guess wrong often enough to matter.
No metric governance. If three agents query raw tables for "Monthly Recurring Revenue," you get three SQL statements and three different numbers, with no way to tell which one leadership should act on.
No safety boundary. Raw SQL access exposes every table the credential can reach, including the ones nobody intended an agent to see.

Databricks' customer data points the same direction: a lack of structural control is the single biggest bottleneck to shipping AI. Teams that implement governance and security tooling ship 12x more production deployments, and standardized evaluation tooling yields 6x more.

The failure mode isn't that the agent can't write SQL. Modern models write excellent SQL. The failure mode is that it doesn't know what your business means.

Anthropic reached the same conclusion in production

The strongest evidence for this isn't a vendor benchmark, it's Anthropic publishing its own internal architecture.

In How Anthropic enables self-service data analytics with Claude (June 3, 2026), Anthropic's data team reports that 95% of business analytics queries are now automated through Claude, at roughly 95% aggregate accuracy, and close to 99% in some domains. The headline result is impressive. The explanation is the useful part.

Anthropic is explicit that this is not a model story. Analytics accuracy, in their framing, is a context and verification problem, not a code-generation problem. The same Claude that reaches 95% with the right scaffolding never got above 21% on their internal evals without it.

Their agents don't start by improvising SQL. The stack they describe has four layers:

Data foundations: the warehouse itself: models, transformations, tests, and the metadata that describes them.
Sources of truth: a human-curated semantic layer of metric and dimension definitions, plus lineage graphs and business-context knowledge. Notably, they found that auto-generating metric definitions from raw tables and query logs didn't work: it reproduced the ambiguity instead of removing it.
Skills: procedural knowledge in markdown telling the agent which sources to consult, in what order, and what a finished answer looks like. That skill set is synced to multiple surfaces and served as resources over MCP.
Validation: offline evals, ablation testing, and online monitoring with adversarial review.

Two details matter most for anyone building this. First, the semantic layer is the required first path: when a question maps to a defined metric, the agent calls that definition and gets the same number every other surface in the company produces. Raw table access is the fallback, not the default. Second, the same governed context is exposed across agent surfaces, so the answer doesn't change depending on whether someone asks in Slack, in an IDE, or in a chat window.

And they are honest about the limits. This architecture reduces failures; it doesn't eliminate them. Anthropic keeps adversarial review running precisely because silent failures still happen, and reports that without active maintenance accuracy drifts from 95% back toward 65%.

Better models help. Better context architecture is what makes self-service analytics trustworthy.

A governed semantic layer gives agents shared meaning

A semantic layer is the translation between how data is stored and how the business talks. It maps raw tables to defined business concepts: instead of querying billing_ledgers_final, the agent queries an entity called Revenue and asks for MRR broken down by acquisition_channel.

Combining that with agent access gives agents something raw warehouse credentials cannot: a shared definition of customers, revenue, churn, pipeline, and every other concept they need in order to reason correctly.

The measurable effect is large. A general-purpose model writing SQL against an unmapped schema fails roughly half the time, Snowflake's internal benchmarks put GPT-4o at about 51% text-to-SQL accuracy on raw schemas. Grounding the same model in a governed semantic model lifts accuracy past 90%.

That is the same conclusion Anthropic reached, arrived at from a different direction: the governed definition is what turns a plausible answer into a correct one.

MCP is becoming the interface between agents and business data

Dashboards were the interface between people and business data. MCP is becoming the interface between agents and business data.

The Model Context Protocol (MCP), released as an open standard by Anthropic, is the emerging connection layer of the AI ecosystem, the USB-C port for agent tooling. Rather than writing bespoke integration code for every model and every tool, you run a reusable MCP server. The agent connects, discovers what's available (metrics, schemas, reports) and calls it. The same server works for Claude, for IDEs like Cursor, and for custom orchestrators.

Standardizing that interface pays off quickly. In its 2026 Business Trends Report, Google Cloud describes how pulp manufacturer Suzano cut query times by 95% for 50,000 employees by deploying standardized semantic data interfaces.

But MCP on its own doesn't make data trustworthy. It solves connectivity, not meaning. An MCP server pointed at raw tables is a faster route to the same wrong answers. The quality of what comes back still depends entirely on the governed context sitting behind it, which is exactly where the interesting engineering is.

People and agents working from the same definitions

None of this makes dashboards, analysts, or data teams disappear. It changes the collaboration model.

People define and govern what the business means, what counts as an account, how expansion ARR is calculated, which source system wins when two disagree. Agents perform the continuous investigation humans don't have time for. Both work from the same underlying definitions, and the semantic layer becomes the contract between them.

This matters more than it sounds, because of something Anthropic observes directly: once agents become the consumers of the data model, the person asking the question often can't validate the answer themselves. The reader of a dashboard could sanity-check a number against the chart next to it. The reader of an agent's paragraph cannot. Governance stops being a compliance concern and becomes the thing that makes the output usable at all.

From a modern data stack to an agent-ready data foundation

The usual framing of this problem is vendor sprawl, ingestion here, warehouse there, transformation, semantics, and a custom API on top. That framing misses the point.

The problem isn't that there are too many vendors. It's that traditional data stacks were designed for humans consuming dashboards, not for agents consuming context. A human reading a report brings their own business knowledge to it. An agent has to be given that knowledge explicitly, in a form it can navigate, which is a requirement almost no stack was built to satisfy.

An agent-ready data foundation comes together in four moves:

Connect your data. Managed ingestion from many sources into a warehouse you control.
Govern what it means. Define metrics, entities, and relationships once, version-controlled like code.
Serve it to agents. Expose the governed model through a secure MCP server, so Claude, your IDE, and your own agents all read the same definitions.
Learn continuously. Definitions, lineage, and skills evolve with the business instead of drifting away from it.

The practical difference at query time: agents don't guess against raw schemas. They work from the same governed definitions your business already trusts, rather than inventing their own interpretation of the underlying tables, which removes one of the largest sources of analytics hallucination.

This article was originally published on the RevOS blog.

Running Hermes Agent on Kubernetes: What Breaks, What Doesn't, and a Production-Safe Setup

RevOS — Tue, 06 Oct 2026 10:07:05 +0000

Hermes Agent is Nous Research's self-improving AI agent. It builds skills from experience, keeps persistent memory across sessions, and connects to Telegram, Discord, Slack, WhatsApp, and Signal out of the box. With 230k+ GitHub stars, plenty of teams now want to run it somewhere more durable than a laptop.

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:

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.
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.