Agent execution

Where the agents can run

Both agents were checked against four places code could run. Only one is supported today.

The run planner is designed around that: it prepares the exact commands for your machine and reads the output you bring back, entirely in your browser.

Interactively

cd your-project
albertcode            # or: albert-mini

Type a request. The current mode decides what a change does (see Architecture); /plan and /do choose for one request.

Answering the gates

In the terminal a gate is a question over the prompt; in the browser it is a card. mini-AlbertCode documents a key for every answer, the same in both interfaces:

An answer given in one interface is seen at once in the other, and a task is never answered twice.

From a script: run

Both agents send one request without the interface, print what happens, and end with the answer or the change:

albertcode run "Why does the cart total round down?" --lane ask
albertcode run "Add a test for the 10% code" --approve plan,result
albert-mini run "rename the helper" --lane direct_auto --json

Without --approve, a governed change stops at its plan and exits with code 3. Open the session to read and answer it (albertcode --session <id>, albert-mini -s <id>, or either browser).

mini-AlbertCode documents its exit codes in full:

From a script: one step at a time

AlbertCode SWE Agent also exposes every step of a governed task as a subcommand that prints JSON, so a script can hold each gate:

TASK=$(albertcode create "Add tests for the billing module" --workspace ./repo | jq -r .id)

albertcode show    "$TASK" | jq -r .state     # wait until it says plan_ready
albertcode approve "$TASK"                    # approval 1: the plan
albertcode show    "$TASK" | jq -r .state     # wait until it says completed
albertcode diff    "$TASK"                    # read the change
albertcode accept  "$TASK"                    # approval 2: apply it

albertcode reject <task> discards a plan; albertcode rollback <task> throws away a task you have not accepted.

In CI

The run command and the installers' --yes option are what a CI job needs. A sketch for a job that asks a question and keeps the event log:

curl -fsSL https://raw.githubusercontent.com/huynvic/mini-albertcode-swe-agent/main/installer/install.sh | sh -s -- --yes
albert-mini run "Summarise what changed in this branch and any risk you see" --lane ask --json > run.jsonl

A job also needs a model connected without the interactive step. AlbertCode SWE Agent's profiles do that, and suit scripts and shared services:

albertcode configure --name local --provider local --base-url http://localhost:11434/v1 --model <model>
albertcode --profile local

Guides for specific CI systems aren't published yet — "Guides for running AlbertCode in CI" is on the roadmap. Treat this as a starting point, not a supported recipe.

Inspecting results

Bring output back to the run planner to read it:

• the --json event log of a run, and its exit code;
• albertcode show <task> — the task as JSON, with its state;
• albertcode diff <task> — the files and the unified diff, as JSON;
• git diff after accepting a change.

The inspector runs in your browser and never uploads what you paste. The --json event format isn't publicly documented, so events are shown generically: their type and message fields, with error-looking events highlighted.