KTern AI, an SAP digital transformation platform, faced challenges in building autonomous agents that could operate across long-running SAP transformation projects requiring persistent context, secure tool integration, multi-tenancy, dynamic scalability, and production-grade observability. The company migrated from a self-managed container stack to Amazon Bedrock AgentCore using the Strands Agents SDK, building over 20 specialized agents through configuration rather than custom orchestration code. This approach reduced agent development time by 85%, cut infrastructure costs by 70%, and reclaimed 480 engineering hours per month. In production, the agentic platform delivered 45% faster SAP project timelines, 60-70% reduction in discovery and assessment time, 90% autonomous identification of operational exceptions, and 82% first-pass success rate on automated test case generation.
KTern AI is an SAP Spotlight Partner that provides a Digital Transformation as a Service (DXaaS) platform specifically focused on SAP S/4HANA migrations and system conversions. The company faced a critical challenge in evolving from a traditional SaaS platform into what they term a “next-generation agentic AI platform” capable of autonomously orchestrating the complex, multi-month SAP transformation workflows that enterprises undertake. This case study, published in July 2026, represents one of the more comprehensive production deployments of agentic AI systems using Amazon Bedrock AgentCore and provides detailed insights into the LLMOps considerations for building, deploying, and operating over 20 specialized AI agents in enterprise environments.
The transformation at KTern AI is particularly relevant to LLMOps practitioners because it demonstrates the full lifecycle of operationalizing LLM-based agents at scale, from initial architecture decisions through production deployment, monitoring, and continuous evaluation. The company’s explicit move away from self-managed infrastructure to a fully managed agentic platform also provides insights into the build-versus-buy decisions that many organizations face when scaling GenAI systems.
SAP digital transformations represent some of the most complex enterprise IT initiatives, typically spanning 12-18 months and involving intricate interdependencies across business processes, custom code, and organizational change. KTern AI’s previous approach had delivered value through their proprietary “institutional knowledge intelligence engine” that encoded SAP transformation patterns, but the platform still required significant manual consultant effort and operated through more traditional single-turn AI interactions.
The company identified several interconnected challenges that prevented truly autonomous operation at enterprise scale. First, persistent context management emerged as a critical requirement—agents needed to retain state across hundreds of interactions over months-long projects, building cumulative understanding rather than resetting with each session. The challenge here wasn’t just storing conversation history but selectively maintaining the right context without overloading agents, which the team explicitly recognized could slow performance, increase costs, and elevate hallucination risks.
Second, secure and governed tool integration posed significant operational hurdles. Real agents operating in SAP transformation scenarios need authenticated, real-time access to live SAP environments, customer ERP systems, process mining sources, and analytical repositories. Each tool connection must meet enterprise security standards with full auditability, which eliminates ad-hoc integration approaches. Third, the multi-tenant nature of the platform required configuration-driven flexibility where each customer operates as an isolated tenant with distinct processes, exceptions, and business rules, yet agents must be deployable without custom engineering for every tenant.
Dynamic scalability represented another dimension of complexity. A rapid SAP assessment might engage a handful of agents for a few hours, while a full enterprise migration could run dozens of agents continuously over months, requiring infrastructure that scales elastically without manual intervention. Finally, production-grade observability emerged as non-negotiable—debugging multi-agent workflows without detailed logs, traces, and metrics simply doesn’t work in enterprise environments where agents make consequential decisions affecting business-critical systems.
Before adopting AgentCore, KTern AI operated on a self-managed container stack that they built and maintained themselves. While functional, this approach consumed substantial engineering resources on infrastructure concerns rather than their core differentiation: designing agents that understand SAP transformation domains.
KTern AI’s solution centers on a clean separation of concerns where SAP domain intelligence remains in their application layer while all infrastructure concerns—hosting, scaling, memory management, tool access, identity, and observability—are delegated to Amazon Bedrock AgentCore. The company explicitly chose a configuration-driven approach where agent behavior is defined through prompts, tool bindings, and orchestration patterns rather than custom orchestration code.
The architecture flows from client layer inward. Enterprise users submit transformation requests through the KTern AI platform, which routes to an agent orchestration layer where specialized agents run on AgentCore runtime with full session isolation ensuring one customer’s context remains inaccessible to others. Each agent invokes external tools through the AgentCore gateway implementation of Model Context Protocol (MCP), which manages authenticated connections to SAP APIs, customer ERP systems, and KTern AI’s repositories. Network security is enforced through VPC interface endpoints powered by AWS PrivateLink, keeping all traffic off the public internet.
AgentCore memory serves as the persistence layer, retrieving and updating project context tied to each engagement, preserving process decisions, code patterns, and accumulated insights across sessions. AgentCore identity enforces authentication and least-privilege access for both agents and tools, with every action and model response captured by AgentCore observability and forwarded as logs, metrics, and traces to Amazon CloudWatch. At the foundation, Amazon Bedrock provides model access including Anthropic’s Claude family of models, while Amazon S3, AWS Lambda, and AWS IAM support the broader system.
The team reports that deploying their first production agent took 4-6 hours with zero infrastructure code, a stark contrast to their previous approach requiring 2-3 weeks of custom infrastructure assembly per agent. This represents an 85% reduction in development cycle time and 95% reduction in infrastructure setup time. New agents now reach production same-day through configuration deployment, and the company maintains over 50 agent configurations across customer scenarios as of the publication date.
KTern AI operates over 20 specialized agents in production, each owning a discrete domain of the SAP transformation lifecycle. The company uses different Strands multi-agent patterns matched to workload characteristics: swarm patterns for parallel discovery tasks, workflow patterns for sequential phases, and graph patterns for conditional pipelines. This design choice reflects sophisticated thinking about orchestration—different transformation activities have different dependency structures and parallelization opportunities.
The reverse engineering agent performs deep automated analysis of existing SAP landscapes, scanning custom ABAP code, user exits, enhancements, configurations, and process variants to build current-state inventories. Its output feeds downstream agents as a shared foundation for reasoning about migration impact and modernization paths. The forward engineering agent then converts these insights into clean-core-aligned target architectures, applying SAP’s clean-core principles to recommend what functionality to retain, refactor, or retire.
The fit-to-standard agent evaluates customer business processes against SAP standard processes, identifying customization divergence and recommending alternatives—work that typically requires functional consultants to manually review hundreds of processes. The custom code analysis agent assesses the full ABAP landscape for migration compatibility, deprecated API usage, performance risks, and modernization potential, classifying each object by complexity with prioritized remediation guidance.
The test case generation agent automates creation of executable test cases from business process flows, custom code analysis outputs, and configuration data, producing scripts with test data, expected outcomes, and validation criteria. It achieves an 82% first-pass execution success rate, which the company attributes to continuous evaluation practices. The process mining agent analyzes SAP event logs across purchase-to-pay, order-to-cash, and other processes to surface actual process execution versus designed flows, identifying bottlenecks and automation opportunities. The exception mining agent proactively identifies and classifies operational exceptions across Finance, Controlling, Sales, and Materials Management modules, with 90% of exceptions now surfaced autonomously.
The case study provides valuable insights into memory architecture as a first-class design decision in agentic systems. In long-running enterprise workflows spanning months, memory schema design determines whether agents reason like experienced consultants carrying project history or start from scratch every session. KTern AI explicitly frames this as “context engineering”—bringing enough context for agents to reason effectively without overloading them.
AgentCore memory provides the underlying infrastructure for persistent context, but the company’s value-add lies in designing what context to preserve and when to surface it. The system maintains custom code inventories, process decisions, and exception patterns across the 12-18 month typical project lifecycle, with hundreds of agent interactions per project. This design choice reflects understanding that naive approaches to context management—either providing no persistence or dumping entire project histories into every agent invocation—both fail in different ways.
The multi-tenant isolation that AgentCore memory provides built-in was highlighted as particularly valuable, eliminating the need for the company to design, implement, and audit custom isolation mechanisms. Each customer’s SAP transformation context remains strictly separated, which is non-negotiable in enterprise environments where customers may be competitors or operate in regulated industries.
The AgentCore gateway implementation of Model Context Protocol emerged as a critical enabler for the platform’s tool integration strategy. KTern AI’s agents require real-time access to an expanding set of external systems: live SAP environments, customer ERP APIs, process mining sources, and analytical repositories. The list grows with every customer deployment, making hardcoded integrations untenable.
MCP allows the company to register new tools through configuration rather than custom integration code, fundamentally changing the economics of adding capabilities. Exception mining agents, for example, reach Finance and Sales data directly in customer systems through the gateway with authenticated, auditable connections. The security teams at enterprise customers scrutinize every system touching their SAP landscape, and the gateway’s support for least-privilege access per agent plus full audit trails of tool invocations provided the assurances needed for production approval.
The case study doesn’t detail the specific MCP server implementations or tool definitions, but the architectural choice reflects emerging best practices in agentic systems: standardized protocols for tool integration that decouple agent logic from integration mechanics. This separation allows agent developers to focus on reasoning patterns while infrastructure handles authentication, rate limiting, error handling, and observability for tool calls.
KTern AI’s emphasis on observability as a day-one requirement rather than an afterthought reflects hard-won lessons from operating complex systems. Before AgentCore observability, debugging multi-step agent failures meant manually correlating logs across disconnected systems. The company now traces issues from initial request through every agent decision and tool call to final response in minutes, which they directly credit for sustaining 99.8% agent uptime.
The integration with Amazon CloudWatch and OpenTelemetry provides distributed tracing across the multi-agent system. When an exception mining agent fails to surface expected Finance exceptions, operators can trace the failure back through the agent’s reasoning steps, the specific tool calls it made to customer ERP systems, the data it retrieved, and how it interpreted that data in its decision-making. This visibility is essential not just for debugging but for continuous improvement—understanding where agents succeed and fail informs prompt engineering, tool design, and orchestration pattern refinement.
The company specifically calls out that instrumentation from day one pays compounding dividends as agent count grows. With over 20 agents in production and 50+ configurations, the combinatorial complexity of interactions makes system-wide observability non-optional. Each agent’s actions must be traceable not just in isolation but in the context of the broader transformation workflow it participates in.
KTern AI employs AgentCore evaluations to run continuous quality assessment cycles rather than one-time launch validations. The company explicitly learned that agents drift as underlying models update and production data shifts, and continuous evaluation catches drift before customers experience degraded outcomes. For the test case generation agent specifically, where accuracy affects go-live risk for SAP transformations, the team evaluates on every configuration change using KTern AI-specific SAP test cases as evaluation datasets.
This approach reflects sophisticated thinking about LLMOps maturity. Early in GenAI adoption, many organizations treat evaluation as a gate before initial deployment. More mature practices recognize that production environments are dynamic—foundation models get updated by providers, customer data patterns evolve, and agent prompts are continuously refined. Static evaluation gates don’t protect against degradation over time.
The 82% first-pass success rate for test case generation is presented as an outcome of this continuous evaluation discipline. Rather than discovering quality issues through customer complaints, the evaluation pipeline flags model-driven behavior shifts early, allowing the team to investigate and remediate before production impact. The case study doesn’t detail the specific evaluation metrics or datasets beyond mentioning “KTern AI-specific SAP test cases,” but the principle of domain-specific evaluation data is clear—generic benchmarks don’t predict performance on specialized SAP transformation tasks.
The quantitative results KTern AI reports are substantial, though it’s important to note these represent the company’s internal measurements across their production SAP transformation engagements rather than independent third-party validation. The 45% average reduction in overall SAP project timelines and 60-70% reduction in discovery and assessment time represent the most direct customer-facing impacts. Discovery and assessment traditionally consume the largest share of early project budgets while involving extensive manual work from consultants with specialized SAP domain knowledge.
The up to 60% reduction in manual subject matter expert and consultant dependency during analysis phases directly addresses cost and scalability concerns—specialized SAP consultants are expensive and capacity-constrained. The 90% autonomous identification of operational exceptions in Finance and Sales modules automates work that previously required reactive manual review, often only surfacing issues after business impact occurred.
The 40% reduction in post-go-live support incidents is particularly significant from a quality perspective. Post-go-live issues are expensive to resolve, disrupt business operations, and damage confidence in transformation outcomes. The company attributes this improvement to earlier and more comprehensive risk identification by the reverse engineering and custom code analysis agents, which surface technical debt and migration risks before they compound into downstream problems.
From an operational efficiency perspective, the 70% reduction in infrastructure costs versus their self-managed container stack demonstrates the economic advantage of delegating undifferentiated infrastructure to managed services. The 480 engineering hours per month reclaimed—equivalent to three full-time engineers—represents capacity reinvested in agent intelligence and new capabilities rather than infrastructure maintenance. The 99.8% agent uptime sustained across production deployments suggests the managed infrastructure provides reliability that meets or exceeds what the team achieved with self-managed systems.
The shift from weeks to hours for new agent deployment fundamentally changes what’s economically feasible to build. When each new agent capability requires 2-3 weeks of custom infrastructure work, the barrier to experimentation is high—teams carefully gate which agents get built and invest heavily in each one. When deployment compresses to same-day through configuration, experimentation becomes cheap and iteration cycles accelerate.
The company’s lesson that “start with configuration, not code” reflects this learning. Each time the team was tempted to write custom orchestration logic, a configuration-based equivalent proved faster to build and easier to maintain. This discipline keeps the platform maintainable even as agent count and configuration variety grow. With 50+ agent configurations maintained, a custom-code-per-agent approach would create unmaintainable technical debt.
The 95% reduction in infrastructure setup time—no provisioning, no custom pipeline engineering—allows agent developers to focus entirely on the domain logic: prompts, reasoning patterns, tool selection, and orchestration patterns. This separation of concerns is central to the value proposition of managed agentic platforms. Teams build differentiated IP in their domain (SAP transformation intelligence for KTern AI) rather than rebuilding commodity infrastructure.
The emphasis on enterprise security as a first-class concern rather than an afterthought reflects the realities of selling into regulated industries. AgentCore identity provides least-privilege access per agent, full audit trails of tool invocations, and compatibility with existing customer identity infrastructure. These capabilities gave security teams at enterprise customers the confidence to approve agents for production without requiring custom access-control work.
The use of AWS PrivateLink to keep traffic between agents and Bedrock off the public internet addresses network security requirements common in financial services, healthcare, and other regulated sectors. The multi-tenant isolation that comes built into AgentCore runtime eliminates the risk of one customer’s agents accessing another customer’s SAP data, which would be a disqualifying vulnerability.
The case study’s lesson that “make enterprise security credible before the first conversation” suggests the team learned this through experience—likely encountering procurement blockers when security questions couldn’t be confidently answered. In enterprise sales, particularly for systems touching mission-critical SAP environments, security concerns can extend sales cycles by months or kill deals entirely. Having architecture decisions and managed service capabilities that address common security requirements accelerates procurement.
While the case study presents impressive results, several considerations deserve balanced examination. First, the metrics are self-reported by KTern AI based on their internal measurements rather than validated by independent third parties or customers. The 45% reduction in project timelines and 60-70% reduction in discovery time are substantial claims that would benefit from customer validation or detailed methodology explanation.
Second, the case study is published on AWS’s blog and represents a customer success story for Amazon Bedrock AgentCore, which was likely still relatively new as of July 2026. There’s natural selection bias in what gets published as customer case studies—implementations with challenges or ambiguous results don’t become blog posts. The story focuses on successes and benefits while providing limited discussion of challenges faced, limitations encountered, or tradeoffs made.
Third, the 82% first-pass success rate for test case generation, while respectable, means 18% of generated test cases fail on first execution. In the context of SAP transformations where go-live risks are high, this error rate requires human review and refinement of generated test cases. The case study frames this as success through continuous evaluation, but it also represents ongoing manual effort that limits full automation.
Fourth, the agent count of “over 20” operating in production with “over 50 agent configurations” suggests significant complexity in managing the agent network itself. The case study doesn’t address challenges in orchestrating interactions between 20+ agents, managing dependencies, handling failure modes where one agent’s output affects downstream agents, or preventing cascading failures. These are known challenges in multi-agent systems that likely required significant engineering effort to address.
Fifth, while the configuration-driven approach reduces infrastructure engineering, it doesn’t eliminate the core challenge of prompt engineering, reasoning pattern design, and tool selection. These remain complex domain-specific engineering tasks that require both SAP expertise and GenAI capability. The case study mentions “centralized prompt management” with version control and rollback, suggesting they’ve encountered prompt drift or regression issues requiring governance.
The case study demonstrates several indicators of LLMOps maturity worth noting for practitioners. The recognition that memory architecture is a “first-class design decision” rather than an afterthought shows sophisticated understanding of persistent agent systems. The emphasis on context engineering—bringing the right context rather than all context—addresses a common pitfall where teams overload agents with excessive history.
The practice of continuous evaluation on every configuration change rather than one-time validation at launch reflects production-grade quality discipline. The integration of observability from day one rather than adding it reactively shows learning from distributed systems best practices. The standardization on Model Context Protocol for tool integration demonstrates architectural thinking about long-term maintainability as tool count grows.
The explicit documentation of lessons learned—start with configuration not code, instrument from day one, evaluate continuously, make security credible early—suggests the team encountered and learned from mistakes during the journey. These aren’t obvious principles for teams new to agentic systems, and documenting them provides value to the community.
The ability to deploy new agents in 4-6 hours through configuration represents a level of platform maturity that enables rapid experimentation and iteration. This development velocity is a competitive advantage when building domain-specific agentic applications. The 480 engineering hours per month reclaimed by delegating infrastructure to managed services represents substantial capacity for innovation.
This case study represents one of the more comprehensive public examples of operationalizing multi-agent systems at enterprise scale as of mid-2026. KTern AI’s migration from self-managed infrastructure to a managed agentic platform demonstrates clear benefits in development velocity, operational efficiency, and ability to focus engineering effort on domain differentiation rather than infrastructure.
The architectural choices—configuration over code, managed services for undifferentiated infrastructure, standardized protocols for tool integration, continuous evaluation, comprehensive observability—represent emerging best practices for LLMOps at scale. The specific application to SAP transformation workflows demonstrates that agentic AI can deliver measurable value in complex enterprise domains where automation was previously limited to narrow tasks.
For organizations considering similar journeys, the case study validates several principles: invest in memory architecture early, instrument for observability from the start, evaluate continuously rather than once, address enterprise security upfront, and leverage managed services to focus on domain-specific value creation. The quantitative results, while self-reported, suggest that meaningful automation of knowledge work is achievable in production with current technology when thoughtfully applied to well-scoped domains.
The broader implication is that the infrastructure layer for agentic AI is maturing rapidly, with managed services like Amazon Bedrock AgentCore commoditizing capabilities that required months of custom engineering just a year or two earlier. This shifts competitive advantage from infrastructure engineering toward domain expertise, prompt engineering, agent design, and integration quality—areas where companies like KTern AI can differentiate based on their deep SAP transformation knowledge. The case represents a meaningful data point in the evolution of LLMOps from research concept to production discipline.
Notion, a knowledge work platform serving enterprise customers, spent multiple years (2022-2026) iterating through four to five complete rebuilds of their agent infrastructure before shipping Custom Agents to production. The core problem was enabling users to automate complex workflows across their workspaces while maintaining enterprise-grade reliability, security, and cost efficiency. Their solution involved building a sophisticated agent harness with progressive tool disclosure, SQL-like database abstractions, markdown-based interfaces optimized for LLM consumption, and a comprehensive evaluation framework. The result was a production system handling over 100 tools, serving majority-agent traffic for search, and enabling workflows like automated bug triaging, email processing, and meeting notes capture that fundamentally changed how their company and customers operate.
Medable developed Agent Studio, a comprehensive platform for deploying AI agents in clinical trial operations to address the lengthy drug approval process that currently takes over 10 years. The platform enables both internal teams and customers to build configurable multi-agent systems that tackle problems like document classification in electronic trial master files and clinical research monitoring across multiple data systems. By taking a platform-first approach with support for model-agnostic agents, RAG knowledge integration, MCP connectors, workflow functionality, and robust evaluation frameworks, Medable has deployed multiple agentic applications that help clinical research associates process over 80,000 documents per year and monitor data across 13+ disparate systems, with the ambitious goal of reducing clinical trial timelines from 10 years to one year.
Union's Chief ML Engineer shares lessons learned from productionizing agentic systems at scale, addressing the critical infrastructure challenges that arise when deploying LLM agents in production environments. The presentation introduces six design principles for building crash-proof, durable agents using the Flyte 2.0 orchestration platform, focusing on how agents can recover from multi-layer failures (infrastructure, network, logical, semantic) through proper context engineering and durability mechanisms. A key case study with Dragonfly demonstrates these principles in action, where a tiered agent architecture processes 250,000+ software products with 200+ steps and 100+ LLM calls each, achieving 2,000+ concurrent runs, 50% reduction in failure recovery time, 30% increased development velocity, and 12 hours per week saved on infrastructure maintenance.
