A source is a database Evalyst reaches with a native driver: Postgres, MySQL, Snowflake, BigQuery. A connector is for everything else — the billing API, the internal service, the vendor with one undocumented endpoint and no client library.

You describe it in chat. The agent writes a small module against a fixed contract — test, discover_schema, fetch — and the platform decides whether it is any good by running it.

The sandbox is the acceptance test

Generated code is untrusted code, so it never runs on the host. It runs in a container with a read-only root filesystem, dropped capabilities, no privilege escalation, memory/CPU/process limits, a hard timeout, and no network access at all unless the connector declared it needs it.

A connector becomes active only if test() succeeds and discover_schema() returns fields. Anything else is registered as broken, with the error kept so it can be repaired.

Credentials never pass through the model

When a connector needs a key, the agent declares the field name — STRIPE_API_KEY — and nothing else. The connector is registered in a needs credentials state and cannot run. You enter the value in a form, it is encrypted at rest, and only then is the connector validated.

The agent never sees the value, and it never asks for one in chat. If it ever does, that is a bug worth reporting.

When an API changes under you

Connectors break — an endpoint moves, a field is renamed. A monitor re-runs test() and flips a connector to broken when it drifts. Repair hands the agent the code and the error and lets it rewrite, and the rewrite goes through the same sandbox gate as the original. Nothing gets reactivated because it looks fixed.

What lands where

Fetched rows land in Evalyst’s own store, not in your database — we hold read-only credentials to your database and are not in the business of writing to it.

From there they are a first-class table. A cross-source workflow names an extract per input, and an extract is either a query against an attached database or a connector’s last pull, so a single combine can join your Postgres, your MySQL and a vendor API at once. Pulls can be scheduled, and in append mode each one keeps history rather than replacing it — which is what turns an API that only tells you today’s balance into a series you can chart day over day.