What is Peliqan and where does it sit? · Inklings

I came across Peliqan while thinking about a problem I keep running into: AI agents are only as useful as the context they can reach. Claude can reason well. But if the data it needs is spread across Salesforce, an ERP, a support desk, and a handful of spreadsheets — and each of those requires a separate API call — then the agent is constantly doing the slow, expensive work of assembling context before it can do any thinking. That's the gap Peliqan is trying to close.

The architecture has three layers, and understanding them in sequence is how the product clicks.

Cache layer Peliqan syncs data from 250+ sources — Salesforce, Exact Online, AFAS, HR systems, databases — into a built-in Postgres warehouse. This is not your live system. It's a read-only replica that updates on your schedule, with a default sync of around fifteen minutes. Your production systems stay untouched.

Transformation layer As data flows in, Peliqan normalises schema across sources, maintains relationships — which Salesforce deals connect to which Exact Online invoices — indexes unstructured documents like PDFs, attachments, and email threads, and prepares everything for both structured SQL queries and semantic search. The warehouse knows how things relate, not just what they contain.

Inference surface One MCP endpoint exposes all of it to Claude, or ChatGPT, or Cursor — whatever agent you're running. The AI doesn't call live APIs anymore. It queries the cache, and it asks semantic questions about documents. One surface. Audited. Fast.

The thing that landed for me is the latency point. A CFO's real question is never "what's in Salesforce." It's something like: which customers have overdue invoices, recent churn signals, and open support tickets? That question crosses three systems. With single-app MCP connectors — Zapier, Pipedream, one-off integrations — each API call is expensive and sequential. You're making Claude wait three times before it can even start reasoning. Peliqan caches everything together, so that question becomes a single SQL join on data that's already there.

For how I think about AI adoption at Travelopia, the implications are immediate. When a business user like Alex or Devika wants to understand customers who downgraded in Q2 with pending support tickets, they shouldn't be exporting CSVs from three different systems. They should be asking a question. Peliqan makes that question answerable without anyone touching production data. The audit trail means Tier 2 engineers can see exactly what the AI queried and what it returned. And Tier 3 productionisation — routing high-confidence AI actions back into Salesforce, say — has a clean, single point of contact.

What Peliqan doesn't claim to do is the probabilistic reasoning over historical patterns — spotting signals that haven't been explicitly named. That's where the agent layer comes in. Peliqan is infrastructure. It's not trying to be Claude. It's trying to be the thing Claude needs before it can be useful.

I'm still working out where the seam is. But the structural claim is clear: most AI-in-enterprise failures aren't reasoning failures. They're context failures. The model can't think clearly because it's spending all its time fetching. Peliqan is a bet that the fetch layer deserves its own product.

Mid-discovery. Not a recommendation yet. Just a clear picture of what it is.