> However I do personally really dislike that everyone is either marketing themselves or has truly pivoted to AI agents…

I'm the CEO of a direct competitor to trigger, and we're in the same boat. What we make is great for any type of workflow, but our investors are pushing us hard to frame it as AI agents.

FWIW, more than 1/2 of our customers are AI agents, so it does make sense. But you're right, it's great for all sorts of use cases (trigger and us).

I do some AI agent work; I suspect it's because there's a lot of people with infrastructure and programming skills that are new to building "agents". It's easy to think this requires monolithic architecture when a distributed DAG is often optimal. A lot of frameworks and SDKs for "agents" also inadvertently encourage monolithic design.

Long way of saying it's the marketing machine doing its thing. This looks like Cloud or run it yourself DAG software with some bells and whistles.

yeah this really confused me... at first I was like... oh boy yet another "agentic ai saas" but then looking closer I realized this is like hosted temporal alternative which made me a lot more curious.

The core is a durable execution engine, but there's a lot more needed to build good applications. Like being able to get realtime progress to users, or being able to use system packages you need to actually do the work (like ffmpeg, browsers etc).

Both of them are focused more on being workflow engines.

Temporal is a workflow engine – if you use their cloud product you still have to manage, scale, and deploy the compute.

With Temporal you need to write your code in a very specific way for it work, including working with the current time, randomness, process.env, setTimeout… This means you have to be careful using popular packages because they often using these common functions internally. Or you need to wrap all of these calls in side effects or activities.

Restate is definitely simpler than Temporal, in a good way. You wrap any code that's non-deterministic in their helpers so it won't get executed twice. I don't think you can install system packages that you need, which has been surprisingly important for a lot of our users.

I have used Temporal in the past in my previous job and currently using Prefect. All are similar in terms of durable and traced executions but this one seems to be tailored towards AI use cases where as others are more general.

I haven't tried Trigger, planning to give it a spin this weekend!

Dallin's building https://www.buster.so (agents for data analytics).

Yep you do need to be careful with uncaught errors.

When you setup your project you choose the default number of retries and back-off settings. Generally people don't go as high as 50 and setup alerts when runs fail. Then you can use the bulk replaying feature when things do wrong, or if services you rely on have long outages.

I think on balance it is the correct behaviour.

Currently we have two deployment models: self-host the entire platform or use our cloud offering, where we host the platform and your workloads. We've had a lot of feedback from users and potential users that they'd like to be able to run workloads themself and have us host the platform side. We definitely plan on offering this deployment model (and allowing payloads and outputs to stay on-prem as well) eventually, but we're waiting until we can do it properly and that will support all the features of the cloud (snapshot/restore, warm starts, atomic versioning). We're planning on offering this alongside the release of our MicroVM runtime later this year/early next year.

Very common issues were: forgetting to put non-determistic code inside of steps (deterministic code can be put outside of steps, but non-deterministic = boom), incorrect use of cache keys (people would put dynamic data inside the cache key). Another issue we hit pretty frequently that a single step would take longer than the serverless function timeout it was running on (this was before we ran our own compute platform). Another issue was speed, especially with more complicated tasks with hundreds of steps: the amount of data that needed serializing/deserializing became pretty huge. Oh yea, that was another thing (it's coming back to me now), there were lots of fun surprises about data being serialized/deserialized and changing shape (e.g. you couldn't have a step that just returned a class instance, for example) which caused tons of bugs.

(other Trigger.dev co-founder here) That's awesome.

Let us know if there's anything we can do to make the product better for you

Inngest is very similar to Trigger.dev version 2: it’s an API for queuing and orchestrating workflows. You need to divide your work into steps, where each step needs to have serializable inputs and outputs, and takes less than the timeout of your serverless function (if you're hosted on serverless).

Trigger.dev is a queue and workflow engine but we also run compute. This makes some things possible which aren’t when you only control one side:

1. No timeouts, you can run code for as long as you need. 2. You don’t need to divide your work into steps. If you want you can use multiple tasks. 3. You can install any system packages you need, like ffmpeg, Puppeteer etc. Depending on where you’re deploying this can be a problem with other tools. There are maximum bundle sizes on a lot of platforms which are surprisingly easy to hit. 4. Atomic versioning. Each deploy of your tasks is separate and any runs that have started will continue until finished, locked to that version of the code. This means you don’t need to think about versioning inside your code which can becomes messy and error prone.

One other note is that we’re Apache 2.0.

We support this but you do need to pass a public access token to your frontend so it's secure: https://trigger.dev/docs/realtime/react-hooks/triggering

If it were possible, how would you have prevented your Trigger account from being abused once a bad actor got its connection details by inspecting your FE app with DevTools?

A couple things purely from the tech angle:

- We're not really an agent framework, but more like a agent runtime that is agnostic to what framework you choose to run on our infra. We have lots of people running langchain, mastra, AI SDK, hand-rolled, etc on top of us, since we are just a compute platform. We have the building blocks needed for running any kind of agent or AI workflow: ability to run system packages (anything from chrome to ffmpeg), long-running (e.g. no timeouts), realtime updates to your frontend (including streaming tokens). We also provide queues and concurrency limits for doing stuff like multitenant concurrency, observability built on OpenTelemetry, schedules for doing ETL/ELT data stuff (including multitenant schedules). - We are TS first and believe the future of agents and AI Applications will be won by TS devs. - We have a deep integration with snapshotting so code can be written in a natural way but still exhibit continuation style behavior. For example, you can trigger another agent or task or tool to run (lets say an agent that specializes in browser use) and wait for the result as a tool call result. Instead of having to introduce a serialization boundary so you can stop compute while waiting and then rhydrate and resume through skipped "steps" or activities we instead will snapshot the process, kill it, and resume it later, continuing from the exact same process state as before. This is all handled under the hood and managed by us. We're currently using CRIU for this but will be moving to whole VM snapshots with our MicroVM release.

I also see a new AI agent workflow framework/platform/library every week and to me the differentiation of this project is clear in the logging, orchestration and auto-scaling. Of course, I don't need trigger.dev to win the market, I was just looking for exactly this for my own project and haven't found anything else like it.

Docs created by Mintlify https://www.mintlify.com/

co-founder of Magic Patterns here, saw were were mentioned, figured I'd chime in:

We don't use Trigger for marketing at all and I actually never thought of it for that use case.

We're an AI design tool - prompt to create an interactive mockup - and we use Trigger to take screenshots of designs to provide a preview image. Taking a screenshot sounds easy, but it's not because Puppeteer constantly hits OOM errors. So you need a high-end machine, and so it can get expensive. We originally were using a homegrown solution, a microservice, but it would constantly crash (even though were paying $$$$$ for it).

Trigger spinning up jobs was perfect and we migrated in a day and now I never think about it.

That's actually how we started back during YC W23 as a "Zapier for developers" but we pivoted to "async workflows" later in 2023 and have since been used less like Zapier and more like the core part of an apps infra/backend, which has taken off with AI applications building AI workflows and agents, including those examples you quoted there.