RelayDelegate to many coding agents. Decide only what needs your judgment.

Role: Research & Interaction Designer
Design Engineer
Timeline: Aug 2026 – Present
Platform: Desktop and iPhone
Research: 4 semi-structured interviews, 3 moderated concept tests
Tools: Figma, Cursor, Claude Code
Team: Solo project

Relay’s track: eight agent lanes on one stadium. Agents check each other’s work at every exchange zone and send work back without a person. Five calls come to your hand in turn: a product call, code that breaks the spec, two agents that disagree, a choice between fixes, and a change that can’t be undone.

Your hand0

Nothing needs you yetAgents are checking each other’s work at every handoff.

A review model for engineers who run many AI agents in parallel. Agents check each other’s work at every handoff, so a person is pulled in only for product calls, conflicts and anything that can’t be undone.

The short version

Agents scale.
A person’s attention doesn’t.

Problem: Engineers hand tasks to coding agents, step away, and come back to code they didn’t watch being written. Checking it means going through what each agent did, one at a time. Some engineers already run several agents at once across branches.
Design question: How might engineers delegate work to AI agents without continuous monitoring?
Key insight: Most agent changes don’t need approval. Another agent can verify them, or someone just needs to know they happened.
What I designed: The concept and the prototype: the track that shows every agent at once, the calls a person answers, and a Lock Screen version for when they step away.
A concept: Relay is a model for how this kind of review could work. It isn’t a shipped product. The prototype shows eight lanes because that’s easy to follow in a demo, and the number isn’t part of the idea.

Research

Engineers check an agent’s work themselves before they trust it.

Research began with semi-structured interviews of four engineers, from a recent intern to senior engineers.

Semi-structured interviews

01
HPC researcher
Wanted to know what the agent had done, and why it chose that implementation.
02
Senior Android engineer
Trusted a fix only after a failed first attempt, more logs, a revised fix and a test on a device, then peer review.
03
Senior frontend engineer
Saw an agent meet the latest request while breaking an earlier one, and fixed it by restating every requirement together.
04
Recent intern
An unstated constraint sent the agent to the wrong cloud platform. No option it offered was right.

Research setup

Method	Participants
Semi-structured interviews	4 engineers, from a recent intern to senior engineers
Moderated concept test, version one	Staff engineer
Moderated concept test, version two	Industry research engineer
Moderated concept test, version three	Process validation engineer in a regulated industry, outside software

Iterations

It started as a review tool for one agent.

Each version went to an engineer in a moderated concept test, and the next one was rebuilt around what didn’t hold up.

Version one

The spec is the contract.

Review opened on the written requirements and asked the engineer to link each one to evidence.

Version one: a code editor where the review opens on spec checkout-retry 3.2 as the contract.

Concept test of version one with a staff engineer

Most work starts as a casual request, and a formal spec is rare. A new database table is something to know about, with nothing to approve.

Important behavior changes and missed edge cases should be called out too.

Design responseVersion two starts from the engineer’s own ask and separates awareness from approval.

Version two

Start from the engineer’s own ask.

The review opens on the request the engineer typed, what the agent finished, and what it’s unsure about, sorted into confirm or judge.

Version two: guided review beside the code, starting from the engineer's original request.

Turning point

Concept test of version two with an industry research engineer

Runs several agents at once on different tasks, across branches.

The team already checks agent output with integration tests, a separate agent review and code-owner approval.

Design responseA review built for one agent at a time can’t hold that. Version three treats many agents across many branches as the normal case.

Version three

Many agents, one track.

The same review model for many agents: lanes for awareness, batons for decisions, and agents that check each other before a person is asked.

Version three: eight lanes on one track with decisions waiting in the person's hand.

Concept test of version three with a process validation engineer

The track didn’t explain itself at first glance. Once walked through, the asks were specific: trace every conclusion to its source, and show what a decision will affect before it’s made.

Team review and compliance sign-off came up too.

Design responseThe next test runs without me, so the track has to explain itself. Tracing each change to its decision, and previewing what an answer will touch, are both in the prototype now.

The decision model

Agents settle what they can verify.
People decide what needs judgment.

Every prompt runs as a lane, and its agents pass the work along like a relay: plan, build, test, review, land. Each handoff is a check, and the model decides who acts on what the check finds.

Agents settle it

The check passes, or the next agent sends the work back and it returns fixed. The lane keeps moving, and the track marks where each check happened.

The Test agent sends the Safari autofill fix back once. The Build agent adds the missing postal code field.

You’re told

