TCS Rebuilds Financial Testing with Multi-Agent Orchestration

Summary:Tata Consultancy Services has built the Agentic Test Orchestrator on Amazon Bedrock AgentCore to convert Jira stories, business requirement documents, Swagger specifications, and GitLab sources into structured scenarios, Gherkin features, and executable Java or Python tests. The platform uses specialized agents, a bounded LangGraph correction loop, workload-aware ECS execution, and tenant-specific identity, encryption keys, storage, and knowledge bases for regulated BFSI workloads. In an intern

---

The expensive path from requirements to trustworthy evidence

TCS's central problem was not raw test execution. The expensive work sat between requirements and auditable test evidence: interpreting BRDs and Jira stories, designing scenarios, writing and maintaining automation, preparing environments, diagnosing failures, and assembling reports.

The Agentic Test Orchestrator accepts Jira stories, business requirement documents, Swagger specifications, uploaded documents, GitLab source folders, and captured UI flows. It generates structured scenarios, Gherkin feature files, and executable Java or Python tests before dispatching them to the appropriate execution environment.

Rather than relying on one oversized prompt, the system assigns explicit responsibilities:

• Generation Agent: creates structured scenarios, converts them to Gherkin, generates automation code, and validates the result;
• Chat Agent: distinguishes informational questions from artifact-update requests;
• Dynamic Task Agent: converts BRDs into structured user stories with requirements and acceptance criteria;
• Incremental Agent: extends scenarios and code across linked Jira stories rather than regenerating everything;
• Execution Agent: retrieves artifacts, selects an environment, runs tests, classifies failures, initiates controlled repairs, and persists results.

A deterministic supervisor routes the work, while Amazon Bedrock AgentCore Runtime hosts the sessions. Models can be selected according to the task. Human engineers still review generated artifacts, but their focus shifts toward risk analysis, exploratory testing, and release decisions.

Tenant-aware context and security boundaries

TCS required generation to be grounded in each project's domain rather than generic prompts. Uploaded requirements and generated artifacts are stored in Amazon S3, session metadata in DynamoDB, and project documents and synchronized source files in Amazon Bedrock Knowledge Bases through vector embeddings. Retrieval is filtered by tenant, project, and session before material reaches an agent.

The platform separates a shared control plane from tenant application planes. Shared resources include the EKS cluster, container registry, tenant registry, administrative portal, CloudFront distributions, and AWS WAF. Each tenant receives a separate Kubernetes namespace, Cognito user pool, KMS key, S3 bucket, DynamoDB tables, and Bedrock Knowledge Base.

Tenant onboarding is event-driven: an administrative API writes a pending tenant record, EventBridge emits an event, CodeBuild starts, and AWS CDK deploys the tenant infrastructure. This makes provisioning repeatable while preserving tenant-specific identity, data, and key boundaries.

Shared compute with siloed data does not automatically guarantee tenant isolation, however. Operators must still validate control-plane vulnerabilities, IAM condition policies, knowledge-base retrieval-filter bypasses, container-escape exposure, and cross-tenant administrative access. Resource namespaces alone are not a sufficient security model.

Workload-aware execution

The execution agent detects test type and routes it accordingly. API tests run on ECS with Fargate, while Selenium UI tests run on an ECS cluster backed by EC2 instances, where Chrome can use a virtual display. The UI executor can capture that display with FFmpeg, publish it as an HLS stream to S3, and deliver it through CloudFront. Logs go to CloudWatch, and Cucumber reports are stored in S3 with time-limited access.

This split reflects different resource profiles. API tests generally favor fast startup and compute density, making Fargate operationally attractive. Browser tests are more sensitive to Chrome versions, memory pressure, display drivers, and persistent sessions. EC2-backed workers offer greater control but require node-capacity planning, image maintenance, and idle-capacity management.

Even bounded retries cannot eliminate this physical cost. A failed browser test may recreate containers, reload pages, and repeat expensive initialization. Capacity should therefore be modeled around both concurrency and retry behavior, rather than nominal test counts alone.

Bounding automatic code repair with LangGraph

Automatic repair is the highest-risk part of the pipeline. TCS models fetching, execution, fixing, and saving as an explicit LangGraph state graph with a bounded retry loop.

The fetch node retrieves the test project and assets, sanitizes files, and identifies the framework. The execute node starts an ECS task, monitors it, retrieves logs, and parses results. Only failures classified as code errors are sent to the repair agent; connectivity and authentication failures are excluded. The save node persists the final code, status, attempts, logs, parsed results, and report location.

Safety checks reject empty files, unexpected new files, and extreme file-size changes. This is safer than allowing a model to rewrite an entire test repository, but important controls remain unspecified. The implementation should add:

1. git diff policy checks that reject changes outside an allowlist;
2. immutable records of pre-repair, post-repair, and retest results;
3. restrictions on automatic changes to dependency locks and build scripts;
4. prompt-injection defenses for untrusted requirement documents;
5. an independent validation run rather than trusting the same execution chain to certify its own repair.

What the 88% reduction actually measures

TCS compared the platform with its existing process on a representative BFSI workload of roughly 100 test scenarios. The manual process required about two hours of engineering effort per scenario, or approximately 200 hours in total. The orchestrator averaged about 14 minutes per scenario, or roughly 24 hours for the same set, representing an 88% reduction.

This is more useful than a raw throughput metric because it includes requirement translation, script creation, and execution. Still, the evidence is bounded: only about 100 scenarios were evaluated, the benchmark was internal, and the article does not disclose defect-detection rate, false-positive rate, escaped defects, code-maintenance cost, model-inference expense, or cloud-infrastructure cost.

The 88% figure should therefore be treated as a workflow-efficiency signal rather than a generally transferable production guarantee. More decision-relevant metrics include effective coverage, requirement-to-assertion traceability, regression time after changes, failure-classification accuracy, repair rollback rate, cost per scenario, and post-deployment defect escape rate.

Deployment guidance

The pattern is best suited to organizations with structured requirements, versionable test assets, and strict audit requirements. Financial-services teams can begin with API tests and deterministic Gherkin scenarios before adding UI-flow generation.

Before production rollout, teams should build an independent evaluation set stratified by business complexity, change frequency, and risk level. They should define which operations models may generate, modify, or execute only after human approval. Tenant data planes should remain separate from the control plane, knowledge-base retrieval must enforce tenant and project filtering, and prompts, patches, test outputs, and reports should remain traceable.

The reusable lesson is that enterprise agentic workflows depend less on a single model's benchmark score than on context governance, permission boundaries, explicit state transitions, workload-aware execution, and auditable controls. Without those engineering constraints, generative AI adds another uncontrolled layer to an already fragmented testing pipeline.

---

Source: AWS Machine Learning Blog (2026-11-10)

— END —

Tags: #TCS Follow #Amazon Bedrock AgentCore Follow #Multi-Agent Orchestration Follow #Software Test Automation Follow #LangGraph Follow