Every SAP Basis team already automates. Background jobs run nightly in SM36, monitoring scripts poll RFC destinations, and integration middleware posts documents through a communication user that nobody has looked at in years. The question is not whether to automate SAP operations. It is which automation model you trust with production once an AI agent is the one deciding what to run.
This comparison covers the three models most teams weigh when they bring AI into SAP Day 2 operations: a broad technical service account, fixed scheduled scripts, and a governed agent runtime. Each is a reasonable choice for some work. They differ sharply in who decides what runs, how far a mistake can reach, and what your auditors can reconstruct afterwards.
The three models at a glance
| Broad service account | Scheduled scripts | Governed agent runtime | |
|---|---|---|---|
| Who decides what runs | The calling system, at runtime | A human, at design time | The agent proposes, policy decides |
| Scope of access | Everything in the authorization profile | Whatever the script was written to call | One capability at a time, per tool call |
| Handles new situations | Yes, without limits | No, only the scripted path | Yes, inside the policy boundary |
| Human approval before a write | Not built in | Only when the script was designed with one | Set per tool: Full, Approval or Blocked |
| Audit trail | Security audit log entries under one technical user | Job logs in SM37 | Every governed action with tool, risk, status and approval state |
| Blast radius of a mistake | The whole profile | The script's fixed path | The single action that was allowed |
The table hides one important nuance. Scheduled scripts are the safest of the three precisely because they cannot adapt. That is also why they cannot triage an incident they were not written for.
Model 1: The broad technical service account
This is the default when an agent is wired straight into SAP. You create a communication user, give it a profile with S_RFC, S_TABU_DIS and a handful of transactions, and point the agent at it.
It is fast to set up and the agent can do almost anything it reasons its way into. That is the problem. A language model plans its steps at runtime, so its real permissions are the outer edge of the profile, not the task you had in mind. If the profile allows posting financial documents, an agent asked to check open invoices can still call a posting BAPI.
The audit trail does not help much either. Every action lands under the same technical user, so an SoD review sees a stream of activity with no record of why each call was made or who, if anyone, agreed to it.
Use it for: read-only reporting where the profile genuinely contains no write authorizations.
Model 2: Fixed scheduled scripts
Scripts and background jobs are deterministic. A human writes the path once, reviews it and schedules it. Nothing runs that was not designed in advance.
That makes scripts excellent for known, repeatable work: nightly housekeeping, spool cleanup, regular health checks. It makes them useless for the work an agent is actually brought in for, which is reasoning about an alert nobody predicted and deciding what to inspect next.
Use it for: recurring, well-understood tasks where the steps never change.
Model 3: A governed agent runtime
A governed runtime keeps the agent's ability to reason through new situations but moves the decision about what may execute out of the model and into policy. The agent can propose any step. Policy decides whether it runs.
| Governance level | What happens when the agent calls the tool | Typical SAP Basis examples |
|---|---|---|
| Full | Runs immediately under policy guardrails and is logged | Reading SM21 system logs, checking SM37 job status, testing an RFC destination in SM59 |
| Approval | Pauses for a human to approve inline, then runs | Reprocessing an IDoc, restarting a failed background job, clearing a stuck update |
| Blocked | Never runs, and the attempt is recorded | Changing user authorizations in SU01, editing table contents directly |
This is the model Luumen is built on. Governance is set per tool as Full, Approval or Blocked, permissions scope to the individual tool call, and every governed action lands in one queryable audit log with its session, tool, risk, status and approval state. Governed integrations go further: each connection is a capability with a risk level, schemas, an approval floor and evidence requirements, reviewed before it is enabled.
Use it for: incident triage and remediation on production systems, where you want the agent's judgement but not its unchecked authority.
How to choose
Most landscapes end up running all three, each where it fits:
- Keep scheduled scripts for recurring work whose steps never change.
- Retire broad service accounts for anything an agent touches, or strip them to read-only.
- Put agent-driven work on production behind a governed runtime, starting with read tools at Full and every state change at Approval. Loosen individual tools only after the audit log shows they behave.
The deciding question is simple. When the agent is wrong, which model lets you see it, stop it and prove afterwards what happened? For production SAP, only the governed model answers all three.