Your ERP Has a New Coworker. Here's What You Need to Know.
How AI agents connect to the systems that run your business and what two weeks of news just clarified.
Last week, two things happened that most finance and ops teams missed.
SAP updated its API policy to block third-party AI agents from interacting with its systems. Salesforce made it generally available for developers to build and deploy agents directly from the command line. Two large companies, moving in opposite directions, betting differently on the same question: how should AI agents actually talk to enterprise software?
The answer to that question determines what’s automatable in your organization over the next few years. It’s worth understanding.
What an Agent Actually Does
An AI agent is a language model that takes actions, not just answers. It can query a database, open a file, send an email, update a record. The difference between a chatbot and an agent is a set of tools and the autonomy to decide when to use them.
In an enterprise context, the tasks agents are most valuable for tend to span multiple systems. Reconciling invoices against the GL touches an AP inbox, an ERP, and maybe a shared drive. An agent has to reach across all of them, which means connection is the foundational problem.
The Two Dominant Approaches: MCP and CLI
MCP — Model Context Protocol
MCP is an open standard, originally created by Anthropic and now stewarded by the Linux Foundation, that gives AI agents a structured way to interact with external systems. An MCP server sits in front of a tool or data source and exposes a menu of callable functions along with descriptions of what each one does and what parameters it takes. The agent reads the menu, decides what it needs, and makes calls accordingly.
The appeal is standardization. In the same way that APIs let SaaS products plug into each other, MCP lets agents treat external systems as interoperable building blocks. NetSuite ships an AI Connector Service built on MCP. Salesforce supports MCP. The ecosystem is growing.
CLI — Command Line Interface
A CLI is a program you run from a terminal. It accepts commands, executes them, and returns output. It’s not a new idea; it’s how developers have interacted with systems for decades but it’s becoming a first-class integration surface for agents.
Salesforce’s move to ship a dedicated agents plugin for its CLI is the clearest recent example. Developers can now build, configure, test, and deploy Agentforce workflows using the same terminal-based toolchain they’ve always used for code. Agents can do the same.
The CLI’s advantage is composability. The output of one command becomes the input of the next. Data can be filtered, reshaped, and piped through a chain of operations without ever loading it fully into memory. That property, mundane in a developer workflow, turns out to matter enormously for ERP tasks.
When There’s No API
A significant share of enterprise systems — especially on-premise deployments, legacy platforms, and older ERP configurations — don’t have usable APIs. Or the API exists but covers a fraction of the data model, requires expensive licensing, or is so poorly documented as to be effectively inaccessible.
In those cases, the integration surface is whatever the system already exposes.
Email remains one of the most durable integration channels in enterprise software. A large portion of the operational data that flows through a business still moves through inboxes. An agent that reads and writes email participates in those flows without touching a database.
SFTP is how older systems exchange bulk data at scale. Many SAP, Oracle, and legacy MRP environments produce nightly or weekly file drops An agent that reads from an SFTP folder has access to a rich, structured data stream, no API required.
Screen automation, aka RPA is the last resort, and increasingly a viable one. It’s fragile when interfaces change, but for systems that expose no other programmatic surface, it works. AI-powered document parsing has made the unstructured outputs of these interfaces considerably more tractable.
The through-line: the system doesn’t need to change. The agent adapts to whatever surface is already there.
The Three Things an Agent Needs
Reducing this to first principles, an agent automating work in an ERP or system of record needs three things:
1. Data
The information relevant to the task: transaction records, invoice data, vendor master, chart of accounts, whatever the workflow touches. It might come from the ERP directly, from a file share, from email, or from a warehouse. Getting it to the agent cleanly and completely is the first constraint.
2. A Code Environment
ERP tasks are really a chain of transformations and lookups. "Do these invoice line items match the PO within tolerance?" is not answerable by reading data. It requires joining two datasets, computing variances, applying business logic, and producing a structured output. An agent with access to a code environment can do this properly: write a script, run it, inspect the result, adjust, and iterate. Without one, the agent is limited to reasoning in natural language about data it has already read into memory.
3. A Way to Push and Pull from Systems
Once the agent has reasoned about the data and reached a conclusion, it needs to either pull more or push something back. This is where MCP and CLI come in. The integration layer is what makes the agent's output operational rather than advisory.
Why CLI Wins for ERP Work
MCP's value proposition is tool discovery: a structured, typed interface where the agent can ask "what can this system do?" and get a documented answer back. For exploratory tasks or unfamiliar APIs, that's genuinely useful.
But ERP data has a characteristic that breaks the core assumption of most MCP deployments: volume.
A material master in SAP can span millions of rows across multiple views. When an MCP server loads this into the agent’s context window, the architecture becomes bounded by what fits (or rather what doesn’t). Language models have finite context windows, and production ERP datasets will exceed them.
CLI sidesteps this because the code environment handles the data, not the context window. The agent writes a query or script to extract exactly the records it needs. That data lands on disk. A second script transforms and filters it. The output is what reaches the model. The model reads a few hundred rows instead of a few million.
The data is also persistent between steps. An agent working through a multi-step task doesn’t need to hold everything in memory simultaneously. It fetches, stores, computes, fetches again. CLI composability, i.e piping output from one command into the next, is exactly the right tool for this pattern.
That doesn’t make MCP useless. For structured write operations where typed validation before anything touches the system of record is valuable, for multi-agent setups where a central orchestrator coordinates across many downstream tools, MCP earns its overhead. The pattern that tends to work in our experience: CLI for data work, MCP at the point of write.
What the SAP Policy Actually Means
SAP’s new API policy prohibits the use of its APIs for “interaction or integration with semi-autonomous or generative AI systems that plan, select, or execute sequences of API calls.” It also bans “systematic or large-scale data extraction.”
The practical effect is that third-party agents (anything not running through SAP’s own AI layer, Joule) are now in technical violation if they’re making API calls autonomously. The policy says enforcement rights include throttling, suspension, and termination. It explicitly prohibits circumvention through proxies, custom code, or intermediary services.
The DSAG, representing tens of thousands of SAP customers across Germany, Austria, and Switzerland, has publicly criticized the policy for creating uncertainty and potentially blocking innovation. They’ve noted that the policy doesn’t clearly specify which APIs are affected, leaving customers unable to determine what’s compliant. SAP has reserved the right to change the approved API list unilaterally.
SAP markets this as a system stability measure. The commercial effect is that it steers AI workflows toward Joule and SAP’s own ecosystem. These are not mutually exclusive positions.
The workarounds for teams who need to operate outside that ecosystem are, again, the non-API surfaces: SFTP exports for bulk reads, email-based flows for exception handling, and human-in-the-loop checkpoints before anything writes back. Not the architecture anyone would design from scratch, but functional, auditable, and fully outside the policy’s scope.
The Bottom Line
Agents can already connect to your ERP. Through APIs where they're open, through file drops and inboxes where they're not, and through screen interfaces as a last resort. The connection question is largely solved. What separates successful automation from nice Proof-of-Concepts is the combination of a code environment capable of handling real data volumes and an architecture that keeps humans in the loop at the right points.
Thoughts, pushback, or things working differently in your environment: hit reply.