Most agents today are request-driven. Someone opens a chat, describes a task, and the agent does it. That's a good place to start, and it's where most agent products begin.
The agents teams are shipping to their customers now do more. A client posts in a shared Slack channel asking for a refund. A deal moves to Closed Won in Salesforce. An account gets a new owner. Each of these has a clear next step, and the agent already has the access it needs to take it. What's missing is a way for the agent to know something happened.
Triggers adds that. When something happens in your user's apps, their agent starts working on it, as that user and with their permissions. Nobody has to prompt it, and you don't run a polling loop to catch the change.
Triggers is in early access, starting with Slack and Salesforce. The rest of this post covers why this takes more than wiring up a webhook, how Triggers works, and what teams are building with it.
Receiving an event is not hard. Slack will send you a webhook when a message is posted, and most systems have some way to tell you something changed.
The work starts after the event arrives. Say the refund request lands at 11pm. The person whose Slack and Salesforce accounts the agent works with is offline. The agent still has to act as them: look up the account with their access, post a reply in their channel, and leave a record of what it did. That means a valid token for that specific user, the right permissions on it, and an audit trail you can show a customer's security team.
Then there's the delivery layer. Some apps send webhooks and some don't, so you end up polling the ones that don't. Events can arrive twice, so you need deduplication. Upstream APIs have bad days, so you need retries that don't flood them when they recover. None of this is the agent your team set out to build, and all of it has to work for every user of every customer.
Triggers takes on both parts: who the agent is acting as, and getting the event to your agent reliably.
Triggers runs on the same connected accounts your users already have in Scalekit, so there is no second integration to build.
Support requests that get handled at any hour. A customer asks for a refund in a shared Slack channel. The agent picks up the message, finds the account in Salesforce, logs the refund and asks the account owner in the thread to approve it. By the time anyone looks, the work is ready for a yes or no.
Handoffs the moment a deal closes. An opportunity moves to Closed Won in Salesforce. The agent writes a handoff summary from the deal record and posts it to the account team's Slack channel, so onboarding starts the same day. If you've built a deal room sync agent, this is the event that can start it.
Routing that follows ownership. An account gets a new owner in Salesforce. The agent posts a short brief to the new owner in Slack with open deals and recent activity, so the change doesn't stall anything.
In each case the agent acts with the permissions of the person the event belongs to, and nothing new sits in your infrastructure to make that possible. Runs that chain several tool calls keep the same user context throughout, the same way multi-step tool calling works today.
Triggers is in early access with Slack and Salesforce.
Teams are asking for Gmail, Google Sheets and Microsoft Teams next. The requests we get decide what we build after these, so if your agent needs triggers on another app, tell us which one when you request access.
Request early access to Triggers
Triggers is one of several releases from the last month. Admins can now connect a shared app once for the whole organization, users can choose which permissions to grant, and the Search Tools API finds the right tool for a request in one call.
Slack and Salesforce, in early access. You can request triggers for other apps in the early-access form.
A webhook tells you something happened. Triggers also ties the event to the user it belongs to and runs your agent with that user's permissions. Scalekit handles polling for apps that don't send webhooks, plus deduplication and retries, and every run is logged.
No. Users connect their accounts through Scalekit as they do today, and the tokens stay in the token vault. When a trigger fires, the agent's tool calls run with that user's existing connection.
Yes. You turn on a trigger for an event on a connection you already use. There is no separate integration to set up.
