What are data connectors for AI agents?

Summary slides

Why AI agents need dedicated data connectors rather than direct, one-off integrations

An agent that needs to interact with several different external systems, a customer database, a support ticketing system, an internal knowledge base, could in principle have custom, bespoke integration code written specifically, individually for each one, but this one-off, ad hoc approach doesn’t scale particularly well as the actual number of systems an agent needs to work with steadily grows over time, since each new integration requires its separate, distinct authentication handling, its separate, distinct error handling, and its separate, distinct translation logic between that system’s particular data format and whatever format the agent’s reasoning expects to work with reliably.

Dedicated data connectors exist specifically to solve this scaling problem, providing a consistent, standardized interface that abstracts away each system’s particular quirks behind a common, predictable pattern an agent can rely on regardless of which underlying system a connector happens to be talking to at that moment. This standardization is exactly, precisely what lets a team add support for a new external system incrementally, building just one new connector following an already-established, well-proven pattern, rather than needing to rebuild an agent’s entire integration approach entirely from scratch every single time a new system needs to be supported going forward.

What a data connector consists of technically

A complete, well-built data connector typically bundles together several distinct technical components, authentication handling that manages how the connector proves its identity to the external system it’s connecting to, a set of defined operations, named actions the connector supports, fetching a customer record, creating a support ticket, that map directly onto whatever API calls the underlying system requires to carry out that operation, and a schema translation layer that converts the external system’s native data format into a consistent, predictable shape an agent’s reasoning can work with reliably across different systems.

This bundling matters because it lets a connector present a stable, consistent interface to an agent even as the underlying external system’s actual API potentially changes or evolves considerably over time, since a well-built connector absorbs that external volatility entirely internally, within its translation and handling logic, rather than exposing an agent’s reasoning directly to an external API’s raw quirks and considerable inconsistencies that would otherwise force an agent to somehow understand and correctly, reliably navigate every different external system’s particular idiosyncratic behavior directly on its own, without any help.

How authentication and authorization work specifically for agent-facing connectors

A connector needs its actual credentials to access whatever external system it’s connecting to, and carefully managing these credentials safely and correctly, without ever exposing them directly to an agent’s reasoning process or to whatever broader prompt context an agent might otherwise be working within, is an essential security requirement distinct from the ordinary tool-calling permissions already covered in the broader discussion of AI agent permissions, since a connector’s actual credentials typically need to remain entirely, completely invisible to the agent itself, handled instead directly by the connector’s underlying infrastructure on the agent’s behalf rather than ever being passed through or exposed within the agent’s context.

Building this safely means a connector’s actual credential management happens at a distinct layer below what an agent itself can ever directly observe or influence, the agent requests a particular operation, fetch this customer’s record, and the connector itself handles authenticating to the underlying system and executing that request, returning only the relevant result back to the agent without ever exposing the underlying authentication mechanism or the actual credentials involved in that entire process at any single point along the way whatsoever. A connector architecture that fails to maintain this separation, letting credentials leak into an agent’s visible context or reasoning process in any way, creates a serious security exposure the broader discussion of prompt injection specifically, explicitly warns against, since credentials visible within an agent’s context become a target for exactly the kind of manipulation that discussion covers in considerable depth.

How read connectors differ from write connectors and why that distinction matters for safety

A connector that only ever retrieves information, reading a customer record, searching a knowledge base carries considerably different risk than a connector that modifies external state, creating a support ticket, updating a customer’s billing information, and treating these two different categories with the exact same level of scrutiny and the exact same approval requirements misses an important distinction, since a mistaken read operation typically produces, at worst, an unhelpful or incorrect response, while a mistaken write operation can produce and sometimes irreversible consequences within the actual external system it’s connected to.

This particular distinction directly extends the tool calling security principles already covered in the broader discussion of tool calling security specifically to this particular connector layer, suggesting that write-capable connectors deserve considerably more careful, deliberate design, more explicit confirmation steps for consequential operations, and considerably more conservative default permissions than read-only connectors typically require in practice. A team building connector infrastructure should specifically, deliberately classify each connector’s individual operations along this read-versus-write distinction, rather than treating an entire connector as uniformly safe or uniformly risky, when it might bundle together operations that span both categories with meaningfully, considerably different risk profiles worth distinguishing carefully.

