Connections

What a connection is for

Agents work from the material you gave them. A connection extends that to facts that change: whether an order shipped, whether an invoice is still open, whether Thursday at 3 is free. Without one, an agent tells the customer a person will check — which is the right answer, and never a guessed one.

Connections also carry work out: a Slack channel or an email address is where a digest or an alert is delivered once you’ve approved it.

How a credential is handled

• Credentials live in a table with no client-readable access path. Only the server-side service role can read them, and no API of ours ever returns a stored secret.
• A connection is verified with a real API call before it saves, and re-checked on every delivery — so a revoked token surfaces as a broken connection rather than as silence.
• When an agent needs a fact, the platform makes the provider call itself and strips anything credential-shaped out of the result before it reaches the model. The model sees the answer, never the key.
• Any URL you supply — a site to scan, a custom webhook — passes an egress guard that blocks private, loopback, link-local and cloud-metadata addresses, both when saved and on every send.

Lookups about other people

Some lookups are keyed on an identifier anyone could type — a customer’s email — and return that person’s records. Those are offered only when the conversation is with a signed-in member of your workspace on your own dashboard. On a public surface, like the chat widget on your site, they are not available at all. A surface that fails to identify itself gets the fewest tools, not the most.

Supported providers

See what each provider unlocks, and which agent uses it.