How TCS built an agentic test orchestrator with Amazon Bedrock AgentCore

This post was co-written with Varun Valsan from Tata Consultancy Services (TCS). Tata Consultancy Services (TCS) runs large-scale testing for Banking, Financial Services, and Insurance (BFSI) clients, where the slowest part of a release is rarely writing application code. The larger constraint is the chain of work that follows: interpreting requirements, designing scenarios, writing and maintaining automation, preparing execution environments, investigating failures, and assembling evidence for review. BFSI clients need to increase testing throughput while preserving the controls expected in financial services. The objective wasn’t to replace quality engineers. It was to remove repetitive translation and execution work so that engineers could spend more time on risk analysis, exploratory testing, and release decisions. These industry needs generated four specific requirements for TCS. First, every test must be grounded in project-specific context rather than generic prompts. Second, it had to cover both API and browser-based UI testing to match how BFSI applications are built. Third, security is paramount, so every tenant’s data and knowledge store must be isolated. Finally, it must provide a repeatable path from requirement ingestion to test evidence and reporting, so the gains hold across teams and releases. In this post, we show how TCS built an agentic test orchestrator that turns requirements into executable, governed tests, and what it changed for its BFSI testing teams. Why conventional automation and systems weren’t enough TCS already uses traditional test automation for its clients, and it does improve execution speed. But it leaves the slow work untouched: teams must still create the scenarios, convert them into scripts, maintain locators and dependencies, and diagnose failures. When a linked user story changes, scripts generated for an earlier story can quickly become stale. A single generative AI prompt also doesn’t provide the control needed for a multi-stage engineering workflow. TCS therefore designed the Agentic Test Orchestrator to decompose testing into specialized tasks. Each task has its own agent, tools, validation rules, and context. A deterministic supervisor routes work, while an execution workflow controls retries, error classification, persistence, and reporting. To run these agents, TCS chose Amazon Bedrock AgentCore , a service to build, connect, and optimize agents at scale, with any framework or model. Three capabilities drove the decision. First, Amazon Bedrock offers a choice of models, so each agent uses the model that fits its task, such as scenario design or code generation, and TCS can adopt newer models as they become available. Second, AgentCore runtime, a capability of Amazon Bedrock AgentCore, scales with demand, so testers across many tenants can run generation and execution sessions at the same time without TCS provisioning or tuning agent servers. Third, the runtime runs each session in its own isolated microVM, which gives TCS session-level separation for its multi-tenant platform without having to build that layer itself. Together, these capabilities let TCS focus its engineering effort on testing logic rather than agent infrastructure, which shortened the time to bring the platform to its BFSI clients. Solution overview The following diagram shows the end-to-end flow of the platform across five stages, with a per-tenant security layer underneath. Inputs from Jira, business requirement documents (BRDs), and GitLab enter a tenant web application that runs on Amazon Elastic Kubernetes Service (Amazon EKS) behind Amazon CloudFront , with sign-in through Amazon Cognito . TCS uses Amazon Bedrock AgentCore runtime to host the platform’s specialized agents, built with the Strands Agents SDK . These agents generate the tests, refine them with the tester, and manage their execution. Amazon Elastic Container Service (Amazon ECS) runs the generated tests. Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB store the results, and Amazon CloudWatch captures the logs. Throughout, AWS WAF , Amazon Cognito, AWS Key Management Service (AWS KMS) , and AWS Secrets Manager enforce per-tenant security and isolation. Figure 1: High-level solution architecture The TCS Agentic Test Orchestrator is a multi-tenant software as a service (SaaS) solution built on AWS. A tester provides requirements through Jira stories, business requirement documents (BRDs), Swagger specifications, uploaded documents, GitLab source folders, or captured UI flows. From those inputs the platform then generates test scenarios, Gherkin feature files, and executable Java or Python tests. It runs those tests on Amazon ECS, stores artifacts and results, and shows progress and reports in a per-tenant web application. The sections that follow describe how each part of the platform meets one of the four requirements TCS set. 1. Separate the control plane from each tenant application plane TCS required strict isolation of each tenant’s identity, data, and keys, so the platform uses pooled compute with siloed data and identity. A shared control plane provides the Amazon EKS cluster, container registry, administrative portal, tenant registry, onboarding automation, Amazon CloudFront distributions, and AWS WAF protection. Each tenant application plane receives its own Kubernetes namespace, Amazon Cognito user pool, AWS KMS key, Amazon S3 bucket, Amazon DynamoDB tables, and Amazon Bedrock Knowledge Bases . This separation gives each BFSI tenant the data and key boundaries that financial-services controls demand. Tenant onboarding is event driven. The administrative API writes a pending tenant record, emits an event through Amazon EventBridge , and starts an AWS CodeBuild project that deploys the tenant infrastructure with AWS Cloud Development Kit ( AWS CDK ). This pattern makes tenant provisioning repeatable while retaining tenant-specific identity and data boundaries that TCS needed. 2. Ground every agent in project context TCS’s first requirement was that generation reflect each project’s domain rather than a generic prompt, so grounding is built into the platform. The platform stores uploaded requirements and generated artifacts in Amazon S3 and session metadata in Amazon DynamoDB. Project documents and synchronized source files are indexed in Amazon Bedrock Knowledge Bases using vector embeddings. Before material reaches an agent, retrieval is filtered by tenant, project, and session context, so one client’s context doesn’t inform another’s tests. This context layer supports the many ways a BFSI team expresses requirements: Jira stories and linked story chains, BRDs, Swagger definitions, reference code, locator documents, setup modules, test data, and GitLab source folders. For UI automation, a separate capture service uses Puppeteer to convert a URL and a natural-language goal into a UI flow document and an XPath locator document. 3. Use specialized agents instead of one large prompt Because a single prompt can’t give a regulated workflow the control it needs, the platform divides the work among specialized agents that run as containerized services in Amazon Bedrock AgentCore runtime using the Strands Agents SDK. A generation runtime routes requests to dedicated scenario, Gherkin, code-generation, and validation tools. Additional runtimes support conversational refinement, BRD-to-story conversion, incremental generation across linked Jira stories, and test execution. Each agent owns a stage of the lifecycle. Here’s a brief overview of each specialized agent: Generation agent: Creates structured scenarios, converts them to Gherkin, generates Java or Python automation, and validates generated code. Chat agent: Classifies a request as an information query or an update request, then answers or revises the active artifact. Dynamic task agent: Retrieves BRD context and produces a structured user story with requirements and acceptance criteria. Incremental