Connect AI agents to enterprise data: 4 patterns

There is no single best way to connect an AI agent to enterprise data. The right architecture depends on the job: what the agent needs to know, how current the answer must be, which permissions apply, and whether the agent only reads information or can change a business system.

Four patterns cover most implementations:

1. retrieve indexed documents;
2. synchronize application data into a shared store;
3. query a database or warehouse live;
4. call governed APIs and tools.

Most production agents eventually use more than one. The useful decision is not which pattern wins in general. It is which pattern should carry each part of a defined business job.

Start with the job, not the connector catalog

“Connect Salesforce, Snowflake, and Slack” sounds concrete, but it does not describe what the agent must accomplish.

Compare two requests:

• Help a seller find the latest approved answer to a security questionnaire.
• Every morning, identify late-stage opportunities with no customer activity in 14 days and prepare a brief for the manager.

The first is primarily a document retrieval problem. The second needs live CRM records, agreed pipeline definitions, a scheduled workflow, and perhaps activity from another system. Giving both agents the same undifferentiated pool of data creates unnecessary access and makes failures harder to diagnose.

Define the job in one sentence. Name the user, intended decision, cadence, required freshness, permitted sources, and acceptable actions. Then choose the connection pattern.

Pattern 1: retrieve indexed documents

In a retrieval architecture, documents are collected, divided into searchable units, represented in an index, and retrieved when a question appears. The model receives selected passages rather than the entire document collection.

This pattern fits policies, product documentation, research, contracts, support playbooks, and other text-heavy sources. It is especially useful when the answer should quote or cite an approved document.

Its main limitation is that an index is a copy. The team needs to know when it was updated, which version of a document it contains, and what happened when a source was deleted or its access changed. Retrieval quality also depends on how documents are divided and described. A passage can be textually relevant while belonging to the wrong product version, region, or customer.

Use retrieval when:

• the source is mostly unstructured text;
• update lag is acceptable and visible;
• citations to passages matter;
• the agent does not need to perform relational analysis across many records.

Avoid treating retrieval as a universal enterprise-data layer. It is poor at questions that depend on precise aggregation, current transactional state, or a chain of permissions across systems.

Pattern 2: synchronize data into a shared store

In a synchronized architecture, selected data from business applications is copied into a warehouse, lakehouse, operational store, or agent-specific index. The agent queries the shared representation rather than every source separately.

This can simplify multi-source analysis. A revenue workflow might combine CRM opportunities, billing status, product activity, and support events in a curated model. The agent receives consistent field names and joins instead of learning each source API at runtime.

The cost is a second system of record for analytical purposes. Someone must operate ingestion, schema changes, identity mapping, deletion handling, and freshness monitoring. Source permissions do not automatically survive the copy; they must be deliberately preserved or reimplemented.

Use synchronization when:

• the question regularly combines several systems;
• a shared analytical model already exists;
• minute-by-minute freshness is not required;
• the team can operate pipelines and access rules for the copy.

This pattern is often the best place for business definitions. The shared model can encode how the company calculates qualified pipeline, active use, or renewal cohorts. That does not eliminate disagreement, but it gives the agent an explicit meaning to use.

Pattern 3: query a database or warehouse live

Live analytical access lets an agent generate or select a query against a database, warehouse, or semantic query service. The answer can reflect current data without waiting for another indexing cycle.

This is attractive for operational metrics and record-level investigation. It also introduces sharp edges. A syntactically valid query can use the wrong table, join, time period, or business definition. An expensive query can consume significant resources. A broad credential can expose records the user should never see.

The safe architecture is more constrained than “let the model write SQL.” It includes:

• an approved set of schemas, views, or semantic models;
• read-only access for analytical jobs;
• query validation, timeouts, row limits, and cost controls;
• user- or tenant-aware filtering where necessary;
• metadata that explains tables, fields, relationships, and metrics;
• logs that connect the question to the generated query and result.

Use live queries when:

• freshness materially affects the decision;
• the job needs aggregation or drill-down across structured records;
• the data platform can enforce narrow access and resource controls;
• the team can test semantic correctness, not only query execution.

