An agentic change, end to end

Now the agent gets to change something, in a controlled way. The task: Contoso's order-to-cash key user Maria reported that users can add items to a core return agreement that is already CLOSED. Kenji asks a developer to fix it with an agent in CMD client 100, inside software component ZCMC_CLOUD. The business object is ZR_CMC_CoreAgreementItem; the behavior pool is ZBP_R_CMC_COREAGREEMENT; status values are OPEN and CLOSED.

Before the agent starts

• Access restrictions: project CMD only; writable package: the core agreement package only.
• Edit file tool enabled for this exercise; quick-fix tools with AI and feed tools deselected.
• A transport request exists for the change, created by the developer, and the agent is told its number.
• The prompt states the rule, the objects, the constraints and the definition of done.

What the loop looks like

Expect iterations. Activation often fails the first time: a missing method declaration, a wrong field name. The agent reads the error and edits again. That's normal, and it's why the activation result, not the agent's confidence, is the signal. If the agent loops more than a few times on the same error, stop it and read the code yourself.

If the edit tool is off

The edit file tool controls edits made through the MCP server. It isn't the only way an agent can change source. SAP's agentic loop scenario shows the MCP host's own built-in edit tool writing the implementation into the source file opened in the editor, and agents that support VS Code's virtual file system can edit ABAP files that way. So switching the MCP edit tool off doesn't make an agent in VS Code read-only. To keep a session truly read-only, also restrict the host's own file-editing permissions, or use package restrictions so that any change attempt outside the pilot package fails. Know which edit path your agent uses before you rely on either control.

Tests and ATC

The agent adds a local test class in the behavior pool's test include. Good RAP tests isolate the database and the transactional buffer: SAP documents transactional buffer test doubles and mock EML APIs for exactly this. Check that the agent's tests cover both the CLOSED case (item rejected, message filled) and the OPEN case (item accepted), and that each would fail if the validation broke (see sap-abp-205).

ATC runs asynchronously through MCP: abap_run_atc starts a run and returns an ID, and abap_atc_get_result fetches findings. The agent may apply deterministic quick fixes (classic quick fixes SAP attaches to some findings) without Joule tokens. AI-based fixes use tokens and, at Contoso, are left off in this exercise. An ATC exemption is never the agent's call: abap_atc_exemption_request sends a request to an approver, and Contoso's rule is that only a person requests exemptions.

When to stop the agent

• It edits an object outside the task, or asks to.
• It repeats the same failing step more than three times.
• It proposes to create a new transport when the prompt named one.
• It reports success without showing test or ATC results.
• It reads text (a comment, a message, a document) and starts following instructions in it.

Stopping isn't failure. It's the moment where a developer's judgment is worth most. Note what happened in the pilot log; patterns across sessions tell you which AGENTS.md rules or tool selections to change.

Review: the diff tells the truth

The unified diff tool, added in version 1.1, produces a git-like diff for all objects in a transport request. SAP's release blog suggests prompts such as "Explain transport XYZ" or "How much impact does transport XYZ have on the system?". For review, use it the other way round: read the diff yourself and check that the transport contains only what the task asked for. An agent that "helpfully" reformatted an unrelated method shows up here.