How schema mapping and normalization let an agent work across different systems

Different external systems represent conceptually similar information in meaningfully, considerably different actual formats, one CRM’s concept of a customer record looks structurally quite considerably different from another CRM’s equivalent concept, even though both are, at a fundamental level, representing largely the same underlying kind of information, and a connector’s schema mapping layer exists specifically to translate each system’s particular native representation into a consistent, normalized shape an agent’s reasoning can work with reliably regardless of which underlying system that particular information originally came from in the first place.

Building this normalization well means a team maintaining connector infrastructure has to make deliberate design decisions about what that shared, normalized schema should look like in practice, since a normalization scheme that’s too rigidly, overly narrow loses meaningful detail specific to a particular system, while one that’s too loosely, overly permissive fails to provide the consistency an agent needs to reliably reason across several different systems in the first place entirely. A team should specifically, deliberately design this normalized schema around what an agent’s actual reasoning needs to work with effectively and reliably, rather than simply, passively adopting whatever raw format happens to be most convenient for any one particular underlying system to naturally, casually provide by default.

How standardized connector protocols are changing how agents integrate with external systems

Rather than every single team building entirely bespoke, custom connector infrastructure entirely from scratch, the broader field has begun converging on shared, standardized protocols specifically for how an agent should discover, authenticate to, and invoke external data connectors reliably, extending the same kind of standardization benefit the OpenTelemetry semantic conventions covered in the discussion of LLM tracing provide for observability specifically into the distinct domain of agent-to-external-system integration overall.

Adopting these emerging shared standards matters considerably for the same interoperability reasons already covered in that broader tracing discussion, a connector built against a standardized protocol can potentially work across several different agent frameworks without requiring bespoke, framework-integration work for each one individually, and a team can draw on an entire, growing ecosystem of already-built, shared connectors rather than needing to build every single integration entirely from scratch on its own each time. A team building new connector infrastructure today should specifically, carefully evaluate whether an existing, established standard already covers its particular integration need before investing in an entirely bespoke, proprietary approach that would leave it isolated from this broader, actively growing shared ecosystem overall.

How connector versioning and maintenance work as underlying systems evolve

The external systems a connector integrates with rarely stay entirely fixed, an underlying API changes its request format, deprecates a field a connector’s translation logic previously depended on, and a connector that doesn’t account for this ongoing external evolution will eventually, quietly break, sometimes in ways that produce a clear, visible error and sometimes in more subtle, considerably harder-to-notice ways where a connector continues technically functioning while silently returning degraded or inaccurate results.

Building reliable connector maintenance means treating each connector as its piece of infrastructure that needs ongoing, deliberate monitoring and periodic revalidation against its underlying external system, the same discipline the broader discussion of production AI monitoring covers more generally, extended specifically to this connector layer, and specifically versioning connectors explicitly so that a breaking change to a connector’s interface doesn’t silently, unexpectedly break every agent that happens to already depend on that connector’s previous, established behavior. A team that treats connectors as a one-time integration effort rather than ongoing infrastructure eventually accumulates connectors that have quietly drifted out of sync with their actual underlying systems, a risk considerably harder to detect than an outright, clearly visible connector failure.

How connectors handle errors and partial failures specific to external system quirks

Every external system a connector integrates with has its particular failure modes, a rate limit that returns a particular error code, a transient outage that resolves itself after a brief, short delay, a request that partially succeeds while leaving some other part of that same operation incomplete, and a well-built connector has to translate each of these system-failure patterns into a consistent, predictable error representation an agent’s reasoning can understand and correctly, appropriately respond to, rather than exposing an agent directly to each external system’s raw, considerably inconsistent error format.

This error translation directly connects to the error-handling and recovery logic covered in the broader discussion of agent tracing, since a connector that clearly, distinctly signals the difference between a transient failure worth automatically retrying and a permanent failure requiring a different approach entirely gives an agent’s recovery logic considerably better, more reliable information to work with than a connector that simply reports every single failure identically, as one single, undifferentiated error regardless of its actual underlying cause.

How connector security boundaries limit blast radius

