Five workflow patterns for real-world agent tasks

Workflow configuration in MuxAgent is not about checking a box on a settings screen. It is about matching the shape of your process to the shape of the work. The wrong workflow for a task does not just waste time — it either lets mistakes through (too loose) or bogs you down with unnecessary ceremony (too tight).

The workflow configuration guide explains the four built-in configs and when to use each one. This post goes further: five concrete patterns drawn from the kinds of tasks developers actually run with AI agents. Each pattern specifies the workflow config, where approval matters, what verification looks like, and when to deviate.

Think of these as workflow recipes. Use them as starting points, not rigid templates.

Pattern 1: Quick fix — minimal ceremony, fast turnaround

When to use: Bug fixes with clear reproduction steps, small feature patches, typo corrections, configuration changes. The defining characteristic is that you can describe the exact change needed and verify it in under a minute.

Workflow config: autonomous

Graph shape:

plan → implement → verify

No approval gate. The agent plans, implements, and verifies without waiting for human input. You review the result after completion.

Why autonomous works here: The cost of a wrong implementation is low because the change is small and easily reversible. A git diff shows you everything the agent changed. If it is wrong, you revert and try again. The time saved by skipping approval far outweighs the time cost of an occasional bad attempt.

Example task brief:

Fix the off-by-one error in `src/parser/tokenizer.go` line 142 where the
loop index starts at 0 but the token array is 1-indexed. The fix should
make the loop start at 1. Run the existing tests to verify.

Verification approach: The agent runs existing tests as part of its verify stage. You review the diff when the task completes. The entire cycle — plan to verified result — takes minutes.

When to deviate: If the “quick fix” turns out to touch more files than expected, or if the agent’s plan reveals that the bug is more complex than you thought, stop and re-run with default config to add the approval gate. The goal of starting with autonomous is speed, not stubbornness.

Key principle: The lighter the ceremony, the faster the feedback loop. For changes you can verify in seconds, do not add workflow stages that take minutes.

Pattern 2: Feature implementation — full planning and review

When to use: New features that span multiple files, refactors that change interfaces, any change where the approach is ambiguous and the blast radius is non-trivial.

Workflow config: default

Graph shape:

plan → review → approve → implement → verify

All stages active. The agent plans the approach, you review the plan, approve it if the approach is right, the agent implements, and the agent verifies.

Why default works here: Feature implementation has two failure modes. The agent might choose the wrong approach (wrong abstraction, wrong module, wrong interface). Or it might implement the right approach incorrectly (bugs, missed edge cases). The approval gate after plan review catches the first failure mode. The verification stage catches the second.

Without the approval gate, you discover wrong-approach failures only after the agent has finished implementing — which means wasted API tokens and time. The plan review is cheap; the full implementation is expensive. Approval checkpoints pay for themselves here.

Example task brief:

Add a rate limiter to the API gateway that limits each authenticated user
to 100 requests per minute. Use a sliding window algorithm backed by Redis.
The limiter should return 429 with a Retry-After header when the limit is
exceeded. Add unit tests for the limiter logic and integration tests for
the middleware.

Write surface: src/middleware/ratelimit.go, src/middleware/ratelimit_test.go,
src/integration/ratelimit_integration_test.go.

Verification approach: The agent runs both unit and integration tests as part of verification. The plan should specify the algorithm choice, the Redis key structure, and the middleware integration point. Your approval decision should focus on the architecture, not the implementation details.

What to review at approval:

• Does the plan match your mental model of where rate limiting belongs?
• Is the Redis key design reasonable? Will it work with your existing Redis setup?
• Does the test plan cover the important edge cases (window boundary, concurrent requests, key expiry)?

When to deviate: If you have high confidence in the approach (you have built rate limiters before and the task brief is specific enough), you can use autonomous and skip to post-completion review. The workflow config is a tool, not a religion.

Pattern 3: Codebase migration — batch processing with incremental verification

