CSPeach™

Architecture

Two paths into SAP.

Both keep your ABAP source in your environment.

Pick the one that matches your controls.

The two planes

How the data flows.

CSPeach traffic splits into two independent planes that share only one endpoint: your CLI. The LLM plane handles AI calls and skill bundles. The SAP plane handles ABAP. They never cross.

CSPeach two-plane architecture A single CLI on the developer's laptop emits two independent transports. The LLM transport goes through api.cspeach.dev on Fly to Anthropic over the Anthropic Messages API, with skill bundles fetched from manifest.cspeach.dev. The SAP transport goes direct from the laptop to the SAP system over ADT REST, or optionally via a customer-deployed BTP wrapper using XSUAA, Destination Service, and Cloud Connector. When a CSPeach skill reads ABAP source for the LLM to explain or refactor, that source travels the LLM transport as prompt content — not the SAP transport. LLM PLANE api.cspeach.dev Fly · US-East Anthropic Messages API Anthropic / OpenAI model API manifest.cspeach.dev skill bundles BYOK and AI Hub modes bypass api.cspeach.dev. SAP PLANE Fast lane laptop → SAP direct ADT via your BTP wrapper BTP lane XSUAA · Destination · CC on the roadmap ADT REST Your SAP system ECC · S/4 · BTP ADT REST stays in this plane. HTTPS ADT REST cspeach-cli developer laptop
Two independent transports from the CLI. ADT REST goes direct to your SAP system. LLM requests go to the proxy — or, in BYOK / SAP AI Hub modes, directly to your chosen LLM endpoint. ABAP source you ask CSPeach to explain, review, or refactor is included in the LLM prompt. See the FAQ for the full data-residency breakdown.

Fast lane — today, default Available today

Developer laptop. Direct to SAP.

The developer runs cspeach from their laptop. ADT REST goes straight to SAP, in-process via @cspeach/sap-client. SAP credentials (user/password or X.509) stay in the laptop's OS keychain.

Who's on this lane
Every developer using CSPeach today. Solo developers, consultancies, mid-size teams — anyone running CSPeach against their own SAP without standing up extra infrastructure first.
What you get
SAP's CHANGE_LOG shows the real developer — not a bridge user, not a certificate proxy. The same audit trail your SAP team already runs on every other developer action. No XSUAA to configure, no Cloud Connector to deploy, no Destination Service to maintain.
When to look at BTP lane
Shops with strict identity policies that require XSUAA + Principal Propagation for every external system, or shops that don't want developer-held SAP credentials at all.

BTP lane On the roadmap — design ready, build in progress

Your BTP. Your audit.

A small wrapper in your own BTP Cloud Foundry subaccount. The wrapper uses the same standard BTP services your team already uses for any custom extension:

  • XSUAA for authentication. The CLI does OAuth2 PKCE device flow; XSUAA returns a JWT.
  • Destination Service for SAP routing. Customer-managed destination, customer-controlled.
  • Cloud Connector for on-prem reach. Outbound-only tunnel from your LAN.
  • Principal Propagation so SAP sees the real developer in SU01 and CHANGE_LOG audit — not a bridge user.

The wrapper will be published open-source when the build is complete. ADT REST traffic stays inside the customer's BTP tenant — it never crosses cspeach.dev or fly.dev. Prompts sent to the LLM still travel the LLM plane (the managed proxy today; your AI Hub once that mode ships) — see the FAQ for the breakdown.

Roadmap: optional MCP-client mode for customers who deploy SAP's ABAP MCP Server (GA TechEd 2025).

Trust boundaries

What lives where.

Concern Wrapper
(open source, customer-deployed)		 Fly proxy
(closed, CSPeach-owned)
Anthropic / OpenAI routing—✓
BYOK key handling—✓
AI Hub mode (future)—✓ (routes to customer's AI Hub URL)
Skill content + signing—✓
Classifier (Haiku)—✓
Spend caps, billing, customer DB—✓
GitHub OAuth / device auth—✓
XSUAA OAuth2 / JWT validation✓—
Destination Service binding✓—
Cloud Connector binding✓—
ADT REST forwarding to SAP✓—
Scope / role enforcement✓—
Audit log of SAP operations✓—
ABAP source code in flight✓ (transit only, in customer tenant)—

The wrapper has no business logic. It validates JWT, applies scope rules, forwards to ADT, returns the response. A competent reviewer can read the wrapper end-to-end in roughly two hours.

Architect FAQ

Questions architects ask.

Does my ABAP source enter cspeach.dev?

Only when you ask a skill to use it. The CLI's skills (/abap-explain, /abap-review, /abap-refactor and others) read the code locally via ADT, then include it in the LLM prompt so the LLM can do the work. In managed mode (today's default), those prompts transit our Fly proxy on their way to Anthropic.

ADT REST traffic itself — read object, write source, ATC, activation, transport — always goes direct laptop → SAP and never transits our proxy in any mode.

Source your team doesn't share with a CSPeach skill never leaves SAP. To keep prompt contents off our proxy too, BYOK or SAP AI Hub modes route the LLM call direct from laptop to Anthropic or your AI Core respectively — both on the roadmap.

Where do LLM keys and prompts live?

CSPeach has one LLM mode shipping today (Managed) and two more on the roadmap, with different data-residency trade-offs:

  • Managed (today, default) — our Anthropic key lives on our Fly proxy. Your prompts and the LLM's responses transit our proxy so we can meter and bill per use. ADT REST traffic does not transit our proxy in any mode.
  • BYOK (on the roadmap) — your own Anthropic key lives in your laptop's OS keychain. LLM traffic goes laptop → Anthropic directly. We don't see your key or your prompts. Code path exists in the CLI; end-to-end verification pending before we mark this generally available.
  • SAP AI Hub (on the roadmap) — your AI Core token lives in your laptop's OS keychain. LLM traffic goes laptop → your SAP AI Core in your own BTP. We don't see your key or your prompts. Requires a customer-side translation proxy (e.g. SAP's hAIperspace, or pjq/sap-ai-core-llm-proxy) because SAP AI Core doesn't natively speak the Anthropic Messages API.
Where will the wrapper run?

In your own BTP Cloud Foundry subaccount. It uses standard BTP services — nothing custom or non-standard. The wrapper is small enough to read end-to-end in roughly two hours; the source will be published open-source when the build is complete. Currently on our roadmap — see the BTP lane section above.

Does it work with our SSO?

The wrapper uses XSUAA + Principal Propagation; supports Azure AD, Okta, SAP IAS, anything XSUAA can federate to.

What about audit?

Principal Propagation passes the real user identity to SAP. SU01 and CHANGE_LOG see the developer, not a bridge user.

Can we self-host the LLM side too?

Yes — point CSPeach at your own SAP AI Core via the AI Hub mode, with the translation proxy noted above. Local-only LLM (Ollama / vLLM) is on the roadmap but not yet supported for skill workflows.

Want the wrapper when it ships?

Tell us, and we'll let you know.

Get notified when the wrapper ships Try CSPeach today