agent loops

how to set up your first ai agent loop

A loop is what happens when a coding agent stops being one terminal you babysit and starts managing the workspace around itself: picking work, opening isolated panes, checking terminal output, sending follow-up input, and handing you the pieces that need review. Pane makes that workflow agent-agnostic, cross-platform, and open source.

the shape of a loop

The useful version is not a magic prompt. It is a small operating loop:

first loop recipe

1. 1.

   install or update pane

   Use the package-manager path so both you and your agents can rely on the same runpane command:

   npx --yes runpane@latest
   pnpm dlx runpane@latest
   pipx run runpane

2. 2.

   let the agent discover pane

   Ask your agent to inspect Pane's public contract and local runtime state first. The default command context is intentionally small; detailed schemas are lazy-loaded only when needed.

   curl -fsSL https://runpane.com/runpane-cli-contract.json
   runpane doctor --json
   runpane agent-context --json
   runpane agent-context --command "panes create" --json
   runpane agent-context --command "panels wait" --json
   runpane agent-context --command "panels submit" --json

3. 3.

   register the repo if needed

   A loop should not assume Pane already knows about the repository. It can list saved repos, then add the current git repo when missing.

   runpane repos list --json
   runpane repos add --path "$PWD" --yes --json
   runpane agents doctor --agent codex --repo active --json

4. 4.

   spawn work for each task

   The loop can create a pane per issue, stale PR, review pass, or implementation stream. Use a built-in agent template or pass a custom terminal command for any other CLI.

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

5. 5.

   validate readiness and screen state

   After creating panes or sending input, the loop should verify what actually happened. Prefer the compact terminal screen for routine checks; fetch bounded scrollback only when you need history.

   runpane panes list --repo active --json
   runpane panels list --pane <pane-id> --json
   runpane panels wait --panel <panel-id> --for ready --timeout-ms 30000 --json
   runpane panels screen --panel <panel-id> --limit 80 --json
   runpane panels output --panel <panel-id> --limit 200 --json

6. 6.

   answer prompts and continue

   For ordinary follow-up text, use panels submit. Use panels submit-composer for Codex or Claude composer boxes, and keep panels inputfor exact bytes such as Ctrl-C or shell-sensitive payloads.

   runpane panels submit --panel <panel-id> --text "Continue with the review pass." --yes --json
   runpane panels submit-composer --panel <panel-id> --strategy auto --yes --json
   
   printf '\003' | runpane panels input --panel <panel-id> --input-file - --yes --json
   
   runpane panels wait --panel <panel-id> --for idle --timeout-ms 300000 --json
   runpane panels screen --panel <panel-id> --limit 80 --json

a starter prompt for your orchestrator

Give this to Codex, Claude Code, or any agent setup that can run shell commands:

You are running an agent loop for this repo.

Every cycle:
1. Inspect GitHub issues and PRs that need action.
2. Fetch the public contract if needed, then run runpane doctor --json and runpane agent-context.
3. Make sure this repository is saved in Pane and the requested agent is runnable.
4. Create one background-friendly Pane per task or review stream with --source agent and --wait-ready.
5. Start the right terminal agent in each pane with a clear initial prompt.
6. Use panels wait and panels screen before claiming a pane started correctly.
7. Send follow-up input with panels submit or submit-composer; use panels input only for exact bytes.
8. Report the panes created, what each is doing, and what needs human review.

Keep output brief. Do not merge without explicit human approval.

windows and wsl

Pane can run as a Windows app while your repo and agent live inside WSL. In that setup, a Linux shell may not see the Windows Pane daemon directly. The loop can call the Windows wrapper through PowerShell and choose the saved WSL repository by name or id:

powershell.exe -NoProfile -Command \
  'Set-Location $env:TEMP; runpane repos list --json'

powershell.exe -NoProfile -Command \
  'Set-Location $env:TEMP; runpane panes create --repo "Pane" --name "loop-smoke" --agent codex --prompt "Say hello from this loop and wait." --source agent --wait-ready --yes --json'

what pane does not pretend to own

Pane is the local control plane for the loop. Your agent can still use GitHub CLI, MCP servers, Linear, Jira, custom skills, shell scripts, or cron for the outside world. That is the point: Pane does not lock the loop into one model, one editor, one hosted queue, or one operating system.

First-class Pane scheduling is a natural next primitive. You do not need to wait for it to run loops today: use your existing agent CLI as the loop runner, and use Pane as the shared workspace it can manage. The exact issue-to-PR workflow is also packaged as open-source Codex and Claude Code skills.

useful next pages