AigentFlow Desktop is in pre-release. This documentation reflects the current build and will change before general availability.
Working with agents
Session modes
A mode is a promise about what the agent may do in this session. It is the main control you have, and it is enforced outside the part of the app the agent can reach.
Every session runs in one of six modes. They form a ladder: each rung allows everything the rung below allows, and a little more. A new session starts in Discuss.
| Mode | What it may do |
|---|---|
| Discuss | Reads and answers. Nothing on disk changes. |
| Plan | Reads, writes you a plan, and stops. Approving the plan is what moves the session to Working. |
| Review | Reads and runs read-only inspection, then ends with a verdict and evidence. Writes nothing. |
| Guarded | Edits files and nothing else. No network, no shell, and no writing to dependency manifests, lockfiles or .env files. |
| Working | Edits and runs safe commands. It states its plan and waits. |
| Autopilot | Runs unattended and approves its own plans, inside a budget. |
Changing the mode
The badge in the instruction bar toggles between Discuss and Working, which are the two you will use most. The other four are reached by typing a command.
/mode show the current mode and the alternatives /mode guarded switch to a named mode /plan /review /guarded /working /autopilot
The app also suggests a mode as you type. A question suggests Discuss, an instruction to change something suggests Working. It is a suggestion on the bar, never a switch made for you.
Every mode change is recorded, with the reason you gave and the promise you moved to. Widening the mode is recorded as a warning, so it stands out when you read the history later.
What actually stops an agent
The mode is checked before a tool runs, in the part of the app the agent cannot reach. Alongside it, three other limits apply in every mode.
- A file budget. Once a run has changed its allowance of files, a new one is refused. Editing a file it has already changed stays allowed.
- A loop guard. The same tool aimed at the same target too many times in one session is refused, so a stuck agent stops instead of grinding. The count is for the session, and doing something else in between does not reset it.
- A dangerous command list. Recursive deletes of the root or home directory, force pushes, hard resets,
git clean, dropping or truncating tables, writing to a raw disk,mkfs,dd, the classic fork bomb, publishing a package, and piping a download straight into a shell.
When something is refused you see it in the governance record, and if a mode blocked the tool the app offers to switch to Working and carry on. That switch is yours to make.
Claude and Codex are not enforced the same way
This matters, and the app says so on every mode. On Claude the check runs before the tool executes, so a blocked action never happens. On Codex the sandbox is the enforcement, and the app sees an action after it has started, so a breach of the mode promise is reported to you rather than prevented.
In practice: in Guarded on Codex a shell command runs inside a workspace-write sandbox and a write to a lockfile is caught after the fact. In Guarded on Claude the shell is simply not available.
Autopilot
Autopilot is the only mode that asks you to confirm before it starts, because it is the only mode that acts without asking again. The confirmation states the budget in full.
| Limit | Value |
|---|---|
| Turns | 30 |
| Spend | $5 |
| Changed files | 20 |
The run stops before the next turn once any one of the three is reached, so a turn already in progress finishes rather than being cut off. The mode then narrows to Working and tells you which limit ended it.
The budget belongs to the tab, not to the session. Restarting the session in that tab, or switching model, does not hand it a fresh thirty turns. Leaving Autopilot resets the counters, and re-entering asks for consent again.
If you run a team, each member started counts a turn and its changed files count against the same budget. Spend counts only the sessions in that tab.
Narrowing the mode stops the team
If a lead is running team members and you narrow the session below Working, every running member is stopped and named back to you. Their work is contained rather than failed, and their reports still reach the lead.