There are three ways to give an AI agent access to your business data. They differ in how much you build, how fresh the answers are, and whether the agent can do anything other than read.
The three approaches
- 1Direct API integration. The agent reaches each application through code you write, host and keep working. It is the most flexible and the most expensive: one integration to build and maintain per app, and it breaks whenever an API changes.
- 2ETL to a warehouse. Everything is synced into a warehouse and the agent queries a modelled copy. Good for history and for heavy analysis, but the answers are only as fresh as the last sync, and nothing can be written back to the source.
- 3MCP. One protocol, one server, live reads and writes, governed in one place. The agent gets a single endpoint that already knows what it is allowed to do and which credentials to use.
How they compare
- Work to set up – one integration per app, versus one pipeline per source, versus one endpoint
- Freshness – live, versus as fresh as the last sync, versus live
- Writes – possible but hand-built, versus none, versus scoped per user
- Governance – scattered across your code, versus warehouse permissions, versus one audit log
They are not mutually exclusive
The warehouse route and MCP solve different problems, and most teams end up with both. Use the warehouse for history, heavy joins and finance-grade numbers. Use MCP for live state and for anything the agent needs to act on. Because an MCP server can expose the warehouse as one of its systems, the agent can reach both through the same endpoint.
When a direct API integration is still right
If one application needs behaviour no generic tool exposes, write the integration. The mistake is doing it for the fifth application, by which point you are maintaining a connector platform as a side project.
What this looks like in Peliqan
Peliqan gives you both routes over one set of connectors: managed ELT into a warehouse, and an MCP server exposing the same 300+ sources live. Consequently credentials, scope and the audit log are shared rather than duplicated per route. The protocol itself is drawn out on our MCP architecture diagram.
Use this diagram wherever you like
The diagram is free to use, including commercially, as long as there is a visible link back to this page. Download the PNG for slides and documents, or the SVG if you want to edit the labels. No email required. You can browse the rest of the set in the Peliqan diagram library.
Ready to build this on your own data? Get started with Peliqan.
