Connectors

The idea

You ask "how much traffic did we get this week" and the agent answers, because the connection already exists and the agent is allowed to use it.

The alternative, which is what most people do today, is pasting an API key into a chat window. That key is now in a transcript, it is scoped to everything you can do, and nobody can revoke it without noticing it leaked.

Supported services

Normalized shapes

Every connector of the same kind returns the same shape. Two analytics providers fill the same normalized metrics object, so a query written against one works against the other.

Where a provider genuinely does not measure something, the field comes back null rather than zero. That distinction matters: a substituted zero is a wrong number that looks like a real one.

Reading a connector

From an agent session, or your own terminal:

fredrin connectors list
fredrin connectors metrics --provider posthog --days 7

The same surface is on the REST API under the project's connectors routes.

The important rule: read them through Fredrin, not around it. Do not have an agent mint its own provider key or query the service directly. The connection exists, it is scoped, and it is revocable in one place.

Metric triggers

Connectors are what make metric-triggered Automations possible. An Automation can watch a real number and open a ticket when it crosses a threshold, so a Worker is investigating an error-rate spike before you have finished reading the alert.

A threshold can carry a deadband so a metric oscillating around its line does not open forty tickets. Set one when the metric is noisy; there is none by default.

Credentials

Stored encrypted, scoped to the project or workspace that owns them, and never returned to the client. An agent gets query results, never the key.

Revoking a connector revokes it everywhere at once.

Next steps

• Automations - metric triggers.
• The CLI - reading connectors from a terminal.
• Privacy - what is stored and where.