We Cancelled RAG at Lunchtime and Un-Cancelled It by Teatime

The short version: At an AI accelerator in Berlin, I coached a Swiss education provider's team through a four-day agentic build. A retrieval architecture was cancelled and reinstated within four hours, three chunking strategies were tried in a single day, and two products briefly lived on one main branch, before everything converged into one deployed system with roughly 150 passing tests on the eve of the CEO demo. The lesson: when a team of humans and AI agents stops converging, the fix is rarely more conversation. Turn ambiguity into an artifact, a spec or an ADR, and let everyone argue with the artifact instead of each other.

On Wednesday morning in Berlin, the team I was coaching had a retrieval architecture. We'd written the decision record, built the first ingestion slice, and opened the pull request. By lunchtime, RAG was dead. A product spec had landed on main describing an assistant with no question-answering feature at all, so we did the disciplined thing: wrote a withdrawal ADR, closed the PR, documented the pivot, and moved on.

By teatime, RAG was back.

Not because anyone flip-flopped. Because the product team clarified what they'd actually meant: the customer picks a topic, an agent researches trusted sources, ingests them, and retrieval grounds everything the assistant builds from that point on. RAG hadn't been cancelled. It had been misfiled. It was never a chatbot feature. It was the grounding engine underneath the whole product.

Total cost of the round trip: two ADRs, one closed pull request, and about four hours.

I want to be honest about what that felt like in the room, because from the outside it looks like churn. Renumbered decision records. A closed PR with real work in it. An architecture that died and resurrected inside a single working day. If you'd walked past our table at the wrong moment you'd have concluded the team didn't know what it was building.

You'd have been half right, and that's the interesting part.

Why do teams stop converging in agentic development?

The four-hour RAG round trip had nothing to do with architecture. This was a team from a Swiss education provider building a genuinely ambitious thing in four days: an assistant that turns a topic or a pile of uploaded documents into a structured, product-neutral curriculum, lets you refine it in natural language, and then projects the result into the systems the business already runs.

Half the team was holding a mental model where retrieval was the point. The other half was holding a mental model where structuring was the point. Both were correct. Neither was complete. And the spec, the thing that's supposed to arbitrate exactly this, was lagging behind both of them.

No amount of talking was flushing that out. I watched several conversations where everyone nodded and nobody converged, because each person heard the other's words through their own model and found them compatible. That's the failure mode of ambiguity: it doesn't feel like disagreement. It feels like agreement.

What flushed it out was the artifact. The moment "no RAG" existed as a written decision record, something concrete that the product side had to read and react to, the real vision surfaced within hours. People will happily talk past each other all week. They will not sign off a document that contradicts what's in their head.

That's the lesson I keep relearning, and it was my main job as a coach that week: turn ambiguity into an artifact. A spec, an ADR, a worksheet with acceptance checks. Anything with edges. Then let the humans and the agents argue with the artifact instead of each other.

And the four-hour turnaround isn't the embarrassing bit of this story. It's the proof the system worked. The wrong belief got written down, became visible, and died on contact with reality before it could cost anything real. I've seen the untreated version of this disease run for six months inside businesses with fifty times the headcount.

Does vibe coding scale to a team?

I've built a fair chunk of my public identity on vibe coding. I've written about being set free by it, and I stand by every word: one person plus capable AI agents, moving on instinct and iterating fast, is the most productive I've been in thirty years of this industry.

Berlin made me say the second half out loud. Vibes scale to one human. They do not scale to a team.

This team arrived with something I'd rarely seen done properly: a boilerplate repo with real governance for AI agents baked in. A rulebook the agents actually read. A playbook with a repeatable feature recipe. Decision records as a first-class habit. One hard invariant that never bent all week: the browser only ever talks to the data layer, and every model call happens inside a durable workflow activity.

That's not bureaucracy. With multiple humans and multiple AI agents committing to the same young repo in parallel, that discipline is the only thing standing between convergence and chaos. The agents generate code faster than any human can review by vibe. The governance is what makes their speed compound instead of collide.

What happens when parallel tracks have no convergence plan?

Two tracks of quality work nearly collided anyway, and this is the friction worth admitting.

While the backend track was building the durable workflow engine, the frontend developer built something genuinely excellent: a polished single-page app with a German-language UI and one of the best test artifacts I've seen at any size of company, a behavioural contract matrix with one row per observable behaviour, each traced back to a requirement. Proper engineering.

