Automations & triggers

Beyond on-demand runs, agents can run on their own — on a clock or in response to something happening.

Automations (schedules)

An automation runs an agent on a cron schedule. Create and manage them from the Automations page. You pick the agent, the schedule, an optional input message, and an owner — the automation runs as that owner, so it uses the owner’s connection credentials. You can also choose whether a schedule runs the agent’s stable version or its live draft.

The automations list shows an Run as column so you can see whose credentials each schedule uses.

Composio event triggers

A trigger fires an agent from an external event — a new Gmail message, a GitHub PR event, and so on — via Composio. Triggers are configured per agent on the agent detail page, in the Triggers section (above Automations).

Prerequisites

Composio API key — set under Settings → Composio.
Composio webhook secret — also under Settings → Composio. Copy the webhook URL shown there (/api/hooks/composio/{workspace}) into your Composio app’s webhook configuration, then paste the matching secret into TAS.
A connection — the acting user must have authorized the toolkit the trigger listens on (e.g. Gmail). Authorize it under Connections first.

Creating a trigger

On the agent detail page, under Triggers → Add trigger:

Connection — pick which authorized connection’s credentials the trigger runs under (this sets the acting user).
Composio trigger slug — SCREAMING_SNAKE_CASE, e.g. GMAIL_NEW_GMAIL_MESSAGE. Find slugs in Composio’s trigger catalog.
Config (JSON) — per-trigger configuration. Use {} when the trigger has no required fields.

TAS registers the subscription with Composio. When an event arrives, TAS verifies the HMAC signature, looks up the trigger, and queues a run. Enable or disable individual triggers from the same section without deleting them.

Like automations, an event run executes as the trigger’s connection owner.

Each fired run shows up in Runs with Source = Event so you can tell automated activity from hand runs.

External webhooks

An external webhook lets any outside system fire an agent by POSTing to a TAS URL — useful when the event source isn’t a Composio toolkit. Clay is the first-class example: Clay sends an enriched row to TAS, and the agent does the work (e.g. upsert Attio, enroll a sequence).

Create one on the agent’s detail page, under External webhooks:

Add a webhook with a name (and, as an admin, an owner to run as). TAS shows the endpoint URL and a bearer token — copy both now; the token is shown only once (rotate to issue a new one).
The caller POSTs to the URL with the token in an Authorization: Bearer header and a JSON body. TAS verifies the token, queues a run, and acks immediately (HTTP 202) — fire-and-forget. The agent receives the request body as its input (envelope: { "trigger_type": "webhook", "webhook": "<name>", "payload": <your JSON> }), and its instructions + tools_module interpret the fields.

curl -X POST https://<your-tas>/api/hooks/webhook/<id> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"email":"sam@acme.com","domain":"acme.com"}'

Wiring it into Clay

In Clay, add an HTTP API column: method POST, the endpoint URL, a header Authorization: Bearer <token> (Clay’s encrypted “Headers account” is built for this), and a JSON body mapped from your table columns. Clay fires a request per row; each one queues a run.

The agent typically needs a Secret or connection to write results back (to Clay, Attio, etc.) from its Python tools — the webhook only starts the run.

Runs fired this way also appear in Runs as Event. Bad/missing token → 401, a disabled webhook → 403, too many in a short window → 429.