Integrations

A workload rarely runs alone. It gets triggered by someone or something, reads from document repositories, CRMs and databases, and reports back out into the world — a Slack channel, an email, your own application. In Jetty those connections are integrations, and under the hood every one is an environment variable: a named value injected into the sandbox at run time, which the agent reads exactly the way it would read a local .env.

Here are a few rules of thumb for what belongs where:

• Talking to a model? AI Gateway key
• Connecting to anything else? Integration key
• Changes each run? Input parameter

How an integration reaches a run

1. Set it once. Add the variable in Settings → Integrations (/settings/integrations) — a name and a value, like SLACK_WEBHOOK_URL or DATABASE_URL.
2. Every run gets it. The variable is injected into the sandbox environment of every run in the collection. Nothing to redeclare per runbook or per run.
3. The runbook names it. The steps say what to do and which variable to use — “post the summary to the channel behind SLACK_WEBHOOK_URL” — and the agent picks it up from the environment like any CLI tool would.

Secrets are never written to logs. Injected variables are available to the run but kept out of run output and logs. An agent can confirm what's present with the check-secrets tool without revealing any values.

What lives in an integration

Anything that isn't a model-provider key: the credentials for the tools your agent calls, service URLs, standing configuration.

One current limit: there is no OAuth flow — an integration is a long-lived credential, so use tokens, webhooks and connection strings. Rotating one is a single edit: update the value, and the next run picks it up.

Integrations among the other knobs

Four kinds of configuration reach a run, and they differ by where they're set and how long they stand: