How s4ready.ai Works: Multi-Agent Architecture for SAP Migration

Most “AI for SAP” demos show a chatbot that answers questions about ABAP. s4ready.ai is a different class of tool: a multi-agent platform where specialised agents perform verifiable, auditable work on a real ABAP codebase, against a real SAP system, with human approval gates before anything changes. This post explains the architecture behind that claim.

The Agent Topology

The platform runs seven specialised agents, each with a distinct scope, toolset, and output contract:

Agent	Role	Primary Output
A1 Readiness	Assess ABAP objects against 30+ S/4HANA compatibility rules	Risk-scored findings report
A2 Remediation	Rewrite flagged ABAP to use released APIs	Unified diff + remediated source
A3 Test Gen	Scaffold ABAP Unit test classes for custom objects	Test class source files
A4 Docs Gen	Reverse-engineer undocumented code to functional specifications	Markdown specification documents
A5 Data Migration	Build Migration Cockpit objects and data quality rule sets	Migration object config + DQ rules
A6 RAP Builder	Generate RAP Business Objects, OData bindings, and Fiori Elements annotations	CDS + BDEF + service binding source
A7 UI5 Check	Analyse custom SAPUI5/Fiori apps for BTP and S/4HANA compatibility	Findings report + upgrade guidance

None of these agents operate autonomously end-to-end. Each produces outputs that are reviewed by the Orchestrator (for sequencing and completeness) and by a human (before any write action on the SAP system).

Full Platform Architecture

flowchart TD
    subgraph Client
        WEB[Web Application\nNext.js on Vercel]
        API[API Gateway\nNode.js / Hono]
    end

    subgraph Agent Platform - Railway
        ORC[Orchestrator\nworkflow state machine]
        A1[A1 Readiness]
        A2[A2 Remediation]
        A3[A3 Test Gen]
        A4[A4 Docs Gen]
        A5[A5 Data Migration]
        A6[A6 RAP Builder]
        A7[A7 UI5 Check]
    end

    subgraph AI Layer
        LLM[Claude API\nAnthropic]
    end

    subgraph Data & Auth
        SB[(Supabase\nPostgreSQL + Auth + Storage)]
        VLT[Secrets Store\nHashiCorp Vault / BTP Credential Store]
    end

    subgraph SAP Connectivity
        BTP[BTP Destination Service]
        CC[Cloud Connector]
        SAP[(S/4HANA or ECC\nADT REST + RFC)]
    end

    subgraph Source Control
        GH[GitHub\nabapGit serialized objects]
    end

    WEB --> API
    API --> ORC
    ORC --> A1 & A2 & A3 & A4 & A5 & A6 & A7
    A1 & A2 & A3 & A4 & A5 & A6 & A7 --> LLM
    A1 & A2 & A3 & A5 --> BTP --> CC --> SAP
    ORC --> SB
    API --> SB
    A2 & A3 & A6 --> GH
    VLT --> BTP

How Each Agent Uses Claude

Every agent follows the same interaction pattern: structured context construction, tool-augmented reasoning, verified output. The LLM is never called with raw unstructured input or asked to produce output that bypasses verification.

A1 Readiness

A1 extracts the ABAP source via ADT REST, builds a structured dependency manifest (tables, FMs, classes referenced), and runs the ATC S4HANA readiness check variant via the SAP ADT API. It then passes the source excerpt, the dependency manifest, and the structured ATC findings to Claude with a prompt that asks for:

1. A plain-language explanation of each high-priority finding
2. An initial classification: remediate / retire / re-architect
3. Identification of any issues the ATC check may have missed (semantic issues, not just syntactic)

The LLM contribution is explanation and classification — not the detection, which is done by ATC. This is deliberate: ATC is deterministic and SAP-maintained; LLM analysis is contextual but non-deterministic.

A2 Remediation

A2 receives the findings from A1 and the source object. For each high-priority finding, it constructs a prompt including:

• The specific ABAP statement flagged
• The ATC finding description
• The verified C1 replacement object (fetched from the SAP system via check_object_release_status)
• The field mapping between the deprecated object and its replacement

Claude produces a unified diff. A2 then validates the diff mechanically: does every object name in the diff exist in the SAP system? If not, the agent enters a correction loop before surfacing the output to the orchestrator.

A3 Test Gen

