1. Deterministic where it must be, probabilistic where it helps
The complaint we hear most often about first-generation agents is that they were built as one brilliant generalist: a single prompt, every tool, all the judgment. The teams furthest along have quietly dismantled that design. One platform we spoke with, whose agents can take actions it cannot undo, replaced its uniform review process with a risk score. Low-risk changes take a fast lane, high-stakes actions route to mandatory human review, and a council of adversarial agents argues over everything in the middle. Another team, at a large-scale fintech company, benchmarks a couple thousand calls across a handful of models with a frontier-model judge, then routes by task difficulty, sending cheap models the easy work and reserving expensive ones for the calls that earn their cost.
Published engineering write-ups describe the same split. Block's automated analytics work is the cleanest example: one flexible natural-language interface could not serve executives who need exact, defensible numbers and analysts who need freedom to explore, so Block split it. The deterministic path cannot modify the governed SQL behind approved metrics. The exploratory path allows natural-language-to-SQL precisely because its stakes are lower. Elsewhere in the same write-up Block reports a backlog of forty analytics tickets closed in about three hours of total human effort, against roughly two hours per ticket before.
The same split shows up at the product layer, not just internal tooling. DoorDash built the identical shape into its own assistant: a single Orchestrator agent routes each customer turn to one of two narrow domain agents, restaurant discovery or grocery shopping, rather than asking one model to reason about both. It is the complaint from the top of this section, solved in miniature: a single generalist agent tried to do everything, and the fix was to make it do less, better, behind a router that knows which specialist the moment calls for.
The scale argument closes the loop. Salesforce reached a similar conclusion from a different angle, generating flows in a constrained domain-specific language rather than free-form output, because those flows execute hundreds of billions of times a month and open-ended interpretation does not survive at that scale. And Spotify's advertising system applies the idea at the orchestration layer, putting a fast router in front of its specialized agents so expensive model calls happen only when a task genuinely needs one. Spotify reports media plan creation dropping from fifteen to thirty minutes of manual work to five to ten seconds, with the form reduced from twenty-plus fields to a few natural-language messages.
Underneath all of it sits one principle: spend the model's judgment on the parts of the problem that need judgment, and make everything else boring.
2. Bounded loops, graded by the environment
When the agent does get autonomy, the teams that trust it most give it the least room to wander. The lead at one automation platform told us his company's agents do not auto-deploy on merge. A human gate remains the default trust model, which he described, half joking, as vibe-checking the engineer. The joke lands because it names the gap: a human gate is what you fall back on when nothing in the environment can grade the agent's work for you.
The alternative is to build an environment that can. Spotify's background coding agents run a deliberately plain loop: the agent receives a prompt and a scoped set of files, edits while the build system talks back, and stops when the tests pass or when it exhausts a fixed budget of turns and retries. No open-ended exploration, no unbounded sessions. The creativity lives inside walls the environment enforces. Spotify is clear about the limit: the plain loop held for small changes and became unruly beyond them, which is why the bounds are explicit rather than aspirational.
Not every team has a build system to grade against, but the same instinct scales down. DoorDash's internal agentic platform treats that boundary as a deliberate design choice rather than leaving it to whichever engineer happens to build the agent that week. Deterministic workflows still handle the most critical reporting, where auditability is non-negotiable, and anything more autonomous gets a hard budget of steps and time enforced by a circuit breaker, so a plan that starts thrashing gets cut off rather than left to wander unsupervised.
Meta's KernelEvolve pushes the same idea to its logical end. The agent writes GPU kernels, and the environment grades them the only way that matters: each candidate compiles or it does not, passes correctness checks or it does not, runs measurably faster or it does not. Framed as structured search rather than one-shot generation, that loop improved inference throughput for one ads model by more than sixty percent and training throughput on Meta's custom silicon by twenty-five percent. Where the objective is executable, the environment can grade the work directly instead of routing every judgment to a person.
3. Context is engineered, not accumulated
Context is the failure mode almost nobody designs for up front, and it dominates our conversations about long-running agents. Platform leads tell us their agents hit eighty percent of the context window faster than anyone expects, with nothing playing the role of a wise operator pruning and rebalancing mid-session. An engineer who built multi-agent systems at a global bank described the compounding version: queries decomposed across agents dragged the full chat history into tools that needed a fragment of it, and every tool downstream got a little more confused.
The fix starts with what gets handed off in the first place. DoorDash is deliberate about what one agent passes to another inside a single session, often sharing only the final artifact rather than the full conversational history that produced it, on the reasoning that persisting every intermediate step bloats context, degrades accuracy, and drives up cost without adding signal.
The same discipline holds a level up, in what an agent keeps in its own prompt rather than what it hands to another. Shopify's Sidekick team has published the most honest account of where that road ends. As Sidekick grew past fifty tools, its system prompt decayed into what the team calls death by a thousand instructions: special cases stacked on special cases, guidance conflicting with older guidance nobody remembered writing. The fix was structural rather than editorial. Instructions now arrive just in time, returned alongside a tool's data at the moment the agent needs them, instead of living in one ever-growing prompt. The monolithic prompt fails for the same reason the monolithic agent does, and the remedy is the same: load only what the current step needs.
4. Tasks from production, judges held to ground truth
The evaluation half of the playbook follows directly, and this is where the gap between teams is widest. One team we know, at a large enterprise software company, got burned by a vendor's reinforcement-learning fine-tune: the model crushed the in-distribution benchmark, then fell apart in production the moment traffic drifted outside the rubric, malformed tool calls and all. They now treat any offline score that was not seeded from production traffic as a claim about the lab, not the product. The teams that keep their offline signal honest tell us they rotate their golden sets on a thirty-to-sixty-day cycle, because user behavior drifts underneath a static benchmark and every new customer cohort behaves like a small distribution shift.
The public record confirms both the failure and the fix. Shopify's Flow work built its training set backward from workflows merchants had already created and validated, reconstructing the requests that would have produced them, then scored the result against a separately hand-built benchmark. Nubank's framework, published from five customer-support deployments serving over a hundred million users, holds its LLM judges to measured agreement with human raters and validates every idea offline before it reaches a customer, with the gains reported in customer satisfaction rather than benchmark points.
We have written about why this ordering matters, in Efficient Agent Evals and Offline Eval Environments. It is clarifying to watch the largest agent teams in the industry arrive at the same sequence independently.
5. The playbook, assembled
Assembled, the playbook is short. Narrow agents behind a router, not one agent that does everything. Deterministic rails wherever correctness is non-negotiable. Bounded loops graded by a real environment rather than by vibes. Context delivered at the moment of need. Tasks derived from production artifacts, judges calibrated against humans, and offline validation before anything touches a user.
No one designed this centrally. It emerged team by team, from companies solving their own problems and landing in the same place. Convergence is not proof on its own, since these teams read each other's writing, but each practice above has survived contact with production at scale.
The part that never makes it into the engineering blogs is what happens after these practices exist. Two teams told us, independently, that they wired evals into CI and tore the gate out within a week, because the eval baseline was not trusted enough to block a release. Others describe prompts, tools, memory, and datasets drifting with no rollback path, so that even a team running every practice above cannot say which change moved the metric. The practices work. What is missing between them is a release loop: versioned tasks, judges calibrated against humans, and scores tied to a business number, so a gate can be trusted enough to stay in. That is the gap the two teams above ran into, and it is the layer we build.