MakionDocs ← makion.dev

How roles work

A role is the single most important choice you make before sending a task. You pick it in the Chat composer, and it decides two things at once: the agent's methodology — how it approaches the work — and, critically, its SAP permissions — which tools it is physically handed.

This page explains how roles scope the agent, how they are grouped in the picker, and what knowledge each role carries. Every user-pickable role is listed in the summary table at the end, with a link to its detail page.

A role is a permission boundary, not just a prompt#

Roles are enforced at the tool level, not by instruction. When you pick a role, Makion decides which SAP tools to pass to the agent for that run:

Object deletion is disabled for every role, unconditionally — read-only and write alike. No role can delete an SAP object; the request is blocked before it ever reaches SAP. See the Security model for how this is enforced.

Because the boundary is physical, "read-only" in Makion means read-only in fact, not just in intent. This is what lets you hand the agent a whole custom-code estate to analyze, or an incident to triage, with no risk that it changes anything.

Roles are grouped by product#

In the Chat composer the Role selector groups roles under three product headers:

Read-only roles carry a · read-only suffix in the dropdown so you can tell at a glance what a role can do before you pick it.

Every role carries knowledge#

A role is never just a bare permission set. Every role runs with:

  1. A baseline ABAP knowledge pack — the shared conventions and hard limits every Makion role respects.
  2. Your project's own base rules and knowledge — the standards an admin defines per project in the Methodology tab. This is how you make the agent follow your team's conventions. See Methodology and Configuring projects.

Some roles also carry extra role-specific knowledge packs — for example, the build and migration roles ship with focused knowledge for CDS, RAP, or Clean-Core work. Admins customize the base rules and knowledge per project, so the same role can behave differently across two projects on purpose.

Read-only vs write at a glance#

Read-only role Write role
Tools handed to the agent Read set only Read set plus write tools
Can it lock / set source / create / activate? No — physically cannot Yes, as part of the task you direct
Can it delete an SAP object? No No
Typical use Investigate, review, assess, diagnose Implement, test, migrate, build

A write role changes SAP during the conversation you are directing — that is the point of a write role. If you want a hard human-approve-and-apply gate on every write, use Autonomous mode instead.

System roles (Autonomous mode only)#

Beyond the user-pickable roles, Makion has a small set of hidden system roles used only by Autonomous mode's apply pipeline — for example the autonomous planner, the apply executor and writer, the batch activator, and the verifier. You never pick these in the composer; they exist to carry out the propose → approve → apply flow that a human gates. They are documented with Autonomous mode, not here.

All user-pickable roles#

Every role you can pick in the composer, grouped by product.

Development#

Role Read/Write Use it to…
Development Write Implement a requirement end to end — explore, reuse, plan, lock, validate, activate, report. The default role.
Architecture Read-only Get a solution design and plan (objects, patterns, data model, transport, risks) without touching SAP.
Code review Read-only Review target objects against your standards and get prioritized findings with fixes.
Unit tests Write (tests only) Write or extend ABAP Unit tests without changing production logic.
ATC check Write Run ABAP Test Cockpit and report grouped findings; fix only if you ask.
ATC remediation Write Run ATC and fix findings one category at a time, behaviour-preserving, on its own transport.
Research Read-only Investigate and answer questions with evidence — a safe first role.
Specification Read-only (SAP) Turn a raw client spec into Makion's normalized spec format.
Effort estimate Read-only Turn a spec into an honest, banded effort estimate you can download.
CDS Write Design and build real CDS VDM data models bottom-up.
RAP Write Build a complete RAP business object, data model through service.
Fiori Write Make an OData service Fiori-Elements-ready with a @UI annotation layer.
Migration Write Interactively prep one object for ECC→S/4HANA / Clean-Core, human-approved.
Migration Map Read-only Analyze a custom-code estate for an S/4 migration and classify objects by usage.
Clean-core check Read-only Audit objects for S/4HANA clean-core compliance.
Adobe Forms Read-only (SAP) Clone and adapt a SAP Interactive Form and get a finished XDP to paste.

Consulting#

Role Read/Write Use it to…
Assessment Read-only Produce a current-state assessment of a scoped custom-code area.
Authorization Review Read-only Derive required auth objects from code and report missing vs over-grant.
Interface Inventory Read-only Inventory interfaces (RFC, ALE/IDoc, Gateway) from config and code.
Delivery Report Read-only Assemble the client-facing deliverable with a GO / GO-WITH-WARNINGS / NO-GO verdict.
Migration Map Read-only (Also here) Estate analysis for ECC→S/4 planning.
Clean-core check Read-only (Also here) Audit objects for clean-core compliance.

Support#

Role Read/Write Use it to…
Diagnose Read-only Triage an incident from one anchor and rank likely root causes.
Health Check Read-only Run a fast morning sweep for stuck IDocs, failed jobs, and dumps.
IDoc Triage Read-only Deep-dive an IDoc failure and hand off the exact manual reprocess step.