ReadingResearchRadarInvestment framework
Sign in / Sign up
← Back to reading
NewsMaterial3 min readDisconfirmAI Editorial

TCS Decomposes Testing Workflows with Dedicated Agents, Using LangGraph Bounded Loops for Automated Correction

Indian IT services company TCS detailed its Agentic Test Orchestrator for banking, financial services, and insurance (BFSI) clients in an Amazon Web Services blog. The core design decision is that a single prompt cannot provide sufficient control for multi-stage engineering workflows; therefore, the testing lifecycle is split into specialized agents for scenario generation, Gherkin conversion, code generation, validation, and execution, routed by a deterministic supervisor and constrained by LangGraph state graphs to limit retry counts and safety checks. Internal benchmarks at TCS show average engineer hours per scenario dropped from approximately two hours to about 14 minutes across roughly 100 test scenarios, but this data is vendor-reported and has not been independently reproduced.

2026-11-11 00:59 GMT+8

Traditional test automation improved execution speed but did not address the slowest part of BFSI release processes. Indian IT services company Tata Consultancy Services (TCS) described this specific problem in an AWS Machine Learning blog post co-written with Varun Valsan: teams still need to create scenarios, convert them into scripts, maintain locators and dependencies, and diagnose failures. When linked user stories change, scripts generated for earlier stories quickly become stale.

TCS determined that a single generative AI prompt also fails to provide the necessary control for multi-stage engineering workflows. Instead of using a larger prompt, their response was to decompose the testing lifecycle into specialized tasks, each with its own agent, tools, validation rules, and context. A deterministic supervisor routes work, while the execution workflow controls retries, error classification, persistence, and reporting.

Specifically, the platform includes five categories of dedicated agents: a Generation agent creates structured scenarios and converts them to Gherkin, generates Java or Python automation code, and validates it; a Chat agent classifies requests as information queries or update requests; a Dynamic Task agent retrieves Business Requirement Document (BRD) context and produces structured user stories; an Incremental agent extends existing artifacts across linked Jira story chains rather than starting from scratch; and an Execution agent fetches artifacts, selects an environment, runs tests, classifies failures, applies controlled corrections, and saves results.

Sign in / Sign up
ReadingResearchRadarInvestment framework

The design of the correction loop is the most practical reference for practitioners in this article. The Execution agent defines the fetch, execute, fix, and save steps as a LangGraph workflow. LangGraph's explicit state graph provides a fixed step order and a bounded retry loop. When a failure is classified as a code error and the retry policy allows it, a fixing agent receives a constrained error context and proposes targeted corrections. Safety checks reject empty files, unexpected new files, or extreme changes in file size. Environment errors—such as connectivity or authentication failures—are not sent to the code fixer.

TCS measured the effect on a representative BFSI workload of approximately 100 test scenarios: the manual process required about two hours of engineer effort per scenario (roughly 200 hours total), while using the orchestrator reduced the average to about 14 minutes (roughly 24 hours total), reporting an 88% reduction in effort. The article explicitly notes this comes from a controlled internal benchmark, and actual results vary by workload, application complexity, and team.

The transferable insight from this architecture is not the 88% figure—which has not been independently reproduced—but the engineering diagnosis of insufficient control with a single prompt, and the specific design choices to replace it with deterministic routing, agent specialization, state-graph-constrained corrections, and safety check boundaries. For teams needing to use generative AI-assisted engineering workflows in regulated environments, these mechanisms offer more practical value than performance claims.

Sources

  • aws.amazon.comAmazon Web Services↗
Continue researching →