Most teams still run agent development the way they run traditional software projects. Requirements are written up front, builders execute against them, and a demo closes out the cycle. That model works poorly for agents, because the most useful information rarely comes from a planning document. It comes from someone building the system and seeing where it fails, often in ways nobody predicted.

This talk examines what happens when a team is organized around its builders instead of its process. Leaders set broad themes and let builders decide where to focus, build time is protected from the meetings that usually crowd it out, and the demo becomes the meeting where priorities are actually decided. I'll describe how this shifts decision rights, how it affects velocity, and where the approach breaks down, including the mistakes we made before it started working.

The discussion draws on three systems I built under this model. The first is a set of adversarial agents that attack our own system to expose failures before users encounter them. The second is a self-improving loop that feeds production signal back into the agent to make it stronger over time. The third is a swarm simulation that tests agent behavior at a scale manual QA could never reach. Each one began as a builder's experiment, and together they show both the strengths of the model and the points where it needs structure.

Attendees will leave with:

• A practical operating model for organizing a team around builders while still keeping work coordinated
• An approach to using demos as the primary prioritization mechanism, and the changes in decision rights that requires
• Patterns for turning individual experiments into durable capabilities such as adversarial testing, self-improvement loops, and large-scale simulation
• The common failure modes of build-first teams and the early warning signs that the model is breaking down
• Guidance on what to try first, what to avoid, and which changes only succeed once the culture has caught up