Build a governed autonomous replenishment agent for SAP S/4HANA with Claude and MCP

Objective

Build an agent-assisted replenishment workflow that can identify materials configured for reorder-point planning, read current stock and planning parameters, determine whether replenishment is required, calculate a proposed quantity, retrieve sourcing information from SAP, create a purchase requisition and retain a complete decision and execution record.

The target is not unrestricted “autonomous ERP.” It is bounded execution over an existing SAP decision model, with deterministic controls before every write.

Reference scenario

A user submits a request such as: Check replenishment status for plant 1010 and run the replenishment process.

The agent should not receive material numbers, vendor choices, reorder points or quantities in the prompt. It should retrieve them from governed SAP records and use existing sourcing logic where available.

Required inputs

SAP configuration

• Plant and storage-location scope
• Materials using reorder-point planning
• Reorder point and maximum stock
• Current unrestricted and relevant available stock
• Open purchase requisitions and purchase orders
• Source list or purchasing info records
• Units of measure, lead times and lot-sizing rules
• Authorization model for requisition creation

Technical components

• SAP S/4HANA sandbox or test environment
• Published APIs for materials, inventory, sourcing and purchase requisitions
• A custom MCP server exposing narrowly defined SAP tools
• A Claude-compatible agent runtime
• Secure identity and credential handling
• Execution logging and a controlled test dataset

Control inputs

• Permitted plants and purchasing organizations
• Maximum autonomous quantity or value
• Approved material groups
• Exception and confidence thresholds
• Duplicate-request controls
• Approval requirements
• Idempotency policy

Reference architecture

User or scheduled trigger
        ↓
Agent runtime
        ↓
Planning and tool-selection logic
        ↓
Custom MCP server
        ↓
Read-only SAP tools
  • list relevant materials
  • read planning parameters
  • read current stock
  • read open supply
  • retrieve source information
        ↓
Decision validator
  • configuration completeness
  • quantity calculation
  • duplicate and threshold checks
        ↓
Approval gate where required
        ↓
SAP purchase-requisition API
        ↓
Execution verification and audit log

The agent orchestrates the workflow, but authoritative business data and core planning rules remain in SAP S/4HANA. The MCP layer should expose business-level operations rather than unrestricted transaction or database access.

Step 1 — Define the decision boundary

Document exactly what the agent may decide. For an initial deployment, allow it to scan one approved plant, evaluate only reorder-point materials, propose replenishment using an approved formula, create purchase requisitions only below a defined threshold and reject records with incomplete planning or sourcing configuration.

Do not allow the first version to change master data, create vendors, modify reorder points or release purchase orders.

Step 2 — Define the decision formula

A basic policy may use:

Net replenishment need =
maximum stock
− relevant available stock
− confirmed incoming supply
+ approved reservations or demand adjustments

The exact formula must reflect the organization’s policy. Simply subtracting current stock from maximum stock may be wrong when open supply, quality stock, safety stock, reservations, lot sizes or unit conversions matter.

Step 3 — Build read-only MCP tools first

list_reorder_point_materials(plant)
read_material_planning_parameters(plant, material)
read_inventory_position(plant, material)
read_open_supply(plant, material)
read_source_determination(material, plant)
read_existing_requisitions(material, plant)

Each tool should validate input, use a dedicated SAP identity, return structured data, include source timestamps, distinguish missing values from zero and avoid exposing unrelated records.

The first end-to-end test should stop after producing recommendations.

Step 4 — Normalize SAP data before reasoning

{
  "plant": "1010",
  "material": "198",
  "mrp_type": "reorder_point",
  "current_stock": 30,
  "reorder_point": 50,
  "maximum_stock": 100,
  "open_supply": 0,
  "unit": "KG",
  "source_valid": true,
  "configuration_complete": true
}

The agent should reason over a normalized decision object rather than raw OData responses.

Step 5 — Add deterministic eligibility checks

• Is the material within the permitted scope?
• Is reorder-point planning active?
• Are stock and planning units compatible?
• Is a maximum stock value present?
• Is there already sufficient open supply?
• Is an approved source available?
• Is the proposed quantity positive?
• Does it remain below the autonomous threshold?