A well-designed connector architecture deliberately limits what a single, individual connector can do, scoping its credentials and its permitted operations as narrowly as the underlying use case requires, rather than granting a connector broad, sweeping access to an entire external system simply because that broader access happens to be more convenient to initially set up. This deliberate narrowing directly limits the blast radius of a connector being misused, whether through a security compromise or simply through an agent’s reasoning error, since a connector scoped narrowly to only the operations it needs can only cause harm within that same narrow, deliberately bounded scope, regardless of what an agent’s reasoning might otherwise, mistakenly attempt to do with it.

This principle directly extends the least-privilege thinking covered in the broader discussion of AI agent permissions specifically to the connector layer, treating each individual connector as its distinct, deliberately scoped unit of access rather than granting an agent one single, broad, undifferentiated credential that happens to cover every single system it might ever conceivably need to touch. A team building connector infrastructure should specifically resist the convenience of granting broader access than a particular use case requires, since that convenience directly trades away the meaningful security benefit deliberate scoping was built to provide in the first place.

How rate limiting and quota management work at the connector level

Beyond the model-level rate limits covered in the broader discussion of token monitoring, each individual external system a connector integrates with typically imposes its separate, distinct rate limits and its separate usage quotas, and a connector needs to specifically respect these external constraints, tracking its actual usage against each external system’s particular limits and gracefully handling the case where a limit gets reached, rather than simply forwarding every single agent request directly through to an external system without any deliberate awareness of that system’s actual capacity constraints.

Building this connector-level rate awareness well means treating each connector’s external rate limits as their dedicated, distinct operational concern, tracked and monitored separately from a system’s broader model-related cost and token metrics, following the same kind of dedicated, separate tracking the broader discussion of real-time data for AI specifically recommends for real-time data source cost and rate limits more generally. A connector that ignores these external constraints risks triggering a service disruption from the external system itself, an outcome considerably worse and considerably more disruptive than simply queueing or gracefully declining a request that would have otherwise exceeded that external system’s actual capacity.

How to test a connector before exposing it to a live agent

Before a new connector gets exposed to a live, production agent, it deserves the same kind of deliberate, careful validation the broader discussion of data ingestion for RAG recommends for a new ingestion pipeline, testing each individual operation against a realistic range of inputs, including deliberately malformed or unexpected ones, to confirm the connector behaves correctly and fails gracefully rather than in some unpredictable unsafe way an agent’s reasoning might not be prepared to correctly handle.

This testing should specifically include deliberately exercising a connector’s error paths, not just its successful, happy-path operations, confirming that a simulated rate-limit response, a simulated authentication failure, and a simulated partial failure each get translated correctly into the kind of clear, distinguishable error signal covered earlier in this discussion, since a connector that only ever gets tested against its successful, happy-path behavior can still fail in unpredictable, poorly understood ways once it encounters a failure condition in live production use that its testing never specifically covered.

How connector catalogs and discovery help an agent choose the right connector

As an organization’s connector infrastructure grows to cover many different external systems, an agent needs some reliable way to discover which connectors are available and what operations each one supports, a capability typically provided through some form of connector catalog, a structured, machine-readable registry an agent’s reasoning can consult to understand what concrete tools it has available for a particular task, extending the tool-selection reasoning covered in the broader discussion of agent tracing specifically to this broader, growing connector ecosystem.

Building this discovery capability well means maintaining clear, accurate, and consistently up-to-date descriptions of each connector’s actual capabilities within that catalog, since an agent’s ability to select the correct connector for a task depends entirely on how accurately that catalog represents what each connector does, and a catalog containing stale, outdated, or inaccurate connector descriptions will directly lead an agent’s reasoning toward poor, mistaken connector choices regardless of how technically well-built the underlying connectors themselves happen to be.

How connectors relate to tool calling and agent permissions more broadly

A data connector is, in a structural sense, simply one particular kind of tool an agent can call, and everything covered in the broader discussion of tool calling security, the discussion of AI agent permissions, and the discussion of agent security more generally applies directly to connectors as well, treating a connector’s operations as tool calls that need the exact same careful scoping, the exact same explicit confirmation for consequential actions, and the exact same deliberate monitoring that any other powerful tool an agent might otherwise be given access to requires.

Understanding this direct relationship matters because it means a team shouldn’t treat connector security as some kind of separate, distinct concern requiring an entirely different security framework from the one it already applies to its broader tool-calling infrastructure, connectors are tools, specifically ones that happen to bridge an agent’s reasoning out into external systems carrying consequential state, and the same broader security discipline that already governs an agent’s tool use in general applies with, if anything, even more urgency to the connectors that reach into an organization’s live production systems.

