"Distributed systems are hard. If we don’t have to reinvent the wheel, why would we?" — Jean-Denis Greze, CEO, Town
| This case study is based on an interview with Jean-Denis Greze, CEO of Town |
Proof at a glance#
- Roughly 10x usage growth overnight following Town’s public launch, with the platform holding up under the increase.
- 1.5 billion monthly Temporal Actions, up from roughly 150 million following Town’s public launch.
- Incidents involving delayed briefings and dropped email processing largely eliminated, according to Town’s CEO.
- Calendar rescheduling logic built in about one day, compared with the roughly one month the CEO estimates it would have taken on the homegrown system.
The Customer#
Town is the AI work assistant. Townies take on the repetitive tasks people would gladly hand to someone else. Once connected to a user's work tools, a Townie can prepare a morning briefing or help them get ready for a meeting. Afterward, it can start working through the follow-ups. As it learns more about the user's work, it suggests other tasks it could handle.
The goal is to make that help useful from the start. A user shouldn't need to learn how to build an agent or write an elaborate prompt before getting something done.
For CEO Jean-Denis Greze, that means forwarding an agency's lengthy questionnaire to his Townie, Ivy, and asking for a first pass. Ivy gathered the supporting documents into a Google Drive folder, leaving him about five minutes of review and edits before sending it back. He estimates doing the work himself would have taken an hour.
Town serves individuals, including founders, recruiters, and salespeople, as well as whole teams, whose Townies share routines, context, and threads. Townies work with you and your team, in the email, calendar, and tools you already use. They learn how you work, spot where they can help, and get things done for you.
The challenge#
Town's users expect their morning briefing at 6 a.m., ready to read or listen to on the way to work. Preparing it means pulling information from their calendar, email, and Slack, then using an LLM to make sense of the day ahead. On Town's original infrastructure, those briefings sometimes arrived two hours late, well after users needed them.
The system struggled with predictable bursts of work as Town grew. Morning briefings needed to run at the same time for users in each time zone. Meetings ending on the hour brought another wave of requests as assistants began handling follow-ups.
Other tasks needed to stay on track long after the initial request. A user might ask their assistant to check dinner RSVPs in 45 days and follow up with anyone who hadn't responded. An agent could also need to pause for human approval before continuing. Town's infrastructure had to keep track of that unfinished work while handling requests that users expected to be done within seconds.
Town had started with queues and message passing, but the team kept running into more orchestration work. If a task failed, the system needed a way to recover it. If engineers changed the code, they had to account for tasks scheduled weeks earlier that hadn't finished yet. Maintaining those mechanics was taking time away from building the assistant.
Users, meanwhile, needed to trust that delegated work would get done. A missed candidate follow-up or an unsigned form could have real consequences, especially if someone had stopped tracking the task after handing it off.
"Reliability is the product." — Jean-Denis Greze, CEO, Town
The solution#
Town moved its agent harness onto Temporal Cloud. The harness responds to changes in a user's work, such as an incoming email or a rescheduled meeting. It also starts routines at their scheduled times. Temporal coordinates the agent's progress, including when it needs to pause for input and resume later.
For a typical user request, Town's backend gathers initial information and passes the request to the service running its Temporal Workflows. The agent retrieves relevant context, calls the LLM provider, and streams the response to the user. Town saves state in its database, and tool calls run as Temporal Activities. The loop continues until the agent finishes or reaches a point where it needs to wait.
Temporal's Workflow and Activity abstractions help Town handle failures and asynchronous tool responses throughout that loop. Engineers can build on the same orchestration foundation as they add new agent capabilities.
Human approval is part of that flow. When an agent needs permission to send an email, for example, its Workflow pauses with its state preserved. The user's approval passes through Town's backend and resumes the waiting Workflow. Town also implements expiration logic in Temporal so an unanswered approval can close after seven days.
Long-lived state helps with changing plans, too. When a calendar event moves, Town can wake the thread that originally scheduled it, with the earlier conversation and context still available. Engineers can use that context without manually reconstructing the original request.
Town chose Temporal because its capabilities were mature and the platform was stable. Building on it meant the team could improve the assistant without maintaining its own orchestration system. Long-running tasks would otherwise require engineers to build recovery tooling and manage what happens when workflows change.
“You’ve basically solved a ton of hard problems around running large, long-running workflows, both synchronous and asynchronous, which is the life of agents.” — Jean-Denis Greze, CEO, Town
The results#
When Town launched publicly in June, daily usage grew roughly 10x compared with the day before. The platform held up through the increase.
Greze says the severe incidents that had involved late briefings and emails left unprocessed after failed retries have largely disappeared. That gives users a more dependable assistant for work happening in the background, including tasks they may not check on again until the result is due.
The same foundation has shortened feature development. Town added the ability to wake earlier scheduling threads when calendar events moved in about a day. Greze estimates that capability would have taken roughly a month to build on the homegrown system.
More broadly, Town can deploy agents on its existing platform in minutes. Entirely new agent features typically take between a day and two weeks, according to Greze. With the underlying orchestration in place, engineers can focus on what each feature needs to do for the user.
Town now supports team workflows, where Townies coordinate work across people. Greze already sees small examples in his own day: ahead of this interview, a colleague asked her Townie to contact his Townie, Ivy, and arrange reminders for him to read the prep document. As those interactions become more common, Town expects Temporal to remain central to keeping track of what needs to happen next.
“Temporal helped Town move from fragile agent runs to durable workflows at billion-action scale so users can hand off real work and trust that it gets finished.” — Jean-Denis Greze, CEO, Town
The takeaways#
- An agent needs to remember what it promised. Temporal preserves Town's Workflow state while an agent waits for approval or a task's scheduled start. Users can hand off work without setting a separate reminder to check that it happened.
- Changing plans shouldn't mean starting over. When a calendar event moves, Town uses Temporal to resume the earlier scheduling thread with the original conversation and context available.
- Solving orchestration gives engineers more time for the assistant. Temporal handles retries, timers, and durable execution, freeing Town's team to build agent features without recreating that infrastructure for each one.