Changes worth knowing that don’t need sign-off. They collect under Worth knowing and never interrupt.

A lane adds a decline_events table behind a flag.

You decide

Product calls, disagreements and anything that can’t be undone. Each arrives as a baton that says why it needs you.

What should customers see when the bank flags fraud?

1Plan agentBuild agentTest agentReview agentLand

One lane mid-run. The first check passed, the second sent the build back and it returned fixed, and the review agent is now holding a decision for a person.

Every decision that reaches you says why it needs you.

Every decision in the prototype comes with one of these reasons, and each reason keeps its color on the track, in your hand and in the log.

Where it comes fromThe Plan agent raises it before any code is written, because Lane 4 can’t translate a message that doesn’t exist yet.

Play it

Play a full run.

A full run on the checkout code of an online store, from the first prompt to the last merge. The agents are simulated. Press ? inside to see every key.

Jump to a moment

Design decisions

Ask a person rarely.
Make every ask easy to answer well.

Part 1

Part 2

Make every ask easy to answer well

When agents disagree, show evidence before a recommendation.
Compare fixes by what the customer sees.
Make the irreversible slow, and everything else undoable.
Let people answer in their own words, and read the answer back.
Route decisions and landed work by who owns them.

Part 1Ask a person rarely

Decision 1

Split awareness from approval.

When many agents change code at once, what does a person need to see?

Turned downAn approval inbox

ChosenBatons for decisions, Worth knowing for the rest

From agents

Waiting for the next update

Your hand0

Nothing needs you yet.

Eight agents report as they work. Relay sorts every update before it reaches you.

What I chose: Only decisions wait for you. Everything else goes under Worth knowing, which never asks for a sign-off: a new table behind a flag, or a fix one agent sent back to another.
What I turned down: One inbox where every update asks for approval. Approving becomes the job, and the real decisions get lost in it.
Why: Approval is the costly part of a person’s attention, so Relay spends it only where judgment is needed.Staff engineer, concept testA new database table is something to know about. Some structural changes are simply correct.See it in the research

Decision 2

Let agents check each other first.

Who should catch an agent’s mistake: a person, or the next agent?

Turned downA prompt after every step

ChosenA check at every handoff

Safari address autofill Plan agent workingrelay/safari-autofill

3DS timeout retry Plan agent workingrelay/3ds-retry

Decline analytics Plan agent workingrelay/decline-analytics

0 handoff checks0 sent back and fixed by agents0 sent to you

Three lanes start at Plan. Every handoff is a check by the agent receiving the work.

What I chose: Every handoff is a check. The receiving agent reviews the last one’s work before it starts, then passes it on, sends it back or hands the decision to a person. The track shows where each problem was caught.
What I turned down: A person asked after every step, which interrupts all day. Or agents that run unchecked, which hides mistakes until review.
Why: Agents already review each other on real teams. Relay puts that review at every handoff and shows where it caught something.Industry research engineer, concept testThe team checks agent output with integration tests, a separate agent review and code-owner approval.See it in the research

Decision 3

Sort decisions by what they unblock.

Several decisions are waiting. Which one comes first?

Turned downNewest first

ChosenThe answer that frees the most lanes first

Your hand3

DecideLane 112 min ago

What should customers see when the bank flags fraud?

InvestigateLane 67 min ago

Test agent and Review agent disagree about the flaky test.

CorrectLane 22 min ago

The code retries 3DS five times. Spec 3.2 allows two.

Newest first, the call that would free the most work sits at the bottom.

What I chose: Your hand puts first the answer that frees the most lanes. Lane 1’s fraud message leads, because Lane 4 is waiting to translate it.
What I turned down: Newest first, or by lane number. The call that frees the most work can end up last, and the person has to work out what depends on what.
Why: At this scale, each minute a person gives should restart as many agents as possible.Industry research engineer, concept testBuilding features across branches can mean several agents on different tasks at once.See it in the research

Part 2Make every ask easy to answer well

Decision 4

When agents disagree, show evidence before a recommendation.

The Test agent says the flaky test is timing. The Review agent says it’s a race. Who’s right?

Turned downA vote with a confidence score

ChosenEvidence first, then a recommendation

InvestigateLane 6Waiting 4 min

Test agent and Review agent disagree about the flaky test.

Relay won’t recommend a side while its own agents disagree. Check first, or decide.

Test agent

It’s timing. With one retry, 10 of 10 runs pass.

Review agent

It’s a race. The order total can change after Pay is pressed.

Relay suggests a check before anyone decides.

1Fix the raceSide with Review agent. Build agent locks the total while paying.

