Back to the blog

Solving API Integration Forever

AI becomes the ad hoc integrator of everything. Every API with an OpenAPI spec is already integrated.

· 4 min read

Integration is the tax on software composition. Every time you want two systems to talk to each other, someone has to build the connection. Write the adapter. Handle the edge cases. Maintain it forever.

The integration industry exists because this work is endless. Zapier, Workato, MuleSoft, thousands of others—all monetizing the friction between systems that should already work together.

What if integration itself became obsolete?

The integration grind

Consider what happens when you want to connect Stripe to your application. You read the API documentation. Learn the authentication scheme. Figure out the parameter formats. Handle the error codes. Test against the sandbox. Handle webhooks. Keep up with version changes.

That’s one API. Now multiply by every service you use.

The integration ecosystem is a response to this reality. Pre-built connectors. Low-code workflows. Managed syncs. Each approach tries to reduce the per-integration cost. None eliminates it.

Every API still requires someone to build the bridge. The work scales linearly with the number of services you connect.

A different model

What if there was no per-API integration work at all?

Our system indexes OpenAPI specs. Every operation from every API goes into a semantic search index. When an agent needs to accomplish something, it searches for relevant operations, learns their interfaces, and executes them.

No one built a “Stripe connector.” The spec exists, so Stripe operations are discoverable. Same for GitHub, Twilio, Salesforce, AWS—hundreds of services, each available the moment their OpenAPI spec is indexed.

This inverts the integration model. Instead of building bridges between specific systems, you build one bridge to the spec ecosystem. Everything documented becomes accessible.

AI as integrator

The agent does what integration engineers used to do: understand a capability need, find the right API, figure out how to call it, handle the response.

But unlike integration engineers, the agent doesn’t build persistent connectors. It discovers and uses capabilities on demand. The integration is ad hoc—created in the moment, discarded after use.

This sounds inefficient until you realize the alternative. Traditional integration requires someone to anticipate every connection you’ll need, build each one, and maintain all of them. Ad hoc integration handles whatever you need right now, with no upfront cost and no maintenance burden.

The first time you ask for something involving Stripe, the agent finds Stripe operations. The hundredth time, same process. There’s nothing to maintain because there’s nothing persisted. The capability is discovered fresh each time.

What this means for API providers

If you’re building an API, the bar for adoption just dropped. Publish a correct OpenAPI spec, and any AI agent can use your service. No SDK to build. No integration partnerships to negotiate. No marketplace listing to maintain.

The spec is the integration.

This reshapes competitive dynamics. Previously, APIs competed partly on ecosystem presence—who had connectors to what platforms, which marketplaces listed your service. Now the playing field levels. A new API with a good spec is as discoverable as an established one.

What this means for API consumers

If you’re consuming APIs, the integration tax disappears. You don’t evaluate services based on what connectors exist. You evaluate based on whether the service does what you need.

Need to send an SMS? The agent finds Twilio, Vonage, MessageBird—whatever’s indexed. Need to process a payment? Stripe, PayPal, Square, Adyen. The capability matters, not the plumbing.

Multi-service workflows that used to require custom code now emerge from natural language. “When a new customer signs up in Stripe, create them in HubSpot and send a welcome email via SendGrid.” The agent discovers each operation, learns the interfaces, orchestrates the flow.

No integration engineer required.

The compounding effect

This compounds. Every new OpenAPI spec indexed increases the surface area of what’s possible. Every improvement to discovery makes existing specs more accessible. Every enhancement to execution makes calls more reliable.

The investment is in infrastructure, not individual connections. The infrastructure improves once and benefits every API equally.

Traditional integration is the opposite. Investment in one connector doesn’t help other connectors. Improvements to the Stripe integration don’t make the GitHub integration better. Each connection is a separate cost center.

Integration as fossil

There’s a pattern in technology: infrastructure layers that once required manual work get absorbed into general-purpose systems. We don’t build custom network protocols anymore. We don’t write our own parsing libraries. The capabilities commoditized.

Integration is the next layer to commoditize. Not through better integration tools, but through systems that make integration unnecessary.

Every API with an OpenAPI spec is already integrated. The work has been done. The connections exist, waiting to be discovered.

API integration isn’t a problem to solve incrementally. It’s a problem that’s already been solved. The solution just hasn’t been distributed yet.