Back to portfolio

Thesis companion · Anti-patterns

The Demo That Escaped

Anti-patterns for autonomous AI—how teams fake production readiness when agents can change the world, not just chat.

Premise: Most “autonomous” failures are not model failures. They are infrastructure failures: a Friday demo that kept running on Monday, with no owner, no pin, no gate, and no way to stop it. This is the flip side of AI as Infrastructure.

Why anti-patterns matter more than hype lists

Strategy decks love capability. Operations care about blast radius. When an agent has tools, a bad run is an incident—not a weird chat. The patterns below show up in real programs: they look like progress until someone asks who owns the alias, what the kill switch is, or where the eval evidence lives.

Seven anti-patterns

1. The demo that escaped

Looks like

A prototype agent “mostly works” in a stakeholder review. Someone leaves it pointed at a shared mailbox, a staging API that is secretly shared with prod data, or a cron that nobody turns off. Hardening is scheduled for “after we get signal.”

Instead: Treat every always-on loop as a deploy. Shadow mode, explicit promotion criteria, and a retirement date for anything that has not earned production.

2. Floating model aliases

Looks like

gpt-latest, claude-sonnet, or a vendor “recommended” alias in the hot path. Behavior drifts when the provider swaps weights. Your eval suite passes against last month’s model and nobody notices until tickets spike.

Instead: Pin versions (or dated snapshots). Change models through the same change-control path you use for infrastructure—with regression evidence, not vibes.

3. No owner, only a channel

Looks like

The agent “belongs to the AI initiative.” On-call is unclear. When it misbehaves, three teams argue about prompts, platforms, and product. Autonomy without a named owner is theater.

Instead: One accountable owner per loop (product + platform pair is fine). Document who can pause it, who can expand tools, and who signs the release gate.

4. No kill switch

Looks like

Stopping the agent means redeploying, revoking a shared API key that also powers five other services, or asking someone to “just turn off the Zap.” There is no practiced drill.

Instead: A one-action pause that cuts tool execution (not only chat). Test it in a drill the way you test failover. Human override is a product feature.

5. Unbounded tools (and MCP with the kitchen sink)

Looks like

The agent can browse, write tickets, touch production configs, and send email—“so it can be helpful.” Refusal text is treated as containment. A clever plan still reaches the dangerous tool.

Instead: Allowlists, argument constraints, and separate identities per capability. Refusal ≠ containment. See the Agentic Release Gate.

6. Ship the agent, invent the eval later

Looks like

Success is a screenshot, a stakeholder thumbs-up, or “it felt better this week.” Red-team notes live in a slide deck. Prod chats get pasted into GitHub “for examples.” The only gate measures jailbreaks—or nothing.

Instead: A small, versioned eval set before always-on. Traces you can replay. Regression that fails the build when the same leak returns. Start with the 40-Prompt Production Gate mindset: evidence packages, not folklore.

7. Swarm without orchestrator ownership

Looks like

Multiple agents hand work to each other with no single plan of record, no shared budget, and no one who can explain the last decision path. “Multi-agent” becomes distributed irresponsibility.

Instead: An orchestrator with explicit handoffs, budgets, and a story you can audit. Specialists are fine; unowned swarms are not. Architecture foresight belongs with papers like Hydro-Swarm MoE—not with improvised Slack bots.

The pattern underneath the patterns

Every anti-pattern above is a missing infrastructure expectation: pin, owner, boundary, evidence, stop. Teams do not fail because they skipped a clever prompt. They fail because they treated autonomy like a feature demo and hoped operations would appear later.

If you only fix one thing this quarter: name the owner, pin the model, add a kill switch, and refuse to promote any loop that has no eval you can re-run.

Where to go next

Get in touch if you want to pressure-test which of these is already living in your stack.