One-shot unattended agents (Stripe Minions model)

One-shot unattended agents are AI agents given a task and left to run until they complete it - no human supervision, no confirmation prompts, no mid-task steering. The agent writes code, runs the test suite, reads the output, fixes failures, iterates, and when it reaches a passing state, opens a pull request. The developer reviews the PR; they don't watch the work.

This pattern is named after Stripe's "Minions" system, described publicly in 2024-2025: a framework for dispatching AI agents to complete tasks in isolated sandboxes. Each "minion" gets a task description, a clean environment, and execution authority. When it succeeds (tests green, PR opened) or fails definitively (stuck in a loop, cannot fix the errors), it reports back. Stripe uses this pattern at scale for tasks like dependency upgrades, API compatibility fixes, and security patches. While Stripe Minions remains the canonical example, the pattern has since been commercialized. Cursor Automations (2026) provides always-on agents triggered from external systems - Slack messages, Linear tickets, GitHub issues, PagerDuty alerts - that spin up, complete a task, and produce a PR without developer initiation. Claude Code subagents with named @ mentions enable composing multi-agent workflows where a parent agent delegates subtasks to specialized child agents, each running in its own context. In May 2026 the scheduled and async variant became first-class: Anthropic Routines and Cursor's /loop skill dispatch work on a schedule so teams "wake up to PRs ready to merge," and CI auto-fix closes the loop by repairing failing checks before a human looks. This generalizes the Stripe Minions one-shot pattern well beyond a single company. The one-shot unattended pattern is no longer experimental infrastructure - it's becoming a standard product feature.

At L4 (Optimized), unattended agents are the default mode for well-defined tasks. The shift from L3 is the removal of the human loop: at L3, a developer runs Claude Code in YOLO mode and monitors the terminal; at L4, the agent runs in a sandbox and the developer checks their email for a PR notification. The developer's attention is decoupled from the agent's execution.

The sandbox is essential. Unattended agents must run in isolated environments - ephemeral VMs, Docker containers, or git worktrees - where their actions cannot affect production systems, other developers' work, or infrastructure outside the task scope. The sandbox provides the blast radius limit that makes autonomous execution safe.

Unattended agents change the economics of software development fundamentally:

• Decouples developer attention from task execution - a developer can have 5 agents running while they focus on architecture, review, or strategy; execution scales independently of human time
• Enables overnight work - agents launched at end of day complete tasks while the developer sleeps; the next morning's inbox contains PRs, not partially finished work
• Makes parallelism natural - one developer can launch multiple agents on different tasks without context switching overhead; each task progresses independently
• Shifts human role to review - developers become reviewers and directors rather than implementers; this is a fundamentally different and more leveraged use of senior engineer time
• Creates reproducible task execution - the same task specification produces the same kind of PR; this consistency enables measurement and optimization

The Stripe Minions model also demonstrates something important about L4 readiness: it requires L2-L3 investment to be safe. Unattended agents without a mature CLAUDE.md produce autonomous bad decisions at scale. The context engineering work of L2-L3 is what makes L4 viable, not just risky.

In June 2026 this practice got a name and a body of theory: loop engineering. After roughly a year of "AI-native engineering" (marked by the InfoQ retrospective "From MCP and Vibe Coding to Harness Engineering"), the field articulated a cascade - prompt engineering, then context engineering, then harness engineering, then loop engineering sitting one floor above - in Addy Osmani's "Loop Engineering", LangChain's "The Art of Loop Engineering," and Latent Space's "Loopcraft: The Art of Stacking Loops". A "minion launcher" is exactly a loop: a stacked play-test-fix-verify-improve cycle around a fixed model. June saw a rush of loop frameworks (OpenLoop) and meta-harnesses (Omnigent, which lets you swap or combine Claude Code, Codex and Pi behind one layer). The strategic point ties straight to sovereignty: when the model underneath is a swappable commodity, the loop you build around it is the part that is actually yours - so it is worth engineering deliberately, not improvising per task.

1. Identify suitable task categories - Good first candidates: dependency upgrades, adding tests to untested functions, fixing a class of lint warnings, updating API endpoints to a new version, migrating from a deprecated library. These share the property: clear success criteria, verifiable by tests.
2. Build the sandbox - Set up ephemeral environments for agent execution. The simplest: git worktrees (each task gets its own worktree, isolated from your main branch). More robust: Docker containers or cloud VMs that are created per task and destroyed after completion.
3. Write task specifications as structured prompts - Unattended agents need precise task descriptions. Structure: what to do, where to do it, how to verify success (which tests must pass), what not to touch. Store these as templates for repeatable task types.
4. Configure automatic PR creation - Claude Code can be run with --output-format json and integrated with gh pr create in a wrapper script. The agent completes the task; the script creates the PR. Set standard PR templates for AI-generated PRs that include the task specification and agent run summary.
5. Establish a review protocol - AI-generated PRs from unattended agents need a consistent review approach. Create a checklist: does the PR address the task spec exactly? Do all tests pass? Are there changes outside the task scope? Is there anything the agent can't have known about (business logic, edge cases)?
6. Start with one task type - Pick one specific, repeatable task (e.g., "write unit tests for files with 0% coverage") and run 10 agents on it. Learn from those 10 what the failure modes are, what the task spec needs to include, and what the review checklist should cover. Then expand to other task types.

Launching unattended agents without test coverage. The agent's primary feedback mechanism is the test suite. If your tests are sparse, the agent has no way to verify it hasn't broken something. A baseline of 60%+ test coverage is the minimum for safe unattended agent execution. Below that, the agent is flying blind.

Insufficiently scoped task specifications. Vague task specs produce agents that make reasonable but unintended decisions. "Refactor the auth module" is dangerous unattended; "extract the JWT validation logic from auth.ts into a separate jwt.ts file, updating all imports, with all existing tests passing" is safe. Scope determines blast radius.

Not isolating agents from each other. Two agents running simultaneously on the same codebase will conflict. Each agent must have its own sandbox (worktree, branch, or container). Shared state between concurrent agents produces merge conflicts and confusion that's harder to debug than either agent's individual output.

Skipping the review gate. The point of unattended execution is not "merge without review" - it's "complete without supervision." Every agent-generated PR still needs human review before merge. The efficiency gain is in execution (agent does this autonomously), not in quality assurance (human reviews, same as always). Teams that skip PR review for agent-generated code are absorbing unacceptable risk.