An AI agent that can only talk is a demo. An agent that can read a CRM record, file a ticket and update a spreadsheet on behalf of a real user is a product. The gap between the two is the integration layer, and in the past twelve months that layer has turned from a side project into one of the most contested pieces of the agent stack. Large platforms are buying it, investors are funding it and infrastructure vendors are wrapping it in gateways. If you are deciding whether to build your agent integrations in-house or buy them, the ground has shifted under that decision.
This post covers what changed, what the long tail of integrations really costs, and a scorecard you can use to make the call.
The signal: Workday buys an integration platform for agents
On November 19, 2025, Workday announced a definitive agreement to acquire Pipedream, which it described as an integration platform for AI agents. The release cited more than 3,000 prebuilt connectors, more than 10,000 prebuilt tools and more than 5,000 customers. Terms were not disclosed, and SiliconANGLE reported that Pipedream had raised $22.4 million since its founding in 2019. Workday's fiscal 2026 annual report lists Pipedream alongside Flowise, Paradox and Sana as acquisitions made during that fiscal year.
The stated rationale is the interesting part. Workday's pitch was that agents need to move from insight to action, and that action happens in the thousands of applications outside Workday's own HR and finance data. Constellation Research framed it bluntly: to deliver on its agent vision, Workday needed connectors and more agents, and Pipedream supplies the connectors. The same coverage notes the deal sits next to Workday's much larger purchase of Sana.
Read that as a pricing signal from a buyer with deep pockets. A company of Workday's size could have staffed an integrations team. It chose to buy a platform that had already absorbed years of OAuth quirks, API changes and connector maintenance. That is the build versus buy question answered at enterprise scale.
The rest of the category is moving too
Workday is not alone. Several adjacent moves point the same way.
Agent integration platforms are raising real money
Composio raised a $25 million Series A led by Lightspeed in July 2025, pitching managed authentication and connections to more than 3,000 applications for agent builders. In June 2026, Arcade.dev announced a $60 million Series A led by SYN Ventures, positioning itself as a secure action layer that handles authorization and governance for agents acting in business systems.
Unified API vendors are adding agent products
Merge, known for its unified APIs across categories like HRIS and CRM, launched Agent Handler, a separate product that gives agents access to third-party tools through MCP servers. Its launch post leans on per-user credential isolation, searchable logs for every tool call and a gateway that scans tool arguments and responses for sensitive data. That is a telling feature list. The hard part is no longer the HTTP call. It is identity, audit and data control.
MCP gateways are becoming infrastructure
The Model Context Protocol gave agents a common way to discover and call tools, and infrastructure vendors have followed. Docker's MCP Gateway is open source and runs MCP servers in isolated containers, injecting credentials and logging tool activity. Kong offers an enterprise MCP gateway as part of its AI Gateway, with OAuth enforcement, routing and observability across MCP traffic.
Put together, the market is sorting into layers: gateways that govern traffic, platforms that own connectors and per-user auth, and suites that bundle both into a larger product. Whatever you build in-house will be compared, by your customers and your board, to what these vendors ship.
Why the long tail costs more than it looks
Building your first integration is easy. A good engineer can wire up an OAuth flow and a handful of API calls in days. The trouble is that integrations are not features you finish. They are dependencies you operate, and the cost scales with the number of providers times the number of end users.
OAuth app reviews
Many providers gate production access behind a review. Google, for example, requires apps that request restricted scopes to pass an annual security assessment from an assessor Google has approved. Every provider has its own version of this process, its own timelines and its own reviewers. Multiply that by twenty or fifty providers and you have a recurring compliance workload that no one planned for.
Token lifecycles
Access tokens expire, refresh tokens rotate and users revoke access without telling you. Google's OAuth documentation lists several ways a refresh token stops working, including six months without use, a user changing their password when Gmail scopes are involved, and admin restrictions. It also caps live refresh tokens at 100 per Google account per OAuth client, and apps still in "Testing" status get refresh tokens that expire in seven days. Each provider has its own list. Your agent has to detect these failures, avoid retry storms and prompt the right user to reconnect at the right time.
Rate limits
Agents are chatty. A single user request can fan out into dozens of API calls. HubSpot limits publicly distributed OAuth apps to 110 requests every 10 seconds for each installing account. Limits like this vary by provider, by plan and sometimes by endpoint, and you need per-account throttling, backoff and queueing to stay inside them.
API changes
Providers change the rules, sometimes sharply. In May 2025, Slack cut the rate limit on conversations.history and conversations.replies to one request per minute, with at most 15 objects per request, for new installs of commercially distributed apps outside the Slack Marketplace. A product built on reading channel history at volume had to rethink its design or go through Marketplace review. Every integration you own exposes you to changes like this.
On-call
When an upstream provider has an incident, your agent looks broken. Someone on your team has to tell a provider outage apart from an expired token, a revoked scope or a schema change, often at 2 a.m. and often for a provider nobody on the team knows well. This is the cost that never appears in the original estimate.
A worked cost estimate
The numbers below are illustrative estimates, not benchmarks. Change the assumptions to match your team; the structure matters more than the totals.
Assumptions
- You need 25 third-party integrations for your agent product.
- Fully loaded engineering cost is $200,000 per engineer per year (an assumption, adjust for your market).
- An engineer works about 46 productive weeks a year.
- Building one production-grade integration (OAuth, token storage and refresh, a useful set of tools, tests, error handling) takes 2 engineer-weeks.
- Keeping one integration healthy (API changes, token and scope issues, provider reviews, support tickets) takes 0.5 engineer-days per month.
- Shared infrastructure and security work (encrypted token store, key management, audit logging, a share of security reviews) costs $30,000 a year.
- You have 2,000 external end users connecting accounts.
Build in-house (estimate)
| Line item | Calculation | Year 1 | Year 2 |
|---|---|---|---|
| Initial build | 25 × 2 weeks = 50 weeks ≈ 1.09 engineers | $217,000 | $0 |
| Maintenance | 25 × 0.5 days × 12 = 150 days ≈ 0.65 engineers | $130,000 | $130,000 |
| Infrastructure and security | Assumed flat | $30,000 | $30,000 |
| Total | $377,000 | $160,000 |
Buy a platform priced per end user (estimate)
Take Hoook's Connect plan as a worked example of per-user pricing: $99 a month with 100 external users included, then $2 per additional user.
| Line item | Calculation | Year 1 | Year 2 |
|---|---|---|---|
| Platform fee | ($99 + 1,900 × $2) × 12 = $3,899 × 12 | $46,788 | $46,788 |
| Your own integration work | Assume 0.25 engineers for tool design, prompts and product glue | $50,000 | $50,000 |
| Total | $96,788 | $96,788 |
Under these assumptions, buying costs roughly a quarter of building in the first year and about 60 percent of building in the second. Two things move the result most. First, the number of integrations: at five integrations the build case gets much closer. Second, the number of end users: per-user pricing grows with your customer base, so at tens of thousands of connected users you should model the platform fee carefully and ask about volume terms. Also note what the build column leaves out: the opportunity cost of a full engineer not working on your core product.
The evaluation scorecard
Use this table to compare vendors, and to compare any vendor against your own build. Weight each criterion for your product, score options from 1 to 5, and multiply.
| Criterion | What to check | Why it matters | Suggested weight |
|---|---|---|---|
| Coverage | Do they support the apps your customers use, with the actions and triggers you need, not just a logo? | A connector with three read-only actions is not coverage | High |
| Per-user auth | Hosted connect flow for end users, encrypted token storage, automatic refresh, reconnect handling | This is the bulk of the long-tail cost | High |
| MCP support | Hosted MCP servers, per-user scoping, works with the clients you target | MCP is how most agent frameworks now discover tools | High |
| Proxy escape hatch | Can you call any endpoint of a provider with the managed credentials when no prebuilt tool exists? | Prebuilt tools never cover everything; without a proxy you are blocked | High |
| Observability | Logs for every tool call and underlying API request, filterable by user, exportable | You need this for debugging, support and audit | Medium to high |
| Data residency | Where tokens and payloads are stored and processed, and whether a region can be chosen | Enterprise buyers will ask, and some deals depend on it | Depends on market |
| Pricing model | Per end user versus per call or per task, overage rules, what counts as a user | Agents make unpredictable numbers of calls; per-user pricing is easier to forecast | Medium |
| Lock-in and portability | Can you bring your own OAuth apps? Can you export tokens or re-consent users? Is the tool format standard? | If the vendor is acquired or changes direction, you need a way out | High |
A few notes on using it well.
Test coverage with your real workflows. Pick your five most important user journeys and try to build them on each platform during the trial. Count how often you hit the proxy.
Ask about custom OAuth clients. Using your own OAuth app means users see your brand on the consent screen, and it makes migration far easier because the grants belong to your app.
Read the change of control story. The Workday deal is a reminder that your vendor may be bought, and an acquirer's roadmap may not match yours. Ask every vendor what portability you would have if the product changed hands, and get the answer in writing.
When building in-house still makes sense
Buying is not always right. Build when one or more of these is true:
- The integration is your product. If deep, bidirectional sync with one or two systems is your core value, you should own that code and the relationship with the provider.
- You need very few integrations and they are stable. Two or three well-documented APIs with long-lived credentials may not justify a platform fee.
- Your data cannot leave your environment. If contracts or regulation rule out a third party holding tokens, and no vendor offers a deployment model that fits, building is the honest answer.
- You work with private or on-premises systems. Platforms focus on public SaaS APIs. Internal systems usually need your own connectors anyway.
- Your unit economics break at scale. If you have hundreds of thousands of connected users with low revenue per user, per-user pricing may not fit. Run the numbers before you commit.
A hybrid is common and sensible: buy the long tail of SaaS connectors and per-user auth, and build the one or two integrations that define your product.
Where this leaves you
The consolidation around the integration layer tells you two things. The work is valuable enough that large platforms will pay to own it, and it is hard enough that they chose to buy rather than build. For most teams shipping agents, the question is less "can we build this" and more "is this where our engineers create the most value".
Score your options honestly, write down your assumptions and revisit them as your user count grows. If you want a reference point for the per-user model, Hoook is in beta and provides managed auth with a Connect Link, prebuilt tools and triggers across 3,000+ apps, hosted MCP servers with one URL per user, and an API proxy for everything else. Put it through the same scorecard as everyone else.