Signals
Trigger.dev Gives Every Chat Its Own Durable Linux Machine
Trigger.dev's chat.agent gives every conversation its own stateful Linux machine that can run without request timeouts, sleep between turns, and keep streaming through refreshes and crashes. It plugs into AI SDK's useChat without the usual API-route and stream plumbing. The tradeoff is adopting Trigger.dev's runtime and paying only for compute used.
What Changed
- Introduced chat.agent, a backend provider for AI SDK that runs a stateful Linux machine per conversation.
- Added chat.agent() API to define an agent turn as a Trigger.dev task, with no request timeouts.
- Added chat.headStart() API to start turns from a warm server for lower latency.
- Added durable streams that survive page refreshes and crashes, plus built-in tracing and cost metrics per session.
- Added suspension and resumption for human-in-the-loop workflows, compaction, prompt caching, and MCP server integration.
Who Should Care
- Teams building chat or agent products that need long-running tasks with pauses for human approval.
- Developers using Vercel's AI SDK who are tired of writing custom API routes and stream handling for every turn.
Who Should Not Care
- Teams with simple request-response chat flows that already work fine over HTTP without state.
- Organizations that cannot accept a new vendor runtime dependency, even if self-hostable, due to existing deployment constraints.
The Verdict
This is a real architectural shift for AI agent builders: you trade stateless request-response complexity for per-conversation state machines that sleep and wake, which kills timeout and streaming pain dead. But it's a young platform, so expect edge cases and a learning curve; resist adopting it if your flows are simple enough that you don't need that durability yet.
Take This To Your Agent
Copy a ready-to-paste investigation handoff that asks your coding agent to check this update against your product and recommend what to do next.