Agent integrations

Integrations give the build agent tools beyond your repository. Connect Slack and the agent can post a release note; connect a helpdesk and it can read the ticket it's fixing; connect a calendar and it can book the follow-up. Every connector lives in a build room's rail under Integrations, and every one follows the same safety model: reads are cheap, writes are opt-in and gated.

Built-in connectors

Openbook ships sixteen connectors the agent can use as tools out of the box:

Connector	What it gives the agent
WordPress	Read, draft, edit and publish posts and pages on any WordPress site. Connects with the site URL, a username and an Application Password — built into WordPress 5.6 and later, no plugin needed.
Slack	Post to and read channels.
Figma	Read files and designs.
Lovable	The Lovable project.
Shopify	Store data.
Stripe	Find customers, subscriptions and invoices — your own Stripe account, connected with your credentials.
Google Calendar	Create events; attendees are invited and notified.
Cal.com	Event types, availability slots and bookings.
Calendly	Slots and scheduling.
Zendesk, Freshdesk, Zoho Desk, Help Scout, Intercom	Read and update tickets and conversations.
HubSpot, Salesforce	CRM records.

To connect one, open the room's Integrations panel, pick the connector, and provide its credentials.

Connector credentials are stored encrypted, and the panel never shows them back to you — only whether each one is set. If a connector still needs something, it says which field. Integrations are set up per build room, so connecting Stripe in one room does not expose it to agents anywhere else.

When you connect a connector, Openbook makes its cheapest read-only call straight away, so a bad key is found now rather than in the middle of a run.

Read vs write

Every tool a connector offers is classified as a read or a write:

• Reads fetch information — list Slack messages, look up a Stripe customer, read a Zendesk ticket. They change nothing in the external system.
• Writes change the external system — post a Slack message, create a calendar event, update a helpdesk ticket, make a booking.

The distinction matters because writes to a third-party system are often irreversible. A calendar event invites and notifies real attendees the moment it's created; a Slack post is seen the moment it lands. Openbook therefore treats writes with two independent controls, both of which must allow the action before the agent can perform it.

Control 1: writes are disabled by default

When you connect an integration, actions that write to the external system are disabled. The agent can read immediately, but it cannot post, create, update or book anything until you explicitly enable each write action.

This is a deliberate default. Connecting a tool to see what the agent can do with it should never be the same decision as letting the agent act on the outside world. Enable writes one at a time, when you actually want them.

Control 2: autonomy mode gates writes at run time

Even an enabled write action is still gated by the run's autonomy mode. Autonomy modes form a risk ladder controlling which tools the agent may use without confirmation:

Mode	Shown as	What it allows
auto	Work unattended	Everything. Reads, edits and opens a pull request without stopping.
accept	Accept edits	Everything except actions on the outside world. Works unattended like auto, but the pull request opens as a draft — the work lands, a person lifts the gate.
ask	Ask before committing	Reads and edits freely, then waits for you before it creates a branch or opens a pull request. No outside-world actions.
plan	Plan only	Reads and thinks, and writes a plan. It cannot change a file in this mode.

Two rules anchor the ladder:

• Irreversible third-party actions — external mutations like sending messages outside Openbook or creating bookings — only run in auto mode. In any other mode the agent cannot perform them, enabled or not.
• Committing and opening a pull request need at least accept.

Enabling a write action answers "may this room's agent ever do this?" The autonomy mode answers "may it do it in this run, unsupervised?" Both must say yes. A run in ask mode will never send an external message even if Slack posting is enabled — and a run in auto mode still can't use a write you never enabled.

An organization owner can tighten this further for a whole space, with the per-space agent gates at Organization → AI self hosted. Gates only ever narrow what a room already permits — see AI usage & the token allowance.

In practice this means you can safely run in auto mode with only reads enabled, or keep powerful writes enabled but run in ask mode for anything sensitive. The two dials are independent.

Choosing what to enable

A reasonable progression for a new integration:

1. Connect it and leave writes off. Let the agent use reads in a few runs — pulling ticket context, looking up customers — and see what it does with them.
2. Enable the specific writes you need, not the whole set. If the agent should update helpdesk tickets but never close them, enable only the update.
3. Reserve auto mode for runs where external effects are the point — a workflow that posts a daily summary to Slack, for instance — and use the stricter modes everywhere else.

Beyond the built-ins

If the system you need isn't in the connector list, you have two options:

• Define a custom HTTP action — a method, URL and parameters that become a tool the agent can call. GET and HEAD count as reads; anything else is treated as an external mutation and runs in auto mode only. See Workflows, actions & skills.
• Connect an MCP server — a standard way to give the agent a whole set of tools over HTTPS, with per-tool enablement and organization-wide oversight. See MCP servers.