Connectors behave like living systems in production. The moment you build them, you inherit their entire lifecycle. Keeping them healthy, adapting to changes, and responding to failures becomes ongoing work.
Over time, that work quietly pulls teams away from building their actual product and into maintaining integration infrastructure.
Why "Just Call the API" is Misleading When people think about building connectors, they picture a straightforward integration. Read the API docs, write some code, handle authentication, and parse the response. That mental model treats connectors like static infrastructure. Write once, deploy forever. That's not how they actually work.
This isn't just a problem for individual teams. It's an ecosystem-wide misunderstanding that's causing every AI company to rebuild the same fragile infrastructure.
Production changes everything.
Rate limits make connector behavior non-deterministic. An integration that works perfectly for one user can start failing as usage grows, especially when vendors enforce limits that change without notice.
Real customer environments add another layer of unpredictability. Custom fields, modified schemas, and unique integration patterns create edge cases that rarely appear in testing. As a result, connectors that look stable in development often fail the moment they meet real production data.
The mistake is thinking you are building a tool. You are creating a living system that requires continuous monitoring, adaptation, and care across its entire lifecycle.
The Organism Metaphor Connectors behave like organisms that grow, change, require feeding, break under load, and need continuous care.
They grow as the systems they connect to evolve. New features appear in source platforms, and customers expect your connector to support them. The scope expands naturally, even if you never planned to build more.
They change constantly. API versions deprecate, OAuth flows get updated, and data formats shift. If a connector does not adapt quickly, it stops working.
They require feeding. Authentication tokens expire and must be refreshed. Rate limits need constant management. And even when no new features are added, connectors consume engineering time just to remain functional.
They break under load. What works for one customer can fail for the next due to different permissions, schemas, or authentication setups.
They need care. Someone has to own each connector, respond when it breaks, and understand its quirks well enough to fix problems quickly.
Once you see connectors this way, the maintenance burden becomes obvious. You cannot build them once and move on. You can only care for them continuously, and the more connectors you create, the more care they collectively demand.
The 1-5-10 Progression With the first connector organism, teams are optimistic. They write it themselves because it's faster than evaluating tools. The integration works, they ship a feature, and everything feels under control.
At two connectors, the complexity starts to show. Maintenance takes time and begins pulling focus away from the core product. The systems involved change independently, which means something will inevitably break.
At five to seven connector organisms, priorities shift. A significant portion of engineering time goes to keeping integrations working instead of building features. Fixing one connector often overlaps with another failing. Engineers spend their days switching context between different APIs and vendor behaviors.
By ten connectors, the team is in crisis mode. They're not building new features anymore. Most effort goes into maintaining a growing network of fragile integrations. New hires need weeks just to understand how the connectors fit together. What was meant to be a product advantage starts to look like an integration business.
I've seen this progression play out across dozens of companies.
This is an Infrastructure Problem, Not a Feature Problem Every team building AI agents eventually hits the same wall: connectors. Not because they're bad engineers, but because connectors are fundamentally infrastructure.
Think about how this played out with databases. Every company needs databases, yet almost no one builds a database engine from scratch anymore. The complexity just isn't worth it. The infrastructure layer became standardized and shared across the industry.
In every infrastructure shift, there are three pillars: compute, storage, and networking. The breakthrough in data movement wasn't the technology itself. It was the infrastructure that made the technology dependable at scale.
Connector maintenance follows that same arc. The ability to call an API already exists. What is missing is the infrastructure that handles everything around that call. Authentication flows, rate limits, schema changes, edge cases, monitoring, and error handling all live outside the core product logic.
When every team solves these problems independently, it's pure waste. Infrastructure means shared care rather than individual responsibility. No single team should need to become an expert in Salesforce API versioning or Stripe webhook reliability when organizations can hire Salesforce experts to manage those complexities at scale.
What Breaks Over Time Authentication changes constantly. OAuth flows evolve, API keys rotate, and permissions shift. When those systems change, integrations break and must be updated to stay operational.
Rate limits don’t hurt until you scale. Everything works in development. Early customers are fine. Then usage grows, and connectors start failing in ways you didn’t anticipate. Vendors enforce limits differently, with different thresholds and reset windows. Some count requests, some data volume, and some unique users.
Schemas drift over time. APIs that once returned strings start returning arrays. Nullable fields become required. Timestamp formats change between versions. These shifts may not register as breaking changes from the vendor’s perspective, but they break connectors all the same.
Customer diversity amplifies edge cases. One configuration violates your assumptions. Another pushes unexpected volume. A third encounters a vendor-side change you didn’t plan for. Across multiple connectors, these issues compound quickly.
Every team is discovering the same failure patterns independently. That’s the clearest signal that infrastructure is missing.
What the Ecosystem Needs The solution isn't better documentation or cleaner APIs. What the ecosystem needs is shared maintenance infrastructure.
Connector libraries need to be maintained as open standards rather than proprietary silos. When a vendor changes their API, the fix gets implemented once and shared.
This is the vision we're building toward with agentic data infrastructure . Open, composable connectors that the entire ecosystem can rely on and improve together.
The ecosystem needs observability that shows exactly what's happening inside each connector. The kind of visibility you need to debug production issues quickly, audit every access and action, and ensure decisions remain explainable and traceable.
Most importantly, it means treating connectors as infrastructure rather than features. Your competitive advantage isn't in building and maintaining custom connectors. It's in what you build on top of reliable data access.
If you’re building AI agents, your value is in the intelligence of your agents, the quality of their reasoning, and the outcomes they produce. Engineering time is better spent on evals and reliability than on debugging OAuth flows or tuning rate-limit backoff logic.
The Path Forward Connectors are living organisms. They will always require care. Maintaining hundreds of connectors is much easier when we build and maintain them together.
Companies that invest in agentic data infrastructure with reliable connectors, entity resolution, real-time access , and governance baked in will be the ones shipping agents into production.
Everyone else will still be stuck maintaining brittle custom integrations and debugging schema mismatches.
Subscribe to Agent Blueprint to learn more about agentic data infrastructure.
