TCS built a team of agents for bank testing: 100 scenarios in 24 hours instead of 200

Test automation has long sped up test runs, but it barely touches everything else. People still come up with scenarios, scripts get rewritten after every user story change, and a failed test is analyzed by hand. This is the part of the chain that TCS set out to automate for its banking, financial services, and insurance (BFSI) clients. The company described the work together with AWS.

One prompt won't do; you need a pipeline

The company set four requirements. Every test must rely on the context of a specific project. The system must cover both APIs and the browser UI. Each client's data must be isolated. The path from requirement to report must be repeatable from release to release.

A single LLM call doesn't provide that kind of control. So TCS divided the work among agents, each with its own tools, validation rules, and context. Routing is handled not by a model but by a deterministic supervisor. The agents are written with the Strands Agents SDK and run in Amazon Bedrock AgentCore Runtime.

Here is how the roles are distributed:

• the generating agent builds scenarios, converts them to Gherkin, and writes automated tests in Java or Python;
• the chat agent distinguishes a question from a request to change an artifact and either answers or edits;
• the task agent turns a BRD into user stories with acceptance criteria;
• the incremental agent extends tests along a chain of linked Jira tasks rather than starting from scratch;
• the execution agent runs tests, classifies failures, and saves the result.

Context is pulled from Amazon Bedrock Knowledge Bases: Jira, BRDs, Swagger, code, locators, and test data. Retrieval is filtered by client, project, and session, so one customer's knowledge never ends up in another's tests. For the UI, a separate Puppeteer-based service takes a URL and a text goal and produces a scenario description and XPath locators.

How execution and self-healing work

The execution agent determines the test type from the code on its own. API tests run on ECS with Fargate. Selenium tests run on ECS over EC2, where Chrome works with a virtual display and an FFmpeg recording is streamed to S3 and CloudFront.

The error-fixing loop is described as a LangGraph graph with a strict order of steps: fetch, execute, fix, save. The number of retries is capped. If a failure is classified as a code error, a separate agent receives a trimmed context and proposes a targeted fix. Guardrail checks reject empty files, unexpected new files, and sharp jumps in size. Environment errors, such as network or authorization failures, are not allowed to trigger code fixes at all. This addresses the main fear: an agent must not "fix" a test just so that it starts passing.

Client isolation and the result

The platform is multi-tenant. The shared control layer includes EKS, a registry, and an admin portal. Each client gets its own Kubernetes namespace, Cognito pool, KMS key, S3 bucket, DynamoDB tables, and knowledge base. Onboarding runs through EventBridge and CodeBuild with AWS CDK, so deploying a new client is repeatable. Jira and GitLab secrets are stored in Secrets Manager, with WAF, NetworkPolicy, and ResourceQuota layered on top, and OpenTelemetry collects agent traces.

On a representative workload of roughly 100 scenarios, the manual process took about two hours per scenario, or 200 hours. With the orchestrator it comes to about 14 minutes per scenario, or 24 hours. That is an 88% reduction in effort.

Limitations and what to take away

The figure comes from TCS's own internal benchmark, and timelines depend on application complexity and the team. This is a joint publication with AWS, which also sells the solution through its Marketplace. There is no independent verification, nor data on the share of tests that engineers still rewrite.

The practical takeaway goes beyond bank QA. For regulated processes, the working pattern is one where the model doesn't run the process but performs narrow steps. Routing is deterministic, retries are capped, environment errors are separated from code errors, and data isolation is built into the infrastructure. If you are building agents for an end-to-end process, start with these guardrails, and only then pick a model.