---
id: "framework-afk-agent-pipeline"
type: "framework"
source_timestamps: ["00:24:45", "00:29:59"]
tags: ["ci-cd", "automation"]
related: ["concept-afk-agent-work", "entity-sandcastle", "action-use-sandcastle", "concept-agentic-queues"]
---
# AFK Agent PR Pipeline

## Purpose

A production-ready pipeline for running [[concept-afk-agent-work|AFK]] agents safely and at scale. Each agent operates on a single scoped task inside an isolated sandbox, producing a reviewable PR.

## Steps

1. **Define a scoped task** and add it to an issue queue (e.g., GitHub Issues — see [[concept-agentic-queues]]).
2. **An orchestrator picks the issue** and spins up an isolated [[entity-sandcastle|Sandcastle]] environment (Docker / Podman / Vercel).
3. **The AI agent executes the task** within the sandbox, modifying code on a feature branch.
4. **The agent commits the changes and opens a Pull Request** back to the main repository.
5. **A secondary AI agent (running via GitHub Actions)** reviews the PR for security and logic flaws.
6. **A human manager performs a final review** of the PR before merging.

## Roles

- **Worker agent** — implements the issue inside the sandbox.
- **Reviewer agent** — runs in CI, performs first-pass review.
- **Human manager** — final reviewer; their job is no longer to write code, but to gate quality.

## Why isolation is non-negotiable

Without [[entity-sandcastle|Sandcastle]]-style sandboxes, AFK agents can delete local files, exfiltrate secrets from environment variables, or corrupt git history. The sandbox is the safety contract that makes AFK viable.

## When it pays off

**Large, stable codebases with repetitive work** — the pipeline overhead amortizes across many parallel agents. For small, fast-changing projects, an IDE copilot may be a better fit.

## Operational steps

- [[action-use-sandcastle]] — adopt isolated execution.
- [[action-implement-agent-queues]] — feed work via a backlog.
- [[action-blank-slate-agents]] — keep agent context lean.