When to use: Large-scale changes that apply the same transformation across many files. Database schema migrations with corresponding code changes. API version upgrades. Framework migrations (e.g., upgrading from one major version to another).

Workflow config: default (with manual wave decomposition)

Graph shape (per wave):

plan → review → approve → implement → verify

The critical insight for migrations is that the task is too large for a single agent run. Instead, decompose the migration into waves manually and run each wave as a separate task with the full default workflow.

Wave decomposition example (API v2 to v3 migration):

1. Wave 1: Migrate the data access layer — update all repository methods to use v3 query syntax
2. Wave 2: Migrate the service layer — update business logic that depends on changed repository interfaces
3. Wave 3: Migrate the HTTP handlers — update request/response types and validation
4. Wave 4: Clean up — remove v2 compatibility shims, update documentation

Each wave is a complete task with its own plan, approval, implementation, and verification. The approval gate is critical here because each wave builds on the previous one. If wave 1 makes a structural mistake, you want to catch it before waves 2-4 compound the error.

Example task brief (Wave 1):

Migrate all repository methods in src/data/repositories/ from the v2 query
API to v3. The v3 API replaces .Where() chains with a QueryBuilder pattern.
Update each repository file to use the new pattern. Run existing tests after
each file to verify no regressions.

Do NOT modify files outside src/data/repositories/. Service layer changes
are a separate task.

Verification approach: After each wave, run the full test suite — not just tests for the changed files. Migration bugs often manifest as integration failures between layers. The agent’s verification should include both unit tests (did the changed files work?) and integration tests (did the system still work?).

Why not one big task? Task structuring matters more for migrations than for any other pattern. A single task that says “migrate the entire codebase from v2 to v3” gives the agent a write surface that is too broad to reason about effectively. Wave decomposition bounds the write surface and makes each task verifiable in isolation.

Multi-machine variant: For very large migrations, you can run waves in parallel on different machines. Wave 1 and Wave 3 might be independent (data layer and HTTP layer do not interact directly). Run them on separate machines, review the plans separately, and merge the results after both complete. The mobile app gives you visibility across all machines so you can track both waves from one screen.

Pattern 4: Code review agent — read-only exploration and analysis

When to use: Understanding unfamiliar code, security audits, architecture reviews, dependency analysis. The defining characteristic is that no code changes are made — the agent reads and reports.

Workflow config: plan-only or autonomous

Graph shape (plan-only):

plan

Or with autonomous if you want the agent to produce a formatted report:

plan → implement → verify

In plan-only mode, the agent produces its analysis as the “plan” and stops. There is no implementation stage because there is nothing to implement — the output is the analysis itself.

Example task brief:

Analyze the authentication module in src/auth/ for security vulnerabilities.
Check for: SQL injection in query construction, improper session handling,
missing CSRF protection, hardcoded secrets, and insecure cryptographic
patterns. For each issue found, describe the vulnerability, its severity,
the specific file and line number, and a recommended fix.

Why plan-only works here: The agent does not need to change code to provide a security analysis. The plan stage gives it access to read the codebase, reason about it, and produce structured output. Using plan-only mode guarantees that the agent cannot accidentally modify files during its analysis.

When to use autonomous instead: If you want the agent to produce a formatted report (a markdown file, a structured JSON output, or a comment on a PR), autonomous mode lets it go through implementation to write the report file. The verification stage can check that the report is well-structured and addresses all the analysis criteria.

The read-only guarantee: MuxAgent’s workflow graph enforces what the agent can do at each stage. In plan-only mode, the agent’s write surface is limited to its plan output. This is not just convention — the workflow system actively prevents implementation actions during the planning stage. That makes plan-only mode safe for running against production codebases where accidental modifications would be unacceptable.

Team use case: Code review agents are particularly valuable when combined with CI integration. Run a plan-only review on every PR, capture the output, and post it as a PR comment. The review happens automatically, the output is advisory, and no code is modified. This gives every PR a first-pass review even when human reviewers are busy.

