The Integration Tax: Why AI Agents Lose Context Mid-Task
Multi-step AI agents stall the moment they hit a service they can't read. WorkOS Pipes attacks the OAuth plumbing problem — here's what that means for small-team builders.
Multi-step AI agents fail for a predictable reason, and it has nothing to do with the model. They lose context the moment they hit a service boundary they can't cross — and that boundary is almost always OAuth.
WorkOS made this point plainly in a sponsored post on Daring Fireball: the context that actually matters isn't in your database — it's in the tools your users live in every day. Their product, WorkOS Pipes, is a direct attempt to remove that bottleneck. This is worth thinking through carefully, because the problem it describes is real regardless of who solves it.
🔍 Why Agents Lose Context Mid-Task
The problem isn't model quality. It's what the model can see.
Most AI demos are single-turn: ask a question, get an answer, done. Agentic workflows are different. They run for minutes or hours, moving data between systems and making decisions at each step. A realistic task — "summarise this week's open GitHub PRs, check which ones have Slack threads, and post a standup update" — needs:
- Read access to GitHub with a valid token at the moment of the call
- The ability to find matching Slack threads (a separate OAuth flow, a separate token lifecycle)
- Both tokens to still be valid by the time step 4 runs
- Credentials that survive if the agent resumes after a failure
Most small teams wire this up manually, provider by provider. That is weeks of work per integration, and then you own the token refresh logic, the credential rotation, and the edge cases every time an API changes its scope names.
Key takeaway: An agent that stalls at a missing OAuth token isn't a model failure — it's an infrastructure failure. The intelligence and the context have to arrive together.
🛠️ What WorkOS Pipes Does
WorkOS Pipes sits between your agent and the services it needs to read. The pitch is simple: pre-built connectors, managed token lifecycle, credential storage handled. You call the real provider API with a fresh token; Pipes deals with the OAuth dance.
The providers cited in their announcement include GitHub, Slack, Salesforce, and Google Drive — the four that appear in most enterprise and small-team agentic workflows.
| Without managed connectors | With WorkOS Pipes |
|---|---|
| Build OAuth flow per provider | Pre-built connectors |
| Handle token refresh yourself | Managed token lifecycle |
| Store credentials in your DB | Credential storage delegated |
| Debug provider-specific edge cases | Call real provider API with fresh token |
One architectural point worth noting: the claim is that you call the real provider API, not a proxy. This matters because some providers rate-limit proxied requests differently, and because you get the actual response format without a translation layer adding latency or stripping fields.
⚡ The Real Cost: OAuth Plumbing on a Small Team
Here is where the WorkOS framing lands most honestly: the time cost of OAuth plumbing is brutal relative to team size.
Consider a three-person team building an internal workflow agent — one that pulls contract status from Google Drive, cross-checks payment data from a spreadsheet, and sends a Slack alert when something goes overdue. Before writing a single line of agent logic, they have to:
- Register a Google Cloud app, configure the OAuth consent screen, go through verification
- Implement the authorisation code flow and store refresh tokens safely
- Set up a background job to rotate access tokens before they expire (Google's access tokens expire after 1 hour)
- Repeat the entire process for Slack, with different scope names and a different revocation endpoint
- Handle edge cases: token revoked mid-run, user re-authenticates, scope mismatch on an existing token
That is easily 2–4 weeks of engineering time for two integrations. For a student building a side project or a startup trying to ship, that is the project killer.
A managed integration layer doesn't make your agent smarter. It makes the time you spend on the agent go toward the intelligence rather than the plumbing.
💰 Alternatives Worth Considering
WorkOS doesn't publish per-call Pipes pricing in the announcement, so I can't compare numbers directly. But the decision space is real:
| Approach | Setup time | Maintenance | Cost |
|---|---|---|---|
| DIY OAuth per provider | High (weeks/provider) | High | Dev time only |
| WorkOS Pipes | Low | Low | Monthly SaaS fee |
| LangChain / LlamaIndex connectors | Medium | Medium | Free (open source) |
| Managed auth (Auth0, Clerk + custom) | Medium | Low–Medium | Monthly SaaS fee |
For a student or solo builder: LangChain and LlamaIndex both have community-maintained integrations for GitHub and Google Drive. They require more setup than a managed service, but they're free and well-documented. The token refresh logic is your problem, but it's tractable for one or two providers.
For a startup shipping to paying customers: managed credential storage is almost certainly worth paying for. One token storage breach or one midnight Slack alert about a revoked token hitting production will cost more in eng time than the monthly fee.
🌐 The Bigger Picture for Agent Builders
The WorkOS Pipes announcement points at something that will define the next few years of agent development: the race to commoditise the boring layer.
Context — the ability to see what is actually happening in the user's workflow — is the hard constraint on agentic usefulness. Not model capability. GPT-4 class models are already capable enough for most enterprise automation tasks. What is missing is the infrastructure to give the model real-world eyes at every step of a long-running task.
For builders thinking about agentic products: the integration tax is real, and it is an equaliser. Whether you are building in Colombo or California, the same OAuth plumbing has to get done. Managed layers like Pipes reduce that tax. The question is whether the specific providers you need are in the catalogue.
One gap worth noting for the Sri Lankan context: local services — bank APIs, government data endpoints, telco integrations — will not appear in any managed connector catalogue for years, if ever. That is actually an advantage for local builders. You already know which integrations matter for Sri Lankan workflows. The global tools solve the global providers; you solve the local ones.
What This Means for You
If you are building anything agentic right now, the practical takeaways:
- Plan for token lifecycle from step one. An access token obtained in step 1 may be expired by step 7, especially with Google's 1-hour expiry. Build refresh logic before you need it, not after a 2am production failure.
- Check your framework first. LangChain, LlamaIndex, and Semantic Kernel all have OAuth helpers for GitHub, Slack, and Google. Evaluate what's already included before paying for managed connectors.
- Delegate credential storage for production workloads. If your agent handles OAuth tokens for customer accounts, storing those in a plain DB table is a liability. Use a secrets manager or a specialist service.
- The key insight: the quality of an agentic product is mostly a function of data access, not model size. Invest in the integration layer accordingly.
If you're working with OAuth access tokens and want to inspect what's actually inside one — the claims, expiry time, and scopes your agent received — the JWT Decoder on this site decodes any JWT entirely in [your browser](https://induwara.lk/tools/image-upscaler) without sending the token anywhere.
The intelligence in your agent is only as useful as the context it can reach. That has always been true of software. What's changed is that agents run long enough, and broadly enough, that the gap between "what the model knows" and "what the model can see right now" has become the central engineering problem.