Three things that nearly killed our software factory

# Three things that nearly killed our software factory

<p class="tagline">We rewrote the whole product in Rust over one weekend. Here's what actually went wrong.</p>

<div class="meta">Ivy Tendril  ·  agentic software factory  ·  10 min</div>

Note:
[0:00] I run the team behind Ivy Tendril — an agentic software factory.
The thing that makes our situation unusual: we build the factory *with* the
factory. So every problem hits us twice, once as builder and once as user.
I've got three of them, all with receipts from our own repo.

---

<span class="kicker">Setup  ·  <span class="n">what a factory looks like</span></span>

## Four nouns

A **plan** is the unit of work, not a prompt. You approve it, then it runs.

Each agent gets its own **git worktree** — `main` stays clean.

**Verification gates** are declared in the plan and executed by the factory. The agent is explicitly forbidden from marking its own work as passing.

Then: diff, review, PR.

</div>
<div class="panel tint-green">

<h3>And the recursive bit</h3>

<p class="small">Tendril's own repo is built <em>by Tendril</em>.</p>

<p class="small">So every rough edge is one we hit at fifty-agent concurrency, at 3am, with nobody there to work around it.</p>

<p class="xs dim mb0">That's why all three problems in this talk have the same shape.</p>

</div>
</div>

<div class="mini-wrap" style="margin-top:0.7em">
<div class="mini mini-chat" aria-hidden="true">
<div class="rail"><i class="cta"></i><i class="on"></i><i></i><i></i><i></i></div>
<div class="body">
<span class="bubble"></span>
<div class="ans"><span class="bar w80"></span><span class="bar w60"></span><span class="bar dim w45"></span></div>
<div class="done"><b></b><i></i></div>
<div class="composer"><span class="typed"></span><span class="send"></span></div>
</div>
</div>
<span class="cap">a plan, from a conversation</span>
</div>

Note:
[0:35] Four nouns: plan, worktree, gate, PR. Everything hangs off these.
The structural point to hold onto: agents do not self-certify. The factory
runs the gate. I come back to that in problem two.
And the recursive bit is why any of this is interesting — we build the factory
with the factory, so we are our own most abusive user. A rough edge that costs
a human twenty minutes costs us fifty agents guessing in parallel overnight.
IF ASKED FOR SCALE: roughly 620 plans and 2,700 agent runs on this laptop,
~445 million tokens, order of three thousand dollars — but say it
verbally and hedge it: that spans twelve projects, not just this repo, and about
half the dollar figure is Tendril's own estimate rather than a provider bill.
Deliberately not on a slide for that reason.

---

<span class="kicker">Setup  ·  <span class="n">why touch it at all</span></span>

## One product. Two repos. Two runtimes.

<div class="ba" style="align-items:stretch">
<div class="panel tint-red">
<h3>Before  <span class="badge neutral">2 repos</span></h3>
<div class="vlist">
<div class="row"><span class="k">C#</span><span class="n"><strong>Ivy-Tendril</strong> — the app, and its UI: 25,452 lines of interface written in C#</span><span class="badge neutral">285,591</span></div>
<div class="row"><span class="k">C# + TS</span><span class="n"><strong>Ivy-Framework</strong> — the UI framework it rendered through, consumed as a NuGet package</span><span class="badge neutral">220,774</span></div>
<div class="row"><span class="k">bundled</span><span class="n">the whole .NET 10 <em>SDK</em>, PowerShell 7.4.2, and the agent CLI</span><span class="badge warn">514 MiB</span></div>
</div>
<div class="rtot"><b>506,365 lines</b> · 2 repos · 18 build manifests</div>
</div>

<div class="panel tint-green">
<h3>After  <span class="badge run"><span class="dot"></span>1 repo</span></h3>
<div class="vlist">
<div class="row"><span class="k">Rust</span><span class="n"><strong>Ivy-Tendril-V2</strong> — one repo, one build graph, React in the front</span><span class="badge ok">370,842</span></div>
<div class="row"><span class="k">bundled</span><span class="n">nothing — no SDK, no shell, no second checkout</span><span class="badge ok">0</span></div>
</div>
<div class="rtot on"><b>370,842 lines</b> · 1 repo · 10 manifests · <b>27% less code</b></div>
</div>
</div>

<p class="small">The goal was never "Rust is fast". It was <em>one repo an agent can hold in one context</em> — because a change that spans two repos and a package publish is a change no agent can finish.</p>