Pattern 5: Multi-machine deployment verification

When to use: After deploying to staging or production, verify that the deployment is healthy by running checks across multiple machines. Useful for microservice architectures where a deployment touches several services.

Workflow config: autonomous (per-machine checks are well-defined)

Graph shape (per machine):

plan → implement → verify

The pattern: After a deployment, start verification tasks on each affected machine. Each task checks the local service’s health, runs smoke tests, verifies that configuration changes took effect, and reports the results.

Example task brief (for a web service machine):

Verify the deployment of version 2.4.1 on this machine:
1. Check that the running process reports version 2.4.1
2. Hit the /health endpoint and verify a 200 response
3. Run the smoke test suite in test/smoke/
4. Check the last 100 log lines for error-level entries
5. Verify that the new config value API_RATE_LIMIT=100 is in effect
Report pass/fail for each check.

Multi-machine coordination: Start verification tasks on each machine from the mobile app. The app shows all machines and their session status. As each machine’s verification completes, you see the results immediately — green checks or failure details.

This is where the multi-machine capability of MuxAgent becomes a practical operational tool rather than a nice-to-have. Without it, post-deployment verification means SSHing into each machine, running checks manually, and correlating results in your head. With MuxAgent, you start the tasks from one screen and see all results on one screen.

Why autonomous works here: Deployment verification tasks have well-defined checks with clear pass/fail criteria. There is no ambiguity in the approach — the agent runs the specified checks and reports results. Approval gates would add latency to a process where speed matters (you want to know if the deployment is healthy as quickly as possible).

Rollback integration: If any machine’s verification fails, you can immediately start a rollback task on that machine from the mobile app. The same daemon that ran the verification task can run a rollback task. This creates a tight loop: deploy → verify → rollback if needed, all controlled from the mobile app.

Choosing between patterns

The patterns map to two dimensions: blast radius (what can go wrong) and ambiguity (how well-defined the approach is).

Pattern	Blast radius	Ambiguity	Approval needed?
Quick fix	Low	Low	No
Feature implementation	Medium-High	Medium-High	Yes
Codebase migration	High	Medium	Yes (per wave)
Code review	None (read-only)	Low	No
Deployment verification	Low	Low	No

When blast radius is high, use approval gates. When ambiguity is high, use plan review. When both are low, skip the ceremony and let the agent run.

The workflow config is not a permanent decision. You can change it per task, per machine, even mid-session if the situation changes. The configuration system is designed for exactly this flexibility.

Composing patterns

Real work often combines patterns. A typical day might look like:

1. Morning: Start a migration wave (Pattern 3) on your workstation. Review and approve the plan from your phone during breakfast.
2. Mid-morning: The migration finishes. Run a code review (Pattern 4) on the changed files to catch issues.
3. Afternoon: Fix a bug found during review (Pattern 1) — quick autonomous fix.
4. End of day: Deploy and run verification (Pattern 5) across staging machines.

Each task uses the appropriate workflow config for its risk profile. The mobile app provides a unified view across all tasks and machines, so switching between patterns does not mean switching between tools.

The goal is not to memorize five patterns. It is to build intuition for matching workflow shape to task shape. When you get that match right, the agent does better work and you spend less time on ceremony that does not add value.

Building your own patterns

These five patterns are common starting points, but they are not exhaustive. Your team’s specific workflow needs might require variations:

• Pair programming pattern: Plan-only mode where you discuss each section of the plan with the agent before moving to autonomous implementation
• Audit trail pattern: Default mode with mandatory plan archiving for compliance-sensitive changes
• Exploration pattern: Autonomous mode with very broad task briefs for learning a new codebase

The MuxAgent configuration system supports custom workflow graphs beyond the four built-in presets. If your team has a consistent workflow that does not map to any of the patterns above, you can define a custom graph that encodes your specific process.

The best workflow pattern is the one your team actually uses consistently. Start with the built-in configs, adapt them to your work, and formalize the patterns that prove valuable.