Tools like Claude Code or OpenAI Codex have become mainstream as coding assistants, writing code, debugging errors, or explaining snippets.

Now, they are also quickly becoming the primary interface to modern data infrastructure. Instead of clicking through dashboards, teams are asking agents to set up pipelines, configure data catalogs, inspect data flows, and debug failures.

At RudderStack, we’ve built for this future and are increasingly seeing customers manage their CDP through agents.

As teams start using agents to operate their data stacks, a fundamental question is emerging:

What is the right interface for agents to interact with infrastructure: CLI, MCP, or both?

And as we’ve worked closely with these teams, a clear pattern has started to emerge:

It’s not a question of CLI vs MCP, but when to use each.

Understanding this distinction is key to building systems that agents can reliably operate.

Two types of agent interactions with infrastructure

When AI agents interact with a data system, their tasks fall into two fundamentally different categories. This distinction is subtle, but it drives everything about how the system should be designed.

1. State-changing operations (Write path)

These are operations that modify system state.

Examples include:

• Creating a new source
• Adding a destination
• Creating or modifying pipelines
• Updating a tracking plan
• Generating data models for customer-360 or predictive features

For these workflows, configuration + CLI (or Terraform) is the right interface.

The pattern is straightforward: The agent fetches the current state of the system (via CLI), generates structured configuration (YAML, JSON, Terraform) for the changes requested, a human reviews and validates the changes, and the CLI applies the change to the system on explicit approval.

The agent is able to leverage other CLIs or shell tools in this workflow, from validating the format to running unit tests etc.

This approach works well because changes remain explicit and reviewable, everything stays version-controlled, and humans remain in the loop for safety. The system also stays reproducible and deterministic.

In other words, this is AI-assisted Infrastructure as Code. And importantly, LLMs are exceptionally good at generating structured configuration.

2. Read-only system exploration (Read path)

The second category is fundamentally different. Here, the agent is trying to understand the current state of the system rather than change it.

These workflows typically look like:

• Why is this pipeline failing?
• Which events are reaching this destination?
• What changed in the tracking plan yesterday?
• How many users are flowing through this pipeline?

These are diagnostic and exploratory in nature.

To answer them, the agent needs to query system state, inspect metadata, traverse relationships, and reason over the results. For this class of problems, MCP (Model Context Protocol) is the ideal interface.

MCP enables agents to safely query systems, retrieve structured data, and explore without mutating state. This makes debugging safe, exploration repeatable, and the system protected from unintended changes.

The emerging pattern: CLI + MCP

What we’re seeing across teams is a clear architectural pattern:

Write → Config + CLIRead → MCP

This can be thought of simply as: state changes happen through the CLI, while system understanding happens through MCP.

This separation isn’t entirely new. It mirrors patterns in traditional infrastructure systems. But AI agents make it significantly more important.

Agents are extremely good at generating structured outputs like configurations, schemas, and transformations, which makes them well-suited for config-driven write paths via CLI.

At the same time, agents are inherently exploratory. They ask questions, iterate, and reason over intermediate results. This makes safe, read-only interfaces like MCP essential for enabling that behavior without risk.

When these concerns are blurred, systems become harder to debug, risk unintended mutations, and lose operational control. When they are clearly separated, you get better safety, clarity, composability, and overall agent reliability.

RudderStack was built for this model

Interestingly, this is exactly the model RudderStack has been evolving toward.

CLI + config for state changes

With Rudder CLI and Terraform, you can define your entire data stack as code—covering sources, destinations, tracking plans, transformations, and pipelines.

Everything is declarative, version-controlled, and reproducible.

This also makes it a natural interface for AI agents: They generate configuration, humans validate it, and the CLI applies it.

MCP for system introspection

On the read side, we’ve introduced MCP support.

Our MCP interface allows agents to inspect pipeline state, configuration, event flows, and system metadata in a safe, read-only way.

This enables agents to debug pipelines, analyze data quality issues, understand system behavior, and answer operational questions, without modifying anything.

The bigger shift: AI as the control plane

What’s emerging is not just a tooling shift, but an architectural one.

Traditionally, the interface to a data platform looked like:

UI → API → Infrastructure

Now it increasingly looks like:

Agent → (CLI + MCP) → Infrastructure

The agent becomes the control plane.

Humans express intent in natural language. Agents translate that intent into configurations and queries. Infrastructure executes those actions deterministically.

This changes how systems need to be designed. The best systems for this world will expose structured configuration for writes, clear CLI workflows for execution, and safe read-only interfaces for reasoning.

Final thoughts

We’re still early in this transition. But one thing is already clear:

AI agents are not just assisting with infrastructure. They are becoming the primary way it is operated.

And in that world, the question is no longer: CLI or MCP?

It’s: How well does your system separate and support both?