Winning the relay race: keeping long business processes from leaking value
Most of the work that matters in a business isn't one task. A deal goes from first call to signature. A claim goes from report to payout. A new hire goes from application to their first productive week. A month-end close runs from the first reconciliation to signed-off books. Each of these takes weeks, passes through many hands, and only pays off at the very end. And every time the work changes hands, something can slip: a follow-up that never went out, a document nobody read closely, a detail that lived in one person's head.
David Haber at a16z recently put a name to this in Winning the Relay Race: Long-Running Agents in High-Value Customer Journeys. The piece describes these journeys as relay races, where value leaks at every handoff. It argues that agents which can hold context over weeks, wake up when something happens, and send helpers out to do the legwork could carry a journey from start to finish. It's a good read, and it matches what we keep hearing from teams adopting agents.
This post covers how we think about that problem at TeamShared, what already works today, and what we're building next.
Why handoffs are where value leaks
When a process runs for weeks, the hard part usually isn't any single step. It's everything between the steps:
- Context gets lost. The person (or agent) picking up step six often doesn't know what happened in steps one through five, or why.
- Persistence runs out. Following up a fifth time is tedious, so it often doesn't happen.
- Thoroughness gets rationed. When people are stretched, routine cases get a quick look instead of a careful one.
- Nobody can see the whole thing. Information is spread across email, documents, tickets and people's memories.
- Nobody knows what it cost or what it was worth. So it's hard to tell which processes are working.
Agents can help with all of this, but only if they have somewhere to keep the shared state of the process, rules about when a human needs to step in, and a record of what actually happened.
What TeamShared does today
TeamShared is shared memory and execution for a team and its agents. Several pieces that long-running processes need are already shipped:
- Shared memory your agents and people both use. Skills, playbooks and files are versioned. When two agents edit the same skill, playbook or file at once, the slower one now gets a conflict back instead of silently overwriting the other's work.
- Work and projects. Tasks and projects that humans and agents both pick up, so the plan lives in one place.
- Process runs. A process run follows a playbook step by step and shows where it is and what comes next.
- Agent runs with human approval. Agents can pause and wait for a person to approve before they do something that matters.
- An event log. Every important change is appended to a timeline, so you can see what happened and when, and nothing is quietly rewritten.
- Evidence. Steps can say which documents or proof they need, and you can see what's received and what's still missing.
- One wake system. Agents are woken through a single path, whether it's a schedule, a message or a GitHub webhook, with permission checks and spend limits built in.
- Cost per completed task. Each task now shows what it took: token spend, agent time and human review time, with a typical cost per completed task across your projects.
Put together, you can already run a multi-step process where agents and people share context, approvals happen in the right places, and there's a record of the whole thing.
What we're building next
Today's process runs work well for processes that finish in one sitting. The next step is making them last for weeks without losing the thread. This is planned work, not shipped yet.
Process instances. An instance is one long-running run of a business process: this deal, this claim, this hire. Each instance is tied to the thing it's about, called its subject. That's a customer, candidate, vendor or invoice you already track in TeamShared. One customer can have several processes running at once. Each instance has its own timeline, built from the event log, so anyone can open it and see the whole story in one place.
Templates. We don't want to build a separate product for every industry. A template packages the process steps, what the process is about, the evidence each step needs, and what a good outcome looks like. Deals, claims, matters, hires, vendor onboarding and month-end close become templates rather than special features. Templates also set the labels, so your team sees "Claims" or "Hires", not generic jargon. We also plan to let teams share and import templates, and an imported template stays untrusted until an admin approves it.
Triggers that keep work moving. Instances should wake up on their own when something happens: a deadline arrives, a webhook fires, an email comes in, a GitHub event lands. All of these will run through the same wake system that's already shipped.
Helpers and persistence. A step should be able to send out several helper agents in parallel, wait for their results and combine them. Steps will also have retry and escalation rules, like "try this up to ten times, then hand it to a person", so persistence doesn't depend on someone remembering.
Evidence before moving on. A step will be able to require its evidence before it can finish, with any override logged.
Outcomes and economics. When an instance finishes, it should record what came of it: the result, its value, what it cost, and how much of the work was done by agents versus people. Cost per completed task is the first half of this, and it's already shipped. Agents will be able to propose an outcome, but a person has to confirm it before it counts. The agent-versus-human split will be based on the steps each actually completed, counting people's active working time rather than time spent waiting in a queue.
Learning from every run. When an instance closes, what worked and what didn't can feed suggested playbook changes. A person reviews those suggestions before anything changes.
Why we're building it this way
We're deliberately building this on top of what already exists: shared memory, the event log, evidence, human approvals, the wake system and cost tracking. Long processes don't need a separate system. They need the same shared context and accountability that short tasks get, kept up over weeks.
We also want to stay neutral about channels. Your agents might make calls, send emails or work in other tools. TeamShared's job is to be the baton they pass: the shared state, the rules, the approvals and the record.
If you're running processes like these and want agents to carry more of them, we'd love to hear what you need. Tell us which processes you'd turn into templates first.