How TCS built an agentic test orchestrator with Amazon Bedrock AgentCore

Tata Consultancy Services built a multi-tenant agentic test orchestrator using Amazon Bedrock AgentCore to automate test creation, maintenance, and execution for Banking, Financial Services, and Insurance enterprises, according to AWS Machine Learning Blog's report. The platform ingests business requirements from Jira, code repositories, and specification files to generate executable Java and Python test suites. In internal benchmark testing, the automated orchestration architecture reduced overall testing effort by 88 percent while preserving financial compliance controls.

This technical analysis examines the architectural design, security boundaries, multi-agent coordination, and workload routing that power the system. It is written for enterprise architects, quality assurance leaders, and engineering teams building generative artificial intelligence automation under stringent financial regulatory controls.

01Bedrock AgentCore runtime and model flexibility

Conventional test automation tools accelerate script execution but still leave scenario design, locator updates, and failure triage to manual engineering effort. In enterprise banking software, requirements shift frequently across release cycles, causing static scripts generated from earlier user stories to break. A single generative prompt cannot handle the validation rules, deterministic retries, and multi-stage coordination required for enterprise-grade testing workflows.

To resolve these constraints, Tata Consultancy Services architect Varun Valsan and AWS engineers structured the platform around Amazon Bedrock AgentCore. The service enables teams to select specialized foundation models optimized for distinct tasks, such as scenario generation or code drafting, while allowing seamless adoption of future models. This architectural flexibility prevents vendor lock-in and aligns model capabilities with specific testing stages.

AgentCore runtime also delivers dynamic scaling, supporting concurrent generation and execution sessions across dozens of client organizations without manual server provisioning. Furthermore, the runtime hosts every execution session inside an isolated microVM. This architecture provides robust session-level separation for multi-tenant banking workloads without requiring the engineering team to build custom virtualization layers.

02Pooled control plane and siloed tenant architecture

Financial institutions require strict boundaries around data access, encryption keys, and administrative control to satisfy regulatory audits. To address these mandates, the orchestrator combines pooled compute infrastructure with completely segregated tenant data planes. A centralized control plane hosts shared operational assets, including an Amazon Elastic Kubernetes Service cluster, container registries, administrative portals, and tenant tracking directories.

Network traffic arriving at the shared control plane passes through Amazon CloudFront distributions protected by AWS WAF rules. In contrast, each client organization receives a dedicated tenant application plane provisioned with a private Kubernetes namespace, Amazon Cognito user pool, and AWS Key Management Service cryptographic key. Client data resides in dedicated Amazon S3 buckets, Amazon DynamoDB tables, and Amazon Bedrock Knowledge Bases.

Client onboarding runs through a fully automated, event-driven provisioning workflow initiated by administrative requests. The administrative API registers a pending tenant record, which publishes an event through Amazon EventBridge. That event triggers an AWS CodeBuild job that deploys client-specific infrastructure using AWS Cloud Development Kit templates, guaranteeing repeatable and isolated environment setups.

03Project context grounding and Puppeteer flow capture

To prevent hallucinations and generic outputs, every test generation workflow grounds autonomous agents in project-specific engineering artifacts. The platform stores uploaded requirements, test metadata, and generated scripts across Amazon S3 and Amazon DynamoDB. Project documentation and synchronized repository files are converted into vector embeddings and indexed within Amazon Bedrock Knowledge Bases.

Before context reaches an agent, the retrieval layer filters data by tenant, project, and session identifiers, ensuring strict information isolation across institutional boundaries. The ingestion engine handles varied technical inputs, including Jira user stories, business requirement documents, Swagger API specifications, locator sheets, and GitLab code repositories. This contextual awareness ensures generated tests reflect actual application logic and dependency paths.

For web applications, the platform provides an automated user interface capture service running headless Puppeteer instances. The service navigates target URLs based on natural-language test objectives, extracting user interface interaction sequences and DOM hierarchies. It then produces structured flow documentation alongside an XPath locator catalog, supplying downstream agents with exact target selectors.

04Specialized agents across the testing lifecycle

Instead of relying on a monolithic prompt, the orchestrator distributes testing responsibilities across five specialized agents running in containerized microVMs via the Strands Agents SDK. A deterministic supervisor manages workflow progression, error classification, and state persistence across stages. Each agent operates with dedicated tool sets, validation rules, and scoped context tailored to its specific lifecycle role.

The generation agent drafts structured scenarios, translates requirements into Gherkin syntax, produces Java or Python test scripts, and executes syntax validation checks. A conversational chat agent classifies user prompts into informational queries or code modification requests, updating active testing artifacts accordingly. This separation allows engineers to interactively refine test cases without regenerating entire project suites.

Complex delivery tasks rely on three additional agents that manage ongoing release iterations. A dynamic task agent converts business requirement documents into structured user stories with explicit acceptance criteria. Meanwhile, an incremental agent extends test suites across linked Jira story chains, while an execution agent coordinates runtime environments, classifies run errors, and applies automated script fixes.

05Dual execution routing across Fargate and EC2

Enterprise banking applications present divergent runtime requirements for backend interfaces and interactive browser experiences. The execution agent inspects generated test code to classify test types and route workloads to specialized infrastructure. This workload-aware routing prevents resource contention and optimizes cloud computing expenditures across continuous testing pipelines.

Headless API test suites are routed directly to Amazon Elastic Container Service running on serverless AWS Fargate compute. Because API verification does not require graphical rendering, Fargate provides cost-efficient, instantaneous elasticity for high-volume contract checks. The execution agent runs the suites, validates status codes, and streams execution metrics to central storage.

Interactive browser tests using Selenium require graphical rendering and are routed to an Amazon Elastic Container Service cluster on Amazon EC2 instances running Chrome with a virtual display. FFmpeg captures display output and publishes HTTP Live Streaming feeds to Amazon S3 for CloudFront delivery, while Amazon CloudWatch aggregates system logs. Internal evaluations demonstrated an 88 percent testing effort reduction across these workflows.