Introduction

Toyota Motor North America (Toyota) runs BasisPilot, an AI-assisted SAP operations platform, on a large SAP landscape on AWS. The current BasisPilot scope covers 20 SAP systems on 60+ Amazon EC2 hosts across development, test, stage, and production environments, spanning multiple AWS accounts and Regions. The platform supports key SAP workload types, including ABAP and Java application stacks and SAP HANA databases, including multi-tenant HANA deployments. Operating this landscape required engineers to move between terminals, SAP GUIs, spreadsheets, and AWS consoles.

Within Toyota’s SAP BTP Platform function, BasisPilot was designed and developed as a single-dashboard operations platform with an embedded, tool-calling AI assistant powered by Amazon Bedrock. Although it started with SAP operations, the same platform is now useful to authorized product, infrastructure, and support teams that need visibility into AWS-hosted workloads, health indicators, and common troubleshooting context without waiting for a manual status update. This post describes what the platform does, how it is architected, the AWS services behind it, and how the AI assistant supports approved operational workflows – from health checks to SAP kernel upgrade planning and execution support.

An in-house innovation

BasisPilot is not a commercial product. It began as an internal engineering initiative within Toyota Motor North America (Toyota), focused on the SAP BTP Platform and SAP operations landscape.

Manish conceived the platform, defined its operating model, and led the architecture, design, and implementation. That work included the shared evidence model, the serverless APIs, the cross-account controls, the asynchronous workflow engine, the SAP dependency logic, the approval boundaries, and the tool-calling AI layer. Toyota stakeholders and AWS contributors collaborated on review, validation, and refinement. The platform brings several day-to-day operations into a single serverless interface – monitoring, lifecycle management, patching, HA, DR, backups, cost, and security – with an AI-assisted operations layer for approved, auditable workflows. Its scope has expanded from an SAP operations dashboard into a shared visibility and troubleshooting tool for authorized teams.

Using Kiro as an implementation accelerator

After defining the BasisPilot concept, operating model, and architecture, Manish used Kiro, an AI-powered IDE from AWS, as his development environment to speed up focused implementation tasks: exploring a large codebase, drafting scaffolding, tracing defects across React and Lambda boundaries, and refining tests and technical documentation. It was particularly useful when a single change crossed API contracts, DynamoDB tracking, Systems Manager execution, and the user interface.

The SAP dependency sequences, approval boundaries, rollback requirements, cross-account controls, and verification criteria came from Manish’s SAP operations experience and were checked against actual system behavior. He reviewed and adapted suggestions, integrated them into BasisPilot conventions, tested the results, and retained responsibility for the final design and implementation.

About the content in this post

In line with Toyota’s public-content guidelines, this post describes architecture patterns, AWS services, and design decisions only. It contains no account identifiers, internal hostnames, endpoints, credentials, system IDs, or other environment-specific details.

“I didn’t start by asking where AI could fit. I started with the decisions a Basis engineer has to make before touching a system: what evidence do I trust, what has to happen in what order, and what should stop me. BasisPilot came from writing that judgment down as platform behavior.”

– Manish Kumar, Senior SAP Product Owner, Toyota Motor North America

Mission and goals

BasisPilot was guided by five principles, in the spirit of kaizen (continuous improvement):

• Single dashboard – SAP systems, AWS hosts, clusters, backups, and patch cycles visible in a single dashboard, regardless of the AWS account or Region where they reside.
• Safe automation – every mutating action flows through role-based access control, environment-aware approval gates, and a complete audit trail.
• AI-assisted operations, not a generic chatbot – the assistant can answer questions, request approved backend tools, summarize diagnostics, and guide controlled workflows while the platform enforces validation, approval, execution, and audit controls.
• Shared self-service visibility – authorized application, infrastructure, and support teams can view health, alerts, and troubleshooting context directly, reducing dependency on manual updates from the SAP BTP Platform team.
• Serverless and cost-efficient – there are no servers to patch for the platform itself; the backend runs on Lambda, DynamoDB, and managed AWS services with pay-per-request pricing.

What the platform does

BasisPilot is a React single-page application served from Amazon CloudFront, backed entirely by serverless APIs. Access is role-based: some users can operate approved workflows, while others use the platform for read-only visibility, incident triage, and status checks. The dashboard provides these functional modules:

Figure 1 – BasisPilot landscape dashboard captured from the real interface. Operational values are original; the captured region contains no SID, hostname, account, or IP values that require masking.

Dashboard: Landscape-wide health for authorized teams: system availability, resource hotspots, critical alerts, SLA attainment, and cloud-infrastructure summaries at a glance.

Systems: Per-system view for ABAP and Java stacks alike – component status (ASCS/PAS/AAS or SCS/JAS, plus database), live metrics, and start/stop/restart controls.

Host Manager: Host-level CPU/memory/disk, SAP process status, filesystem detail (including HANA data/log volumes), and bulk host operations.

Backup Status: HANA backup catalog visibility (full/differential/incremental/log), consecutive log-backup failure detection, and RPO violation alerts.

OS Patching: AWS Systems Manager Patch Manager compliance per environment, patch-baseline approval-date automation, patch windows, and an approval-gated, SAP-aware reboot orchestration (stop SAP → reboot → start SAP).

Cluster Status: Pacemaker/Corosync HA cluster health, HANA System Replication state, node roles, failover history, and safe cluster operations (maintenance mode, standby, controlled switchover).

Disaster Recovery: DR test orchestration with AWS Elastic Disaster Recovery – mock and real drills, step-by-step execution with human confirmation gates, and full audit per test.

Threat Monitor: SAP security intelligence: critical-transaction monitoring from the SAP Security Audit Log, HANA audit events, and SIEM export (CEF, Syslog, CSV, JSON).

Security: Automated SAP security-baseline compliance: standard-user checks, client settings, profile parameters, system changeability, and HANA user security – collected on a schedule.

Activity Log: Complete who-did-what audit trail of every start/stop/upgrade/patch/storage action across the landscape, with live progress for in-flight operations.

Cost & Optimization: Multi-account spend trends, EC2 rightsizing and newer-generation recommendations, Amazon S3 lifecycle analysis, Savings Plans coverage, and stale-backup cleanup opportunities.

Findings: Continuous security/cost inspectors: open security groups, aged IAM keys, unencrypted Amazon EBS, public S3, idle resources, and backup-vault hygiene.

AI Assistant: Page-aware assistant that answers SAP operations questions, calls approved backend tools, tracks long-running tasks, and produces downloadable reports.

Shared visibility beyond the core platform team

A key design outcome is that BasisPilot is not limited to one specialist group. The same health, inventory, and troubleshooting views can be exposed through RBAC to other authorized teams that manage or depend on AWS-hosted enterprise platforms. For read-only users, the assistant helps answer common questions such as whether a system is up, which component is unhealthy, whether a maintenance window is active, or whether an issue is related to host resources, backup status, or platform availability. Operational actions remain limited to approved roles and approval-gated workflows.

Who benefits

BasisPilot serves several roles across the enterprise, each through the access their responsibilities require. The following groups gain the most from the platform:

• SAP Basis and platform engineers – operate approval-gated workflows: start/stop, OS patching, kernel and HANA revision upgrades, HA cluster operations, DR drills, and storage migrations.
• SAP operations and on-call responders – track long-running work through the action tracker and return to persisted state instead of rebuilding a runbook from memory.
• Application and product teams – check system health, component status, and active maintenance windows for the SAP workloads they depend on, without waiting for a manual update.
• Infrastructure and support teams – use read-only visibility and the assistant for first-line triage across accounts and Regions.
• Security and compliance teams – monitor SAP Security Audit Log events, run baseline compliance sweeps, and export findings to the corporate SIEM.
• FinOps and cost owners – review multi-account spend trends, rightsizing recommendations, Savings Plans coverage, and stale-backup cleanup.
• Audit and change-management stakeholders – rely on the complete activity trail and evidence packs that connect changes to enterprise ITSM and SAP Cloud ALM.

Continuous monitoring and SLA tracking

Underneath the dashboards, a fleet of scheduled collectors keeps the platform’s picture of the landscape current without any manual polling:

• Live metrics every 5 minutes – CPU, memory, SAP process status, and cluster state collected in parallel from every host through SSM. Collectors are EC2-state-aware, so a stopped instance can never show stale “green”.
• Hourly trend history – performance (CPU/memory/disk/load average) and per-filesystem usage written to dedicated history tables with 90-day TTL-based retention, powering the trend charts with real data rather than extrapolation.
• SLA measurement every 5 minutes – availability samples per system rolled into monthly attainment against environment-specific targets (99.0% for dev/test, 99.5% for stage, 99.9% for production), displayed on a dedicated SLA dashboard.
• Security and compliance sweeps – SAP Security Audit Log events every 5 minutes and security-baseline compliance every 30 minutes.
• Critical alerts – component-down, backup-failure, and resource-threshold conditions surfaced on the dashboard with acknowledgement workflow.

Figure-2 SLA Dashboard

Maintenance windows

Planned downtime is a first-class concept. A dedicated maintenance API lets engineers place any system into a maintenance window – individually or in batch – with start/end times, reason, and the responsible engineer recorded. While a window is active, the system’s alerts are suppressed, so planned work never pages anyone, and every create/update/delete is written to the audit log. The AI assistant participates too: it can list current and upcoming windows, schedule new ones conversationally, and its own long-running workflows (kernel upgrades, patching) respect and reference maintenance state.

“What impressed me most about BasisPilot was the originality, depth, and completeness of Manish’s design and implementation. He did not treat it as an adoption of existing SAP capabilities or as a collection of disconnected tools. He conceived and built an end-to-end enterprise platform, including the user interface, APIs, databases, authentication and authorization, role-based access control, backend services, AI capabilities, and the governance model required to operate them responsibly. The platform represents a substantial engineering effort, with a broad and deeply integrated codebase spanning Python, React, and JavaScript, developed to bring the architecture into operation.

One of the most important architectural choices was the clear separation between the data and intelligence plane and the governed control plane. That separation allows insights and AI capabilities to evolve while identity, authorization, approvals, execution, verification, and audit remain deterministic and controlled. Manish led the design from the SAP dependency model through the AWS architecture, application architecture, security model, and implementation. He translated deep SAP operating knowledge into a working cloud-native system rather than simply recommending an adoption path. We have already started to see benefits from this approach, including a clearer understanding of complex SAP landscapes, more informed decision-making, and greater confidence in the reliability, resilience, and continuity of the business operations that depend on SAP.”

Anshuman Kowtha, Manager, Toyota Motor North America

The hard problem: SAP time does not fit HTTP time

A complete SAP maintenance event is not a single command. Application servers must drain before central services stop. Shared or multi-tenant databases must not be stopped while dependent applications are still active. SAP HANA needs time to flush and reach a verified state. Startup has to wait, in order, for Amazon EC2, AWS Systems Manager, the database, central services, and application instances. Routine operations take 10 to 90 minutes, and some database and upgrade workflows continue for hours. All of it is incompatible with a synchronous web request.

BasisPilot therefore separates request time from operation time. An actions API creates a durable tracker before long work begins. Amazon DynamoDB stores the action ID, current phase, progress, completed results, approvals, and errors. AWS Systems Manager Run Command performs the host-side work, and the dashboard and chat interface both read the same tracker. When a Lambda function’s own time runs low, it checkpoints state and re-invokes itself asynchronously; the browser simply polls the tracker record. The same pattern powers the AI agent’s long-running tasks, OS patch reboots, kernel upgrades, and multi-terabyte storage migrations. This phase-based, self-checkpointing design is the AWS-recommended pattern for work that outlasts a synchronous request, and it lets Toyota run multi-hour SAP operations on Lambda without holding a connection open.

Closing or refreshing the browser does not decide whether SAP is still stopping. The engineer can return to persisted state instead of reconstructing the runbook from memory, and for longer upgrades, monitoring checkpoints resume observation without blindly replaying the change.

Dependency gates protect both uptime and controlled downtime

The sequence is enforced in code, not just displayed on screen. During shutdown, BasisPilot stops application instances, verifies they are down, then stops central services, the database, and Amazon EC2 where requested. If a database shutdown cannot be verified, infrastructure shutdown is blocked. Startup reverses the chain: EC2 and Systems Manager readiness, database health, central services, then application instances. Parallel work is allowed within a safe layer, never across dependencies that must stay ordered.