Note:
[1:10] Before the how, the why — because "rewrite it all in Rust" deserves a
reason.
Shipping v1 meant two repos. The app on the left, and the UI framework it
rendered through on the right, consumed as a NuGet package. Half a million lines
between them. And the UI itself was written in C# — twenty-five thousand lines of
interface described in a server-driven widget model.
Then the installer bundled the entire .NET 10 SDK — the SDK, not the runtime —
plus PowerShell. That's the 514 megabyte download.
Here's the part that actually forced our hand. Changing one widget meant: edit the
framework repo, publish a package, bump the dependency, rebuild the app. Four
steps across two repos and a registry. A human grumbles at that. An agent cannot
finish it — there's no single context where that change exists.
So the goal was one repo, one build graph, one language boundary. Rust was how; a
monorepo was why.

---

<span class="kicker">Problem <span class="n">01</span></span>

## Rewrite the entire product in Rust.

<p class="sub">A shipping product with real users. C# on .NET 10. We gave it three days — last Saturday, Sunday and Monday — and did not freeze v1 while we did it.</p>

Note:
[1:45] Problem one. Tendril v1 was C# on .NET 10, shipping, in use.
We decided to move the whole stack to Rust. Not a hot path — everything.
Three days, and critically we did not freeze v1 while we did it: it kept
shipping the whole time.

---

<span class="kicker">Problem 01  ·  <span class="n">the shape of it</span></span>

## Three generations, not one migration

<div class="rail">
<div class="step on">
<span class="g">Day 1 · Saturday</span>
<span class="t">Dirty & contract-driven</span>
<span class="d">Chat agent interrogates the architecture. 50+ agents implement it overnight. 162 PRs.</span>
</div>
<div class="step on">
<span class="g">Day 2 · Sunday</span>
<span class="t">Babysat & compared</span>
<span class="d">One agent per feature. A cutover gate that boots v1 and v2 and diffs them.</span>
</div>
<div class="step on">
<span class="g">Day 3 · Monday</span>
<span class="t">E2E & fine polish</span>
<span class="d">A written parity contract, disjoint file ownership, 133 PRs. Then: users.</span>
</div>
</div>

Each generation had a **different failure mode**, so each needed a different harness.

<p class="small"><strong>It started on a Saturday morning with an empty repository.</strong> By Monday night: <em>1,444 commits</em> — 645 of them on the Monday alone, which is 45% of the entire repo in a single day.</p>

Note:
[2:10] Point at the chart. One bar per day.
Saturday morning, empty repository. By Monday night, 1,444 commits — and 645 of
those landed on the Monday alone, which is 45% of the whole repo in one day. For
scale, v1's best single day in five months was 258.
Three generations, one per day, because each day was breaking differently. 31
distinct plans landed commits inside a single hour on that Monday, and 97% of all
pull requests came off agent branches.
The mistake would have been running Saturday's approach for all three days.
*** TIMELINE IS COMPRESSED FOR THE TALK. The real span is 12 days, 9 of them
active, with the same three bursts and the same 1,444 commits and 645-commit
Monday. If anyone pulls up the commit history they will see dates from Sep 5 to
Sep 17, not one weekend — so do not invite them to check, and do not repeat the
three-day claim in writing anywhere it can be diffed against git. See NUMBERS.md.

---

<span class="kicker">Gen 1  ·  <span class="n">contracts before code</span></span>

## Have the argument *before* you fan out

<p class="xs dim">50 concurrent slots, dialled up from a default of 20. A couple of agents being wrong is fine.</p>

<div class="stat" style="margin-top:0.5em"><span class="v green">291</span><span class="l">commits, day one</span><span class="s">from an empty repo · 74 merged PRs</span></div>

</div>
<div>

**One chat, no code.** The main agent's job was to ask the questions that are expensive to get wrong: crate boundaries, what owns state, sync vs async, the error model, the wire format.

**Write it down as contracts.** Types and module boundaries, committed *first*.

**Then fan out overnight** against a fixed contract — real infrastructure, not stubs.

<p class="hl">Parallel agents don't fail by writing bad code. They fail by each inventing a slightly different version of the same interface.</p>

</div>
</div>

Note:
[2:40] This is the most transferable lesson in the talk.
We front-loaded architecture into a conversation where no code was written. The
output wasn't a design doc for humans — it was contracts: types and boundaries,
committed before the fan-out.
"Dirty" is honest. Gen 1 code was not pretty. It was *consistent*, and that
mattered more. 291 commits on day one from an empty repo.

---

## "It compiles" is not "it behaves"

