The Unsupervised

Agent Pipeline

Autonomous issue-to-PR pipelines with Rust, MCP, and Claude Code

Hesham Salman

The Gap

Agents are capable. The bottleneck is initiation.

Claudio parallelizes agents across worktrees
But someone still reads the issue
Someone still writes the prompt
Someone still kicks it off and opens the PR

For well-scoped tasks, that someone
doesn't need to be a human.

VISIBLE: Title "The Gap" and subtitle. All bullet points are hidden (fragments). SAY: "I built Claudio to run multiple Claude Code instances in parallel, and it works well." [CLICK → fragment 1: "Claudio parallelizes agents across worktrees" appears] SAY: "Each agent gets its own worktree, its own branch, its own task. But..." [CLICK → fragment 2: "But someone still reads the issue" appears] SAY: "...someone still has to read the issue." [CLICK → fragment 3: "writes the prompt" appears] SAY: "Someone still has to write the prompt." [CLICK → fragment 4: "kicks it off and opens the PR" appears] SAY: "Someone still has to kick it off and open the PR." PAUSE. Let this land. SAY: "For complex, ambiguous work, that judgment is the point. But for bug fixes with clear repro steps? Dependency updates with automated tests? Mechanical refactors?" [CLICK → fragment 5: "doesn't need to be a human" appears] SAY: "The agent is capable enough. The bottleneck is the human who has to tell it to start." ADVANCE to next slide. TARGET TIME: ~1.5 minutes total. If running long, cut the "For complex, ambiguous work" sentence — the visual makes the point.

The Loop

What Symposium does on every tick

Poll Tracker

→

Dispatch

→

Implement

→

Review

→

Draft PR

→

Monitor

Reviewer requests changes → agent addresses feedback → loop continues

VISIBLE: Title "The Loop" and subtitle. Pipeline steps are all hidden (fragments). SAY: "Symposium is a Rust service running a Tokio event loop on a timer. Every 30 seconds, it ticks." [CLICK → fragment 1: "Poll Tracker" box appears] SAY: "It polls your issue tracker. Right now that's Notion or Sentry, via MCP." [CLICK → fragment 2: arrow + "Dispatch" appears] SAY: "It sorts by priority, filters out anything already running or in retry backoff, and dispatches." [CLICK → fragment 3: arrow + "Implement" appears] SAY: "An agent implements the change in an isolated worktree." [CLICK → fragment 4: arrow + "Review" appears] SAY: "A second agent reviews the diff and fixes obvious mistakes." [CLICK → fragment 5: arrow + "Draft PR" appears] SAY: "Then it pushes the branch and opens a draft PR." PAUSE briefly. The pipeline is now visible end-to-end. Let the audience absorb it. [CLICK → fragment 6: arrow + "Monitor" appears] SAY: "And here's where it gets interesting. Symposium monitors that PR." [CLICK → fragment 7: review feedback loop text appears below pipeline] SAY: "If a reviewer requests changes, it spins up another agent to address the feedback. That loop continues until the PR is approved, merged, or closed." PAUSE. SAY: "The human reviews at their convenience, not at the agent's pace." ADVANCE to next slide. TARGET TIME: ~2.5 minutes total. This is the slide that sets up the rest of the talk. Don't rush it. If you're at 3 minutes here, you're fine — trim the architecture slide instead.

Architecture

A single Tokio event loop

CLI (clap)

Orchestrator (tokio event loop + mpsc channels)

Config Layer (WORKFLOW.md watcher + hot-reload)

Notion / Sentry Tracker (MCP client → MCP server)

Agent Runner (claude CLI + streaming JSON parser)

HTTP Server (axum: dashboard + REST API)

