A context engine for AI agents is, structurally, a Durable Execution problem.
You can’t cache a team’s understanding of its own system. A Slack thread can override documentation overnight. Conventions can change from two PRs ago. So the ingestion layer can’t snapshot an answer and serve it. It has to compute against the current state continuously, across a dozen heterogeneous sources, and survive arbitrary failure while it does.
That’s the work Unblocked moved onto Temporal. Here’s why we did it, what we evaluated, and what changed.
What Unblocked is, and why ingestion is hard#
Unblocked is a context engine for AI-driven software development. It reasons over code, PRs, conversations in Slack and Teams, docs, runtime signals, and a long list of data connectors, and computes them into understanding that developers and their agents query through MCP, a CLI, or an API.
One architectural decision shapes everything downstream: we don’t cache answers. The underlying truth changes constantly, and a cached answer that was correct yesterday is wrong today, with the error hidden behind confidence. So we compute against the current state of the code, the conversations, and the decisions on every request.
That decision turns ingestion into a hard part of the system. It has to be continuous, polyglot, durable, and observably correct across thousands of workspace deployments and source-control organizations running under a single account. It’s the backbone of the product.
Before Temporal: The DIY actor model#
The original design was an actor model. Each ingestion job was pinned to a single compute instance, held its state in memory, and rehydrated on crash. Around that we’d written custom queues, custom retries, and custom recovery code, threaded through the codebase.
It worked. But the diagnosis was uncomfortable: this is operating-system and cloud-fabric work, not Unblocked IP. We were spending real engineering on a commodity.
“No one’s coming to Unblocked saying ‘this company’s incredible, we need to use their product because they built their own queue.’ It was a commodity, and we were spending real engineering cycles on it” — Narayan Sainaney, Principal Engineer, Unblocked
The evaluation#
We surveyed the market. The shortlist came down to three options: Prefect, Temporal, and rolling our own on the primitives we already had, ActiveMQ, S3, and Postgres.
Prefect was a strong tool and the team was good to us, but it was Python-only, and that didn’t fit a stack spanning Kotlin, TypeScript, and Python.
Roll-your-own was the option we ruled out fastest. It's what we were already doing, and what we wanted to stop doing.
Temporal won on three things: polyglot SDK support, Durable Execution as a primitive rather than something we’d assemble ourselves, and a depth of capability we hadn’t reached yet.
The implementation#
Martin built a thin Kotlin shim over Temporal’s Java SDK. Pages of orchestration code collapsed to four or five lines per workflow.
The philosophy was deliberate: minimal abstraction. Don't hide Temporal's primitives behind our own. Expose them. Another engineer, Rashin, then layered on opinionated retry and exception handling, tuned to Unblocked's ingestion patterns.
From there adoption spread organically, one data source at a time. Asana first, then CI, then Slack, then most of the rest of our integrations.
“Temporal splits the way you think about your algorithm from the way you actually run the Activities. It kills a whole class of programming issues and confines the rest to little boxes.” — Martin Scotta, Principal Engineer, Unblocked
The payoff#
The wins compounded as more of the system moved over:
- Deployment-free Workflows. Long-running jobs survive arbitrary instance churn and pick up from the last checkpoint.
- No more deploy-time database CPU spikes. Background jobs no longer fire on service start; Temporal schedules them properly.
- One path for user-triggered and cron flows. The same Workflow handles both, which deleted a whole category of “did the UI change cause this?” edge cases.
- Observability for free. The Temporal UI replaced an in-house admin console we’d planned to build.
The biggest payoff isn’t on that list, by the way. Engineering capacity moved off orchestration plumbing and onto product: the AI engineering layer that sets Unblocked apart from a connector or a search tool, and makes it valuable.
“We essentially became deployment-free. It doesn’t matter if the instance dies or the database is soft — we just pick up from wherever it left off. In the past we needed a pile of tricks and code to get that. Now we write the Workflow and forget about it.” — Martin Scotta, Principal Engineer, Unblocked
Scale, and what’s next#
Today Unblocked runs roughly 1 million Temporal Workflows per day, 3.6 million live, across every data source except code. It’s self-hosted on Kubernetes, with 12 History and 12 Matching replicas in production, Aurora Serverless for persistence, and KEDA autoscaling per queue.
Code ingestion is mid-migration off Prefect now. And internally, adoption is roughly 50/50. The next push is getting the rest of the engineering team off bespoke patterns and onto Temporal-first defaults.
“If we were building a company from scratch today, the rule would be: everything has to be Temporal. Everything.” — Martin Scotta, Principal Engineer, Unblocked