TCS builds governed test orchestrator on Amazon Bedrock AgentCore

Tata Consultancy Services built an agentic test orchestrator on Amazon Bedrock AgentCore to turn project requirements into governed API and browser tests for financial-services teams. According to an AWS account co-written with TCS, the system automates requirement ingestion, test generation, execution, correction and evidence collection. Quality engineers remain responsible for reviewing AI-produced artifacts and making risk, exploratory-testing and release decisions.

The platform accepts Jira stories, business requirement documents, Swagger specifications, uploaded documents, GitLab source folders and captured user-interface flows. It generates scenarios, Gherkin feature files and executable Java or Python tests. Instead of asking one model to handle the full workflow, a deterministic supervisor routes work among specialized generation, chat, dynamic-task, incremental and execution agents.

Amazon Bedrock AgentCore Runtime hosts the agents, which TCS built with the Strands Agents SDK. Amazon EKS hosts the tenant web application, while Amazon ECS runs generated tests. Amazon S3 and DynamoDB store artifacts, results and metadata, and CloudWatch captures logs. Project material is indexed in Amazon Bedrock Knowledge Bases; retrieval is filtered by tenant, project and session before context reaches an agent.

TCS describes the service as pooled compute with siloed identity and data. A shared control plane supplies the EKS cluster and common services, while each tenant receives a separate Kubernetes namespace, Cognito user pool, KMS key, S3 bucket, DynamoDB tables and Bedrock Knowledge Base. AWS documents a separate runtime boundary in which each AgentCore session receives a dedicated microVM with isolated compute, memory and filesystem resources. AWS also says the customer backend, rather than AgentCore, must enforce the mapping between users and session IDs.

The execution agent sends API tests to Amazon ECS on AWS Fargate and Selenium browser tests to an EC2-backed ECS cluster that can run Chrome with a virtual display. Browser runs can be recorded and streamed through S3 and CloudFront. Logs go to CloudWatch, and Cucumber reports are stored in S3 with time-limited access. Final records include the code, run status, attempt count, logs, parsed results and report location.

Automated correction follows a LangGraph fetch-execute-fix-save state graph with a bounded retry loop. Only failures classified as code errors are eligible for a proposed fix. Checks reject empty files, unexpected new files and extreme file-size changes; connectivity and authentication failures bypass the fixer. The account also lists tenant-specific encryption keys, tenant-scoped database access, separate identity pools, role-based authorization, Kubernetes NetworkPolicy and ResourceQuota, non-root containers, dropped Linux capabilities, AWS WAF, HTTPS delivery, OpenTelemetry traces and CloudWatch monitoring. These are described design controls. The supplied evidence does not include an external security assessment or proof of regulatory compliance.

TCS says it runs the orchestrator in production for banking, financial-services and insurance clients. The supplied sources, however, do not name customers or disclose deployment dates, tenant counts, test volumes, service levels or other measures of production scale. TCS also reports that a controlled internal comparison covering about 100 scenarios reduced average effort from roughly two hours to about 14 minutes per scenario, an 88% reduction. The raw results, scenario mix, error rate, review effort and test-quality measures were not published, and the result has not been independently reproduced.