As CTO at Dispatch Integration, I work with many CTOs and product leaders at B2B SaaS companies across many sectors. In all of them, the integration conversation has historically been the same. A customer would ask whether the application is connected to some other system. The team looks at the roadmap, weighs the size of the deal and the probability of this being a one-off or a market segment, and either puts a connector on the roadmap or hands over the API docs and wishes the customer well. Integration is now a feature request. It queues up behind everything else.

The agentic era is changing this. Customers are no longer only asking you to connect to another system. They are building agents that will operate within your product on their behalf, coordinate with other agents connected to other systems, and orchestrate workflows that go far beyond a traditional integration.

These agents built by your customers are users you never onboarded, and cannot train. They often show up with credentials issued for a different purpose, and they do not behave exactly like a human user or like a traditional integration.

Govern AI Agent Access With Least-Privilege Permissions

When building an integration, best practice is to use an integration system user (or ISU), which is a service account created so that a middleware tool or a customer-built integration can read and write data. In practice, many of these ISU accounts have permissions you would never grant a human being. We’ve seen ISUs with full read access for every object and write access to records that the integration will never touch. Nobody scopes them down because it’s tedious, and the integration works either way.

This is not best practice, but it is survivable because integrations are deterministic. An integration that does the wrong thing does it the same way every single time. It can be damaging, but you find it, you fix it, you move on. The blast radius of a badly scoped ISU has historically been bounded by the fact that the code only ever does what the code says.

Agents are not bound in the same way. Give an agent that same god-level service account, and you have handed a non-deterministic actor the keys to your customer’s entire data set. That’s pretty scary. Now imagine 10,000 customers, each with 1,000 agents. 

The question for a product leader isn’t whether your customers will do this. They will if it’s easy. The question is what your role is in preventing them from running with scissors. That means auditable, governed access with exactly the permission level a given agent needs to take a given action, and not one step more. It means being able to answer, with an audit trail, which agent did what and under whose authority.

If your platform can’t express that today, that’s a roadmap item.

Why Your API Is Not an AI-Ready Semantic Layer

AI Agents need more than your API. They need to understand context and meaning.

An API spec tells an agent what endpoints exist and what shape the payload takes. It doesn’t tell the agent what any of it means, and meaning is what an agent needs in order to act correctly.

For example, timesheet data is called time_entries in one system, time_registrations in another, and time_submissions in a third. A human reads all three, thinks for 4 seconds, groks the differences from their experience, and takes the right action. An agent doesn’t automatically have the experience to know your time_entries maps to another system’s time_registrations, but doesn’t map to a 3rd system’s time_submissions, because that object is approved time, not raw time. Unless you have made it crystal clear what each object is, what it isn’t, and how it relates to the objects around it, the agent has to guess. And AI agents are confident guessers.

Related to this, you probably have excellent version control over your API. But you almost certainly have much looser control over your documentation. In just about every project we run at Dispatch, the production API never perfectly matches what the documentation says. Sometimes the documentation still refers to fields that were deprecated two releases ago, or the behavior was changed. 

That gap was tolerable when the reader was a developer who could test their way around it. It is not tolerable when the reader is an agent taking action on your customer’s data. Your semantic layer, including the documentation, object definitions, and a description of how your application actually works, now needs the same discipline and change control as your API.

Build MCP Services Around Jobs, Not API Endpoints

The fastest way to have an AI story is to wrap your existing REST API in an MCP server and announce it. Don’t do that.

First, it exposes write operations before you’ve built the governance to support them. Second, it worsens the semantic problem. A wrapped API that dumps a hundred and forty endpoints in front of an agent with no guidance about which one is appropriate will cause the agent to pick a plausible one. Plausible is not the same as correct.

It’s far safer and better to design MCP services around specific jobs, with scoped permissions and clear semantics, rather than mirroring your API surface. Workato’s platform is genuinely good at this, and it’s a large part of why we work in that ecosystem.

I’d also suggest starting with read-only access. It’s dramatically safer. A large number of customers will get immediate, obvious value from simply connecting their favourite LLM to your application and interrogating their own data conversationally. You can earn a lot of trust before you ever expose a write.

Move Critical Product Guardrails Beyond the User Interface

This piece of advice may surprise many product teams.

There’s a good chance some of your business logic lives in your user interface rather than in your backend. This is often not by design, but small choices accumulate. These are things like a confirmation dialogue that prevents a destructive action, a dropdown that only ever offers valid combinations or a screen that quietly won’t let you submit until three other things are true. All of that logic exists to protect and guide users.

None of it is reachable through your API. Which means an agent operating on your platform doesn’t have the guardrails your human users have never had to think about, because they are core to the user experience.

Finding out which of your rules live in the UI is a discovery exercise worth doing early, because remediation can sometimes be a real piece of engineering. You may need to move logic to the backend before your platform is safe to expose to agentic processes.

Understand the New Jobs Customers Give Their AI Agents

Your customers are not, for the most part, asking agents to do the same work their deterministic integrations already do. They’re asking for entirely different jobs to be done. This is often a long tail of work that was never economical for humans to do before and is not viable for deterministic automation.

Understanding the nature of this tail is both interesting and exciting because your customers are also learning what is possible. Meet with your AI-oriented customers who are already building agents for your application or others. Ask them what they’re trying to accomplish and why, and be inspired by their stories. Begin reading your own logs to see what agents are actually doing in your system. Great product teams are always doing customer research, but this is different because both the customer and the vendor are on the same journey of discovery at the same time about the art of the possible with agentic AI.

How Dispatch Helps Product Companies Prepare for Agentic AI

At Dispatch, we see all sides of this. We build integrated and orchestrated workflows, including agentic ones, for large and mid-sized enterprises, so we see what customers are actually trying to do inside other people’s products. And we help product companies build and manage the integration and orchestration layer for their platform, which is the basis for agentic communication.

None of what we see involves rebuilding the product. It’s really more about raising the bar on topics that you’ve always considered — thinking through permissions and governance, working on documentation and the semantic layer, placing product logic where it belongs, and learning which jobs your customers are trying to get done. Start narrow, start read-only, and start on the journey today.

Learn from more CIOs about why integrations are THE SYSTEM for the agentic era.