BasisPilot treats “command accepted” as an intermediate state. Success requires live verification of the intended outcome, which is what prevents the platform from reporting a landscape as available while a database, enqueue service, or application process is still incomplete.

One evidence model from dashboard to assistant

The landscape dashboard, Systems view, Host Manager, Backup Status, action tracker, and AI assistant are different views of the same operating evidence. System cards expose component roles and work-process health. Host views add CPU, memory, disk, filesystems, and top processes. Backup Status adds full, differential, incremental, and log-backup history, along with missing, failed, stale, and continuity conditions.

So for a question like “Is this system safe to maintain?”, the assistant can assemble system state, host load, backup protection, cluster context, maintenance windows, and recent action history. If an approved action follows, deterministic workflow code controls sequencing, authorization, execution, verification, and audit. Generated text never becomes a shell command.

Guardrails also define what the assistant will not do

BasisPilot does not treat a broad question as permission to inspect the entire landscape. Backup status, for example, is deliberately scoped to a single SAP system, because the platform must resolve the correct HANA database host and catalog before returning backup and recovery-point information. When a user asks only for “backup status,” the assistant asks which SAP system to check. It does not merge unrelated systems or guess the target from recent context.

This boundary is enforced before model and tool execution. Once the user supplies the system ID, the request can be routed to a read-only backup tool. The same principle applies to every capability: the assistant is an interface to typed, scoped tools, not a general permission to inspect or change everything.

Figure 3a and 3b: Genuine BasisPilot chatbot exchange: a broad backup-status request is stopped at the scope boundary and the assistant asks for one SAP SID before querying backup data. Only the example SID values are masked; the request, response, timestamp, and interface are unaltered.

Architecture

BasisPilot uses a hub-and-spoke design. A central hub account hosts the platform – the frontend, APIs, AI agent, and all DynamoDB state. Spoke accounts (stage, production, DR) contain the actual SAP workloads. The hub reaches into spokes exclusively through STS AssumeRole into a tightly-scoped cross-account role, and all host-level work travels through AWS Systems Manager Run Command – no SSH keys and no open inbound access for platform-managed actions. This hub-and-spoke model with AWS STS and AWS Systems Manager follows the AWS-recommended approach for cross-account operations, so Toyota reaches every spoke account without standing credentials or inbound network access.

The following diagrams progressively expand the same architecture-from the complete hub-and-spoke view to the serverless, AI, monitoring, and action layers. The Data flow section then follows how those components work together at runtime.

Figure 4 – BasisPilot reference architecture: authenticated users reach a serverless hub platform; the Bedrock AI agent and API Lambdas act on SAP systems in spoke accounts only through STS and AWS Systems Manager.

Figure 5 – Detailed component view: serverless platform layers in the hub; SAP workloads in spoke accounts reached only through STS AssumeRole and SSM.

Data flow

With the platform layers established, the runtime path is easier to follow:

Discovery. A feeder Lambda discovers SAP EC2 instances using resource tags – including multi-tenant HANA mappings where one database serves several SAP systems – and populates the host/system inventory in DynamoDB.

Collection. EventBridge triggers collector Lambdas (every 5 minutes for live metrics, cluster state, SLA samples, and security events; hourly for performance and filesystem trends; three times daily for the HANA backup catalog) that run read-only commands on hosts through SSM in parallel, and write CPU, memory, filesystem, SAP process, backup, security, and SLA data to DynamoDB. Collectors are EC2-state-aware: a stopped instance actively zeroes its cached process counts so the dashboard never shows stale “green”.

Serving. API Lambdas read from DynamoDB and serve the React frontend through API Gateway with a Cognito JWT authorizer on protected routes. EC2 state is always checked first – a stopped instance overrides any cached process data.

Action. Mutating operations (start/stop, patching, upgrades, storage changes) run as phase-based workflows: each API call completes well under the gateway timeout, progress is tracked in DynamoDB, the UI polls a tracker, and stalled phases self-heal with bounded, idempotent retries.

Design lesson: phase-based everything

SAP operations routinely take 10–90 minutes – far beyond any API Gateway or Lambda limit. BasisPilot splits every long operation into small phases with state checkpointed in DynamoDB. The Lambda re-invokes itself asynchronously when its own time runs low, and the browser (or the chat UI) simply polls a tracker record. The same pattern powers the AI agent’s long-running tasks, OS patch reboots, kernel upgrades, and multi-terabyte storage migrations.

