Autonomous mode
Autonomous mode lets the agent work unattended. You hand it a task or an existing specification, it works on its own against your SAP system entirely read-only, and it can only propose changes — never write them. Every proposal lands in a ship queue, where a human approves it and, in a separate deliberate step, applies it to SAP.
This is the strongest safety gate in Makion. In interactive Chat a write role changes SAP as you direct it; in Autonomous mode there is no such shortcut — the agent's SAP access is read-only for the entire run, and the only path to a write is a human clicking Apply to SAP. See the Security model for how this is enforced.
Who can use it, and enabling it#
The Autonomous tab is visible only to a project admin, and it must be enabled per project by an admin.
If the tab is disabled you will see:
Autonomous mode is not enabled for this project — an admin can enable it in the Admin panel
An admin turns it on for a project in the Configuring projects panel. It is off by default and applies only to the project it is enabled for.
The apply pipeline in one picture#
The whole model is three stages, and each stage after the first is a human action:
- Propose (agent, read-only) — the agent runs unattended and writes its intended changes into the ship queue as proposals. Nothing touches SAP.
- Approve (human) — a person reviews a proposal and approves or rejects it. Approving only records your decision — it does not write anything.
- Apply (human) — a person clicks Apply to SAP. This is the only step that writes. Applying a single proposal writes one object; applying all approved proposals writes them all and then activates them (see Apply all — the two-phase process).
Approving is not applying. A proposal can sit Approved indefinitely with zero effect on SAP. The live system changes only when a human clicks Apply to SAP and confirms.
The launcher#
The launcher starts and controls an autonomous run.
| Control | What it does | When it appears |
|---|---|---|
| Project: {name} | A line naming the project this run targets. | Always |
| Describe the task for the agent | A textarea for a plain-language task. Mutually exclusive with the specification select — use one or the other. | Always |
| …or run an existing specification | A select to run a saved specification instead of a typed task. Mutually exclusive with the task text. | Always |
| Run | Starts the run. Shows Running… while in flight. | Always |
| Stop | Drops the live stream but leaves the run resumable — the work is not ended, only detached from your view. | While a run is in flight |
| Cancel run | Ends the run server-side. Shows Cancelling… while it finishes. | While a run is in flight |
Provide either a task description or a specification, never both — the two inputs are mutually exclusive.
Failure and resume#
An autonomous run can stop before it finishes. When a run has failed or halted, a banner shows a typed reason and a way to continue:
- AI limit — the AI subscription or engine hit a limit.
- Auth — an authentication problem (AI engine or SAP sign-in).
- Network — a connectivity problem.
- SAP — an error returned by the SAP system.
- Other — an unclassified error.
- Halted — the agent stopped itself deliberately.
The banner carries a Resume button, which continues from the first unfinished step rather than starting over.
Watching a run#
While and after a run, the tab shows its progress:
- Live log / output — the agent's running narration and output.
- Result summary — a short summary of what the run produced.
- Steps — the run broken into steps, so you can see how far it got.
- Recent runs — a list of prior runs for this project to revisit.
The ship queue#
The ship queue — Proposed changes (ship queue) — is the list of changes the agent wants to make. Nothing in it has touched SAP.
Approving only records your decision — nothing touches SAP until you explicitly apply an approved item.
Each proposal moves through a fixed set of states:
Pending → Approve → Apply (writes to SAP).
Per-proposal controls#
Each proposal shows a Requirement (what change is proposed) and a Rationale (why the agent proposes it), a status, and its own actions.
| Field / control | What it does |
|---|---|
| Requirement | The change the agent proposes. |
| Rationale | Why the agent proposes it. |
| Status | One of Pending, Approved, Rejected, Applied. |
| Approve | Records approval. Does not write to SAP. |
| Reject | Records rejection. Does not write to SAP. |
| Delete this proposal | Removes the proposal from the queue. |
| Apply to SAP | Writes this one change into SAP. Shows Applying… while it runs. |
Apply to SAP is the only per-proposal action that writes. It carries a ⚠ warning — Applying WRITES this change into the live SAP system — and a confirm dialog:
Write this change to {object}… cannot be undone. You must click Yes, write to SAP to proceed, or Cancel to back out.
Bulk actions#
The queue also offers actions across many proposals at once:
| Action | What it does |
|---|---|
| Approve all pending | Approves every pending proposal at once (asks you to confirm). Still does not write to SAP. |
| Apply all approved to SAP | Writes and activates every approved proposal in a two-phase process (see below). |
| Clear rejected | Removes all rejected proposals from the queue. |
| Clear all non-applied | Removes every proposal that has not been applied. |
Apply all — the two-phase process#
Apply all approved to SAP does not write objects one at a time. It runs in two phases over exactly the set of approved proposals — the same shape as activating a transport:
- Phase 1/2 — writing… — all objects are written inactive.
- Phase 2/2 — activating… — a single mass activation runs over exactly that set of objects.
Writing everything inactive first, then activating the whole set together, avoids the broken intermediate states you would get from activating objects one by one when they depend on each other.
Related pages#
- Security model — how read-only access and the human apply gate are enforced.
- Chat — the interactive surface, where a write role changes SAP directly.
- Specifications — saved specs you can run in Autonomous mode.
- Configuring projects — where an admin enables Autonomous mode per project.