The data connection alone cannot tell an agent what “revenue” means in your company. That is why sources and definitions both matter.

Pattern 4: call governed APIs and tools

A tool exposes a bounded business capability: search approved tickets, retrieve an account, create a draft, update an allowed field, or request an action. The agent chooses a tool and supplies structured parameters; deterministic code enforces authorization and executes the request.

This pattern is the clearest route from answers to action because it can separate what the model proposes from what the application permits. It also keeps business rules near the system responsible for them.

The Model Context Protocol authorization specification defines an OAuth-based authorization flow for HTTP transports and requires resource-bound token handling in supported implementations. MCP can standardize how an agent discovers and calls tools, but a protocol does not choose your permissions, validate your business rules, or decide which actions need human approval.

Use governed tools when:

• the agent needs a bounded operation rather than raw data access;
• existing APIs already enforce important rules;
• the action should have typed inputs and predictable outputs;
• authorization and audit need to be enforced outside the model.

The operating burden moves into tool design. Schemas must stay compatible, errors must be interpretable, retries must be controlled, and sensitive actions need approval and idempotency safeguards.

Four patterns compared

The table is a starting point. A customer-health agent may retrieve account notes, query current usage from a warehouse, and call a read-only support API. Each connection should have a reason tied to the job.

A practical selection process

1. Inventory the evidence the job requires

List the minimum facts needed to produce a useful result. Separate documents, historical analysis, current records, and possible actions. Do not begin with every system the company could connect.

2. Assign an authority and freshness requirement

For each fact, identify the recognized source and acceptable delay. A policy may change monthly; inventory may change by the minute. “Live” adds operational cost, so reserve it for information whose age changes the decision.

3. Attach business meaning

Document the definitions, joins, exclusions, and comparison periods that materially affect the answer. A field description is not always enough. If two functions use different meanings, preserve the distinction instead of silently selecting one.

4. Choose the narrowest access path

A support-summary job may need read access to selected tickets, not administration rights in the support platform. A revenue brief may need a curated CRM view, not every object the service account can reach.

5. Keep authorization outside the model

The model can select a tool or propose a query. Deterministic application and source controls must decide whether that user and agent may perform it. The next article in this series examines AI-agent permissions and access control in detail.

6. Design the evidence trail

Record the source or tool, relevant version, query or parameters, permission decision, and returned evidence. The amount of detail exposed to an end user can vary, but the operator needs enough to investigate a disputed result.

7. Test failure, not only success

Remove a source. Change a field. Ask for a forbidden customer. Submit an ambiguous term. Force a timeout. A connection architecture is production-ready only when these cases produce a safe, understandable outcome.

An example: a weekly customer-risk brief

Imagine a hypothetical customer-success team wants a Monday brief of accounts that may need attention.

• Product documentation and support playbooks use document retrieval.
• Historical product activity and billing events are synchronized into an analytical model.
• Current renewal opportunities are read through a constrained CRM view or API.
• The agent can create a draft follow-up task through a governed tool, but a manager must approve assignment.

The architecture is mixed because the evidence is mixed. It remains understandable because each connection has a defined purpose.

Google Cloud describes a similar progression from static data exposure toward agentic workflows, noting that security, cost, and semantic accuracy must be designed into the architecture. Its implementation is platform-specific, but the underlying constraint applies broadly: connecting an LLM to a database is not a complete data system. See Building an Agentic Data Layer.

What to document before launch

For every agent job, keep a short connection register:

• source owner and business purpose;
• connection pattern;
• approved operations and data scope;
• identity and permission model;
• update cadence or freshness expectation;
• definitions the agent must use;
• evidence retained for review;
• failure owner and revocation procedure.

This turns “the agent has access” into something an operations, data, or security team can review.

Jovis gives teams a governed workspace for approved business connections and purpose-defined agents. Start with one recurring question, then connect only the evidence needed to pursue it. A smaller, legible architecture is easier to trust and improve than an agent with access to everything.