AWS services used

The AI assistant: useful because it is constrained

The AI assistant is designed to support authorized engineers, product owners, and support teams, not replace operational ownership. It uses Amazon Bedrock with tool use: the model can request one of the platform’s 68 typed tools, but the application validates the request, checks RBAC, applies approval policy, and then executes the tool only when it is safe to do so. This separation is important: the model can help reason through the task, but the platform remains responsible for authorization, validation, execution, and audit.

Tool categories

How a request flows through the agent

Intent routing. Before the model receives a request, lightweight routing narrows the available tool list to the most relevant options. This narrows the prompt scope and reduces incorrect tool selection. Simple confirmations such as “yes” or “proceed” are matched back to the previous pending action, and high-confidence inputs – for example, a kernel-media path supplied after the agent asked for one – can use a deterministic fast path instead of another model call.

RBAC gate. The caller’s role comes from JWT claims and is checked against the tool’s required permission. Viewer roles remain read-only; operator and admin roles can request controlled actions.

Approval gate. Environment-aware policy: production actions, multi-tenant database hosts, and destructive operations always create a pending approval instead of executing. The user sees exactly what will run – and for complex workflows like kernel upgrades, approval is requested only after a live pre-check report (current vs. target version, running processes, media validation) is presented in tabular form with selectable confirm/cancel buttons. Stale approvals expire automatically.

Input validation. System IDs are pattern-validated, SSM commands are assembled from allowlisted operations, and unsafe shell metacharacters are rejected. The assistant never receives a free-form shell to execute.

Execution & verification. Long operations run as async tasks with live progress cards in the chat. The workflow verifies outcomes with live process checks instead of trusting cached state, and higher-risk workflows include rollback paths, such as restoring the backed-up kernel if startup verification fails.

Audit. Every tool call, approval, and result lands in the actions log with user identity – the same trail the Activity Log page renders.

Case study: AI-assisted SAP kernel upgrade workflow

One representative workflow shows the intended operating model. The engineer stays in control, and the assistant coordinates the checks and approved execution steps:

1. The engineer asks for a kernel upgrade on a system. The assistant asks for the kernel media location, either a host path or an S3 location.
2. After the engineer provides the path, a deterministic fast path starts an async pre-flight check: current kernel level, target media validation, warnings for mixed patch levels, running instances on each host, and disk-space checks.
3. The assistant presents the plan in a table with Proceed/Cancel buttons. At this point, no change has been made.
4. After approval, the workflow runs host by host: stage and extract media → back up the current kernel → stop the system’s instances in the expected order → deploy → start central services first → verify process health and kernel level. If startup verification fails, the workflow restores the backup rather than leaving the system in a partially upgraded state.
5. The final result, including old to new patch level and backup location, is posted to the chat and recorded in the audit log. During pilot use, the engineer’s role shifted from executing a manual runbook to supervising an approved workflow. Based on observations from 15+ pilot kernel upgrades in May 2026, estimated elapsed completion time per system decreased from approximately 2.5 hours to 45 minutes, a reduction of about 70%. Hands-on engineering effort was not measured separately.

Lesson learned: AI workflows must coexist with other automation. During early internal testing, a stalled dashboard stop-tracker’s self-healing retry fired minutes after a successful AI-assisted upgrade had restarted the system, creating a conflicting stop action. The fix was systemic, not cosmetic: workflow locks per system, freshness windows on retries and approvals, and post-action re-verification windows. When several automations share the same landscape, a retry should never assume that the world is unchanged; it must re-check state before acting.

Model strategy

• Tiered models: simple status questions go to a lower-latency, cost-efficient Claude tier; investigations, multi-step workflows, and report synthesis use a stronger reasoning tier. The tier is chosen per request, not per session.
• Bounded tool loops: a hard cap of seven tool-use turns per request, with forced synthesis on the final turn, keeps latency and cost predictable.
• Result caching: read-only tool results are cached with per-tool TTLs; saying “refresh” bypasses the cache. Destructive and confirmed actions never use cache.
• Embedded knowledge base: SAP Basis runbooks (start/stop sequences, OOM analysis, split-brain recovery, EBS expansion procedures) are packaged with the Lambda for low-latency retrieval before the assistant recommends or starts a workflow.

