To truly understand how this project's custom autonomous framework operates, you cannot just look at the code. You have to watch the machine in motion.
We are going to dissect a real-world ticket: TASK-F-82. The objective of this task was simple: Build a Python script that pings the Human Architect on Telegram whenever a task is ready for final approval. How did the Swarm handle this?
Phase 1: Henry (The Blueprint)
Every task begins as a strictly formatted Markdown file in front of the human Architect. But the human does not manually write these files.
The Architect asks Henry, the Project Manager Agent, to build a feature via a simple chat prompt: "Henry, build a search box for the UI."
Henry does not write source code. Instead, he checks the PROJECT_CONTEXT.md,
cross-references existing components, and drafts a pristine Markdown file matching the stateful YAML
frontmatter standards (TASK-100-search-box.md). He then physically drops that file
directly into the tasks/active/ directory.
Within exactly zero seconds, orchestrator.py's watchdog observer detects the
raw file system creation event, identifies the file in the active/ path, and asynchronously
fires off the Coder subprocess CLI via an OS-level Popen command.
Phase 2: Flem (The Coder)
The orchestrator launches an isolated opencode terminal instance utilizing the
minimax-m2.5-free model. This agent identifies itself as Flem, our junior
coder.
The first thing Flem does on *every single execution* is read the .cursorrules bootloader.
He possesses zero memory of any previous task. The bootloader forces him to map the project architecture
into his immediate context window. We can see this occurring in his raw CLI logs:
The .cursorrules bootloader also contains explicit SECURITY LOCKS,
establishing hard Anti-Snoop
boundaries. If Flem attempts to read the .env file, the CLI sandbox automatically rejects
the tool call, the OS process exits with a non-zero code, and the Orchestrator instantly fires a
Telegram Crash Alert to the Human Architect.
Flem begins writing code. However, our system intercepts Model Context Protocol (MCP) diagnostics. Flem makes a type mistake updating the Orchestrator to watch the new Telegram hook. The language server immediately slaps him with an error:
Without human intervention, Flem reads the LSP diagnostics, opens orchestrator.py back up,
corrects his type comparisons, and runs his unit test script. Upon success, he opens the very markdown
file that triggered him (TASK-F-82...md), edits it natively via regex to change
status: in_progress to status: in_review, fills out his QA checklist, and
executes a bash git mv command to physically move the file to
tasks/review/, leaving all of his file modifications uncommitted for the human to review
later.
Flem's OS process immediately dies. His memory is completely flushed from RAM.
Phase 3: Bella (The QA Lead)
The moment Flem moves the file to tasks/review/, the Orchestrator's watchdog
catches another physical file system event. It immediately spins up a brand new, completely distinct
opencode subprocess. This agent identifies as Bella, the QA Lead.
Bella does not know Flem. She has no shared memory with Flem. All she knows is that a markdown file exists in her review folder, and there is unmerged code sitting in the Git tree awaiting validation.
Bella reads her instructions from .cursorrules, checks the Git Diff, and fundamentally
distrusts the Coder. In her raw log, we see her explicitly trigger python scripts manually in the
terminal to verify Flem's work actually functions without crashing the backend:
Bella opens the physical markdown file and edits it yet again: status: pending_human_review.
She physically executes a git mv moving the markdown file into the final directory layer:
tasks/human-review/.
Bella's process dies. RAM is flushed.
Phase 4: The Architect
Now, the magic happens. The Orchestrator intercepts the file dropping into
tasks/human-review/. Because this specific ticket was building the Telegram alerting
feature, the Orchestrator itself executes the very exact Python script Flem just authored,
utilizing the API keys stored in your local dotfiles natively.
Across the continent, Rotem's phone buzzes. It's a Telegram message:
ID: TASK-F-82-telegram-alerts-human-review
Title: Telegram Alerts for Human Review
Ready for your final sign-off.
The human reads the uncommitted Git diff. The human formally signs off by physically dragging the
Markdown file
into the tasks/approved/ directory.
Phase 5: Henry Returns (The Merge)
The Orchestrator detects the file dropping into tasks/approved/. It instantly spins up our
first agent again: Henry.
Henry opens his pm-agent-prompt.md bootloader. He is explicitly programmed to understand
that if a file arrives in approved/, the Architect has formally signed off on the Coder's
uncommitted work.
Henry executes a clean git commit -am "Feature(TASK-F-82): Telegram Alerts Built" to
permanently bind the work into version control. Then, he physically executes a git mv
moving the markdown file out of the active flow and into the tasks/done/ graveyard.
Finally, Henry triggers a python script firing off one last Telegram message alerting Rotem that the task was successfully closed out.
Phase 6: The Graveyard
The markdown blueprint rests permanently in tasks/done/. It serves as an immutable, stateful
record of exactly who coded what, which tests were run, and who approved it.
The Coder subprocess is dead. The QA subprocess is dead. The PM subprocess is dead.
The system goes silent, listening exclusively to the tasks/active/ network drive. Waiting
for the next PM prompt.