When an engineering team builds a first AI agent that needs enterprise data, the fastest path to a working prototype is usually to write a dedicated connector for that agent. Pull the data you need from your CRM API, format it, inject it into the prompt. Two days of work, agent is running, stakeholders are happy. The hardcoded pipeline is born.
The problem is not visible at project launch. It accumulates. Six months later, the team has four AI agents running in production, each with its own bespoke data connector. The Salesforce connector for the first agent uses the v50 REST API. The one for the second agent uses SOQL directly. Neither has error handling for the field that was renamed in the Spring release. The person who wrote the first one has moved to another team.
This is not a hypothetical. It describes the pattern we saw repeatedly before building Strattum: teams that moved fast on first projects and then hit a wall of technical debt as AI agent deployments multiplied.
Pattern 1: Schema coupling accumulates silently
The most damaging property of hardcoded connectors is their implicit dependency on source schemas at the time they were written. The connector knows that the Salesforce opportunity object has a field called Amount and another called StageName. This knowledge is encoded directly in the connector code, not in a managed schema definition.
Enterprise data source schemas change continuously. Salesforce admins add custom fields, rename picklists, and restructure record types as part of normal operations. SAP configurations evolve as organizations upgrade ERP versions or activate new modules. When the schema changes, the hardcoded connector breaks. But because the break is often partial, the agent produces wrong answers rather than throwing an error. Wrong answers in production are harder to catch than errors.
The coupling is also multiplicative. If you have four agents with four connectors all touching the same Salesforce org, a single schema change in the org may require updates to all four connectors. The team does not always know which connectors reference the changed field until they check the output of each agent individually.
Pattern 2: Credential proliferation creates security exposure
Each hardcoded connector needs credentials to access its data source. In a world of four or more agents each with one or more connectors, you end up with credentials distributed across configuration files, environment variables, and secrets managers in ways that are difficult to inventory. When a credential needs to be rotated, because of a security policy review, a team member departure, or a detected exposure, the rotation requires finding and updating every place the credential is referenced.
The worse version of this is that credentials sometimes end up in places that are not managed secrets at all: in CI/CD pipeline configurations, in agent prompt templates, or in application code that was committed to a repository before the security review happened. We have seen this enough times to treat it as a predictable outcome of the "build it fast" approach, not an unusual mistake.
Centralizing credential management in a connector infrastructure layer solves this cleanly. The connector holds the credential. Agents request context through the connector. If the credential needs to rotate, it rotates in one place. Agents do not need to be updated or redeployed.
Pattern 3: Access policy drift creates compliance risk
In regulated environments, the set of data fields an AI agent is authorized to access should be explicitly defined and controlled. With hardcoded connectors, access policy is implicit: the agent can access whatever data the connector's credential permits. If the Salesforce connected app has read access to the entire customer object, every agent using that connector can access the entire customer object, whether or not the specific agent's use case requires all of it.
Over time, this means the effective access policy of your AI agent fleet grows to the union of all the permissions granted to all the credentials across all the connectors. The access surface expands with each new agent project and is never explicitly reviewed or narrowed. When a compliance team asks what data your AI agents can access, the honest answer is "it depends on which connectors were built with which credentials," which is not a satisfying answer for an access review.
The cost of that policy drift is not just compliance risk. It also means that auditing what any given agent did requires digging into the connector's credential grants and the access logs of the data source system directly, because the connector itself produced no structured access records.
The compound effect
These three patterns interact. Schema coupling creates maintenance work that reduces the team's bandwidth for other issues. Credential proliferation creates security work whenever rotations are needed. Access policy drift creates compliance remediation work when an audit arrives. Each of these costs is manageable in isolation. Together, they add up to the maintenance burden that makes teams reluctant to expand their AI agent deployments, even when the agents are delivering value.
The remedy is not to stop building AI agents. It is to build the connector infrastructure once, as a shared layer, rather than per project. The initial investment in a managed connector platform is higher than writing a one-off script. The ongoing cost of maintaining that platform is substantially lower than the ongoing cost of maintaining N independent connectors each with their own schema coupling, credential management, and access policy state.
Teams that have been through two or three generations of AI agent projects, and lived through the maintenance phase of each, generally see this clearly. The teams that are still in their first project often do not, because the costs have not materialized yet. Both positions are rational given the information available at the time. The only difference is foresight.