Security and governance

• Identity. Amazon Cognito with JWT validation on protected API routes; user identity is always taken from token claims, never from request bodies.
• Least privilege. Spoke-account roles expose only the SSM and read permissions the platform needs, and sessions are short-lived.
• No host exposure. Zero SSH for platform-managed operations; every host interaction is an auditable SSM Run Command with an allowlisted command set.
• Change control. Production actions are always human-approved. Evidence packs and a release-workflow integration connect changes to the enterprise ITSM and SAP Cloud ALM processes.
• Audit and compliance. Platform-managed resources follow enterprise tagging standards, audit logs support compliance traceability, and the security module exports events to the corporate SIEM in standard formats.
• Recovery. Higher-risk workflows capture safety evidence (AMIs, kernel backups, snapshots) and preserve rollback options before the platform changes the target state.

Together these controls apply AWS security best practices, least-privilege spoke roles, short-lived STS sessions, and token-based identity through Amazon Cognito, so Toyota keeps identity, authorization, and audit deterministic even as the AI and data layers evolve.

“BasisPilot transforms SAP operations from fragmented tools and manual runbooks into one intelligent, governed operating platform. It combines real-time visibility, AI-assisted diagnosis, and controlled automation with the approvals, verification, auditability, and rollback an enterprise environment demands. Manish’s leadership turned deep SAP operating expertise into a capability that can scale across the enterprise.”

Ashish Patel, Senior Manager, Toyota Motor North America

Results

Together, the architecture, operating guardrails, and human review model produced the following practical outcomes:

• One platform: BasisPilot reduces the need to move between terminals, consoles, and spreadsheets by bringing SAP application, database, and AWS infrastructure information into one interface across environments and accounts. The team estimates at least 20% less time spent gathering and analyzing operational information. This reflects both fewer interface switches and the assistant’s ability to bring system evidence together and help engineers interpret the findings. The platform consolidates these workflows rather than replacing the underlying SAP and AWS services.
• Broader self-service: Authorized teams can view system health, alerts, and troubleshooting context directly, reducing their reliance on the Basis team for status updates. The team reports an estimated 25% reduction in status-related tickets following the introduction of self-service visibility. This figure applies to requests for system status, not total incident volume or incident-resolution time.
• Less manual effort: BasisPilot supports work throughout the SAP operations cycle, from daily health checks, SAP process and host-load analysis, backup verification, and reporting to coordinated landscape start/stop, patching, upgrades, and storage changes. Engineers use the dashboard and scoped AI tools to gather evidence, investigate issues, and coordinate supported actions. The platform handles dependency sequencing, required approvals, progress tracking, verification, and audit records within those workflows. Cost optimization, security and compliance checks, and high-availability and disaster-recovery views also bring context into routine operational reviews.
  Pilot estimates illustrate two parts of that broader scope. Based on experience with 15+ kernel upgrades in May 2026, hands-on effort decreased from approximately 2.5 hours to 45 minutes per engineer per system, about 70% less hands-on effort. Separately, observations from 30+ filesystem reductions in March 2026 put estimated elapsed completion time at approximately one hour, compared with three to four hours previously, about 67–75% less elapsed time.
• Safer operations: Supported operations follow role-based permissions, environment-aware approval policies, audit logging, and live outcome verification. Higher-risk workflows include backup and recovery steps. For example, the kernel-upgrade workflow can restore the previous kernel if startup verification fails. These controls provide a defined recovery path where implemented, rather than assuming every change is automatically reversible.
• Serverless operating model: BasisPilot’s platform layer runs on managed AWS services without dedicated application servers to administer or patch. Collectors and APIs scale with demand. As of September 25, 2026, the team’s AWS inventory review identified 47 AWS Lambda functions and 53 Amazon DynamoDB tables associated with BasisPilot in its primary hub Region. These counts include pilot and legacy components.

Conclusion

BasisPilot shows what becomes possible when SAP platform expertise is combined with serverless AWS services and AI assistance built around strict authorization and audit controls. The architecture patterns – hub-and-spoke with STS and SSM, phase-based long-running workflows, tool-calling behind RBAC and approval gates, and verification-first automation – can be adapted by enterprises operating large, regulated workloads on AWS.

