AI Velocity Is a Control Problem

The most useful thing Showspring gave me was not another AI demo. It gave me a controlled place to let agents move fast against a real software project and then watch what broke, what accelerated, and what had to be turned into policy.

That distinction matters. It is easy to be impressed by AI velocity in a sandbox. It is harder to make that velocity deployable in an operational environment where systems have owners, costs, permissions, customers, logs, incident paths, and consequences.

So the twist on the usual AI transformation story is this: I have seen how much speed an agentic system can unlock when it is allowed to work on a complex product. I have also seen why that speed is dangerous unless the operating model is designed before the blast radius expands.

The sandbox

My path into this did not start as a software project. It started with prompting, then moved into generated images and video, then into a full production pipeline. Generated video made the problem obvious: a shot can look good and still be wrong. A character drifts. A prop changes. A voice lands on the wrong speaker. A retry fixes one thing and breaks another.

Showspring became the place where those lessons had to harden. An episode moves through concept, script, readout, locations, images, video, audio, render, publish, and shorts. Each stage writes state to the database. Each output can be reviewed, regenerated, restored, or approved. The point was never a single magical prompt. The point was a production system around unreliable intelligence.

Then the experiment folded back on itself. I started using agentic development to build and harden the product that was itself orchestrating AI agents. Showspring was not just the output of AI work. It became the lab where I could observe AI velocity against a real codebase.

The agent stack I actually used

Looking across the Showspring system, the agents split into two different categories. That distinction matters because each category needs different controls.

Agents that build the software (Claude Code coordination). On the build side, the "agent" is not a single product persona. It is a set of parallel AI coding sessions (Claude Code) working concurrently against the same repository. To prevent these sessions from thrashing, colliding, or deploying over one another, they coordinate automatically via custom project-level hooks:

• Self-aware coordination. A hook-based coordination script (`coord.js` under `.sessions/`) automatically tracks active sessions, registering heartbeats and tasks in a lock-free structure.
• File-claim mechanics. Sessions claim files before editing (with claims expiring after 25 minutes), warning other active sessions of potential conflicts to prevent double-editing.
• Push-staggering gates. Deployment is protected by a 90-second push-pacing gate, stopping concurrent sessions from triggering overlapping auto-deploys and PM2 restarts.
• Fast-forward branch discipline. Git is constrained to a strict staging-to-master fast-forward-only model, paired with database staging forks and expand-only migration lints, ensuring concurrent agent builds can never diverge git states or crash active database tables.

Agents that operate the product (Agents building agents). Inside the built Showspring solution, the agentic pieces are more explicit. They run the creative, script, and media pipelines. These are effectively agents constructed by the build agents, executing tasks in a highly orchestrated sequence within narrower tool surfaces:

• Agent 1: Creative Director. Generates episode pitches and sends them through multi-model evaluation with Gemini, Grok, and Claude-style judging before a human approves one.
• Agent 2: Script Writer. Turns the approved concept, show bible, character bible, and segment rules into structured clips with dialogue, scene text, character mapping, and duration.
• Location and canon agents. Extract locations, resolve them against the show library, and keep recurring settings, characters, and props tied to canonical records instead of loose prompt memory.
• Image and video agents. Generate start frames, optional end frames, and image-to-video clips through Gemini, ComfyUI, Veo, and Flow+ paths, with review and regeneration around each stage.
• Multimodal planner. Plans audience reactions, sound effects, and music cues against the rendered episode instead of treating audio as an afterthought.
• Shorts planner. Branches from a finished episode to pick timestamps, hooks, vertical cuts, captions, and platform metadata.
• Director Copilot. Lets collaborators review an episode and request script rewrites from a watch room, with the creator still owning the final decision.
• Agent control plane and hosted MCP. Lets an external AI bootstrap a show with scoped tools: create a show, write the bible, add characters, register segment formats, quote paid enrichment, and generate only what has been approved. Publish and deploy are intentionally absent.

The velocity was real

The first Showspring commit was March 13, 2026. By early July, the repository had crossed three thousand commits. That number is not a trophy. It is a signal that the work changed shape. Agents made it possible to explore more implementation paths, land more scaffolding, build more tests, and harden more surfaces than I could have done manually in the same window.

The interesting part was not that AI wrote code. The interesting part was that the work became parallel. One thread could inspect a route, another could harden a migration, another could generate tests, another could check a UI edge case, and another could summarize the operational risk. That is real leverage.

But it also created a new problem: work appeared faster than human review could comfortably absorb. A high-velocity system does not only produce more good changes. It produces more plausible changes, more partial fixes, more hidden coupling, and more opportunities for an agent to be confidently wrong in a way that looks finished.