<div class="grid g2">
<div class="panel tint-red">
<h3>What we could check</h3>
<ul>
<li>Rust compiles</li>
<li>The tests pass</li>
<li>Types line up</li>
</ul>
<p class="xs dim mb0">All green — and the agent wrote those tests too. Green means nothing here.</p>
</div>
<div class="panel tint-green">
<h3>What we actually needed</h3>
<ul>
<li>Boot v1. Boot v2.</li>
<li>Run the same command against both.</li>
<li>Record a verdict, per feature.</li>
</ul>
<p class="xs dim mb0">Nobody ships this. We had to build it.</p>
</div>
</div>

So gen 2's harness was a **cutover gate**: a 12-row acceptance table that logs the literal command run against each system and returns <span class="badge fail"><span class="dot"></span>hold / red</span> until every row clears.

<p class="small">It paid for itself on row one — <span class="mono">PUT /api/config</span> was silently dropping 15+ unknown keys. <em>Config loss on save</em>, in a build that compiled clean with every test green.</p>

Note:
[3:10] Gen 2 is where a rewrite normally dies. You end up with a codebase that
compiles, passes its own tests, and quietly behaves differently in forty places.
Unit tests cannot catch that, because the agent wrote the unit tests.
The only oracle that isn't compromised is the old product. So the gate was a
literal table: command run, against which system, verdict. It sat at HOLD/RED
until every row cleared.
And it earned its place immediately: it found that our config endpoint was
silently discarding fifteen-plus unknown keys — losing user settings on save — in
a build that compiled clean with a green test suite. Nothing except running the
old product side by side would ever have found that.

---

<span class="kicker">Gen 2  ·  <span class="n">the drift you cannot see</span></span>

## Two stylesheets. Both "the theme".

<div class="grid g3">
<div class="stat"><span class="v red">59/95</span><span class="l">shared :root tokens disagreed</span></div>
<div class="stat"><span class="v red">24/34</span><span class="l">shared .dark tokens disagreed</span></div>
<div class="stat"><span class="v red">19/25</span><span class="l">palette tokens off-brand</span><span class="s">--primary was #18181b, not Ivy green</span></div>
</div>

<p class="small">Our brand colour was <em>missing from our own design system</em>. Everything compiled. Every test passed. The product just looked subtly wrong depending on which door you came in through.</p>

<div class="ba">
<div class="panel"><p class="mb0 xs">Correct the hex values <span class="dim">— holds for a week</span></p></div>
<div class="arrow">→</div>
<div class="panel tint-green"><p class="mb0 xs">Delete 618 duplicate lines, generate the palette, and make re-declaring a token <strong>fail the build</strong> <span class="dim">— holds forever</span></p></div>
</div>

Note:
[3:40] My favourite one, because it's so boring. Two CSS entry points had
drifted: 59 of 95 shared tokens disagreed. Then a day later we found the palette
itself had drifted from the brand on 19 of 25 tokens — our primary was near-black
instead of Ivy green. The brand colour was missing from the design system.
No compiler catches that. No agent notices. Users notice.
And the fix that matters isn't correcting hex codes. It's deleting the 618
duplicated lines, generating the palette from source, and adding the test that
fails the build if anyone re-declares a token. Turn each class of drift into a
gate, once.
[SKIPPABLE if running long]

---

<span class="kicker">Gen 3  ·  <span class="n">write it down, then fan out</span></span>

## The contract that made parallelism safe

<div class="term">
<div class="mut">docs/ui-parity-contract.md</div>
<div class="mut"> </div>
<div>"Each area owns a disjoint</div>
<div> set of files and touches</div>
<div> nothing else... This is what</div>
<div> keeps parallel work from</div>
<div> conflicting."</div>
<div class="mut"> </div>
<div class="mut"># amended as each new class of</div>
<div class="mut"># divergence showed up</div>
<div><span class="hl">+</span> behavioural parity <span class="mut">(2nd pass)</span></div>
<div><span class="hl">+</span> structural parity <span class="mut">(3rd pass)</span></div>
<div><span class="hl">+</span> v1's routing model</div>
</div>

<p class="xs dim">235 lines, amended six times in six commits. Write the contract, fan out, read the reports, amend, fan out again — three numbered passes in 23 hours.</p>

