Connect with your agent

Most sources are connected by telling your agent to connect them. You do not open a settings screen, and Atisbo never opens a pop-up window on your behalf — the one step that is genuinely yours, approving access, arrives as a link you click.

What it looks like

You: Connect our Zendesk so support tickets come in as evidence.

Agent: Found Zendesk in the catalogue — it publishes a ticket created event. Here is the authorisation link: https://connect.composio.dev/... — open it, approve access, and tell me when you are back.

(you open the link, log in to Zendesk, approve)

You: Done.

Agent: Confirmed active. Tickets will arrive as evidence from now on.

Three sentences from you. No URL to copy into a second system, no secret to store, no field to fill in.

What the agent is actually doing

Four steps, in this order. They are worth knowing because if something stalls, the agent will name the step it stalled on.

1. Search the catalogue. Around a thousand tools are reachable. The agent searches by what you asked for, not by a fixed list Atisbo maintains.
2. Create the connection. This registers what will be read and returns an authorisation URL.
3. You approve. The link opens the tool's own consent screen — Zendesk's, Jira's, HubSpot's. Atisbo never sees your password, and the grant is yours to revoke in that tool at any time.
4. The agent confirms. It checks the connection actually went active rather than assuming it did. A connection that is still waiting on you is reported as waiting, not as connected.

Two kinds of connection

Which one you get depends on the tool, not on a preference you set.

Apps that push. A minority of tools can notify Atisbo the moment something happens — a ticket is created, an issue is commented on. Evidence arrives within a couple of minutes.

Apps Atisbo reads. The large majority have no way to notify anyone, but do offer a way to be read. Atisbo reads them on a schedule, once a day by default. Nearly every app supports this, which is why the catalogue is as large as it is.

If you want to know which one you got, ask — the agent knows, and it can tell you when the next read is due.

Read-only is enforced, not promised

Atisbo cannot write into a connected tool. This is not a policy statement, it is a refusal in the code, and it works in two independent ways:

• An action the provider has not declared read-only is refused. The absence of a read-only claim is not treated as one — a tool arriving with no declaration at all is refused, not allowed through.
• An action that claims to be read-only but asks for a write permission is refused anyway. The permission is what the third party actually enforces, so when the label and the permission disagree, the permission wins.

The practical consequence: no agent, no prompt and no mistaken instruction can make Atisbo comment on a ticket, move an issue or edit a document. There is no code path that does it.

When the catalogue does not have it

An empty search result is not the end. Anything that can send an HTTP request or an email can reach Atisbo:

• If the tool can call a URL when something happens, use the signal webhook — your agent can create the endpoint and tell you what to paste where.
• If it can send or be forwarded email, use email.
• If you can export it, paste or upload it.

A good agent will offer one of these rather than telling you the tool is unsupported.

Two things worth telling your agent

Prefer customer voice. Sources differ in what they prove. A support ticket or a sales call is evidence that someone wants something; a deployment log or an error rate tells you what is happening but not what anyone needs. Both are useful and they are not interchangeable — operational feeds corroborate a problem, they do not establish demand for a fix.

Connect different things, not more things. Two support tools pointed at the same queue add volume without adding a second perspective. A support tool plus sales calls plus a survey is what makes a pattern legible.

GitHub is the exception

GitHub does not connect this way. Its setup installs a webhook inside your repository, which is a change to your repo rather than a permission you grant — so it has its own page and its own steps. If you ask an agent to connect GitHub, it will point you there.