The lesson was not that agents replace engineering discipline. It was that engineering discipline has to become executable.

The control plane

It helps to separate two control regimes. Agents that build the software are constrained by repo discipline: release automation, explicit file ownership, tests, CI, staging, and human deploy. Agents that operate the product are constrained by runtime discipline: token scope, project ownership, consent, spend caps, state machines, audit logs, and human publish. Mixing those together makes the story sound simpler than the system really is.

That is why the Showspring agent system is designed around a narrow control plane instead of broad autonomy. The headless agent API and hosted MCP endpoint can create and scaffold a show, write a bible, add characters, register segment formats, quote enrichment, and, with consent, generate images, ideas, scripts, and revisions. It cannot publish. It cannot deploy. It cannot touch projects outside its scope.

The control plane exposes tools, but the platform keeps authority. A token has a scope. A project id is checked server-side. Paid generation is off by default. Cost-incurring tools require a free quote first. That quote returns a short-lived consent nonce. The nonce is bound to the token, expires in 15 minutes, and is required on each paid call. Host tokens have a DB-backed daily spend cap. Sandbox users are clamped by credit balance and model policy.

This is where my view on enterprise AI gets more conservative than the demos. In a demo, the question is whether the model can perform the task. In operations, the question is whether the system can contain the model when it performs the task too eagerly, too expensively, in the wrong account, with stale context, or at the wrong approval level.

What had to become policy

The same pattern showed up in the software process around Showspring. Parallel agents were useful only after the repo developed stronger rules: explicit session conventions, collision-free release files, pre-push checks, test gates, secret scanning, expand-only migration guards, staging smoke tests, and human-controlled production deploys.

AI velocity created	Operational control required
Many changes in parallel	Worktree etiquette, explicit paths, release files that do not collide
Fast feature scaffolding	Tests, refactor gates, inline handler checks, staged verification
Autonomous show setup	Scoped tokens, project ownership checks, server-side tenancy enforcement
Paid generation at scale	Quote first, consent nonce, credit balance, daily spend cap, cost attribution
Long-running media work	DB-backed state, boot recovery sweeps, status polling, resumable stages
Production-ready outputs	Human approval for publish and deploy, logs for diagnosis, rollback path

That table is the real transformation work. Not a prompt library. Not a procurement decision. Not a one-time workshop. It is the conversion of judgment into systems that agents have to operate inside.

Defaults, not mythology

One useful point from the cross-review was that the controls should not be described as if they are magical absolutes. They are defaults with named exceptions. Director Copilot rewrites are deliberately full-quality and uncapped because collaborator feedback is treated as a creator-approved workflow. The host daily spend cap is a backstop checked before a paid tool runs, so concurrent calls can still overshoot by roughly one in-flight unit. Those details matter because real operating controls have shape, limits, and owners.

The goal is not perfect containment. The goal is to make the defaults explicit, make the exceptions visible, and keep final authority over publishing, deployment, and spend where a person can own the consequence.

The operations reality

At operational scale, novelty is not enough. Systems need to be supportable. A production team has to know who can do what, where money is spent, which data was used, what changed, what failed, how to recover, and who approved the final action. The bigger the organization, the less useful it is to say, "the model decided." Somebody still owns the decision.

That is why I think many AI adoption plans are aiming at the wrong layer. They measure access, experimentation, and use cases, but under-measure control. They ask how many people are using AI. They ask which model is best. They ask how many workflows can be automated. The more durable questions are different:

• Scope: what can the agent read, write, create, delete, publish, or deploy?
• Context: what source of truth does the model use, and how does it stay current?
• Cost: which calls are cheap, which are expensive, and where are caps enforced?
• State: can work resume after a crash, or is every run a fragile one-off?
• Review: which steps require human approval, and is that enforced in code?
• Audit: can the team explain what happened after the fact?

When those answers are vague, agents become a liability. When those answers are explicit, agents become leverage.

The actual lesson

Showspring let me see both sides at once. On one side, a complex agentic system can create extraordinary velocity. It can turn a one-line premise into a show scaffold. It can build software around that workflow. It can inspect, draft, test, and iterate at a pace that changes what one person can attempt.

On the other side, velocity does not remove operational reality. It intensifies it. More generated work means more need for source-of-truth context, cost accounting, permissions, review gates, recovery paths, and boring deployment discipline.

That is why I keep coming back to control. Not control as resistance to AI, but control as the thing that lets AI be useful outside the demo. The companies that win will not be the ones that merely let agents do more. They will be the ones that make sure agents do more inside systems that know when to stop them.