AI agent workflows
imux works best when each agent session has a clear workspace, visible files, a bounded objective, and a human review loop. Use these patterns when running Claude Code, Codex, Gemini CLI, OpenCode, Aider, or any other terminal-based coding agent.
# One workspace, one concrete task
icc new-workspace
cd ~/work/app
claude
# Mark state for the operator
icc notify --title "Agent waiting" --body "Review the proposed patch"
icc sidebar status set review --label "Review" --value "needed"Run one meaningful objective per workspace
A workspace should represent one repo, one remote host, or one concrete investigation. This keeps the terminal, file explorer, Git state, browser surface, and supervisor context aligned.
- Create a new workspace for each unrelated task instead of piling every agent into one terminal.
- Rename the workspace after the outcome you want, not after the tool name.
- Keep the most relevant files open so the active task has visible evidence beside the shell.
Use terminal agents as execution engines, not hidden workers
The agent can run inside the shell, but the operator should keep the surrounding evidence visible. imux makes that easier by keeping files, browser previews, notifications, and Git state attached to the same workspace.
- Launch the agent from the repo root or the intended remote path.
- Ask for bounded changes with a clear done condition.
- Verify changed files and command output before asking for another step.
Route attention with notifications and metadata
Long-running agents are easier to supervise when scripts can signal progress, completion, or failure into the workspace UI.
- Use `icc notify` from hooks when an agent needs human input.
- Use sidebar status entries for CI, deploy, preview, or review state.
- Use the latest-unread jump shortcut to return to the next workspace that needs attention.
Keep the review loop local and concrete
Agent output is not enough. imux is designed so the human can inspect paths, run tests, open the browser, read console errors, and review Git state before accepting work.
- Open changed files immediately after a meaningful edit.
- Run the narrowest useful verification command first.
- Only package, commit, or deploy after reviewing the visible working tree.
A strong agent brief
- Name the repo, folder, or SSH target first.
- State the exact outcome needed in one sentence.
- List the files, commands, URLs, or logs that matter if you already know them.
- Define what counts as done before the agent starts changing code.
- Ask for verification evidence, not just a summary.