An AI agent is a background job that runs for hours
Most software runs inside the space of a single request. A user clicks, a function wakes up, does its work in a few hundred milliseconds, returns an answer, and goes back to sleep. That model built the modern web. It also quietly assumes that useful work is short.
AI agents break that assumption. Ask an agent to research a company, draft a report, and file it across three systems, and you have left the world of the quick request. The agent might make forty model calls, wait on a slow API, pause for a person to approve a step, and keep working for twenty minutes or two hours. Run that on an ordinary serverless function and it dies at the timeout, halfway through, with no memory of what it already finished.
That gap between how AI actually runs and how our infrastructure expects code to run is the problem Trigger.dev set out to close.
Trigger.dev is an open-source platform for building AI agents and background workflows in plain TypeScript. You write a normal async function, deploy it, and get long-running execution with automatic retries, queues, scheduling, and observability built in. No timeouts, no separate queue to wire up, no worker fleet to babysit. The company came out of Y Combinator's Winter 2023 batch and is backed by Orange Collective, the fund run by YC alumni.
Background jobs got interesting again
Background jobs are one of the oldest ideas in software. Send the welcome email after signup, resize the uploaded image, run the nightly report. For years the category was treated as solved and a little boring: pick a queue, add a worker, move on.
AI changed the shape of the work. A background job used to be short and cheap, and it either succeeded or failed cleanly. An agent workflow is long, expensive, and full of steps that can fail on their own. One model call times out. A tool returns garbage. A rate limit hits on the thirtieth of fifty documents. If a two-hour job dies at minute ninety and restarts from zero, you have burned real money and real time replaying work that already succeeded.
So the humble background job became the hard part of shipping AI. The interesting question stopped being "how do I run this asynchronously." It became "how do I run this for a long time, survive failures, and never redo work I have already paid for." That question has a name in distributed systems: durable execution.
What durable execution actually means
Durable execution is the ability for a program to run for a long time and pick up exactly where it left off after a crash, a deploy, or a restart. The state of the task is saved as it goes, so a failure at step forty does not send you back to step one.
Trigger.dev does this with a checkpoint-resume system. When a task waits, on a slow API, a retry backoff, or a person, its running state can be frozen to disk and restored later on a fresh machine, continuing as if nothing happened. The underlying technology is CRIU, or Checkpoint/Restore in Userspace, the same Linux mechanism Google has used at scale for years. Paired with idempotency keys, it means each step runs once and its result is cached, so a retry resumes rather than repeats.
The practical payoff shows up as a list of things developers no longer have to build themselves:
No timeouts. Tasks run for as long as the work takes, minutes or hours, without the hard limits on AWS Lambda or Vercel functions.
Automatic retries. If a task throws, it runs again with a backoff you control, instead of silently dropping the job.
Queues and concurrency. You set rules for how many tasks run at once, so a burst of agent runs does not overwhelm a downstream API.
Scheduling. Cron-style scheduled tasks live next to the rest of your code instead of in a separate system.
None of these are new ideas on their own. The shift is getting all of them from one platform, wrapped around code that looks like the code you already write.
It is still just TypeScript
The closest comparison to Trigger.dev is Temporal, the durable-execution engine that large infrastructure teams reach for. Temporal is powerful, and it is also demanding. Your workflow code has to be deterministic, which means learning a set of rules about what you can and cannot do inside a workflow and structuring your program around the engine.
Trigger.dev's bet is that most teams do not want to learn a new programming model to get reliability. You write a normal async TypeScript function. You call your LLM, hit your database, await your API. There are no determinism constraints and no execution-time limit, and the platform handles the checkpointing underneath. Trigger.dev manages the workers, so there is no cluster to run yourself.
That choice is the whole philosophy. Reliability that requires rewriting how you think about your code gets adopted by the teams who have no other option. Reliability that fits inside a function you could have written anyway has a chance at everyone else. Trigger.dev is aiming at everyone else.
Pausing for a human, and seeing what happened
Two capabilities matter more for agents than they ever did for classic background jobs.
The first is human-in-the-loop. Real agent workflows often need a person to approve a refund, sign off on an email before it goes out, or correct a step before the agent continues. Trigger.dev has waitpoints for exactly this: a task can pause, for as long as it needs to, until a human approves, rejects, or adds feedback, then resume from that point. Because the run is durable, waiting on a person for an hour costs nothing while it waits.
The second is observability. When a workflow runs for two hours across dozens of steps, a failure buried in the middle is hard to find. Trigger.dev ships real-time dashboards built on OpenTelemetry, with a query language for digging through runs, plus streaming logs and run status you can pull straight into a React front end. When an agent misbehaves, you can see which step, which input, and which model call went wrong.
Open source as the way in
Trigger.dev is MIT-licensed and open source, and that choice is doing real work for the company. Developers can read the code, run it on their own hardware with Docker or Fly.io, and adopt it without a sales call or a worry about lock-in. The cloud product exists for teams who would rather not operate the infrastructure themselves, but the way in is a repository, not a contract.
That way in has been busy. The project has drawn more than nine thousand stars on GitHub and an active community of TypeScript developers, the kind of grassroots adoption that developer infrastructure lives or dies by. Before this company, the same team shipped JSON Hero, an open-source JSON viewer used by more than thirty-five thousand developers a month. Building tools that engineers pick up on their own is a pattern for them, not a first attempt.
The team and the backing
Trigger.dev was founded by Matt Aitken, Eric Allam, James Ritchie, and Dan Patel. Allam was previously CTO of Code School, an early online code-learning platform acquired in 2015. Aitken built iPad apps that won Apple's App of the Year. Together they had already shipped and open-sourced developer tools that found real audiences, which is the relevant track record for a company whose success depends on engineers adopting it one repository at a time.
The financial backing has kept pace. After a seed round out of Y Combinator, the company raised a $16 million Series A led by Standard Capital, with participation from Y Combinator and from operators like Michael Grinich, the founder of WorkOS. Orange Collective, the YC-alumni fund, backed the company as part of its Winter 2023 cohort. Investors who have built and sold developer infrastructure tend to recognize the shape of it early, and durable execution for AI is a shape a lot of them seem to believe in.
The unglamorous half of the agent era
Step back and the bet is clean. The industry is pouring effort into making agents smarter at reasoning, planning, and using tools. Far less attention goes to what happens when a smart agent has to run for two hours in the real world, where APIs fail, machines restart, and someone needs to approve step nine. A capable agent on flaky infrastructure is still an unreliable product.
Trigger.dev is building the layer that lets an agent's work survive contact with reality. It took one of the oldest problems in software, running work in the background, and rebuilt it for a moment when that work suddenly got long, costly, and worth protecting. If the coming wave of software really is agents doing multi-step work on our behalf, the ordinary question of how to keep those jobs alive through failure turns out to be one of the important ones. Trigger.dev decided to answer it in the language millions of developers already write.