AI-Agent als CAP-Modul oder Azure Function – Entscheidungs-Matrix für 4 Workloads
BTP CAP-Service vs Azure Container App: zwei Hosting-Pfade für AI-Agents, beide mit derselben Governance. Wann CAP gewinnt (in-app, kurze Calls, SAP-Daten), wann Azure (long-running, multi-step, custom-tooling). Plus: was beide Pfade teilen.
Die Frage am Architektur-Whiteboard
Sie wollen einen AI-Agent bauen. Erste Frage: läuft er auf BTP als CAP-Modul oder auf Azure als Container App / Function? Beide funktionieren, beide haben Trade-offs. In BAMVP haben wir beide Pfade – diese Use-Case erklärt wann welcher.
Vier typische Workloads im Vergleich
```mermaid
flowchart TD
W1[Bug-Repro-Assistent
~5s pro Call]
W2[Daten-Klassifikator
1-2s pro Call]
W3[Multi-Step Code-Refactor
30-180s pro Call]
W4[Long-Running Agent
5-30 Min Sessions]
W1 --> CAP1[BTP CAP] W2 --> CAP2[BTP CAP] W3 --> AZ1[Azure Container] W4 --> AZ2[Azure Container]
style CAP1 fill:#bbf7d0,stroke:#15803d style CAP2 fill:#bbf7d0,stroke:#15803d style AZ1 fill:#bfdbfe,stroke:#1e40af style AZ2 fill:#bfdbfe,stroke:#1e40af ```
Workload 1 – Bug-Repro-Assistent
Anforderungen: User klickt Knopf, Agent untersucht ein anonymisiertes Daten-Slice + Stack-Trace, schlägt Fix vor. Single-Call zu Anthropic, ~5 Sek Antwort-Zeit.
Pfad: BTP CAP-Modul.
Begründung: - Kurze Lebensdauer passt zu Cloud-Foundry-Limits (max 30s Approuter-Timeout, mit Workaround bis 5 Min) - Daten kommen aus HDI-Container, der CAP-Service hat sie eh - XSUAA-Scopes sind schon definiert - Audit-Log via BTP Audit Log Service direkt erreichbar
Workload 2 – Daten-Klassifikator
Anforderungen: pro neuem Datensatz eine Kategorie zuweisen (z.B. „Reklamation legitim oder nicht“). 1-2 Sek pro Call, eventuell hunderte Calls pro Stunde.
Pfad: BTP CAP-Modul.
Begründung wie oben. Plus: das CAP-Service kann den Klassifikator als srv.before('CREATE', BillingItems', …)-Hook einsetzen – keine separate Service-zu-Service-Latenz.
Workload 3 – Multi-Step Code-Refactor
Anforderungen: Agent bekommt eine Refactor-Anforderung, läuft 30-180 Sek, ruft Claude mehrfach mit Tool-Use, schreibt Files, baut Tests, eröffnet PR.
Pfad: Azure Container App (oder Functions Premium-Plan).
Begründung:
- Cloud-Foundry-Approuter-Timeout ist hinderlich
- Tool-Use mit File-Write braucht persistenten Workspace, nicht stateless CAP-Handler
- Container-Image-Pattern erlaubt Custom-Dependencies (z.B. für git-Operations) ohne Buildpack-Klimmzüge
- Azure-VNet-Egress passt zu Anthropic-Allowlist
Workload 4 – Long-Running Agent
Anforderungen: Agent führt 5-30 Min lange Sessions, mit User-Interaktion, Memory zwischen Steps, Tool-Use für externe Systeme.
Pfad: Azure Container App mit Persistent State.
Begründung wie 3. Plus: Container-Pattern erlaubt sticky-Session-Routing (z.B. via Application Gateway), CAP/Cloud-Foundry macht das nicht out-of-the-box.
Was beide Pfade teilen
| Aspekt | Implementation |
|---|---|
| Identität | XSUAA in BTP / Azure AD Managed Identity in Azure – beide via SAP IAS gefedert |
| Audit-Log | BTP-Pfad: Audit Log Service. Azure-Pfad: schreibt auch ins BTP Audit Log via REST. Eine Wahrheit. |
| Prompt-Registry | gemeinsames Git-Repo, beide Pfade ziehen Prompts via Tag |
| Eval-Gates | gemeinsame Golden-Sets, gemeinsame CI-Workflow |
| Approver | gleiche Rolle: AI Privacy & Operations Lead |
| Incident-Process | gleiche Eskalations-Kette, gleiche Sev-Definitionen |
Decision-Matrix in einem Bild
| Kriterium | BTP CAP | Azure Container |
|---|---|---|
| Daten direkt in HDI | ✅ | ⚠ JDBC nötig |
| Kurz (< 30s) | ✅ | ✅ |
| Lang (> 30s) | ⚠ Workaround | ✅ |
| Tool-Use mit File-Write | ⚠ | ✅ |
| Custom-Native-Deps | ⚠ Buildpack | ✅ Container |
| Kosten ohne Last | niedrig (Cloud Foundry) | niedrig (Functions Consumption) |
| Kosten mit Last | mittel | mittel-hoch |
| BTP Audit-Log direkt | ✅ | via REST |
| Operations-Tooling | BTP Cockpit | Azure Monitor + App Insights |
Was bei Mischmodellen passiert
In BAMVP haben wir beide Pfade nebeneinander. Der Bug-Repro-Agent ist BTP-CAP, der Refactor-Agent ist Azure-Container. Beide rufen denselben Anthropic-Endpoint, beide loggen in dasselbe Audit-System, beide nutzen die gleichen Prompts aus dem Git-Repo.
Was wir gelernt haben: die Mischung funktioniert, wenn Governance einheitlich ist. Wenn Sie zwei Audit-Systeme, zwei Prompt-Repos, zwei Approver-Rollen haben – dann wird die Komplexität schnell unbeherrschbar.
Wer eine 30-Min-Beratung dazu will
Ein Architektur-Review (30 Min) schaut Ihren konkreten Workload an und macht die Entscheidung BTP vs Azure mit Begründung. Output: Ein-Seiten-Empfehlung mit Setup-Kosten und Operations-Aufwand.
Stand: 2026-05-10
