- AI agent integration with internal systems — what it means
- AI agent integration with internal systems means making business systems — CRM, inventory, core ERP and the like — readable and writable by AI. There are three methods: ① API integration ② CLI tools ③ MCP servers, and MCP is the one to build when staff should operate systems directly from the AI clients they already use, such as Claude or ChatGPT.
Hi, I’m Masato — a Webflow specialist who has been expanding into AI website production and AI development. I run a web production company called Webharu in Shiogama, Miyagi, Japan.
“We’ve rolled ChatGPT and Claude out internally. But the AI can’t touch our business systems — customer records, inventory — so in the end we’re still moving data around with screenshots and copy-paste.” That is the single most common situation we hear about in AI adoption conversations. This article is written for the IT, DX and engineering leads at companies that run business systems such as CRM, inventory or core ERP (it is not aimed at individuals or small teams looking to build a new service from scratch). We sort the ways of connecting an AI agent to your internal systems into three, cover which to choose when, and go all the way to the “don’t hand the AI the keys to everything” safety design that always comes up in internal approvals and board briefings — all based on what we run in production ourselves.
✓What’s in this article
- Three integration methods — API integration, CLI tools, MCP servers
- A comparison of the three (best fit, compatibility with AI clients, scale of development)
- An explanation of each, with our own examples
- How to build a “the AI never gets full authority” safety design (in a form you can drop straight into an approval document)
- How to start small, read-only first
The conclusion: there are three ways to connect an AI agent to internal systems
Starting with the answer. There are broadly three ways to let an AI agent operate your internal systems.
- ① API integration — give the system an entrance that can be read from and written to from outside. The base layer under every other approach
- ② CLI tools — call the AI from your internal tools and apps. A way to embed AI narrowly into one specific workflow
- ③ MCP servers — a standard that lets AI clients such as Claude, ChatGPT and Cursor operate your internal systems directly
And the choice, up front. If you want the AI your staff already use every day to touch your internal systems, MCP is the one to build. If all you need is a fixed process running automatically in the background, API integration is enough. If you only want to embed one AI feature into one internal tool, CLI is the shortest route.
Comparing the three — the deciding factor is “from which AI, and who uses it”
The table above in one line: if the AI your staff already talk to should do the work itself, build MCP; otherwise it depends on the use case.
API integration suits automated processes that connect systems behind the scenes — syncing data every night, registering form submissions into a core system, and so on. But if you try to hand a bare API to an AI, you are left with a translation step: explaining the endpoints and the authentication to the AI every single time.
CLI tools run the other way: your internal app calls the AI. The scope of work is small, but it becomes bespoke development per app.
The decisive quality of an MCP server is that it is a shared standard usable directly from any compatible AI client — Claude, ChatGPT, Cursor and others. Build for one specific AI service and you rebuild every time you switch; with MCP, you can change the AI and keep the same connection point (and the list of compatible clients has kept growing through 2026). The longer a business system is going to live, the more this matters.
Method ① API integration — the base layer between business systems and AI
An API is an entrance for reading from and writing to a system from outside. It long predates AI, but it is still the foundation of every AI integration. Neither an AI nor a program can touch a system with no entrance.
In our own case, we implemented a REST API on our CMS, HaruCMS (create, read, update and delete articles, image upload and so on), then put the MCP server described below on top of it. Because the API foundation came first, the MCP layer could stay thin — that order is the standard play. The full record of the design decisions is in our write-up on adding an API and MCP server to our own CMS.
API integration on its own suits automated processing with neither a human nor an AI in the loop. Conversely, if you want to operate the system inside a conversation with an AI, you need one more layer (MCP) above the API.
Method ② CLI tools — embedding AI into internal tools runs the other way
Where ① and ③ have the AI touching your internal systems, a CLI tool is the reverse: your internal tool calls the AI.
Here’s our own example. We built a CLI bridge that lets local apps and internal tools call an AI (Claude) with no API key at all, and we use it on live AI site-builder projects. Issuing API keys and distributing them to each tool turns key management and leak prevention into permanent operational overhead; this approach removes the worry itself.
It suits pinpoint AI features for one specific task — “I want a button that has the AI draft the quote,” that sort of thing. It is small to build, but it becomes bespoke work per tool, so for a company-wide AI foundation we choose ③, MCP.
Method ③ MCP servers — a standard usable directly from AI clients
MCP (Model Context Protocol) is a shared standard for AI to operate external systems. If an API is the entrance to a system, MCP is the hand the AI uses to open it. With an MCP server in place, your staff can say “list last week’s inquiries” or “save this article as a draft” inside their normal Claude or ChatGPT conversation, and it happens.
We have implemented MCP servers on two of our own SaaS products and run them in production. For the CMS, HaruCMS, we publish an eight-tool MCP server along with developer documentation and llms.txt; for the email API, HaruMail, sending and receiving can be driven through MCP. These are not sales demos — they are what we use every day.
We have first-hand lessons too. Trying a general-purpose third-party MCP (Webflow MCP 1.0), simply connecting it loaded so much information that it consumed most of the AI’s context and never became usable (the measurements are in our article on trying Webflow MCP). That experience is why our own MCP servers rigorously follow a “few tools, small responses” design. An MCP server isn’t done when it is built; this design quality is what decides whether it is usable.
The practical side of building an MCP server is covered in our MCP server development guide, and putting one on top of an existing SaaS or in-house service in our article on embedding MCP into a SaaS.
Safety design — “never hand the AI full authority” is something you build, not something you ask for
This is where the biggest anxiety sits for DX and IT leads. “If we give the AI the keys to our internal systems, what stops it deleting or sending something on its own?” The answer, up front: if you design the API and MCP so that dangerous operations simply cannot be executed, you can integrate without ever handing the AI full authority. A policy of “let’s instruct the AI carefully” protects nothing. Structure protects you. The four items below are written so you can put them straight into an approval document or a board briefing — because being able to say “even if the AI misfires, the damage is structurally capped here” is what gets internal sign-off. These are the four designs we run in production.
① Key revocation — when a person leaves, their key stops too
In HaruCMS, suspending a member automatically revokes any API key that person issued. If keys survive independently of accounts, you get the hole where “we disabled their login, but external writes still go through.” In an internal system where transfers and departures are inevitable, this is the first mandatory item.
② Two-step dangerous operations — an API where nothing fires in one shot
In HaruMail, every sending tool can only get as far as creating a draft; the actual send can only be executed by a separate tool called confirm_send. If the AI misunderstands, all that happens is one draft. Rather than asking in the prompt “please don’t send anything on your own,” make one-shot sending structurally impossible — and every irreversible operation, sending email, taking payment, deleting, publishing, can be made two-step on the same principle.
③ Audit logs — record every operation, traceable afterwards
Every write operation goes into an audit log. Because a record of when, which key and what action is preserved, anything unexpected can be identified immediately and that single key stopped.
④ Allowlists — narrow what can be written from the start
On the admin MCP that operates our own platform, write operations are limited to a safe allowlist. Instead of handing over a key that touches everything and trusting the holder to be careful, we narrow the authority we hand over in the first place.
How to proceed — three stages, starting small and read-only
Do not plan writes into your core systems from day one. The path we recommend has three stages.
- Stage 1: connect read-only. The AI is allowed to reference data and nothing else. With no write permission, data cannot structurally be lost or altered. Just “the AI can answer questions about internal data” eliminates most copy-paste transcription
- Stage 2: open up writes behind two-step approval. Registration, sending and publishing are added in the form “the AI drafts, a human checks and confirms.” The same idea as HaruMail’s confirm_send above
- Stage 3: full operation. With audit logs and key management in place, widen the systems covered and the operations permitted
In this order, every stage has a fixed ceiling on “how bad it can get.” Start small and widen only where the effect is visible — that is the standard play for AI integration.
Our development menu maps onto the same three stages. Stage 1 corresponds to the MCP Starter (read-only) at ¥2,500,000 (excl. tax, roughly 4–6 weeks); the API + MCP Full Pack at ¥5,000,000 (excl. tax) covers REST API design, authentication and authorization, rate limiting, audit logs, two-step dangerous operations, the MCP server and developer documentation; and Full Integration from ¥10,000,000 (excl. tax, quoted individually) covers unrestricted writes, multiple AI clients and per-system work. Slicing the approval into stages — “read-only scope first” — assembles the evidence decision-makers need and makes it far easier to get through.
In closing: the barrier to AI adoption isn’t the AI’s ability, it’s the entrance
Most of the time, AI adoption stalls not because of what the AI can do but because the AI cannot touch your data. Three methods — API for background automation, CLI for pinpoint embedding, MCP when your staff’s AI should operate the system directly. And safety is built not from operational policy but from structure: key revocation, two-step operations, audit logs, allowlists. That is the conclusion we have arrived at running our own services in production.
Webharu takes on API and MCP server development as a complete package, through authentication, rate limiting, audit logs and public documentation (details of our API & MCP Development service). Even if all you want is a verdict on “could this task of ours be handed to an AI?”, do get in touch through a free consultation.
FAQ
How much does it cost to develop an AI agent integration with internal systems?
We offer it as a three-stage menu (all excl. tax). ① MCP Starter (read-only) ¥2,500,000 — an entry plan that puts a read-only MCP layer over an existing REST API, roughly 4–6 weeks ② API + MCP Full Pack ¥5,000,000 — the full set, from REST API design through authentication and authorization, rate limiting, audit logs, two-step dangerous operations, the MCP server and developer documentation ③ Full Integration from ¥10,000,000 — unrestricted writes, multiple AI clients, quoted individually per system. Ongoing maintenance starts at ¥150,000/month. Most companies begin with the read-only starter, because it is the easiest to get approved.
How long does development take?
It depends heavily on whether the existing system has an API. If a well-organized API already exists, the MCP layer on top is thin; if not, the work starts with designing the entrance (the API) and takes longer. We work in stages — get a small read-only scope running first, then widen once the effect is visible — which shortens the distance to the first result.
Our internal systems are old and have no API. Can they still be integrated?
Yes. In that case we start by designing the entrance (the API). You do not need to expose every feature — the standard play is to build a read-only entrance for just the data you want the AI to touch. Once the API foundation exists, an MCP server goes on top so your internal AI clients can use it.
Could the AI delete our internal data or send it outside on its own?
We stop that by design. In our production systems four things are built into the structure: ① suspending a member automatically revokes the keys they issued ② dangerous operations such as sending email cannot execute without going through a separate tool, confirm_send ③ every write operation is recorded in an audit log ④ writes are limited to operations on an allowlist. The principle is to protect through structure, not through operational policy.
Can it be used from both ChatGPT and Claude?
If you build it as an MCP server, the same connection point works from any compatible AI client — Claude, ChatGPT, Cursor and others (the list has kept growing through 2026). The key point is not to build for one specific AI service, so that switching doesn’t mean rebuilding.
Where should we start?
Pick the one task where people spend most of their time copying from one screen into another, and connect that data to the AI read-only. With no write permission, accidents are structurally impossible, and the effect is felt immediately. If you aren’t sure which task fits, you are welcome to use our free consultation just for a verdict on “could this be handed to an AI?”