A3 receives the remediated source from A2 and builds an ABAP Unit test class using CLASS ... FOR TESTING conventions with cl_abap_unit_assert. Generating meaningful tests requires understanding what the code does. For well-named, structured ABAP this works directly. For legacy code with FORM routines and global variables, A4 Docs Gen runs first to produce a specification that A3 uses as a test oracle.

Data Flow: A Typical Readiness Scan

sequenceDiagram
    participant User
    participant API as API Gateway
    participant ORC as Orchestrator
    participant A1 as A1 Readiness
    participant LLM as Claude
    participant SAP as SAP System
    participant DB as Supabase

    User->>API: POST /scans {package: "ZSD_CUSTOM", system: "S4D"}
    API->>DB: Create scan record (status: queued)
    API-->>User: 202 Accepted {scan_id}

    ORC->>DB: Poll for queued scans
    ORC->>A1: Dispatch scan task

    A1->>SAP: List objects in package ZSD_CUSTOM
    SAP-->>A1: 47 objects (programs, classes, function groups)

    loop For each object
        A1->>SAP: Fetch ABAP source via ADT REST
        A1->>SAP: Run ATC S4HANA_READINESS
        SAP-->>A1: Source + findings
    end

    A1->>LLM: Classify findings, explain high-priority items
    LLM-->>A1: Classifications + explanations

    A1->>DB: Write findings (47 objects, 312 findings)
    A1-->>ORC: Scan complete, risk index 0.61

    ORC->>DB: Update scan status: complete
    User->>API: GET /scans/{scan_id}/report
    API->>DB: Fetch findings
    API-->>User: Full report JSON

The abapGit GitHub Integration

abapGit serializes ABAP repository objects to XML files, one per object. The s4ready.ai platform uses this to:

1. Read source without RFC dependency: agents can analyse abapGit-serialized code from a GitHub repository without needing a live SAP system connection. This is valuable for initial assessments where SAP connectivity is not yet established.

2. Track remediation changes as Git commits: A2 Remediation writes its output as pull requests against the abapGit repository. Each PR contains the remediated source as a unified diff, the ATC findings it resolves, and the verification results for all new object references. Human review happens in GitHub’s standard PR interface.

3. Audit trail: every change — automated or human — is a Git commit with author, timestamp, and linked finding IDs. The audit requirement from the project constitution is satisfied automatically.

The abapGit serialization format is deterministic and well-understood. Object type metadata, program attributes, and source code are all captured. The one gap is runtime configuration (user exits active in customising, transaction variant assignments) — these require separate documentation, which A4 Docs Gen includes in its output.

Infrastructure: Supabase and Railway

Supabase handles authentication (email + OAuth, with row-level security ensuring strict tenant isolation), scan state and findings (append-only PostgreSQL schema — results are never overwritten, preserving the audit trail), and file storage for large artefacts (ABAP source exports, migration configs) as blobs referenced from the database.

Railway runs each agent as a separate service, reflecting their different resource profiles. A1 Readiness is I/O-bound and scales horizontally. A2 Remediation is CPU-bound. A5 Data Migration runs long-duration batch jobs with different timeout requirements. Railway’s private networking keeps inter-agent communication off the public internet — the Orchestrator is the only publicly exposed service.

Security Model: No SAP Credentials in the Platform

The security architecture rests on one principle: s4ready.ai never stores SAP credentials.

The customer configures a BTP Destination in their own BTP subaccount. The platform holds a BTP Destination Service binding — an API key that can retrieve destinations, not the SAP credentials themselves. When an agent calls SAP, it fetches the destination, receives a short-lived OAuth token, uses it for that API call, and discards it. Nothing is stored.

The required SAP technical user authorisations for read-only analysis:

• S_RFC with SYSID and FUNC for ADT-required RFC calls
• S_ADMI_FCD with ATC for check execution
• Package-level S_DEVELOP with SHOW for the scanned packages

No write authorisations are required for analysis agents. A2 Remediation and A3 Test Gen deliver output as diffs and files — a human with appropriate authorisations performs transport activation and release. Infrastructure secrets (Supabase service key, GitHub app key, BTP binding credentials) are stored in HashiCorp Vault and injected at service startup. No secret appears in the codebase, container images, or agent prompts.

All ABAP changes are delivered for human review. Write access to production systems is architecturally excluded from agent service accounts. The platform automates analysis and generation — the judgment on what to deploy, when, and with whose approval stays with the customer.