all-agents docs
Integrations and code

Integrations and code

How a workflow reaches the systems you work in, and what the code it runs is allowed to touch.

Work lives inside other people's software. A workflow that cannot open your CRM, read your inbox or write a row into a spreadsheet is a description of the job rather than the job. This section covers how a workflow gets into those systems, how you hand it the credentials to do that, and what the code it runs is permitted to do once it has them.

There is no catalogue

Automation tools usually ship a list of supported apps, so "can it talk to X" really means "is X on the list this quarter". All-Agents has no such list. There is no connector directory, no marketplace, and no per-app code inside the product.

The integration gets written during your interview instead. You name the system, you connect it, and the assistant writes the small piece of code that talks to that system's own API. If a service has an API, or a website you can sign in to, a workflow can reach it. Nothing is unsupported, and nothing waits on our roadmap first.

That trade has a cost, and it is fair to know it before you rely on it. An integration written on the spot is only as good as what the assistant worked out about that API, and it is yours alone. Nobody else's workflow shares it, and nobody else's fix repairs it. When one breaks you get a repair conversation and a change you approve, not a vendor patch.

Three ways a workflow reaches a system

A real browser. Every workflow has one. You never connect it and you never declare it. During the interview the assistant drives it while you watch, and you can take over at any point. This is the path for systems with no usable API: an internal portal, an old admin panel, a supplier's site that only ever had a login page.

Code the assistant wrote. Once a workflow is codified, its repeatable parts are small Python functions that run in a fresh sandbox. Each one declares what it may reach before it runs, and that declaration is enforced rather than trusted. See what a workflow's code may do.

An event subscription. When the work should start because something happened somewhere else, the assistant writes the code that registers the subscription with that service and keeps it alive. Triggers and schedules covers what happens once the event arrives.

Web search and a file sandbox come with every run too. Like the browser, they are always there and never declared.

Credentials stay yours

A workflow gets into a system in one of two ways. A login you complete yourself leaves a signed-in browser profile behind. A key you hand over becomes a connection: one credential for one system, stored server side, handed to a sandbox as an environment variable only when a step that declared it runs, and scrubbed out of what gets recorded afterwards.

Settings lists every key you hold under Connected apps, with a Disconnect button beside each one.

On this page