A short form
A small card, titled with the Integration’s name, asking for what it needs — a few fields at most. Fill it in and the run carries on from where it paused.
Integration health & prompts
Integration health & prompts
Section titled “Integration health & prompts”An agent is only as good as the Connections it can actually reach. The workspace shows you which ones are healthy, what each one can do, and exactly what happened when a call fails.
The Integrations panel
Section titled “The Integrations panel”The workspace side panel lists every Integration this agent is bound to, with its current state:
| State | What it means | What to do |
|---|---|---|
| Connected | Reachable and authorized, with the number of abilities available | Nothing |
| Needs authorization | The Connection has expired or was never completed | Authorize in Console |
| Unavailable | It couldn’t be reached, with the reason | Fix in Console |
| Changed since approval | Its set of abilities changed since you approved it | Review in Console |
Expand a row to see the abilities themselves, each with what it is allowed to do:
- Read — looks at data
- Write — creates or changes something
- Destructive — deletes or cannot be undone
- Always confirms — asks you every time, whatever your settings
The dot on each row tracks what actually happened during the current run, so a Connection that was fine ten minutes ago and just started failing shows as failing while you watch.
When a call fails, it says so
Section titled “When a call fails, it says so”A failed call renders as a failure — the service’s own explanation, marked clearly, never a tidy-looking summary of nothing.
The run doesn’t stop. Your agent sees the failure and can try a different approach, and a failure that needs you to act (an expired authorization, a refused credential) also raises a persistent notice with an Authorize in Console link.
Your agent is also told up front which of its Integrations are unavailable for this run. So instead of improvising around a missing Connection, it tells you — “Linear isn’t authorized for this agent — open Console → Integrations → Linear and click Authorize” — and you can fix it in a few seconds.
Abilities that always confirm
Section titled “Abilities that always confirm”Some abilities are marked by the service itself as needing a person — the sort of thing that shouldn’t ever happen unattended. Those:
- Always ask, at every autonomy level, including Autopilot
- Offer no “always allow” — you confirm each time, on purpose
- Are refused where there is nobody to ask, with a clear message: “This ability needs a person to confirm; it is not available on this run.”
That last case is deliberate. A scheduled Flow, a customer conversation, or a run delegated from a phone call has no one at the keyboard, so an ability that requires a human confirmation is declined rather than quietly auto-approved.
When an Integration needs something from you
Section titled “When an Integration needs something from you”An Integration can ask you for details in the middle of a run, and you answer without leaving the conversation. There are two shapes:
A link to finish elsewhere
Some services need you on their own site — a consent screen, a bank connection. You get a chip that opens it, and you tell Auteryn when you’re done.
Either card names the Integration that is waiting on it, so you know who asked. You can decline; the agent is told and continues without it. And on a run where nobody is watching — a scheduled Flow, a customer conversation — the request is declined automatically rather than leaving the run hanging.
Results that aren’t text
Section titled “Results that aren’t text”When an Integration returns more than text, the workspace renders it:
- Images come back as artifacts in the conversation, labelled with the Integration and ability that produced them.
- Links and file references are kept as links you can follow.
- Audio isn’t displayed; the reply says so rather than dropping it silently.
Testing a Connection
Section titled “Testing a Connection”In the Console, Test on an Integration gives you one of three answers — and they mean different things:
| Verdict | Meaning |
|---|---|
| Reachable · credential verified | Auteryn connected and made a real authenticated call that worked |
| Reachable · credential rejected | It connected, but the credential was refused — with the service’s reason |
| Reachable · not verified | It connected, but this service offers no cheap way to prove the credential works |
The third is honest rather than green: “reachable” is not the same as “working”, and the distinction is what saves you from discovering a bad credential mid-run.
If a service changes the set of abilities it offers after you approved it, the row is flagged Changed since approval so an unexpected new ability never arrives unnoticed.