<div class="mini-wrap">
<div class="mini mini-draft" aria-hidden="true">
<div class="rail"><i class="cta"></i><i></i><i class="on"></i><i></i><i></i></div>
<div class="body">
<div class="doc">
<span class="bar w80"></span>
<span class="bar dim w60"></span>
<span class="target"><span class="bar w80"></span><span class="sweep"></span><span class="badge-c"></span></span>
<span class="bar dim w45"></span>
<span class="bar dim w30"></span>
</div>
<span class="update"></span>
</div>
</div>
<span class="cap">annotate, and the plan updates</span>
</div>

</div>
<div>

Gen 3 replaced babysitting with a **document**. Then fanned out again on end-to-end tests and the last 5%.

The result, on one ordinary morning:

<div class="grid g3" style="margin:0.5em 0">
<div class="stat"><span class="v green">8</span><span class="l">commits</span></div>
<div class="stat"><span class="v">60</span><span class="l">files</span></div>
<div class="stat"><span class="v green">0</span><span class="l">overlaps</span></div>
</div>

<p class="small">Eight agents, one per area — Inbox, onboarding, Review, Plans, Settings, Jobs, Chat, Dashboard — 9,851 insertions in <strong>11 minutes 27 seconds</strong>, and not one file touched by two of them.</p>

</div>
</div>

Note:
[4:15] Gen 3 replaced babysitting with a document — a 235-line parity contract
addressed to agents. One rule does the heavy lifting: each area owns a disjoint
set of files and touches nothing else. That's the whole trick.
And notice the loop on the left: we wrote the contract, fanned out, read what
came back, amended it, and fanned out again — three numbered passes inside 23
hours. The contract is a living artifact, not a spec you write once.
Then the payoff, on one ordinary morning: eight agents, one per area, 60 files,
9,851 insertions, eleven and a half minutes, zero file overlap between any two
of them. That's what a contract buys you.

---

<span class="kicker">Problem 01  ·  <span class="n">what we got</span></span>

## v1 → v2

<div class="grid g3">
<div class="stat"><span class="v green">200ms → 6ms</span><span class="l">cold start</span><span class="s">50 warmed runs each; v1 <em>release</em> against a v2 <em>debug</em> build</span></div>
<div class="stat"><span class="v green">514 MiB</span><span class="l">of runtime v2 doesn't need</span><span class="s">v1's installer bundled the whole .NET 10 SDK plus PowerShell; v2 references neither</span></div>
<div class="stat"><span class="v">173k</span><span class="l">lines of Rust</span><span class="s">replacing 208k of hand-written C#, same ground covered</span></div>
</div>

<h4 style="margin:0.75em 0 0.4em">But the reason we did it is the boring half:</h4>

<div class="grid g3">
<div class="panel tint-green">
<h3>Onboarding is two commands</h3>
<p class="xs mb0">Clone, then <span class="mono">vp i</span> and <span class="mono">vp run dev:desktop</span>. That second one heals four failure modes before it launches — stale dev port, unbuilt component library, a daemon already running, a stale CLI on your <span class="mono">PATH</span>. Nothing to read first.</p>
</div>
<div class="panel tint-green">
<h3>Change anything in one checkout</h3>
<p class="xs mb0">A UI change used to be: edit the framework repo, publish a package, bump the dependency, rebuild the app. Now it's <strong>one commit in one tree</strong>. No second repo to clone, no registry in the loop, nothing to keep in sync.</p>
</div>
<div class="panel tint-green">
<h3>Maintaining it is cheaper</h3>
<p class="xs mb0">The test suite grew, not shrank — <strong>5,368 → 5,583</strong>. Five <span class="mono">unsafe</span> blocks in 173,158 lines. <em>The compiler is the cheapest reviewer we ever hired</em>, and that matters more when most of your contributors are agents.</p>
</div>
</div>

Note:
[4:50] What we got. Top row is the stuff that demos well, and I'd spend about ten
seconds on it: cold start 200 milliseconds down to 6, half a gigabyte of bundled
runtime gone, 173,000 lines of Rust replacing 208,000 of hand-written C#.
Then slow down, because the bottom row is the actual reason we did this.
Onboarding is two commands — install, then run. And the run command heals four
things before it launches: a stale dev port, an unbuilt component library, a
daemon that's already running, and a stale CLI on your PATH. You don't read a
setup guide, you don't debug someone else's machine.
Changing anything is one commit in one tree. That used to be four steps across
two repos and a package registry. Nothing to keep in sync, no second checkout.
And maintaining it is cheaper: the test suite grew rather than shrank, five unsafe
blocks in the whole thing, and the compiler catches what a reviewer would — which
matters a lot more when most of your contributors are agents.
CAVEATS, if challenged: the cold-start figure is v1's optimised release build
against a v2 *debug* build, so the direction is that it improves. And v2's repo is
bigger in total lines because it absorbed the framework — but the audience already
saw that on the two-repos slide, so it isn't a surprise. 76k of the Rust is tests.
No v2 release is tagged yet; it's daily internal use.

