Agents
Give agents tools & integrations
Without tools an agent can only produce text. With tools it can read a real order, post to a real channel and book a real meeting. I built this part of the product, and the honest summary is that tools are where agents stop being a demo and start being able to break things — so every one of them is capped and guarded.
The ten tools
This is the full list. Enable them per agent in the agent builder’s Tools section — an agent gets nothing it was not explicitly given.
| Tool | What it does | Needs connecting first | Calls per day, per user |
|---|---|---|---|
http_request | Call any REST API, any method | No | 1,000 |
send_webhook | POST a payload to a URL you own | Outbound webhook | 500 |
send_email | Send email from the platform | No | 100 |
slack_message | Post to a Slack channel | Slack | 300 |
discord_message | Post to a Discord channel | Discord | 300 |
google_chat_message | Post to a Google Chat space | Google Chat | 300 |
telegram_message | Send a Telegram message | Telegram | 300 |
notion_create_page | Create a Notion page | Notion | 300 |
google_calendar_list_events | Read calendar events | Google Calendar (OAuth) | 300 |
google_calendar_create_event | Create a calendar event | Google Calendar (OAuth) | 300 |
Connect the ones that need it under Account → Integrations. Credentials are encrypted at rest, and an agent never sees them — it asks for the tool by name and the platform supplies the connection.
Turn one on
- Open the agent and click Edit.
- In the Tools section, tick the tools this agent may use.
- If a tool needs a connection, add it under Account → Integrations first.
- Save, make sure the agent is Active, and run it.
- Open the run and read the step rows — each tool call shows its arguments, its result and its status.
Why the daily caps exist
Agents run on their own once you put them on a schedule or behind a webhook, so a buggy prompt can call a tool in a loop with nobody watching. A cap bounds that loop; it does not stop it. The loop keeps running until the day’s allowance is gone, so a cap protects your bill rather than acting as a safety control. The caps are per user, per tool, per day, and set well above heavy legitimate use — a workflow on a five-minute schedule is about 288 runs a day.
The control, as opposed to the bound, is the SSRF guard: it refuses private and internal addresses outright, so the call never leaves. What nothing stops today is an agent choosing a public address it was never meant to reach — including this product’s own webhook URL, which a run can call with send_webhook to start another run. That is an open finding, recorded rather than fixed, and it was named by somebody else in public before it was named here.
The email cap is the strict one at 100, and deliberately so: it sits below the mail provider’s own account-wide quota, which verification and password-reset mail also draw on. An agent that could exhaust that quota would stop new users being able to confirm their address.
When a tool call does not work
The result shows HTTP 403
The agent reached something it is not allowed to reach. Outbound calls pass through an SSRF guard that blocks private and internal addresses, so an agent cannot be talked into scanning the network it runs on. A refused call now shows its status next to the tool name instead of passing silently.
The tool is not connected
A tool whose integration is missing fails rather than pretending. Add the integration under Account → Integrations and re-run — you do not need to rebuild the agent.
The agent answered anyway
This is the one to watch for, and the mechanism is exact. Source: a run of mine published in full made two http_request calls that came back HTTP 403 — and the tool result recorded "ok": true anyway, because the request itself completed. The agent read that as data it had. Its Slack escalation did fail outright (Slack was not connected); its email escalation went out; and the reply it drafted told the customer it had checked her orders. The run cost $0.0204, took 28.5 seconds and finished COMPLETED.
So read the step rows, not the run status. Every step records what it received and what it returned, which is what tells you whether the work actually happened.
Bring your own LLM key
Under Account → Integrations you can add your own provider key. Runs then bill to your account with the provider instead of the platform’s daily allowance, and the key is encrypted at rest. This is the usual reason to switch: the free plan’s allowance is a spend ceiling, and your own key removes it.
Next
- Put the agent on a schedule or behind a webhook so it runs without you — see Automate: schedules & webhook triggers.
- Read a failed run end to end — see How to troubleshoot a failed run.