Running one AI agent on an underspecified task produces one bad output. Running five parallel agents on the same underspecified task produces five bad outputs simultaneously, each confidently wrong in a different direction. This is not a model problem. It's a preparation problem — and it's forcing a new category of skill.
A paper published on arXiv in May 2026 gave this skill a name: context fluency. The authors tested a three-phase preparation methodology — which they named "mise en place," borrowed from the French culinary tradition of pre-arranging every ingredient before cooking begins — in a competitive hackathon setting. About two hours of deliberate preparation preceded the parallel implementation, by multiple concurrent AI agents, of a full-stack educational platform.
The preparation isn't what you probably imagine. It's not writing better prompts. It's translating what you already know about your codebase — the why behind the patterns, the constraints that aren't written down anywhere, the architectural decisions made two years ago that nobody mentions but everyone respects — into a form that machines can actually act on.
What's Wrong With How Most People Start Agent Tasks
The default agentic workflow in 2026 looks like this: describe a task, fire an agent, review the output when it finishes. Sometimes it works. More often, for anything complex, it goes wrong somewhere in the middle because the agent made an assumption you didn't anticipate.
For a single agent, this is annoying. You correct the brief and re-run. For parallel agents — where you're executing multiple workstreams simultaneously — the same underspecification creates multiplied problems. Each agent makes its own assumptions about the shared parts of your system. When the outputs come back, they've gone in different directions. Reconciling them is more work than starting over would have been.
The mise en place paper names the root cause clearly: vibe coding — their term for the dominant pattern of prioritizing speed of implementation over deliberate preparation. Agents lacking sufficient context produce code requiring extensive debugging and refactoring, not because the model is bad, but because no model can recover the tacit knowledge that wasn't given to it.
The Three Phases Before Any Agent Touches Code
The methodology proposes three preparation phases, none of which involve writing actual code.
Contextual grounding is the most time-consuming and the most undervalued. You're externalizing domain expertise that lives in your head — or distributed across the heads of a team — into structured documents an agent can read and act on. Not API documentation (the agent can probably find that). The implicit knowledge: why this service owns this concern and not that one, what an early architectural decision ruled out that you're still working around, which patterns in the codebase are intentional constraints and which are historical accidents.
This is qualitatively different from writing a spec. A spec says what to build. Contextual grounding says why the codebase is the way it is, which is the information that determines whether an agent's implementation will fit the system or need to be pulled out.
Collaborative specification is a dialogue with an agent to produce design artifacts before any implementation happens. You use an agent's synthesis capabilities to stress-test your brief and surface the cases you haven't thought through — not to generate code, but to generate questions. What does success look like here? What's ambiguous in this description? What would an agent need to know to implement this correctly that isn't in this document?
The output is a specification detailed enough that multiple agents can implement different parts independently and have their work remain coherent.
Task decomposition converts the specification into structured, dependency-aware records — what can run in parallel, what must run sequentially, what each agent needs to see to do its part. This is the infrastructure that makes parallel execution actually parallel rather than sequentially constrained by shared state.
Two hours of this in the hackathon. Then the agents ran.
Why Tacit Knowledge Is the Actual Problem
There's a reason senior developers have an outsized advantage in agentic workflows that has nothing to do with their ability to review agent outputs.
Senior developers carry enormous implicit codebase knowledge — years of accumulated understanding about why things are the way they are, what approaches were tried and abandoned, what the team's actual quality bar is versus what's written in the style guide. This knowledge shapes every decision they make during implementation. It's invisible, unwritten, and essential.
AI agents read files. They're excellent at synthesizing what's explicitly present in a codebase. They're completely blind to what isn't there: the decision not to use a particular pattern, the constraint that comes from a third-party integration whose docs aren't in the repo, the performance characteristic that was discovered in production and shaped the current architecture.
When a senior developer runs an agent on a task, they're typically providing this context implicitly through how they frame the prompt. "Implicitly" is the problem. Implicit context doesn't distribute across five parallel agents. It doesn't persist between sessions. It's in your head, and heads don't scale.
Context fluency is the practice of making this implicit knowledge explicit in a machine-legible form. Not "document your architecture" in a general sense — but specifically: what would an agent that had never seen this codebase before need to know to implement this correctly? What's in your head that isn't in any file?
The Preparation Time Problem
There's a practical obstacle. Preparation time is invisible in most productivity metrics.
WakaTime tracks time in your editor. GitHub tracks commits. Code review tools track PR cycle time. None of them track the two hours of contextual grounding and collaborative specification work that determines whether the subsequent agent run produces mergeable output or requires three correction cycles.
From a measurement perspective, effective agentic preparation looks identical to not working. You're not in your editor. You're not pushing commits. You're writing documents that describe your codebase to machines.
This is one reason developers underinvest in it. When you track productivity by editor time and commit frequency, preparation is a cost center with no corresponding credit. The agent run that succeeds in one pass looks like fast output. The two hours that made it possible look like admin work.
At xeve we track at the application level — which apps you're in, for how long, and when. A developer who spends time in a notes app or a document editor before running agents will show that time in their data. It doesn't disappear into a measurement gap. Whether they're externalizing tacit knowledge or writing something unrelated: that's a question only they can answer. But the time is visible. The developers I've seen get consistently good results from parallel agent runs treat preparation as a first-class work category. They budget time for it explicitly. They notice whether the time they spend preparing correlates with fewer correction cycles afterward.
What Gets Better When You Actually Prepare
The hackathon test is a single data point in a compressed environment, so I'm cautious about over-indexing on specific numbers. But the shape of the result is consistent with what developers report anecdotally: parallel agent runs preceded by careful preparation produce output that coheres. Parallel runs that skip preparation produce output that requires reconciliation.
The mise en place paper frames context fluency as an emerging professional skill, comparable to knowing how to write clear requirements or structure a complex PR. That framing seems right. We're early in figuring out what professional discipline around agentic workflows looks like. The developers building it now — treating preparation as real work, measuring their own context quality, iterating on how they externalize what they know — are ahead in a way that compounds.
The culinary comparison is more apt than it first seems. A professional kitchen mise en place is not just organization. It's the externalization of expertise into a state that lets multiple people execute in parallel without coordination overhead. Every ingredient in its place, every process thought through before the service begins.
That's the problem of parallel agent orchestration. That's what context fluency is for. The preparation that produces it is invisible to most productivity tools, which is probably why most developers skip it.