Autonomous Pipeline Patterns: Combining the Tools

The Full Scheduling Spectrum

By this point you've seen every layer of Claude Code's automation stack. Putting them on a single spectrum makes the selection logic clear:

The selection rule: start at the most session-dependent option that meets your needs. If the task must run while your machine is off, move to cloud. If it must run even without launching Claude Code, stay in cloud. If it fits in the current session and you're present, stay session-scoped.

Pattern 1: /goal + Auto Mode for Unattended Work

The most common autonomous pairing. Auto mode removes per-tool permission prompts within each turn. /goal removes the per-turn prompt between turns. Together, they let Claude work through a multi-step task end to end without any input from you.

The pattern for an unattended API migration:

1. Switch to auto mode: Shift+Tab until the auto mode indicator appears
2. Set a verifiable goal: /goal every call to OldAPI has been replaced with NewAPI, all tests pass, and git status is clean
3. Walk away — Claude works through files, runs tests, checks its own progress, and stops when the evaluator confirms the condition is met

The key to making this work reliably is the goal condition. "Migrate the API calls" is not verifiable. "Every call to OldAPI in src/ is replaced, npm test exits 0, and git status is clean" is verifiable — the Haiku evaluator can confirm each part from the transcript.

Pattern 2: /loop vs Channels for Monitoring

Both /loop and Channels serve the monitoring use case, but with different triggering models that suit different scenarios.

Use /loop when: you're watching a process that doesn't emit events, you want a summary at regular intervals regardless of whether anything changed, or the external system can't push events to you. Polling a deployment status every 5 minutes, checking a long-running test suite, reviewing a PR for new comments every 15 minutes — these all fit /loop naturally.

Use Channels when: the external system can send events, latency matters, and token efficiency is a concern. A CI system that pushes a failure notification the moment a build fails is more responsive and cheaper than Claude polling every 5 minutes for 40 minutes. If your CI system supports webhooks and you have an open session, Channels eliminate the polling overhead entirely.

The practical question: can the external system push? If yes, consider Channels. If no, or if the system is something you watch (not a system that alerts), use /loop.

Pattern 3: Routine + Dynamic Workflow for Large-Scale Review

For large-scale review work that runs on a schedule — nightly security audits, weekly dependency checks, weekly PR quality reviews — the right design chains a cloud Routine to a Dynamic Workflow.

The Routine handles the scheduling: it runs at the configured time, with no machine required, triggering a fresh Claude Code cloud session. Inside that session, the task is too large for a single conversation — hundreds of files, dozens of sources — so the session launches a Dynamic Workflow. The workflow fans out agents across the scope, collects findings in script variables, cross-checks adversarially, and returns a single report to the session. The session then opens a PR with the findings and stops.

This design keeps each layer doing what it's good at: Routines for scheduling and triggering, Dynamic Workflows for scale and quality, the Routine session for final synthesis and output.

Boundaries in Conversation

In auto mode, you don't just control behavior through settings and rules. You can also state boundaries in the conversation itself and the classifier will enforce them.

If you tell Claude "don't push" or "wait for my review before deploying", the classifier treats those messages as block signals. Even if the default rules would allow a push, the stated boundary prevents it. The boundary stays in force until you explicitly lift it in a later message — Claude's own judgment that a condition was met does not lift it.

This is useful for safety-sensitive tasks where you want to be in the loop at specific checkpoints without adding permanent deny rules to your settings. Start the session with the boundary: "Don't open any PRs without showing me the diff first." Run the task in auto mode. When Claude has a diff ready, it surfaces it for your review instead of pushing directly.

Important note: conversation-stated boundaries are not stored as rules. The classifier re-reads them from the transcript on each check. If context compaction removes the message where you stated the boundary, the classifier can no longer enforce it. For hard guarantees, add a permissions.deny rule in your settings instead.

A Decision Framework

When you're about to start a substantial Claude Code task, work through these questions:

1. Does it have a verifiable end state? If yes, use /goal. If not, it's probably interactive work or monitoring.
2. Does it need to run while I'm away from my machine? If yes, use a cloud Routine. If no, session-scoped tools are fine.
3. Does it require access to local files or tools? If yes and it's scheduled, use a Desktop task. If no and it's scheduled, cloud Routines are simpler.
4. Is the task larger than one context window? If yes, use a Dynamic Workflow. If no, subagents or /goal are sufficient.
5. Does it need permission prompts suppressed? If yes, use auto mode. If you need total suppression in a container, use bypassPermissions.

Most real tasks don't fit cleanly into one answer. The examples in the next lesson show how to chain tools together when the task crosses multiple categories.