VISIBLE: Title "Architecture" and subtitle. All stack layers are hidden (fragments). SAY: "The architecture is straightforward. It's a layer cake." [CLICK → fragment 1: "CLI (clap)" layer appears at top] SAY: "CLI parses your workflow config." [CLICK → fragment 2: "Orchestrator" layer appears] SAY: "The orchestrator is a single Tokio event loop. Workers report back through mpsc channels." [CLICK → fragment 3: "Config Layer" appears] SAY: "Config watches your WORKFLOW.md file and hot-reloads on changes. Bad parse? Keeps the old config." [CLICK → fragment 4: "Notion / Sentry Tracker" appears] SAY: "The tracker talks to Notion or Sentry through MCP — I'll explain that in a moment." [CLICK → fragment 5: "Agent Runner" appears] SAY: "The agent runner spawns Claude Code as a subprocess and reads streaming JSON from stdout, so the dashboard can show progress in real time." [CLICK → fragment 6: "HTTP Server" appears at bottom] SAY: "And there's an axum HTTP server for the dashboard." ADVANCE to next slide. TARGET TIME: ~3.5 minutes total. This slide is a quick orientation, not a deep dive. If you're running long, just click through the layers with one-liners and skip the details — the audience will read the labels.

MCP as Universal Adapter

One protocol, two consumers

Symposium spawns @notionhq/notion-mcp-server
as a child process, speaks JSON-RPC 2.0 over stdio

Server lives for one polling cycle, then gets dropped.
Process isolation. No connection management.

The agent uses the same MCP server
to read comments, update status, fetch context.

One protocol. One server. Two consumers.

VISIBLE: Title "MCP as Universal Adapter" and subtitle "One protocol, two consumers." All body text is hidden (fragments). SAY: "Symposium never calls the Notion API directly." [CLICK → fragment 1: "spawns notion-mcp-server as child process" text appears] SAY: "It spawns the official Notion MCP server as a child process and speaks JSON-RPC over stdio. Same for Sentry." [CLICK → fragment 2: "Server lives for one polling cycle" text appears] SAY: "The server only lives for one polling cycle. Spawn it, query, drop it, kill the process. It's stateless. If the MCP server misbehaves, it can't corrupt the orchestrator." PAUSE. [CLICK → fragment 3: "The agent uses the same MCP server" text appears] SAY: "Here's the key insight — the coding agent also talks to Notion through MCP. When the agent needs to read issue comments or update status, it calls the same server through its own config." [CLICK → fragment 4: "One protocol. One server. Two consumers." punchline appears] SAY: "One protocol, one server, two consumers. That's the real value of MCP here — not just a nice API, but a universal adapter that both sides speak." ADVANCE to next slide. TARGET TIME: ~4.5 minutes total.

Workspace Isolation

Each issue gets its own directory via hooks

hooks:
  after_create: |
    git -C ~/Developer/my-org/my-repo worktree add \
      {{ workspace }} -b symposium/bug-{{ issue.safe_identifier }}

Hooks are Liquid templates with access to issue properties

Workspace setup is fully user-controlled.
Symposium doesn't know or care that it's a git worktree.

VISIBLE: Title "Workspace Isolation", subtitle, and the YAML code block showing the after_create hook. Two bullet points are hidden (fragments). SAY: "Each issue gets an isolated workspace. You're looking at the after_create hook — this runs after Symposium creates the workspace directory." PAUSE. Give the audience a moment to read the code. SAY: "In this case, it's a git worktree add from a local repo, with a branch name derived from the issue ID." [CLICK → fragment 1: "Hooks are Liquid templates" text appears] SAY: "Hooks are Liquid templates. They have access to the issue's title, description, identifier — anything from the tracker. safe_identifier sanitizes the ID for branch names — strips colons, slashes, that kind of thing." [CLICK → fragment 2: "Workspace setup is fully user-controlled" text appears] SAY: "The key point: Symposium doesn't prescribe how workspaces work. It runs your hook and trusts that a directory exists afterward. You could use worktrees, you could clone, you could rsync. The hook is the contract." ADVANCE to next slide. TARGET TIME: ~5.5 minutes total. You're about halfway. If you're past 6 minutes, pick up the pace on the next two slides.

Fail-Open Design

A failing component should never halt the system

Component fails

Preflight agent crashes
Config file has a typo
Agent attempt fails
Notion API is flaky

System response

Main agent proceeds anyway
Previous config retained
Exponential backoff + retry
Re-fetch on next tick

Early versions didn't do this.
A single flaky API response would stall the entire pipeline.