2Keep the retrySide with Test agent. Review agent logs the race as a known risk.

Relay doesn’t take a side yet.

What I chose: Relay holds back its recommendation and offers a way to check: run the test 20 times without the retry. Three failures point to the race, and only then does Relay recommend a side.
What I turned down: A majority vote with a confidence score. It hides that the agents disagree, and it doesn’t tell the person what to check.
Why: People trust a fix they have watched fail and then pass, so Relay asks for a run before it takes a side.Senior Android engineer, interviewTrusted a fix only after a failed first attempt, more logs, a revised fix and a test on a device, then peer review.See it in the research

Decision 5

Compare fixes by what the customer sees.

German text overflows the payment panel, and three fixes work. How do you choose without reading three diffs?

Turned downThree diffs side by side

ChosenForks rendered the way they’d ship

Lane 4, three forks in German

German overflows the payment panel. Pick a fix.

Phone width390 px

AShorter copy

Zahlung49,00 €

•••• 4242

Karte abgelehnt. Andere Karte nutzen.

49,00 € bezahlen

All checks pass

locales/de/checkout.json+1 −1

− "decline.generic": "Ihre Karte wur…

+ "decline.generic": "Karte abgelehn…

BWrap to two lines

Zahlung49,00 €

•••• 4242

Ihre Karte wurde abgelehnt. Versuchen Sie es mit einer anderen Karte.

49,00 € bezahlen

Panel grows on small phones

decline-message.css+2 −1

− white-space: nowrap;

+ white-space: normal;

+ min-height: 2lh;

CCut off, full text on hover

Zahlung49,00 €

•••• 4242

Ihre Karte wurde abgelehnt. Versuchen Sie es mit einer anderen Karte.

49,00 € bezahlen

Hides most of the message

DeclineMessage.tsx+2

+ style={{ textOverflow: "ellipsis" }}

+ title={message}

Test agent caught German overflowing the payment panel, and Build agent tried three fixes, each on its own branch.

What I chose: Forks side by side, each rendered as it would ship, with its test result and the code it takes. Picking one closes the others.
What I turned down: Three diffs next to each other. Engineers can read them, but the difference that matters here is how each one looks.
Why: A behavior change should show up where you can see it, so nobody has to find it in the code.Staff engineer, concept testWanted important behavior changes and missed edge cases called out.See it in the research

Decision 6

Make the irreversible slow, and everything else undoable.

How do you keep a person fast without letting them make a mistake they can’t take back?

Turned downThe same dialog on every answer

ChosenAn undo tray, and hold to confirm

ConfirmLane 7Waiting 4 min

Landing drops the coupons_legacy table. It can’t be undone.

Review agent checked that no code reads it and that the backup restores.

Tablecoupons_legacy

Rows18,204

Last read94 days ago

BackupSaved 09:52, kept 30 days

Answers wait here for three seconds before they reach the lane.

Lane 7’s change can’t be undone, so the card says that before anything else.

What I chose: Every answer waits three seconds in an undo tray before it reaches its lane. Anything irreversible, like dropping a table, needs a press and hold, can’t be switched off in the rules and comes with a reversible alternative.
What I turned down: The same confirmation dialog on every answer, which trains people to click through. A dropped table would look exactly like a copy change.
Why: Undo covers almost every answer, so the interface slows a person down only where undo can’t help.Process validation engineer, concept testAsked to see what a decision will affect before it’s made.See it in the research

Decision 7

Let people answer in their own words, and read the answer back.

The options come from the agent. What if the right answer isn’t one of them?

Turned downA text box straight to the lane

ChosenYour words, read back before they ship

DecideLane 1Unblocks 2 lanes

What should customers see when the bank flags fraud?

1“Your card was declined. Try another card or contact your bank.”Recommended

2“We couldn’t verify this payment. Contact your bank.”

3Ask Maya, product manager

The receiving agent reads your answer back before it reaches the lane.

When no option is right, the field takes your own words.

What I chose: Every decision has a field for your own words. Before anything reaches the lane, the receiving agent says how it read them: as an option, as the answer itself, or as a teammate to ask. It checks them like any handoff, so a message that hints at fraud is flagged against spec 3.2 before it ships.
What I turned down: Options only, which makes the person a picker of the agent’s ideas. Or a text box that goes straight to the lane, where a misread answer only shows up in review.
Why: Engineers correct agents in their own words, and a read-back catches a misread answer before it reaches the code.Senior frontend engineer, interviewSaw an agent meet the latest request while breaking an earlier one, and fixed it by restating every requirement together.See it in the research

