Configuring projects
This is the page that answers the central question: how do I make Makion follow our exact instructions when it builds code or acts in the system? The answer is a project. A project pairs a SAP system with the settings and standards that shape every task run against it — the AI engine, the ABAP flavor, whether it may run unattended, and the rules, roles and examples the agent reads on every run.
Set a project up well once, and every developer who works in it gets the same, predictable behavior. This page walks the whole setup in order.
One project per "team × SAP system × way of working." If two teams have different standards or different systems, give them separate projects and tune each independently.
The four things that steer the agent#
Makion's behavior on a project comes from four layers, set across two tabs:
| Layer | Where you set it | What it controls |
|---|---|---|
| Target & engine | Admin tab → Projects table | Which SAP system, which ABAP flavor, which AI engine, and whether autonomous runs are allowed. |
| Base rules | Methodology tab | The standards the agent always follows — naming, patterns, do / don't. |
| Role methodologies | Methodology tab | How each role behaves, and whether that role may write to SAP. |
| Knowledge base | Methodology tab | Standards and worked examples the agent reads every run. |
The precise mechanism: on every task, Makion combines base rules + the role the developer picked + the knowledge-base files into the context the agent works from. So precise base rules + good examples = the agent "follows instructions" reliably. The Methodology page explains this layering in full; this page tells you the order to do it in.
Setup checklist#
1. Create the project#
From the top-bar Project selector, click + New project and give it a name. The person who creates a project becomes its project admin, so they can manage its methodology and members even without being a superadmin. See Sign in & projects for the selector.
2. Point it at a SAP system#
Open the Systems tab and set up the SAP connection this project targets — tiers DEV / QAS / PROD, where QAS and PROD are read-only. Then, in the Admin tab's Projects table, set the SAP system column to that system so the project and its connection are paired.
3. Set the project's technical profile (Admin → Projects)#
In the Admin tab, the Projects table has one row per project. Set:
| Column | Choices | What it does |
|---|---|---|
| Project | — | The project name (read-only label for the row). |
| SAP system | your configured systems | Which SAP system this project targets. |
| ABAP flavor | modern (7.40+ / S/4) or classic (<7.40 / ECC) | Shapes which language constructs and patterns the agent uses — modern inline / CDS / RAP style versus classic ECC-safe ABAP. Set this to match the target system. |
| Engine | Claude, Gemini, Codex, Kimi, or Grok | Which AI model runs this project. See AI engines & login. |
| Autonomous | checkbox | When on, this project may run unattended agent runs. See Autonomous mode. |
Autonomous ON allows unattended agent runs. Autonomous work is still read-only and proposes changes into a ship queue that a human approves and applies — but leave it off for projects that should only ever run interactively. See Autonomous mode.
4. Write the methodology (Methodology tab)#
Open the Methodology tab and set the three blocks — this is where "follow our exact instructions" is actually encoded:
- Base rules — the standards the agent always follows on this project, no matter the role: naming conventions, clean-core expectations, transport discipline, review habits. Write them in plain language and click Save base rules. Precise, unambiguous base rules are the single biggest lever on how faithfully the agent works.
- Roles — for each role the developer can pick in Chat, edit its methodology and toggle Can change SAP (write). Unchecked means read-only: the agent is physically handed only read tools. Tune each role to say exactly how your team builds, reviews, or supports ABAP. See How roles work.
- Knowledge base — add standards and worked examples as files (for example a canonical "how we structure a report," a preferred error-handling pattern, a pre-finish checklist). These are read on every run, so they are the best place for concrete examples the agent should imitate.
5. Add the developers#
Give the people who will work in the project access:
- A superadmin uses Admin → Project access and ticks the checkbox for this project in each developer's row.
- A project admin uses the project's Members tab — Add a developer, then set their role.
Full detail is in Users & access.
After setup#
- Developers pick the project in the top-bar selector, connect in Systems, and work in Chat.
- Refine as you learn: tighten base rules, add examples to the knowledge base, and let Retro surface rule and knowledge fixes from real sessions.
- Everything the agent does is recorded — see the Audit trail.
Where to go next#
- Methodology — the base rules, roles and knowledge base in full.
- AI engines & login — choose and authenticate the project's engine.
- Users & access — grant access and manage members.
- Autonomous mode — how unattended runs propose changes for human approval.