JumpStart Architecture

JumpStart SAP Intelligence is a standalone Next.js application maintained by the Cosmos team. It owns the SAP/Oracle/BTP workbench experience, project data, connection credentials, and domain tools. Cosmos owns identity, agent execution, storage, registry resources, model configuration, and observability.

Runtime Model

JumpStart is not embedded in the Cosmos frontend. It has its own domain, NextAuth session, PostgreSQL database, API routes, and worker process (BullMQ queues on Redis). It uses @cosmos/sdk as the boundary for platform calls.

Current Runtime Notes

• Runtime metadata, journey execution, DMS access, project RBAC, and Configurator manifest calls are scoped to the active user and the canonical Cosmos project. The SDK carries the project ID as a typed field (X-Project-Id); JumpStart does not put a project ID in observability metadata.
• Project members, groups, and journey grants are stored only in native Cosmos project RBAC; JumpStart keeps no local mirror of them. A journey is usable only when its agent is authorized for the project and the journey's own catalog entry is enabled, and this is enforced again at execution (HTTP 403 otherwise). Journeys without an agent cannot be enabled.
• Terminal/session persistence handles conflict reconciliation and terminal-scoped ADK session reuse.
• ADK owns context compaction and history filtering. JumpStart sends no compaction or history-filter controls, and its context indicator shows the context window ADK reports.
• Object-package and Enhanced ABAP flows include typed deployment capabilities, lifecycle signals, diagnostics, AXPP, Smart Forms, and Adobe Forms coverage.

Primary Chat Flow

All AI chat execution runs as durable worker jobs.

1. The browser creates or resumes a terminal/session and posts a job request under app/api/cosmos/chat/jobs/*.
2. JumpStart resolves the active project, blueprint, skills, KBs, files, and connection context.
3. The worker creates a request-scoped CosmosClient with the user's Cosmos token and the canonical Cosmos project ID.
4. The worker calls ADK V2 through @cosmos/sdk, passing a prompt-only system prompt (or the blueprint's agent), model/provider selection, selected skills, KB collections, execution context, DMS/file context, and local tools.
5. When ADK requests a local tool, the SDK invokes JumpStart handlers for SAP, Oracle, BTP, canvas, DMS, context, and built-in operations. Failed tools return their error message to the model.
6. Job progress, tool events, generated files, and final output are persisted and streamed back to the browser through the replaying SSE endpoint app/api/cosmos/chat/jobs/[id]/stream. Sibling routes under chat/jobs/[id]/ handle accept, reject, resume, cancel, and notify.

Cosmos Service Use

Tool Execution Boundary

Cosmos Resource Delegation

JumpStart can ask Cosmos Assistant to create or map platform resources when a blueprint needs them. The flow is confirmation-gated:

1. JumpStart Assistant or the blueprint builder produces a resource plan.
2. The user confirms the action and any required deployment intent.
3. JumpStart calls Cosmos Assistant with the confirmed requirements and plan.
4. Cosmos Assistant returns resource results with IDs, versions, deployment status, questions, or failures.
5. JumpStart updates the generated blueprint with the primary agent, default skills, and default KB/collection IDs when those resources are resolved.

The delegation path does not delete Cosmos resources and does not deploy unless the confirmed request explicitly allows deployment.

Data Boundary

SAP and Oracle credentials are encrypted with CREDENTIALS_ENCRYPTION_KEY and remain in JumpStart's database. They are not sent to ADK, MCP, or Configurator.

Knowledge Map Access

Knowledge Map reads go through JumpStart server routes (app/api/cosmos/knowledge-map/graphs). JumpStart calls Configurator with its own service token, the signed-in user as the on-behalf-of subject, and the canonical project ID. A graph is returned only when the journey agent's manifest grants graph.read on it, the graph is ready, and the project catalog grants it; the check runs on every read.

Session Persistence

Terminal state is persisted in PostgreSQL through PUT /api/data/sessions. A beforeunload handler flushes active state with keepalive: true during navigation. This is why tests and maintenance scripts should navigate away and let the flush settle before clearing terminal/session rows.

Layout Note

JumpStart has two tab strips:

Keep test IDs and tab behavior aligned in both places.

Related Documentation

• Overview
• Integration Guide
• Deployment
• Cosmos Architecture