How connector design affects agent observability and tracing

Each individual connector call an agent makes deserves the exact same detailed tracing the broader discussion of agent tracing recommends for ordinary tool calls, capturing the operation invoked, its parameters, and its result, since a connector call failure or a connector call producing a surprising, unexpected result is exactly the kind of event a team needs full, detailed visibility into when diagnosing why a particular agent trajectory didn’t behave the way it was originally expected to.

This tracing requirement extends specifically to capturing which particular connector and which particular operation got invoked, distinct from the broader, more generic tool-call tracing covered in that discussion, since a system with many different connectors available needs this additional granularity to distinguish a failure originating in one particular connector’s integration from a failure originating in a different one, precisely the kind of granular diagnostic detail a team needs to pinpoint where within a complex, multi-connector system a problem originated.

How connectors should handle sensitive data flowing through them

A connector that reads from or writes to a system containing sensitive information, customer personal data, financial records, health information, needs to specifically account for that sensitivity throughout its entire processing pipeline, not just at the point of authentication, since data flowing through a connector can potentially end up captured in logs, traces, or error messages if a connector’s implementation doesn’t specifically, deliberately guard against that exposure, directly extending the same privacy discipline the broader discussion of agent observability recommends for trace data specifically into this connector layer as well.

Building this protection well means a connector should specifically identify which of its fields carry sensitive content and apply appropriate redaction or masking before that content ever reaches a log, a trace, or any other observability surface a team might otherwise review, rather than assuming sensitivity handling is somehow a concern belonging entirely to the underlying external system or to the broader application, and never the connector’s responsibility. A team building connectors for systems that handle sensitive data should treat this redaction logic as a mandatory, non-optional part of the connector’s core design, not an optional enhancement to be added later only if someone happens to specifically remember it.

How connectors should be governed and owned within an organization

As an organization’s connector ecosystem grows to cover many different external systems, each individual connector needs a clear owner, a team or individual responsible for that connector’s ongoing maintenance, its security posture, and its response when that connector’s underlying external system changes or when a security concern gets raised about it, extending the same cross-team ownership principle the broader discussion of LLM observability recommends specifically to this connector infrastructure.

Building this ownership deliberately means maintaining a clear, accurate, and up-to-date record of who owns each connector, rather than letting connector ownership become ambiguous or effectively orphaned once whichever original team happened to build a connector moves on to other work or the individual who originally built it leaves the organization entirely. A team without this clear, deliberate ownership structure risks accumulating a growing set of connectors nobody specifically maintains anymore, quietly drifting toward the kind of unmonitored, unmaintained state the broader discussion of connector maintenance specifically warns against, precisely because no one holds clear responsibility for noticing and correctly addressing that quiet, gradual drift before it eventually becomes a problem.

How connectors should handle bidirectional consistency and confirmation

A write connector that reports success back to an agent but where the underlying external system failed to fully apply that write, due to a downstream validation failure, a partial system outage, or some other asynchronous processing delay, creates a dangerous gap between what an agent believes happened and what happened in the external system, a gap that can lead an agent’s subsequent reasoning to confidently proceed based on a state that never truly existed. Building reliable write connectors means specifically confirming that a write operation fully completed as intended before reporting success back to the agent, rather than simply reporting success the moment a request was accepted for processing without any confirmation that processing completed correctly.

This confirmation requirement matters most for consequential write operations, placing an order, updating a financial record, where the cost of an agent confidently, incorrectly believing an operation succeeded when it didn’t can be serious, and considerably less critical for lower-stakes operations where eventual consistency and a somewhat more relaxed confirmation approach remains perfectly acceptable. A team building write connectors should specifically calibrate how rigorously they confirm success against the consequence of an agent proceeding incorrectly on a false confirmation, applying the same kind of deliberate, use-case-calibration the broader discussion of real-time data for AI recommends for freshness requirements more generally.

How connector design should anticipate an agent making unexpected or unusual calls

An agent’s reasoning, however well-designed, will occasionally construct a call to a connector that’s technically valid but unusual, requesting an unusually large volume of data in a single call, invoking an operation in an unexpected sequence relative to how a human developer might have originally anticipated that connector being used, and a robust connector needs to handle these edge cases gracefully rather than assuming an agent will always call it in exactly the narrow way its original developer happened to originally imagine.