Get started

The patterns behind BasisPilot build on managed AWS services you can adopt in your own SAP or enterprise operations platform. These resources are a useful starting point:

• Amazon Bedrock – build tool-calling AI assistants with governed access to backend tools. See the Amazon Bedrock documentation
• AWS Systems Manager – run agentless, auditable commands on EC2 hosts without SSH.
• AWS Lambda and Amazon DynamoDB – implement phase-based, self-checkpointing workflows with durable state tracking.
• Cross-account access with AWS STS – reach workloads in spoke accounts through short-lived, tightly-scoped roles.
• SAP on AWS – reference architectures and operations guidance for running SAP workloads on AWS.

To apply this in your organization, start by writing your operational judgment, the dependencies, approval gates, and verification steps, into platform behavior, then add an AI assistant as a scoped interface to those governed workflows.

Authors:

	Manish Kumar is a Senior SAP Product Owner within Toyota Motor North America’s (Toyota) SAP BTP Platform team. His experience spans SAP solution architecture, cloud migrations, system upgrades, and enterprise modernization. He conceived BasisPilot and led its design, architecture, and implementation, connecting SAP expertise with AI-assisted analysis and governed operations on AWS. His work combines product ownership with hands-on engineering, emphasizing reliability, security, and human oversight: the platform prepares the work, engineers approve every change. Manish holds certifications in SAP BTP solution architecture, TOGAF 9, and AI governance (IAPP AIGP), and is an IEEE Senior Member and an IAPP Fellow of Information Privacy (FIP).
	Anshuman Kowtha is a Technical Manager at Toyota Motor North America, where he leads platform strategy and delivery across the company’s SAP and AWS cloud environments. With 23 years in enterprise technology and more than 15 years leading enterprise-scale SAP landscapes, he has guided organizations through major platform shifts — from on-premises infrastructure to hyperscale cloud, from legacy SAP to S/4HANA — building and scaling mission-critical systems through periods of migration, transformation, and continuous modernization. He brings a hands-on technical foundation, deep operational rigor, and a strong focus on governance and security to helping enterprises adopt cloud and identity platforms at scale.
	Ashish Patel is Senior Manager of SAP Technology at Toyota Motor North America, bringing 24 years of SAP platform experience, including more than seven years at Toyota. His expertise spans SAP and ERP platforms, cloud infrastructure, and system integration, with a focus on aligning technology strategy with business priorities. He leads initiatives to strengthen platform reliability, improve operational efficiency, and support digital transformation. His leadership emphasizes collaboration, continuous improvement, and developing teams that translate complex technical challenges into practical business solutions. Ashish holds multiple SAP Technology Associate and Specialist certifications, along with the AWS Certified Solutions Architect – Associate credential.
	Neill Reidy is a Principal Technical Account Manager at AWS who helps enterprises build resilient, operationally excellent cloud environments. He brings 29 years of experience in Linux and networking. He has spoken at AWS re:Invent, holds multiple AWS Professional certifications and has written AWS blog posts and customer case studies on AWS Systems Manager, Amazon Connect, AWS Unified Operations and disaster recovery.
	Vijay Sitaram is Principal Technical Account Manager at AWS. With 26 years of experience in IT focused on Database and SAP technologies, he is a support leader for SAP workloads on AWS for Automotive & Manufacturing customers. He helps customers operate and scale SAP workloads with focus on resilience, cost and operations excellence. He has written several AWS for SAP blog articles, authored AWS workshops for backup, resilience and AI-Led kiro-cli with MCP for SAP operations, owner of AIOPS for SAP MCP Server, and an AWS re:Invent speaker. He is certified in AWS Solution Architect Professional and GenAI Professional. In his free time, he is active in CrossFit, weightlifting, mountain biking, and wilderness backpacking.

© Toyota Motor North America. This document describes internal tooling architecture for knowledge-sharing purposes. All environment-specific identifiers have been omitted in accordance with Toyota public-content guidelines. AWS service names are trademarks of Amazon.com, Inc. or its affiliates. SAP and SAP HANA are trademarks of SAP SE.