Decision 8

Route decisions and landed work by who owns them.

Agents’ work lands on a team. Who should see what, and how does their answer get back?

Turned downEvery pull request to every teammate

ChosenRouted by who owns the code

Choose a person to see what reached them and what came back.

Each item goes only to the person who owns that code or copy.

What I chose: Ownership decides. Type @ and the owner comes first: Maya gets Lane 1’s question with its options, the lane waits for her, and her answer goes straight back to it. The lanes that touch Priya’s payments code reach her as one review, and an agent answers her question with the test run. Leo hears that customers will see a new message, and his request comes back to you.
What I turned down: Every teammate gets every pull request, one review per agent. Or questions get forwarded in chat, where they lose their options and the lane never hears the answer.
Why: A reviewer runs out of attention the same way you do, so each person gets only the changes they own, in one review, with the test run attached.Industry research engineer, concept testCode-owner approval is already a step in the team’s workflow.See it in the research

Designing the agents’ behavior

When an agent acts alone, and when it asks.

In an AI product, much of the design is policy: what an agent may settle alone, and what it must hand to a person. Relay shows that policy, and the person can change it.

At a handoff	What happens	Why
Agents agree and nothing is irreversible	Keep running. It shows up under Worth knowing.	Nothing here needs a person’s judgment.
Code and spec disagree	A Correct decision comes to you.	The spec is a promise to the product team.
A product call is open	A Decide decision. Answer it, write your own, or pass it to its owner.	A passing test can’t make a product call.
Agents disagree	An Investigate decision, with evidence before any recommendation.	Relay won’t take a side its own agents dispute.
More than one fix works	A Pick decision, unless you’ve made it a rule.	Rules come from people’s answers, never from agents alone.
Something can’t be undone	A Confirm decision, every time, press and hold.	A guardrail no rule can switch off.
Code someone owns is ready to land	Its owner reviews it first, with related lanes in one review.	Owners know what their code must not break.
A landed change affects someone	They’re told, and what they ask comes back to you.	The people a change reaches can prepare before customers notice.

The switches for when agents must pass a person the decision.

Rules you set before the run

Switch a handoff off and agents settle it themselves, then tell you under Worth knowing. Irreversible changes stay locked on.

A Pick decision offering to answer and make it a rule.

Rules it learns from you

Answer the same way twice and Relay offers to make it a rule. Japanese is then handled for you, in this run and the next. Any rule can be removed.

An Investigate decision: lanes 1 and 3 pass alone but fail together.

Checks no single agent can do

The Land agent tests every lane with what’s already on main. Two lanes that pass alone can fail together, and that’s a call for a person.

Craft

One metaphor, carried through every screen.

The relay gives each part of the review a place people already understand: who holds the work, where it changes hands, and where it ends. A glance at the track should show what’s moving and what’s waiting on you.

Lane numbers
Painted on a blue start strip, like a real track. One lane per prompt.
A decision waiting
The agent stops and raises a baton in the color of its reason.
Exchange zones
Where the next agent checks the last one: a check, a return arrow, or your call.
Finish line
Landing tests each lane together with main before it merges.
Two keys
Test and Review agents both sign off. Any new change resets both.

Decide
Correct
Pick
Investigate
Confirm

Color tells you why

A baton’s color is the reason a person is needed, and it never means anything else.

Handoffs you can see

A baton flies to your hand when an agent needs you, and back to its lane when you answer, so every handoff can be followed by eye.

JK: Move between decisions
123: Answer
↵: Take the recommended answer
Z: Undo before it reaches the lane
E: Gather evidence
C: Compare forks
R: Make it a rule
/: Answer in your own words
@: Ask a teammate
O: Zoom into a lane

Every decision, one key away

Engineers live on the keyboard, so every decision can be answered without the mouse.

Zoom from the whole run to a single line.

Click any lane to see its relay log: what each agent did, what the next one checked, where you stepped in, the two keys and the exact lines that changed, each tied to the spec it answers to.

Lane 1 zoomed in: relay log, two keys and the diff tied to spec 3.2.

How it’s built

Agent behavior, written as data.

The run is a script: each lane’s prompt, each agent’s steps, and the decisions whose answers rewrite what happens next. Choose the verification message and the German string, the diff and the next decision change with it. A small engine plays the lanes in real time.

The rule that holds back a recommendation while agents disagree is one of those lines, shown here.

Built with Claude Code the same day as the concept boards, and imported into Figma as a code layer beside them. Deep links open any moment, which is how this page drops you into a single decision.

