Connect once. Use everywhere.

By Phoebe Maio and Sarah Berger

For most of software’s history, integrations were built around interfaces.

A person clicked a button in one application, which sent a request to another application. If you wanted the same action somewhere else (a different screen, a workflow, or a self-service experience) you built another integration.

That made sense when the caller was predictable. Usually, it was a person sitting in front of a specific screen.

AI agents break that assumption.

Today, a customer asking to cancel an order might be helped by someone on your team. Tomorrow, Gladly AI might handle it. The same cancellation could also be triggered by an automated workflow or by an AI agent built by another company.

The caller changes. The job does not.

Yet most integration architectures still treat these as separate use cases. They connect the order system to the agent desktop, then connect it again to the workflow engine, then connect it again to the AI agent.

You end up maintaining several versions of the same capability.

We think the better model is simple: The integration should belong to the action, not the interface that happens to use it.

That is the idea behind Gladly’s App Platform.

One action, many callers

Consider a common support request such as cancelling an order.

To complete it, your Gladly AI agent needs to know how to authenticate with the order system, what information the system requires, which API request to make, and what a successful or unsuccessful response looks like.

That is the real integration work, and once it has been done, it should not matter whether the request came from a button, a workflow, or an AI agent. Each caller should be able to use the same underlying action.

With App Platform, a team defines something like Cancel Order once.

If Gladly AI is handling the conversation, it can call the action directly. If a member of your team is helping the customer, they can run it from Gladly Team. The platform can generate a form for any required information and show the result as a card inside the conversation.

If the cancellation is part of an automated process, a workflow can call the action without a person being involved. And if an approved AI agent from another vendor needs to perform the same task, it can call that action through MCP.

These are not four integrations. They are four callers using one capability.

That distinction becomes more important as AI agents take on more work. Companies will not have one agent doing everything. They will have different agents for different jobs, built by different teams and vendors. Rebuilding every connection for every agent will quickly become impossible to manage.

Whatever architecture you choose also has to assume that new callers will appear.

A connection is a contract

When we say “define an action,” we do not mean writing instructions like “go cancel this order.”

The connection describes exactly how the action works. It defines the information the system needs, the request it expects, the authentication it requires, and the response it returns.

You can think of it as a contract between Gladly and the system being connected.

For example, Cancel Order might require an order ID and a cancellation reason. The order system may return a confirmation, an updated order status, or an error explaining why the cancellation was rejected.

App Platform turns that contract into something the rest of Gladly can use consistently. A form can collect the required information from a team member. A workflow can supply it automatically. An AI agent can determine when it has enough information to call the action.

The interface changes depending on who, or what, is using it. The contract stays the same.

This separation is what makes the connection reusable. The integration is no longer buried inside a particular feature. It becomes part of a shared layer that the platform can build on.

Most teams can start with connections that already exist

Gladly comes with connectors for systems such as Shopify, BigCommerce, Klaviyo, and many others.

Some actions retrieve information, such as looking up a customer’s orders or checking the status of a shipment. Others change something in the connected system, such as cancelling an order or updating a customer record.

A team chooses the connector it needs, authenticates its account, and turns on the actions it wants to make available.

The connector and the account are separate. The connector defines how Shopify works, for example, while the account provides the credentials for a specific store. This means the same connection can support a US store and an EU store without combining their data or permissions.

There will always be systems for which a connector does not already exist. In those cases, a developer can create one.

AI is also changing that part of the process. Because a connector is a structured description of an API request, a model can read API documentation and draft much of the implementation. A developer still needs to review the result, test edge cases, and make sure the action is safe. But the work increasingly starts with a useful draft instead of an empty file.

The important outcome is not that every connection becomes effortless. It is that each connection only has to be defined once.

You should not need to rebuild it when you add a new workflow, launch another customer experience, or bring in a new AI agent next year.

Every connection can become an AI tool

The same architecture that makes an action reusable inside Gladly also makes it available to AI agents.

When an action is turned on, App Platform can expose it as a tool. An approved agent can discover what tools are available, understand the information each one requires, and call them when appropriate.

MCP, or Model Context Protocol, provides a standard way for AI systems to discover and use those tools.

This matters because an outside agent should not need its own direct integration with every system your company runs. It should not need one custom connection to Shopify, another to your loyalty platform, and another to your order management system.

Those connections already exist.

Instead, the agent can use the capabilities your team has made available through Gladly, subject to the permissions you control.

The work you do to connect your systems for your own team becomes useful to the AI agents you add later.

This works in the other direction too. Gladly can use tools exposed by other platforms. When another system makes a capability available through a standard interface, Gladly does not need a one-off bridge built specifically for it.

That is what an AI-native integration layer should do: make capabilities portable without making access uncontrolled.

Open does not mean unrestricted. Administrators still decide which connections exist, which actions are enabled, and which people, workflows, or agents are allowed to use them.

The unglamorous parts do matter

Making an API call is often the easiest part of an integration. Keeping the connection reliable is harder.

Different systems use different authentication methods. APIs change versions. Credentials expire. Requests fail. A response that worked yesterday may contain an unexpected field tomorrow.

When every interface owns its own integration, every team has to solve these problems independently.

App Platform handles that plumbing in one place.

It supports the authentication method each system requires, including OAuth, API keys, and systems that require no authentication. Versions are namespaced, so a breaking change does not silently change the behavior of an action already being used in live conversations.

Smaller updates can be introduced without forcing every caller to migrate at once. When a connection fails, the platform can identify and report the failure instead of letting it disappear inside a workflow or agent interaction.

These details are not the headline feature. But they are what make the architecture usable in production.

An AI agent that can call a tool in a demo is interesting. An AI agent that can call it reliably, with the right permissions, across thousands of customer conversations is a product.

The value compounds

A reusable connection saves work the first time a second caller needs it.

The larger payoff comes later.

When you connect a new system, its actions can become available to the people, workflows, and AI agents already using the platform. When you add a new AI agent, it can use the connections you have already built.

Each new connection makes the platform more capable. Each new caller makes the existing connections more valuable.

That is different from the old integration model, where every new interface created another maintenance burden. In the new model, the work accumulates instead of multiplying.

This is the architectural shift AI agents require.

Integrations can no longer be treated as hidden wiring between two fixed products. The number and type of callers will keep changing. Some will be people. Some will be workflows. Some will be agents we know about today, and others will come from companies that do not exist yet.

The stable part is the action itself.

Look up the order. Check the shipment. Issue the refund. Update the customer.

Define those capabilities once. Secure them once. Maintain them once.

Then let every approved experience build on them.