VISIBLE: Title "Fail-Open Design" and subtitle. Both columns and the bottom text are hidden (fragments). SAY: "The most important design decision in Symposium is fail-open over fail-closed." [CLICK → fragment 1: left column "Component fails" appears with four failure modes] SAY: "Every component can fail." Point at the list. "The preflight agent might crash. The config file might have a typo. The implementation agent might produce garbage. The Notion API might be down." [CLICK → fragment 2: right column "System response" appears with four responses] SAY: "In every case, the system degrades gracefully." Walk through the pairs left-to-right: "Preflight crashes? Main agent proceeds anyway. Bad config? Keep the old one. Agent fails? Exponential backoff and retry. Flaky API? Re-fetch next tick." PAUSE. [CLICK → fragment 3: "Early versions didn't do this" warning text appears] SAY: "Early versions didn't do this. I had a single flaky Notion API response stall the entire pipeline. You can't build an autonomous system that requires everything to go right." ADVANCE to next slide. TARGET TIME: ~6.5 minutes total.

Filesystem as IPC

The agent writes files. The orchestrator reads them.

PREFLIGHT_SKIP → skip this issue, agent explains why PR_TITLE → title for the draft PR PR_BODY.md → description, reasoning, issue link workspace dir → the workspace itself is the contract

No shared memory. No sockets. No database.
Simple to debug, resilient to agent crashes.

VISIBLE: Title "Filesystem as IPC" and subtitle "The agent writes files. The orchestrator reads them." All file rows are hidden (fragments). SAY: "The orchestrator and the agent communicate through the filesystem. No protocol, no schema — just files." [CLICK → fragment 1: "PREFLIGHT_SKIP → skip this issue" row appears] SAY: "If the preflight agent decides an issue should be skipped, it writes a PREFLIGHT_SKIP file. Symposium reads it and short-circuits the pipeline." [CLICK → fragment 2: "PR_TITLE → title for the draft PR" row appears] SAY: "The implementation agent writes a PR_TITLE file." [CLICK → fragment 3: "PR_BODY.md → description, reasoning, issue link" row appears] SAY: "And a PR_BODY.md with the full description — what was changed, why, and a link back to the issue." [CLICK → fragment 4: "workspace dir → the workspace itself is the contract" row appears] SAY: "The workspace directory itself is the contract. Symposium doesn't need to know what the agent did. It just reads the results off disk." [CLICK → fragment 5: "No shared memory..." summary text appears] SAY: "No shared memory, no sockets, no database. If the agent crashes, the workspace is still there. You can inspect it, re-run, or let the retry pick it up." ADVANCE to next slide. TARGET TIME: ~7.5 minutes total. If you're past 8 minutes, you need to move quickly through the next two slides to leave time for takeaways.

PR Review Monitoring

Where the real time savings come from

Each tick checks open PRs for reviewer feedback

Groups reviews by author, keeps only the latest
CHANGES_REQUESTED → spin up agent to address
Reviewer later approves → no re-trigger

Without this, Symposium is a fancy auto-PR-opener.
With this, it's an autonomous contributor.

VISIBLE: Title "PR Review Monitoring" and subtitle "Where the real time savings come from." All content is hidden (fragments). SAY: "The feature that saves the most time isn't the initial implementation. You'd review that anyway." [CLICK → fragment 1: "Each tick checks open PRs for reviewer feedback" appears] SAY: "Each tick, Symposium checks its open PRs for reviewer feedback." [CLICK → fragment 2: "Groups reviews by author, keeps only the latest" appears] SAY: "It groups reviews by author and keeps only the latest from each." [CLICK → fragment 3: "CHANGES_REQUESTED → spin up agent" appears] SAY: "If someone requests changes, an agent spins up in the existing workspace to address the comments." [CLICK → fragment 4: "Reviewer later approves → no re-trigger" appears] SAY: "And it's smart about state. If a reviewer requests changes and later approves, that approval supersedes. No unnecessary agent runs." PAUSE. [CLICK → fragment 5: "auto-PR-opener vs autonomous contributor" punchline appears] SAY: "This is the difference between an auto-PR-opener and an autonomous contributor. The back-and-forth revision cycle that normally takes days of async waiting just... happens." Let the line land. Don't rush to the next slide. ADVANCE to next slide. TARGET TIME: ~8.5 minutes total.

What Actually Breaks

Learned from running against a real codebase

Agent failures

Fixates on the wrong part of an issue
Passes tests but misses the point
PRs too large to review

System failures

Slashes in issue IDs broke routing
Capacity guard blocked PR reviews
Restart wiped all tracked PR state