scenario.ts, the flaky test decision

flaky: {
  kind: 'investigate',
  by: 'review',
  title: () => 'Test agent and Review agent disagree about the flaky test.',
  claims: [
    { by: 'test', text: 'It’s timing. With one retry, 10 of 10 runs pass.' },
    { by: 'review', text: 'It’s a race. The total can change after Pay is pressed.' },
  ],
  evidence: { label: 'Run it 20 times without the retry', runs: 20 },
  // No recommendation until the evidence is in.
  recommend: (_c, b) => (b.evidence === 'done' ? 0 : -1),
  options: () => [
    { label: 'Fix the race', side: 'review', then: [back(3, 1, 'review'), …] },
    { label: 'Keep the retry', side: 'test', then: [fyi('raceRisk'), …] },
  ],
}

Measuring success

How I’ll know it works.

Every handoff ends with agents settling it, a person being told, or a person being asked. That makes the handoff rules a classifier, and a classifier can fail either way: asking a person who didn’t need to be asked, or settling something a person should have seen. Precision measures the first, recall the second.

Precision: Calls that needed youOf the decisions Relay hands a person, the share they agree needed them, judged after the run. When it drops, people start answering without reading.
Recall: Problems that reached mainProblems that landed without anyone being asked: a spec broken, a table dropped, a message that leaks a fraud signal. On anything that can’t be undone, the target is zero.
Trust: Answers made with the evidence openHow often people open the evidence before taking a recommended answer. It’s the earliest sign of rubber-stamping, long before a bad merge.
Learning: Rules that holdLearned rules still in place a month later. A rule people keep reversing was learned from the wrong answer, and Relay should stop offering it.

The next test

Can an engineer run a full relay without me in the room, and catch what matters?

How: Five or six engineers run the same scenario twice: once in Relay, once with today’s diffs and chat. The scenario plants a false success message and a retry limit that breaks the spec. Sessions are unmoderated and recorded.
Success looks like: More engineers catch both planted problems in Relay, make the calls that need them, and can explain why each lane landed.
What I’ll watch: Where people hesitate before answering, and what they type when none of the options fits.

Where it goes next

Let agents earn more room,
and show proof for every step.

Autonomy that’s earned: Handoff rules are switches today. Next, Relay proposes them from track record: when agents settle a kind of call the way a person would have, run after run, it offers to stop asking. When something it settled gets reverted, it starts asking again.GuardrailIt can suggest more autonomy. It never takes it.
Checks that fail differently: Two agents built on the same model can miss the same bug. For changes that are hard to undo, Relay sends the check to a different model or a different method, like replaying production traffic, and shows which one caught what.GuardrailHeavier checks cost time, so only riskier lanes get them.
A record behind every line: Click any landed line to see the decision that shaped it: who made it, what they saw and what the agents checked. Before answering, see which lanes and files the answer will touch. A process validation engineer asked for both, and a regulated team can’t sign off without them.GuardrailEvery link points to the source.

Enter passcode

RelayDelegate to many coding agents. Decide only what needs your judgment.

Agents scale.A person’s attention doesn’t.

Engineers check an agent’s work themselves before they trust it.

It started as a review tool for one agent.

The spec is the contract.

Start from the engineer’s own ask.

Many agents, one track.

Agents settle what they can verify.People decide what needs judgment.

Agents settle it

You’re told

You decide

Every decision that reaches you says why it needs you.

Play a full run.

Ask a person rarely.Make every ask easy to answer well.

Ask a person rarely

Make every ask easy to answer well

Part 1Ask a person rarely

Split awareness from approval.

Let agents check each other first.

Sort decisions by what they unblock.

Part 2Make every ask easy to answer well

When agents disagree, show evidence before a recommendation.

Compare fixes by what the customer sees.

Make the irreversible slow, and everything else undoable.

Let people answer in their own words, and read the answer back.

Route decisions and landed work by who owns them.

When an agent acts alone, and when it asks.

Rules you set before the run

Rules it learns from you

Checks no single agent can do

One metaphor, carried through every screen.

Color tells you why

Handoffs you can see

Every decision, one key away

Zoom from the whole run to a single line.

Agent behavior, written as data.

How I’ll know it works.

Can an engineer run a full relay without me in the room, and catch what matters?

Let agents earn more room,and show proof for every step.

Agents scale.
A person’s attention doesn’t.

Agents settle what they can verify.
People decide what needs judgment.

Ask a person rarely.
Make every ask easy to answer well.

Let agents earn more room,
and show proof for every step.