Building this robustness well means specifically testing a connector against unusual, edge-case call patterns during the validation process covered earlier in this discussion, not just the more conventional, expected usage patterns a connector’s original design was primarily built around, and building explicit, sensible limits, a maximum result size, a reasonable timeout, directly into the connector itself rather than assuming an agent’s reasoning will always naturally, spontaneously request something reasonable without that connector ever needing to enforce any limit of its own. A connector without these explicit, deliberate limits risks an agent inadvertently triggering an expensive or disruptive operation against the underlying external system simply because nothing in the connector itself was built to prevent that particular kind of unusual but technically valid request.

Common mistakes teams make around data connectors for AI agents

Several patterns recur often enough across teams building data connectors for AI agents that naming them directly, explicitly is worth doing before they lead to a costly security exposure or an unreliable, considerably fragile integration that could have been avoided entirely.

1. Building bespoke, one-off integration code for each new external system rather than adopting a consistent, standardized connector pattern that scales considerably better as integrations grow.

2. Exposing a connector’s actual credentials within an agent’s visible context or reasoning process rather than keeping that authentication handling entirely separate, below what the agent itself can ever directly observe.

3. Treating read and write connectors with entirely identical scrutiny and entirely identical approval requirements, missing the different risk each category carries.

4. Building a normalization schema either too narrow to preserve meaningful detail or too loosely permissive to provide consistency across different systems.

5. Building entirely bespoke, proprietary connector infrastructure without first evaluating whether an existing, established standard already covers the same particular integration need.

6. Treating a connector as a one-time integration effort rather than truly ongoing infrastructure requiring deliberate, periodic revalidation against its actively evolving underlying system.

7. Reporting every single connector failure entirely identically as one undifferentiated error, missing the distinction between transient failures worth retrying and permanent ones requiring a different approach entirely.

8. Granting a connector broad, sweeping access to an entire external system purely for convenience rather than deliberately, carefully scoping its credentials as narrowly as the actual use case requires.

9. Forwarding every single agent request directly through a connector without any awareness of the underlying external system’s actual rate limits and capacity constraints.

10. Testing a connector only against its successful, happy-path operations, never deliberately exercising its actual error paths before exposing it to a live production agent.

11. Maintaining a connector catalog with stale, outdated, or inaccurate capability descriptions, directly leading an agent’s reasoning toward poor, mistaken connector choices.

12. Treating connector security as a separate concern requiring an entirely different framework rather than applying the exact same tool-calling security discipline already governing broader agent tool use.

13. Tracing connector calls only as generic, undifferentiated tool calls, missing the granularity needed to distinguish a failure in one particular connector from one in a different one.

14. Letting a connector silently continue functioning while returning degraded or inaccurate results once its underlying external system has quietly changed.

15. Building connector infrastructure without any deliberate blast-radius thinking, letting a single compromised or misused connector potentially affect considerably more of an external system than the actual use case ever required.

16. Failing to specifically redact or mask sensitive fields before connector data reaches logs, traces, or any other observability surface a team might otherwise review.

17. Leaving connector ownership ambiguous or effectively orphaned once the original building team moves on, letting maintenance quietly drift unnoticed.

18. Reporting write success the moment a request was accepted for processing, without confirming the underlying operation fully completed as intended.

19. Building a connector without explicit, sensible limits on result size or call volume, leaving it exposed to an agent’s occasional unusual but technically valid request.

What connects all nineteen of these mistakes is a single underlying pattern: treating a data connector as a simple, mechanical translation layer rather than as a security-sensitive piece of infrastructure that deserves the exact same deliberate scoping, deliberate testing, and deliberate ongoing maintenance a team would apply to any other component that bridges an agent’s reasoning out into consequential external systems.

The deeper principle underneath all of this is that a data connector is precisely the point where an agent’s abstract reasoning meets concrete, external consequence, and the care a team puts into designing, scoping, testing, confirming, redacting, owning, and monitoring that boundary directly determines whether an agent’s broader capability translates into something safe and reliable in live production, or into a liability that only becomes visible once something has already gone wrong in a system the connector was never built carefully enough to protect in the first place.