Retries catch transient failures.
Judgment failures need human eyes.
That's why everything opens as a draft.

VISIBLE: Title "What Actually Breaks" and subtitle "Learned from running against a real codebase." Both columns and bottom text are hidden (fragments). SAY: "Let me be honest about what breaks." PAUSE. Let the title set the tone. [CLICK → fragment 1: left column "Agent failures" appears with three items] SAY: "Agents fail in ways you don't expect." Walk through the list: "They fixate on the wrong part of an issue. They produce changes that pass tests but completely miss the point. Sometimes they generate PRs so large that reviewing them takes longer than doing the work manually." [CLICK → fragment 2: right column "System failures" appears with three items] SAY: "And the system itself breaks too." Walk through: "Issue IDs with slashes broke URL routing. The capacity guard that prevents over-dispatching accidentally blocked PR review checks from ever running. A restart wiped all tracked PR state because it lived only in memory." PAUSE. SAY: "Every one of these surfaced from running Symposium against a real codebase." [CLICK → fragment 3: "That's why everything opens as a draft" punchline appears] SAY: "Retries handle transient failures. But judgment failures need human eyes. That's why everything opens as a draft. Symposium doesn't merge. A human always has the final say." ADVANCE to next slide. TARGET TIME: ~9.5 minutes total. If you're past 10 minutes, skip the "What's Next" slide entirely — go straight to takeaways.

What's Next: Epics

From individual issues to multi-task projects

Real projects have dependencies.
Data model before API. API before UI.

Reads dependency graphs from Mermaid diagrams or Notion relations
Dispatches tasks when dependencies are merged
Single dependency → stacked PR
Multiple dependencies → bases off main

VISIBLE: Title "What's Next: Epics" and subtitle. All body content is hidden (fragments). NOTE: If you're past 10 minutes, skip this slide — press right arrow twice to jump to takeaways. SAY: "The current version handles independent issues well. But real projects have dependencies." [CLICK → fragment 1: "Real projects have dependencies" text appears] SAY: "A feature might need a data model change before the API layer, and the API before the UI. You can't just throw all the tasks at agents simultaneously." [CLICK → fragment 2: "Reads dependency graphs from Mermaid/Notion" appears] SAY: "The next version reads dependency graphs — either Mermaid diagrams in the epic page, or Notion's 'blocked by' relations." [CLICK → fragment 3: "Dispatches tasks when dependencies are merged" appears] SAY: "Symposium only dispatches a task when its dependencies have been merged." [CLICK → fragment 4: "Single dependency → stacked PR" appears] SAY: "Single dependency? Stacked PR on the dependency's branch." [CLICK → fragment 5: "Multiple dependencies → bases off main" appears] SAY: "Multiple dependencies? Fan-in from main. Proper stacked PR workflows, automatically, across an entire epic." ADVANCE to next slide. TARGET TIME: ~10.5 minutes total.

Takeaways

Fail-open, not fail-closed.
Autonomous systems can't require everything to go right. Design every component to degrade gracefully.

The filesystem is good enough.
Files are the simplest IPC between an orchestrator and an agent. Simple to debug, resilient to crashes.

Close the loop.
The real value isn't auto-opening PRs. It's handling the review cycle that normally takes days.

VISIBLE: Title "Takeaways" only. All three takeaway boxes are hidden (fragments). SAY: "Three takeaways." [CLICK → fragment 1: green "Fail-open, not fail-closed" box appears] SAY: "First: fail-open, not fail-closed. If you're building an autonomous system, you have to assume components will fail. Design every part to degrade gracefully. A broken piece should never stall the whole pipeline." [CLICK → fragment 2: orange "The filesystem is good enough" box appears] SAY: "Second: the filesystem is good enough. You don't need shared memory, databases, or message queues for agent coordination. The agent writes files, the orchestrator reads them. It's the simplest thing that works." [CLICK → fragment 3: purple "Close the loop" box appears] SAY: "Third: close the loop. Auto-opening a PR is table stakes. The real time savings come from handling the review cycle. That's where days of async back-and-forth compress into minutes." PAUSE. Let it sit for a beat. SAY: "Thank you." ADVANCE to end card (blog links + repo URL). TARGET TIME: ~11 minutes total. The end card is just a resource slide — leave it up during Q&A. No need to narrate it.