DEV Community: RevOS.ai

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.

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

DEV Community: RevOS.ai

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

What is an MCP server?

What does "MCP" stand for?

How does an MCP server work?

The three things an MCP server can expose

MCP server vs. API: what is the difference?

Why AI agents need MCP servers

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

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

MCP vs. RAG: a quick distinction

What to look for in a data MCP server

How is an MCP server secured?

Shared secret tokens

OAuth: acting on behalf of the user

Risks worth understanding

Frequently asked questions

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

Is an MCP server a real server?

Why would I need an MCP server?

Does ChatGPT use MCP?

What is MCP in agentic AI?

What is an MCP server in simple terms?

Can you host your own MCP server?

What is the difference between MCP and RAG?

How is an MCP server secured?

The bottom line

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

What is agentic data engineering?

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

How agentic data engineering works

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

What it looks like in practice

The trust problem: governing an AI agent on production data

Will AI agents replace data engineers?

What tools power agentic data engineering

Where agentic data engineering is headed

Getting started

Frequently asked questions

What is agentic data engineering?

How is agentic data engineering different from traditional data engineering?

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

Will AI agents replace data engineers?

How accurate is AI at writing SQL?

What tools power agentic data engineering?

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

Do AI data agents need a semantic layer?

How do I get started with agentic data engineering?

AI Trends 2026: Self-Service BI Is Becoming Agentic

The four generations of self-service analytics

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

Why raw text-to-SQL breaks agentic analytics

Anthropic reached the same conclusion in production

A governed semantic layer gives agents shared meaning

MCP is becoming the interface between agents and business data

People and agents working from the same definitions

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

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

Is there an official Helm chart for Hermes Agent?

Hermes Agent is stateful: define your persistence boundary first

Why the official image fights runAsNonRoot

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

Resources, probes, and graceful shutdown

Two security boundaries, not one

A minimal deployment that actually works

Production checklist

Where this connects to governed data

Why the official image fights `runAsNonRoot`