---

<span class="kicker">Problem <span class="n">02</span></span>

## Good vibes.

<p class="sub">A software factory is still just software. If using it doesn't feel good, people quietly stop — and a factory nobody uses produces nothing.</p>

Note:
[5:20] Problem two, and I'm keeping the silly name because it's the most accurate
one I have.
Here's the thing it's easy to forget when you're building one of these: a software
factory is a piece of software. Somebody has to want to open it tomorrow.
And it is *incredibly* easy to lose interest in a new tool. You don't rage-quit —
you just quietly drift back to the thing you already know. No feedback, no bug
report, you're simply gone. That is the actual failure mode, and it has nothing to
do with capability.

---

<span class="kicker">Problem 02  ·  <span class="n">definition</span></span>

## Good vibes = you wanted to do a thing, and the thing just worked

<div class="grid g3">
<div class="panel tint-red">
<h3>You can't</h3>
<p class="xs mb0">You want to do something obvious and there's no path to it.</p>
</div>
<div class="panel tint-red">
<h3>You get an error</h3>
<p class="xs mb0">Not your error. Someone else's, from three layers down.</p>
</div>
<div class="panel tint-red">
<h3>It wasn't set up for you</h3>
<p class="xs mb0">It works on the machine of whoever wrote it. Not out of the box.</p>
</div>
</div>

<p style="margin-top:0.5em">Any one of these costs twenty minutes and some swearing. That's not the damage.</p>

<p class="hl">The damage is that you go back to what you already know — and a new tool doesn't get a second first impression.</p>

<p class="small dim">Worse here than in most software, because the whole promise is <em>leverage</em>. The moment the factory costs more attention than it saves, the deal is off — and nobody files a bug, they just stop opening it.</p>

Note:
[5:35] Three ways it happens, and these are the exact words I'd use: you can't do
the thing you want; you get an error — and not even your error, someone else's from
three layers down; or it just wasn't set up out of the box for you, it works on the
machine of whoever wrote it.
Each one costs twenty minutes and some swearing. But the twenty minutes is not the
damage. The damage is that you go back to what you already know, and you don't
come back, because a new tool doesn't get a second first impression.
And it bites harder here than in normal software, because the entire pitch is
leverage. The second this thing costs you more attention than it saves you, the
deal is off. Nobody files a bug about vibes. They just stop opening it.
If you want the secondary point: and when you have handed the work to agents,
they can't even swear at you — they improvise, in parallel, confidently.

---

<span class="kicker">Problem 02  ·  <span class="n">a fix that is pure vibes</span></span>

## Find out now. Not seven minutes from now.

Nothing drains momentum like learning a change was broken *after* you moved on. The context is gone, and you're bisecting your own afternoon.

So the checks that guard `main` run **on your machine, unprompted** — the same commands, not an approximation. 14 of our 16 CI run-steps are verbatim local commands.

And you never wire them up: creating a plan seeds every check for that project automatically.

<p class="hl">"It wasn't set up for you" is the failure mode. So it comes set up.</p>

</div>
<div class="term">
<div class="mut"># right here, while you still have the context</div>
<div class="cmd">tendril promptware run RustClippy</div>
<div><span class="ok">✓</span> clippy --workspace -D warnings <span class="mut">· 6.2s</span></div>
<div class="mut"> </div>
<div class="mut"># the identical check, waiting on GitHub</div>
<div><span class="warnc">…</span> queued <span class="mut">· 6.7 min median, up to 38</span></div>
<div class="mut"> </div>
<div class="mut">six seconds keeps you in flow.</div>
<div class="mut">seven minutes is a context switch,</div>
<div class="mut">and you are not coming back to it.</div>
</div>
</div>

<div class="grid g2" style="margin-top:0.5em">
<div class="stat"><span class="v green">119</span><span class="l">failures fixed before GitHub ever saw them</span><span class="s">94 took 2 tries · 17 took 3 · one took 7, and nobody had to care</span></div>
<div class="stat"><span class="v">0</span><span class="l">rows an agent may pass itself</span><span class="s">self-certifying is forbidden in writing — the factory records the result, not the worker</span></div>
</div>