Any failed test should create an explicit exception, not a silent skip.

Step 6 — Separate calculation from explanation

Use deterministic application logic for the authoritative quantity calculation. The model may choose the next permitted tool, interpret exception context, produce a user-readable explanation and assemble an execution plan. It should not perform the final arithmetic only in free-form text.

Step 7 — Retrieve sourcing through SAP

Where possible, rely on SAP source determination for vendor selection, purchasing organization, purchasing group, price source, purchasing info record, source list or quota arrangement.

The agent should never infer a supplier from conversational context.

Step 8 — Add one constrained write tool

create_purchase_requisition(
  plant,
  material,
  quantity,
  unit,
  requested_date,
  approved_source_reference,
  agent_run_id
)

The MCP server should reject unsupported plants or materials, quantities above the threshold, missing source references, duplicate run IDs, stale inventory snapshots and writes lacking a required approval token.

Step 9 — Require an execution plan before the write

{
  "decision": "create_purchase_requisition",
  "material": "198",
  "plant": "1010",
  "quantity": 70,
  "unit": "KG",
  "reason": "Stock of 30 KG is below the reorder point of 50 KG; target maximum is 100 KG.",
  "source": "SAP source determination",
  "approval_required": true
}

This object becomes the basis for approval, execution and audit.

Step 10 — Verify the SAP transaction

After creation, read the requisition back from SAP and verify the document number, plant, material, quantity, unit, source assignment, price where relevant, creation time, origin reference and status.

A tool response saying “success” is not sufficient.

Validation plan

1. Stock above reorder point — no requisition.
2. Stock below reorder point — correct quantity proposed.
3. Existing open requisition covers the shortage — no duplicate.
4. Missing maximum stock — exception.
5. Missing source determination — exception.
6. Incorrect unit conversion — blocked.
7. Quantity above threshold — approval required.
8. API timeout after write — reconcile before retrying.
9. Concurrent runs for the same material — only one requisition.
10. Material data changes between read and write — stale plan rejected.

Compare the result against SAP MRP or the approved replenishment policy, a manual planner calculation, existing requisition records, unit-conversion tables and sourcing configuration.

Production risks

Incomplete planning data

Materials with incomplete configuration should enter a visible remediation queue rather than disappear from the workflow.

Wrong inventory definition

“Current stock” may not equal available stock. Quality inspection, blocked stock, reservations, transfers and open supply can materially change the decision.

Duplicate execution

A timeout can leave the agent uncertain whether SAP created the document. Retrying without reconciliation may create a duplicate requisition.

Prompt injection through business data

Free-text material descriptions, vendor notes or email content must never be treated as trusted instructions.

Excessive tool authority

An MCP server exposing generic SAP writes gives the agent a much larger action surface than the use case requires.

Planning-policy drift

If SAP planning parameters are outdated, the agent may execute the configured policy correctly while producing a poor operational result.

Scaling checks

• Thousands of materials rather than a demo subset
• Parallel runs across plants
• API limits and long-running workflows
• Identity propagation and transaction locking
• Recovery after partial failure
• Master-data changes during execution
• Approval latency
• Planner workload created by exceptions
• Reconciliation with MRP and procurement workflows

Success metrics

• Correctly identified replenishment needs
• False-positive requisition rate
• Duplicate-document rate
• Share requiring human escalation
• Time from stock signal to approved requisition
• Planner time saved
• Exception-remediation time
• Service-level and excess-inventory impact
• Audit and reconciliation failures

Dataleo perspective

The useful architecture is not an AI that “knows how much to buy.” It is an agent that discovers the relevant SAP state, invokes narrowly authorized tools and executes a bounded decision whose rules remain traceable to the system of record.

The condition for trust is transactional control: deterministic calculations, scoped identities, stale-data checks, idempotency and post-write reconciliation. The principal failure mode is correct execution against an incomplete planning model. An agent can automate weak reorder points, missing open-supply logic or outdated sourcing rules faster than a human planner.