AI coding agents
Switchboard
Linear

Manual AI Agent Runs vs Switchboard Automation

Decide when to steer Claude Code or Codex manually and when to let Switchboard turn Linear issues into pull requests.

Junction TeamJunction Panel7 min read
On this page

Manual AI agent runs and Switchboard automation solve different problems.

A manual run is best when you want to stay in the loop: start Claude Code or Codex, watch the agent reason through the task, answer questions, approve actions, and redirect when the problem changes. Switchboard automation is best when the work is already structured enough to flow from Linear issue to isolated worktree to pull request.

The mistake is treating those as maturity levels where automation is always the upgrade. It is not. The better question is whether the work needs interactive judgment or repeatable execution.

This guide gives you a decision framework for choosing the right Junction workflow.

The difference in one sentence

Use a manual run when the task still needs conversation. Use Switchboard when the task is already a clear, bounded issue.

That distinction sounds simple, but it changes how you scope work.

Manual runs are flexible. You can ask an agent to investigate an unfamiliar failure, summarize a code path, try an implementation, pause, change direction, and refine the result. The human is present enough to correct the run as new information appears.

Switchboard is structured. It watches Linear, picks up configured work, creates an isolated agent workspace, runs the task with Claude Code or Codex, and moves the result toward a pull request. That makes it useful for repeatable issue-to-PR work, not for unresolved product thinking.

Linear's own API and webhooks docs describe webhooks around issue and comment changes. That kind of event-driven model is useful when the issue is a reliable handoff. It is much less useful when the issue is still a placeholder for a conversation.

Choose a manual run for discovery

Discovery work is rarely automation-ready.

Examples:

  • "Find out why onboarding intermittently fails."
  • "Compare these two implementation options."
  • "Read the authentication flow and tell me where the edge cases are."
  • "Prototype a fix, but stop before changing database behavior."
  • "Explain why this test is flaky before editing it."

These tasks benefit from live steering. You may want to ask follow-up questions after the agent reads the code. You may want to stop the run if the first hypothesis is wrong. You may want to inspect output before deciding whether implementation should happen at all.

In Junction, that is a normal chat-driven agent session. The daemon runs locally. The browser or phone shows output, approvals, Git state, and diffs. You can keep the loop tight without sitting in front of the terminal the whole time.

Choose Switchboard for bounded implementation

Switchboard is stronger when the work has a clear finish line.

Examples:

  • "Update the empty state copy in BillingPlanPicker and adjust the related test."
  • "Add validation for this form field and show the existing error style."
  • "Fix the broken setup link in the docs page."
  • "Add a regression test for this reported route bug."
  • "Rename this public label across one feature area."

Those are not trivial tasks, but they have boundaries. A reviewer can tell whether the pull request did the job. The issue can name the expected files, behavior, constraints, and verification steps.

That is the kind of issue Switchboard can turn into background work. The value is not that the agent becomes unsupervised magic. The value is that structured work no longer needs a human to manually start every run.

A practical decision table

Use this table before starting work:

Question Manual run Switchboard
Is the task still ambiguous? Better fit Poor fit
Does the agent need active back-and-forth? Better fit Poor fit
Can one Linear issue become one pull request? Possible Better fit
Are acceptance criteria already clear? Possible Better fit
Is the work repeatable across many issues? Possible Better fit
Does it touch risky shared systems? Better fit first Only after scoping
Does it need local execution? Yes Yes, through the daemon
Does it need human review before merge? Yes Yes

The last two rows matter. Switchboard does not change Junction's local-first model, and it does not remove review. It changes how work is initiated and routed.

A manual run can become a Switchboard issue later

Many good automation workflows start manually.

Suppose you ask Claude Code to investigate why a settings page crashes on mobile. The agent finds that the same pattern appears in three components. At that point, do not automatically ask the same live session to refactor everything. Turn the discovery into smaller Linear issues:

  • "Fix mobile crash in settings section A."
  • "Fix mobile crash in settings section B."
  • "Add regression test for missing drawer data."

Now those issues may be ready for Switchboard. The manual run produced the context. Switchboard can handle the bounded follow-up work.

This is a healthy pattern: manual first for uncertainty, automation later for repeatable implementation.

Switchboard automation still needs a review model

Automation does not eliminate human-in-the-loop review. It moves the human decision to better checkpoints.

A useful review model includes:

  • issue quality before pickup,
  • scoped worktree isolation during the run,
  • notifications when attention is needed,
  • diff review before accepting the result,
  • and pull request review before merge.

General human-in-the-loop guidance often makes the same point in broader automation terms: approval workflows work better when reviewers see the evidence needed to make a fast, informed decision. For coding agents, the evidence pack is the issue, output, Git state, diff, test result, and pull request.

Junction puts those pieces near the agent session instead of scattering them across a terminal, chat log, and separate Git view.

What not to automate yet

Do not send a task to Switchboard just because it is inconvenient.

Keep it manual when:

  • the issue asks for product judgment,
  • the acceptance criteria are missing,
  • the work crosses many packages without a clear boundary,
  • the task touches migrations, billing, deployment, or destructive operations,
  • the issue is really an investigation,
  • or the reviewer would not know what a correct pull request looks like.

Those tasks can still involve Claude Code or Codex. They just need a human in the loop earlier.

How this maps to Junction plans

Junction's Free plan is enough to start with one saved daemon connection and two active or open chats. That is a good fit for trying manual local agent supervision.

Junction Core is for the core control plane without those daemon and chat limits. If you run multiple machines or keep several agent sessions open, Core is the plan that matches that workflow.

Switchboard is for teams that want Linear automation on top of Core. It adds the issue-to-pull-request path: watch Linear, pick up configured work, run agents in isolated worktrees, and move completed work toward review.

The plan difference mirrors the workflow difference:

  • Free: prove the local control surface with a small number of sessions.
  • Core: scale manual control across more daemons and open chats.
  • Switchboard: add structured automation from Linear.

Example workflow

Here is a concrete sequence that uses both modes well.

  1. Start a manual Codex run to investigate a flaky setup test.
  2. Read the output in Junction and ask for a narrower diagnosis.
  3. Codex finds two separate causes: unstable time mocking and a missing route assertion.
  4. You stop the broad run before it edits unrelated tests.
  5. You create two Linear issues, each with one expected fix and one verification command.
  6. Switchboard picks up the tagged issues.
  7. Each run gets its own isolated worktree and branch.
  8. Junction notifies you when each run needs input or reaches review.
  9. You review the diffs and pull requests before merging.

The manual session handled uncertainty. Switchboard handled bounded follow-through.

The simplest rule

If you would need to sit with the agent and explain the task as it unfolds, start manually.

If the issue already contains the explanation, constraints, and review path, use Switchboard.

That rule keeps automation useful without pretending every software task is ready to become a background job.

If you are still setting up local agent control, start with the Junction setup guide. If your team is deciding when to add Linear automation, compare pricing and read the Switchboard workflow overview.