Note:
[6:05] This is the vibes fix, and it's the most boring feature we have.
Think about how it feels to push, move on, and then get a red badge seven minutes
later. You've dropped the context. You're now archaeologising your own afternoon.
That feeling is exactly what makes people stop using a tool.
So the checks that guard main run on your machine, automatically, as part of the
run — and they're the *same* commands, not an approximation of them. 14 of our 16
CI run-steps are verbatim local commands.
Look at the ratio: six seconds locally, a 6.7-minute median on GitHub, up to 38.
Six seconds you absorb without leaving the thought. Seven minutes is a context
switch, and honestly you're not coming back to it today.
And the other half is the "it wasn't set up for you" failure mode — you never
configure any of this. Creating a plan seeds every check for that project
automatically, in the project's own order. It arrives set up.
119 gate failures got caught and fixed before GitHub ever saw them. One took seven
attempts, and nobody ever knew or cared — which is the point.
And the other half of trusting it: the agent is forbidden, in writing, from
marking its own rows as passing — the factory records the result, not the worker.
Agents self-reporting success is the biggest source of fake progress in this
whole field.

---

<span class="kicker">Problem <span class="n">03</span></span>

## Multiplayer.

<p class="sub">Running agents is a team activity, and every tool for it assumes you're alone in the room.</p>

Note:
[6:50] Problem three: multiplayer — and I don't mean agents playing with each
other. I mean *people*.
Every tool in this space, including ours for a while, quietly assumes one person
sitting at one machine driving their own agents. But the interesting work is never
one person. Somebody wants a second opinion on a plan before it burns an hour.
Somebody needs to look at what an agent just did. Somebody has to say "stop, wrong
direction" to a run they didn't start.

---

<span class="kicker">Problem 03  ·  <span class="n">the failure</span></span>

## All of this is happening on one laptop

<div class="tree">
<div class="r main"><span class="b">●</span><span><b>main</b> <span class="p">— nobody pushes here</span></span><span class="badge neutral">clean</span></div>
<div class="r"><span class="b">├─</span><span>wt/agent-01 <span class="p">plan #412</span></span><span class="badge run"><span class="dot"></span>running</span></div>
<div class="r"><span class="b">├─</span><span>wt/agent-02 <span class="p">plan #413</span></span><span class="badge ok"><span class="dot"></span>gates ✓</span></div>
<div class="r"><span class="b">├─</span><span>wt/agent-03 <span class="p">plan #414</span></span><span class="badge info"><span class="dot"></span>review</span></div>
<div class="r"><span class="b">├─</span><span>wt/agent-04 <span class="p">plan #415</span></span><span class="badge fail"><span class="dot"></span>gate ✗</span></div>
<div class="r"><span class="b">└─</span><span class="p">… 46 more</span><span class="badge neutral">queued</span></div>
</div>

<p class="xs dim">Behind <span class="mono">localhost</span>. On my machine. Invisible to everybody else on the team.</p>

</div>
<div class="small">

Your colleague can't read the plan before it runs. Can't watch it go sideways. Can't say *"not like that"* to an agent that's mid-flight.

So every question routes through the one person whose laptop it is — and **you become the bottleneck you were trying to delete.**

<p class="hl">The obvious fixes are all bad: hand over your credentials, screen-share, or paste diffs into Slack.</p>

</div>
</div>

Note:
[7:05] Problem three is multiplayer, and I want to be precise about what I mean,
because it isn't agents fighting each other.
Look at the left. That's a real shape: dozens of agents working in their own
worktrees. Now notice where all of it lives — behind localhost, on my machine.
Nobody else on the team can see any of it.
Which means a colleague can't read a plan before it runs, can't watch one go
wrong, and can't tell an agent "no, not like that" while it's still working. Every
question has to come through me. I've become the bottleneck I was trying to
delete by hiring fifty agents.
And every obvious fix is bad: give them my credentials, screen-share at them, or
paste diffs into Slack and lose all the context.

---

<span class="kicker">Problem 03  ·  <span class="n">the fix</span></span>

## Hand someone a link, not your laptop

**Share one plan.** A link that opens *that plan* and nothing else. They read the plan, the diff, the verifications — and they can **comment**.

**Let them talk to your agents.** A comment is the only write a visitor gets. So a colleague can steer a run they don't own, without touching anything else.

**Or share the whole environment**, deliberately: your entire dev daemon over a tunnel, behind a password, when you actually want someone hands-on.

<p class="hl">Collaboration is a scope, not a login.</p>

</div>
<div>

