Your agent writes the integration for the system you actually use
An event trigger used to need a system we had written support for ourselves. That made the answer to "can it watch my applicant tracker" a question about our backlog rather than about your work.
The interview writes the integration during the conversation now. It authors a small bundle of Python: one function each to check, create and delete the subscription on your service, or a single polling function for services with no webhooks. The engine runs those in a sandbox and drives them through the same arm, pause and repair path everything else uses.
Every webhook-style trigger gets its own secret URL to paste into the service's settings page. The URL is the credential, so an unknown id, a wrong secret and a disabled trigger all return the same blank 404. Request verification and the registration handshake are declarations the engine executes itself, so no authored code sits on that unauthenticated route.
Credentials are granted rather than written into the code. A slot reads its connection from the environment it is handed, and publish refuses to arm a bundle whose connection is missing or revoked while you are still there to fix it, instead of failing on the first convergence pass minutes later.
If creating or deleting a subscription on your service fails, that trigger parks for repair rather than being retried. A failed create that half succeeded would otherwise become five duplicate subscriptions.
This entry describes what shipped on the day it shipped. For how the capability behaves now, read /docs/integrations.