Four Ways In and Out: How ThinnestAI Talks to the Rest of Your Stack

The question behind "does it integrate with X"

Nobody actually wants their agent to join a network of other agents. What they want is narrower and more boring: the agent should be able to look something up in a system they already run, and the things it learns should end up somewhere their team already looks.

That is four separate movements, and they are worth separating because each has its own failure mode. The agent reaching out. Us pushing to you. You pushing to us. And your own systems speaking to your customer on our rails.

1. The agent reaches out

Mid-conversation — on the website widget, WhatsApp, Telegram or a live phone call — the agent can call something instead of guessing.

• MCP servers. 21 pre-registered connections, with addresses read from the registry and grouped by what they do, plus a directory of 1,434 services generated from the official registry. Twenty of those addresses are hand-verified; the rest are listed as published. That distinction matters — "it is in the directory" and "we tested it" are different claims, and blurring them is how somebody finds out the hard way.
• Any MCP address you paste. If you run your own server, we do not need to have heard of it.
• Your own HTTP endpoints, through Actions. The agent calls a URL you own with arguments it worked out from the conversation.
• Shopify, in two lanes. A no-authentication Storefront connection for catalogue, cart and checkout — what the shop window already shows any visitor. An OAuth Admin connection for order status and tracking, which is about a specific person's order and needs the merchant's permission.
• Built-in web search, which runs provider-side and so is available only on models that offer it. Your own material is always searched first.

Credentials for third-party tools sign in through an OAuth popup, are sealed with AES-256-GCM, renew themselves, and are unreadable by the dashboard database role even with a hand-written query. Any URL you give us is validated and DNS-resolved before we fetch it, so an address that resolves inside our own network is refused rather than requested. Third-party tools are namespaced, so none of them can register under the name of a built-in and quietly take over knowledge retrieval.

And every tool arrives switched off, with a hard cap of eight per agent. These endpoints are reachable from a public chat by a stranger.

2. We push to you

Outbound webhooks, signed so your side can verify who sent them, delivered to any HTTPS endpoint you control. Five event types, chosen per endpoint:

• A lead — captured mid-conversation, with whatever details the customer gave.
• An escalation — the agent has decided a person is needed.
• A resolution — the conversation closed.
• A finished call — outcome, seconds, campaign.
• A finished campaign — the counters.

A webhook that fails five times in a row is switched off, and the notifications feed tells you it happened. An integration that fails silently is worse than one that fails loudly, because you keep making decisions on data that stopped arriving on Tuesday.

This lane is also how the agent reaches Sheets, Zoho and effectively any CRM through Zapier today. We would rather say that than list forty logos.

3. You push to us

The Events API takes a fact from your backend — an order was delivered, a payment failed, a trial expired — and that fact enrols the customer in a drip sequence. Your systems already know these things; this is how they become a conversation without anybody exporting a list.

Consent is re-checked at every send in a sequence, not just at enrolment, so an event firing on a customer who opted out last week does not produce a message.

4. Your systems speak to your customer

The transactional messaging API — a POST to /api/v1/messages — sends order confirmations and one-time codes from your own systems over WhatsApp. API keys, rate limits, and idempotency, so the retry your job queue does at 2am does not send the same confirmation twice.

It has been proven end to end against Meta rather than against a mock, which is a lower bar than it sounds and a bar a surprising number of integrations do not clear.

What we do not have, and why

There is no agent-to-agent protocol here. No agent card published at a well-known URL, no discovery network, no capability tags, and no way for another platform's agent to invoke yours or for yours to delegate to a specialist.

The reason is that the integration a business actually needs is with a system of record — a store, a CRM, an internal endpoint that knows an order number. Those speak HTTP and, increasingly, MCP. A protocol for agents to call each other solves a problem that arrives after that one, and shipping the second before the first would be a demo rather than a product.

Two more absences worth naming: there is no visual canvas wiring these together — integrations are configured in a settings screen — and there is no bring-your-own model key, because the models are curated and platform-managed.

Where a tenant's data stops being trusted

Everything a tenant adds — a crawled page, an uploaded PDF, a tool's own description — is fenced and labelled as data before it reaches the model, so text you ingest cannot issue instructions to your agent. That boundary is tested rather than asserted: eight live prompt-injection attacks run against the public endpoint as part of the test suite.

Get started

Point a webhook at a request-bin URL and enable the lead event first. It is the shortest path to seeing real data leave the platform in a shape you can build against, and it takes about two minutes.

Connect your first integration free →

No credit card required • Trial includes 25 voice minutes and 200 chat replies