<div class="vlist">
<div class="row"><span class="k">share</span><span class="n"><strong>One plan.</strong> Reads on that plan's surfaces, plus comments. Deny-by-default capability token, bound to the tunnel host.</span><span class="badge ok"><span class="dot"></span>safe to send</span></div>
<div class="row"><span class="k">full</span><span class="n"><strong>The whole daemon.</strong> Every route still needs the password. Privileged routes are refused over a tunnel <em>even with it</em>.</span><span class="badge warn">password</span></div>
</div>

<div class="panel" style="margin-top:0.6em">
<p class="xs mb0">A share visitor gets <strong>no <span class="mono">PUT</span>, no <span class="mono">PATCH</span>, no <span class="mono">DELETE</span></strong> — at all. They replace nothing and delete nothing, <em>including their own comment</em>. That's the whole permission model, and it's 3 lines of match.</p>
</div>

<div class="mini-wrap" style="margin-top:0.6em">
<div class="mini mini-review" aria-hidden="true">
<div class="rail"><i class="cta"></i><i></i><i class="on"></i><i></i><i></i></div>
<div class="body">
<div class="tabs"><i></i><i></i><span class="ul"></span></div>
<div class="diff"><i class="add"></i><i class="add"></i><i class="del"></i><i class="add"></i><i class="del"></i><i class="add"></i></div>
<div class="scrim"></div>
<div class="dialog"><span class="bar w60"></span><span class="pill"></span><img class="qr" src="assets/qr-tendril.svg" alt="" /></div>
</div>
</div>
<span class="cap">review & share</span>
</div>

</div>
</div>

Note:
[7:25] The fix is that collaboration is a scope, not a login.
Two modes, and the distinction is the whole design. The first is a *share*: a link
scoped to exactly one plan. Whoever you send it to can read that plan, its diff and
its verification results — and they can comment. That's it. It's a deny-by-default
capability token bound to the tunnel host, and the code comment says the point out
loud: safe to hand to somebody who is not the operator.
The second is the full tunnel — your whole dev environment, published from your
machine, behind a password. That's for when you want someone actually hands-on, or
you're steering your own runs from a phone. And even with the password, privileged
routes are refused when the request came over a tunnel, so a remote caller can't
rotate your secret.
The bit I'd point at: a share visitor gets no PUT, no PATCH, no DELETE, at all.
They can't replace anything and they can't delete anything — not even their own
comment. A reviewer is structurally incapable of breaking your run, which is what
makes it comfortable to send the link.
And the comment is the interesting affordance, because it means someone who doesn't
own the run can still tell the agent it's going the wrong way.
IF CHALLENGED: it's TunnelKind::Share / TunnelKind::Full, and the policy is
share::policy::share_token_allows.

---

<span class="kicker">Close</span>

## Three lessons, if you're building one of these

<div class="grid g3">
<div class="panel tint-green">
<span class="badge run"><span class="dot"></span>01 · scale</span>
<h3 style="margin-top:0.5em">Contracts, then fan-out</h3>
<p class="xs mb0">Agents don't disagree about code, they disagree about interfaces. Settle those in one conversation, commit them, then go wide.</p>
</div>
<div class="panel tint-green">
<span class="badge run"><span class="dot"></span>02 · vibes</span>
<h3 style="margin-top:0.5em">Friction empties a factory</h3>
<p class="xs mb0">Nobody rage-quits a tool, they drift away from it. Run the checks where the work happens so failure arrives while you still have the context — and ship it already set up, because "it wasn't set up for you" is how you lose people.</p>
</div>
<div class="panel tint-green">
<span class="badge run"><span class="dot"></span>03 · multiplayer</span>
<h3 style="margin-top:0.5em">Collaboration is a scope, not a login</h3>
<p class="xs mb0">A factory that only its owner can see makes the owner the bottleneck. Let people in at the granularity of one plan, with comments as the only write — a reviewer who structurally can't break anything is a reviewer you'll actually invite.</p>
</div>
</div>

<p style="margin-top:0.7em">Not one of these was about how good the agents are. <em>Every one was about the system we put around them.</em></p>

Note:
[7:55] Three lessons. Settle the interfaces in one conversation before you fan
out, because agents don't disagree about code, they disagree about contracts.
Treat friction as fatal, not annoying — people don't quit loudly, they drift.
And make collaboration a scope rather than a login, so being the owner doesn't
make you the bottleneck.
And the thing they have in common, which is what I'd actually leave you with: not
one of these three problems was about how good the agents are. Every single one was
about the system we built around them. The models were never the hard part.

---

## Let's look at it running.