Built against a mock backend. Its own throwaway server, its own decision record, an older version of the data model.

So for a stretch of the week, main effectively contained two different products: a real durable-loop backend with no UI, and a beautiful UI wired to scaffolding. Nobody had done anything wrong. Both tracks were moving fast and doing quality work. But parallel tracks without a convergence plan aren't parallel, they're divergent, and the difference only becomes visible when you try to join them.

The data model made the point vividly. Mid-week, the schema evolved to a new five-level structure designed to play nicely with strict structured output from the model. The worker migrated. The frontend renderer didn't. First live run: a React crash on a field that no longer existed. It was root-caused and fixed within hours, and only that quickly because the event log made it obvious which side had emitted what. The rule that came out of it is one I'll be stealing: when a schema is the contract between two agent-built halves, migrate both sides in one commit or don't call it done.

How should you chunk real documents for RAG?

If the ADR whiplash shows what shared understanding looks like, the ingestion pipeline shows what evidence-driven iteration looks like. The team went through three chunking strategies in roughly twenty-four hours, and every one of those pivots was correct.

Version one was the textbook chunker: 1,200 characters with 200 of overlap. The first real customer document, an actual course dossier rather than a friendly demo PDF, shredded it. Module headers stranded at chunk edges. One module split across a page boundary with no bridging overlap. Retrieval quality was never going to survive that.

Version two detected the document's structure with heading patterns and kept one module per chunk. It worked beautifully, for that document. The patterns were artifacts of the demo doc. They'd have failed on the next customer's formatting.

Version three, the one that shipped, handed the problem to the model itself: the LLM reads the document and proposes semantic chunk boundaries as structured JSON, deterministic code materialises and token-caps them, and the plan is persisted so workflow retries stay idempotent. Verified live against the document that broke version one: the split module stayed whole, the fragments got merged.

Three strategies in a day sounds like thrashing. It's the opposite. Every pivot was forced by a real document failing, not by taste. That's the whole method: put real inputs through the system early, believe what breaks, and don't fall in love with version one.

What does a disciplined convergence actually look like?

The week's redemption arrived as a single, enormous, disciplined pull request, and I mean disciplined: it executed the decision records rather than ignoring them.

Everything joined up at once. Ingestion with the LLM-planned chunking feeding a vector store. Hybrid retrieval running semantic and keyword search in parallel, reranked, ending in an explainable scope decision with the full ranked candidate table visible in the UI so a human can see exactly why the system trusted what it trusted. Grounded curriculum structuring producing clean English output from German sources. Projection into the format the business's incumbent system expects. Live research that fetches a university's public course material into session-scoped corpora. And the polished SPA, rewired from its mock onto the real backend with its entire component and test surface intact, which is the proof the parallel track was good work on the wrong contract, not wasted work.

One moment from that convergence deserves its own paragraph. Earlier in the week, one developer had built a grounded question-answering feature to about ninety per cent completion. Good work. Wrong deliverable, once the product vision clarified. Instead of defending it, they let it be demoted and its retrieval pipeline repurposed to ground the structuring step. No ceremony, no sulking, straight back to work. Ego-free reuse under a deadline is the most impressive engineering behaviour I saw all week, and I've just watched a team ship a product in four days.

The other thing worth calling out is what the product refuses to do. Every node in the generated curriculum cites its sources. Unvalidated drafts are marked as drafts. Sensitive topics get flagged for expert sign-off. And when the corpus doesn't contain the answer, the system says so instead of inventing one; we verified that out-of-corpus questions come back with zero citations rather than confident fiction. For an education provider, that honesty is the entire difference between a product and a liability.

What did four days actually prove?

As I write this, the CEO demo is tomorrow morning. Five minutes: one minute of problem, the value proposition, then live.

The system is already running at one stable HTTPS URL, deployed in a Swiss region because the data belongs there, verified end-to-end: topic in, grounded English curriculum tree out, projected into the incumbent system's format. Roughly 150 tests passing across backend and frontend. Four days ago this team had two products on one main branch and an architecture that died and came back inside four hours.

They don't need the demo to go well to have proven the point. The point is already proven.

Two things I'm taking home. Vertical slices with end-to-end verification beat horizontal layers, every single time, and I'll now say that with field evidence rather than conviction. And when a team of humans and AI agents stops converging, the fix is almost never more conversation. Write the decision down. Give the ambiguity edges. Let everyone argue with the artifact.

The artifact doesn't mind.