← back to blog
Agent Loops Are Here: How to Set Up Your First Loop with Pane

Agent Loops Are Here: How to Set Up Your First Loop with Pane

Parsa · 2026-06-18

People are starting to call the workflow loops. The name is right. A coding agent wakes up, checks what changed, opens or resumes work, reads terminal output, sends the next prompt, and leaves you with the parts that need judgment.

Theo posted a good example: Codex went through stale PRs, closed the useless ones, reviewed the out-of-date ones, and spun each reviewed PR into its own thread. The interesting part is not that one agent wrote a lot of text. It is that the agent managed the workflow around the work.

That is exactly the shape Pane has been moving toward. Pane already gives your agents an open-source local control plane: list repos, add the current repo if Pane has not seen it yet, create panes, start Codex or Claude Code or any terminal CLI, read bounded terminal output, send input, and validate what happened before reporting success.

- - - - - - - - - - - - - - - -

the loop is not the scheduler

A scheduler is useful. It is also not the whole product. The harder primitive is workspace control: when the loop decides there are twelve things to do, where do those twelve things live?

You can run the outer loop today from Codex, Claude Code, a shell script, cron, a GitHub-aware skill, or whatever orchestrator you prefer. Pane supplies the thing those loops were missing: an agent-operable UI and terminal workspace.

- - - - - - - - - - - - - - - -

what pane adds

The runpane CLI now gives agents the primitives they need without teaching them Pane through a huge prompt. The first call is small:

runpane agent-context
runpane agent-context --command "panes create" --json
runpane agent-context --command "panels output" --json

From there the agent can set up the workspace:

runpane repos list --json
runpane repos add --path "$PWD" --yes --json

runpane panes create \
  --repo active \
  --name "review-pr-51" \
  --agent codex \
  --prompt "Review PR #51. Run checks, summarize findings, and stop before merging." \
  --yes \
  --json

And then the loop can actually validate the terminal it just created:

runpane panes list --repo active --json
runpane panels list --pane <pane-id> --json
runpane panels output --panel <panel-id> --limit 200 --json

printf 'Continue with the review pass.\n' | \
  runpane panels input --panel <panel-id> --input-file - --yes --json

runpane panels output --panel <panel-id> --limit 200 --json

That last line is the important UX detail. Agents are unreliable when they assume. They are much better when every mutating action gives them a next thing to check. Pane makes "did it actually work?" part of the loop.

- - - - - - - - - - - - - - - -

why this is different

Most loop demos quietly assume one model, one platform, one hosted queue, or one Mac-only app. Pane's version is deliberately less magical and more useful: if the agent runs in a terminal, Pane can host it. If the user is on Windows, WSL, macOS, Linux, a VM, or a remote machine, Pane can still be the visible workspace.

That means a loop can be simple:

Every 5 minutes:
1. Check GitHub issues and PRs.
2. Create or resume one Pane per active task.
3. Ask each agent to continue.
4. Read bounded terminal output.
5. Report only what needs human review.

First-class Pane scheduling is an obvious next primitive. But the loop is already usable because the CLI lets any agent operate the UI and terminal workspace today.

If you want the mechanical walkthrough, start with How to Set Up Your First AI Agent Loop with Pane. If you want the CLI/MCP tradeoff and install posture, read runpane CLI: Agent Control for Pane. If your agent needs the raw command surface, send it to the runpane CLI docs.