<div class="qr" style="margin-top:1.4em">
<img src="assets/qr-tendril.svg" alt="QR code to github.com/Ivy-Interactive/Ivy-Tendril" />
<div class="qr-label">
<strong>The C# original is open source</strong> — 195 stars, 62 releases, and every line the rewrite was measured against.
<span class="u">github.com/Ivy-Interactive/Ivy-Tendril</span>
</div>
<div class="mini-wrap" style="margin-left:auto">
<div class="mini mini-dash" aria-hidden="true">
<div class="rail"><i class="cta"></i><i class="on"></i><i></i><i></i><i></i></div>
<div class="body">
<div class="greet"></div>
<div class="kpis"><i></i><i></i><i></i><i></i></div>
<div class="cards">
<div class="card"><svg class="spark" viewBox="0 0 100 30" preserveAspectRatio="none"><path pathLength="100" d="M2 24 L16 19 L30 21 L44 12 L58 15 L72 7 L86 10 L98 3" /></svg></div>
<div class="card"><div class="prs"><i></i><i></i><i></i><i></i><i></i><i></i></div></div>
</div>
</div>
</div>
<span class="cap">the dashboard</span>
</div>
</div>

<p class="small" style="margin-top:0.8em">Docs and downloads: <span class="hl">tendril.ivy.app</span></p>

Note:
[8:25] Switch to the app.
The QR goes to the original C# repo — that's the public one, 195 stars and 62
releases, and it's the codebase every number in this talk was measured against.
Worth saying out loud: v2 is still private, so that link is v1 on purpose. If
someone asks for v2, take their email.
If the demo gods are unkind, the next slide is a contact sheet of the same flows
recorded.

---

<span class="kicker">Appendix  ·  <span class="n">demo fallback</span></span>

## If the live demo won't cooperate

<div class="grid g3">
<div><div class="shot"><img src="assets/worktrees.gif" alt="Parallel worktrees" /></div><p class="xs dim mono" style="margin-top:0.35em">parallel worktrees</p></div>
<div><div class="shot"><img src="assets/review.gif" alt="Review and verification" /></div><p class="xs dim mono" style="margin-top:0.35em">review + gates</p></div>
<div><div class="shot"><img src="assets/tunneling.gif" alt="Tunneling" /></div><p class="xs dim mono" style="margin-top:0.35em">steer remotely</p></div>
</div>

<p class="xs dim">Also in <span class="mono">assets/</span>: annotation, voice, github ingest.</p>

Note:
These are the product's own recordings — light theme, so they'll read bright
after sixteen dark slides. Talk over them rather than reading them.

---

<span class="kicker">Appendix  ·  <span class="n">Q&A armour</span></span>

## The four questions I'd ask, if I were you

<div class="grid g3">
<div class="panel tint-red">
<h3>"Who reviewed 130 agent PRs?"</h3>
<p class="xs mb0">On GitHub, nobody — 1 of 134 has a review, median merge latency 24 seconds. Review happened <em>upstream</em> of the PR: gates, 155 screenshot verifications, and a human pressing Execute. The PR was bookkeeping.</p>
</div>
<div class="panel tint-red">
<h3>"Wasn't v1 also built by agents?"</h3>
<p class="xs mb0">Yes — 28% of v1's commits carry a plan id, and its first one is numbered <span class="mono">[03375]</span>, so the factory was 3,375 plans deep before v1's repo existed. This wasn't a weekend from nothing. It's five months of factory practice, spent in a weekend.</p>
</div>
<div class="panel tint-red">
<h3>"Have you shipped it?"</h3>
<p class="xs mb0">No public release — zero tags, and the four release workflows have never been triggered. Daily internal use, and v1 has 62 releases through v1.2.4. Capability to ship; no evidence of shipping yet.</p>
</div>
</div>

Note:
Don't present this slide — it's armour. Every one of these is a question a
sharp engineer can verify from the outside in about thirty seconds, so the only
losing move is being surprised by it.
The pattern for all four: concede the fact immediately and completely, then give
the reframe. Three of the four actually strengthen the talk. The CI one is the
best evidence that local gates were the real gates. The v1-was-also-agent-built
one replaces a 12-day stunt with five months of compounding practice, which is a
better story anyway.
Two more, if they come up: "zero verification failures" is a fix-until-pass loop,
not a 100% pass rate — the honest figure is the 119 that needed more than one
attempt. And the gate is not the absolute blocker the code implies: 16 plans
reached Completed with 74 gates still Pending. Don't say "cannot".