Sanaf AI
Start free
Developer Tools

Trigger.dev, worked by an AI employee

Not another app for your team to learn, and not a set of rules for you to build. You hire an AI employee, you give it access to your Trigger.dev account, and you ask it for things in Slack or Teams the way you would ask anyone else on the team. There is nothing to map and nothing to maintain.

  • Developer Tools
  • Connects with a key
  • 10 ready-made tools
  • Asked in Slack or Teams
At work

An illustration of how the conversation reads, not a transcript from a client account.

What Trigger.dev is

Trigger.dev is a platform for building, deploying, and managing reliable background tasks and workflows.

You paste in a key from your own Trigger.dev account. It is kept encrypted, and you can withdraw it from inside Trigger.dev whenever you like.

How a run works

One message in, the work done in Trigger.dev.

  1. 01

    You ask

    You message your AI employee in the chat your team already has open, in one sentence, in your own words.

  2. 02

    It works out the step

    It decides what the job needs in Trigger.dev. You do not pick anything from a menu or wire anything together.

  3. 03

    It does the work

    Signed in to your own Trigger.dev account, inside the access you granted it, doing the thing you asked for.

  4. 04

    It reports back

    It tells you what it did, in the same thread. If it could not do something, it says so rather than guessing.

10 tools it already has

What it can do in Trigger.dev

These are the ready-made tools your AI employee already has in Trigger.dev. It is not limited to them, but it never has to be taught these.

  • Batch Trigger TaskStart multiple runs of one deployed Trigger.dev task in one provider-side batch and return the batch and run IDs.
  • Execute TRQL QueryRun one read-only Trigger.dev Query Language SELECT statement for custom run analytics and return JSON rows or CSV text.
  • Get BatchRetrieve a task batch's status, run IDs, completion counts, and item errors.
  • Get Batch ResultsRetrieve the success or failure outcome and encoded output for every run in a completed task batch.
  • Get ErrorRetrieve one Trigger.dev error group's message, occurrence history, affected versions, and resolution or ignore state.
  • Get RunRetrieve one run's status, timing, payload, output, attempts, metadata, relationships, schedule, and cost details. Presigned payload or output URLs are returned without fetching th
  • Get Run ResultRetrieve one run's compact success or failure result, including its encoded output or error and usage duration.
  • List ErrorsReturn one forward page of Trigger.dev error groups, optionally filtered by task, version, status, text, or time window.
  • List RunsReturn one forward page of runs in the connected environment, optionally filtered by time, status, task, version, tags, schedule, bulk action, test mode, or error.
  • Trigger TaskStart one run of a deployed Trigger.dev task and return the new run ID.
Access, and who is in charge of it

You stay the boss of your Trigger.dev account.

Nothing connects until you approve it. You grant access one app at a time, you can take it back the same way, and everything your AI employee does in there is written down where you can see it.

How we handle your data
  • It signs in to your own Trigger.dev account. You are not moving anything into ours.
  • You grant access one app at a time, and you can take it back the same way.
  • Everything it does in Trigger.dev is written down, with what it did and when.
  • Anything you tell it to check with you first, it checks with you first.
Other apps in the same corner of the business

It works in Trigger.dev and the rest of your software in the same job

A real job rarely stays in one place. Reading a message in one app, checking a record in another and writing the result in a third is one request to your AI employee, not three.

See every app

Questions people ask about Trigger.dev

Can an AI employee really work inside Trigger.dev?
Yes. It signs in to your own Trigger.dev account and works in it the way a new hire would, from the chat your team already has open. Nobody installs anything, and nobody learns a new screen.
Do I have to move anything out of Trigger.dev?
No. Nothing moves and nothing is replaced. Your records stay in Trigger.dev, your team carries on in the same screens they used yesterday, and your AI employee works alongside them in there.
How does it get into my Trigger.dev account?
You paste in a key from your own Trigger.dev account. It is kept encrypted, and you can withdraw it from inside Trigger.dev whenever you like. You approve it before anything connects, and you can take the access back the same way you gave it.
What can it actually do in Trigger.dev?
It has 10 ready-made tools in Trigger.dev today, among them Batch Trigger Task, Execute TRQL Query and Get Batch. The full list is on this page. It is not limited to those, but it never has to be taught them.
Can it use Trigger.dev and the rest of my software in the same job?
Yes, and that is usually the point. Reading a message in one app, checking a record in Trigger.dev and writing the result somewhere else is one request to your AI employee, not three separate ones you stitch together.
Who decides what it is allowed to do in Trigger.dev?
You do. You grant access one app at a time and can withdraw it at any time, anything you ask it to check with you first it checks with you first, and everything it does in Trigger.dev is written down with what it did and when.