TCS Agentic Test Orchestrator: Multi-Tenant Agent Isolation on Bedrock AgentCore

Tata Consultancy Services (TCS) built a multi-tenant agentic test orchestrator on Amazon Bedrock AgentCore that turns requirements documents into executable, governed tests for banking, financial services, and insurance (BFSI) clients. The system uses specialized agents, per-tenant isolation, and workload-aware execution to cut testing effort by 88% in internal benchmarks. This is not a proof of concept. It is production infrastructure serving regulated financial institutions where audit trails, compliance boundaries, and tenant isolation are non-negotiable.

Why Multi-Tenant Agent Orchestration Matters in BFSI

Financial services testing has unique constraints. Multiple clients share infrastructure, but their test data, compliance requirements, and security policies cannot bleed across tenant boundaries. Traditional test automation tools do not handle natural language requirements or adapt to client-specific regulatory frameworks. TCS needed an orchestrator that could:

Parse requirements written in business language, not Gherkin or code.
Generate test cases that respect per-client compliance rules.
Validate outputs against governance policies before execution.
Maintain strict tenant isolation across shared compute resources.

The orchestrator uses Amazon Bedrock AgentCore to coordinate three specialized agents: a requirements parser, a test generator, and a validator. Each agent operates within tenant-specific boundaries, and workload-aware execution routes tasks based on complexity, client policy, and agent capability.

Architecture: Specialized Agents and Isolation Boundaries

The orchestrator separates concerns into three agent roles:

Requirements Parser Agent
Ingests natural language requirements documents (Word, PDF, Confluence pages). Extracts testable conditions, business rules, and acceptance criteria. Tags each requirement with client ID, regulatory framework (SOX, PCI-DSS, GDPR), and priority. Outputs structured JSON that downstream agents consume.

Test Generator Agent
Receives parsed requirements and generates executable test cases. Uses client-specific templates (Selenium, Playwright, API test scripts). Injects tenant-specific test data from isolated storage buckets. Applies compliance rules (e.g., no PII in logs, encryption at rest for test artifacts).

Validator Agent
Checks generated tests against governance policies before execution. Verifies that test scripts do not access cross-tenant resources. Confirms that test data complies with data residency rules. Flags tests that violate client-specific security policies for human review.

Each agent runs in a separate execution context with scoped IAM roles. Tenant isolation happens at three layers:

Data isolation: S3 buckets partitioned by client ID with bucket policies enforcing tenant boundaries.
Execution isolation: Lambda functions or ECS tasks tagged with tenant metadata, enforced by resource-based policies.
Model isolation: Bedrock model invocations include tenant context in prompts, and outputs are stored in tenant-specific DynamoDB tables.

Workload-Aware Execution: Routing Logic

The orchestrator does not treat all test generation tasks the same. Workload-aware execution routes tasks based on:

Complexity: Simple CRUD tests go to a lightweight generator. Multi-step workflows involving state transitions go to a more capable agent with access to historical test patterns.
Compliance tier: High-risk clients (Tier 1 banks) trigger additional validation steps. Lower-risk clients (regional credit unions) skip redundant checks.
Agent availability: If the primary test generator is backlogged, the orchestrator routes to a secondary agent or queues the task.

Routing decisions happen in a central orchestration layer built on AWS Step Functions. Each workflow step includes:

States:
  ParseRequirements:
    Type: Task
    Resource: arn:aws:lambda:us-east-1:123456789012:function:RequirementsParser
    Parameters:
      TenantId.$: $.tenantId
      Document.$: $.requirementsDocument
    Next: RouteToGenerator
    
  RouteToGenerator:
    Type: Choice
    Choices:
      - Variable: $.complexity
        StringEquals: "high"
        Next: AdvancedGenerator
      - Variable: $.complianceTier
        StringEquals: "tier1"
        Next: ValidatedGenerator
    Default: StandardGenerator
    
  ValidatedGenerator:
    Type: Task
    Resource: arn:aws:lambda:us-east-1:123456789012:function:TestGenerator
    Parameters:
      TenantId.$: $.tenantId
      Requirements.$: $.parsedRequirements
      ValidationRequired: true
    Next: ValidateTests

The orchestrator maintains state in DynamoDB, keyed by tenantId and workflowId. Each state transition logs an event to CloudWatch with tenant metadata for audit trails.

State Management and Failure Handling

Multi-step test generation workflows require durable state. The orchestrator persists:

Workflow state: Current step, agent outputs, validation results.
Tenant context: Client ID, compliance tier, data residency region.
Retry metadata: Failed steps, error messages, retry count.

When an agent fails (e.g., the test generator produces invalid syntax), the orchestrator:

Logs the failure with tenant ID and workflow ID.
Retries with exponential backoff (3 attempts max).
If retries fail, routes to a human review queue.
Notifies the client via SNS with sanitized error details (no cross-tenant leakage).

The validator agent acts as a circuit breaker. If it detects policy violations (e.g., a test script attempting to access another tenant’s S3 bucket), it halts execution and flags the workflow for security review. This prevents compliance failures from reaching production.

Governance and Audit Trails

Every agent invocation, state transition, and validation decision generates an audit event. TCS uses CloudTrail and CloudWatch Logs Insights to reconstruct workflows for compliance audits. Key audit fields include:

tenantId: Which client triggered the workflow.
agentRole: Which specialized agent handled the task.
inputHash: SHA-256 hash of input data (requirements, test scripts).
outputHash: SHA-256 hash of generated artifacts.
validationResult: Pass/fail status from the validator agent.
humanReviewRequired: Boolean flag for manual intervention.

For Tier 1 clients, audit logs are immutable (S3 Object Lock) and retained for seven years. Lower-tier clients get standard retention (one year).

Trade-Offs and Operational Realities

Dimension	Benefit	Cost
Per-tenant isolation	Compliance, no cross-tenant data leakage	Higher infrastructure overhead (separate S3 buckets, DynamoDB tables per tenant)
Specialized agents	Clear separation of concerns, easier debugging	More orchestration complexity, potential for agent coordination failures
Workload-aware routing	Optimized resource usage, faster turnaround for simple tasks	Routing logic adds latency, requires tuning per client
Validator agent	Catches policy violations before execution	Extra step in workflow, can become a bottleneck if validation rules are complex
Audit trail immutability	Meets regulatory requirements for Tier 1 clients	Storage costs increase, no ability to delete logs even if they contain errors

The 88% reduction in testing effort comes from eliminating manual test case writing, not from faster test execution. The orchestrator still runs tests at the same speed as traditional automation. The win is in the upfront generation phase.

Likely Failure Modes

Agent output drift: If the test generator’s prompts are not version-controlled, changes to the underlying Bedrock model can produce incompatible test scripts. TCS mitigates this by pinning model versions and running regression tests on agent outputs.

Tenant context leakage: If a developer accidentally omits tenantId from a Step Functions parameter, the orchestrator might route a task to the wrong agent or storage bucket. IAM policies enforce tenant boundaries, but misconfigured workflows can still cause failures.

Validator bottleneck: If validation rules become too complex (e.g., checking every test script against a 500-page compliance manual), the validator agent becomes the slowest step. TCS addresses this by caching validation results for common patterns.

State explosion: Each workflow generates multiple DynamoDB entries (one per state transition). For high-volume clients, this can hit DynamoDB throughput limits. TCS uses on-demand billing and partitions tables by tenantId to avoid hot partitions.

Technical Verdict

Use this pattern when:

You need to serve multiple regulated clients from shared infrastructure.
Test generation involves natural language requirements, not just code.
Compliance and audit trails are non-negotiable.
You have distinct agent roles (parsing, generation, validation) that benefit from specialization.

Avoid this pattern when:

You have a single tenant or no regulatory constraints (simpler orchestration will suffice).
Test generation is deterministic and rule-based (no need for LLM-powered agents).
Your workflows are short-lived and do not require durable state.
You cannot afford the operational overhead of managing per-tenant isolation boundaries.

The TCS orchestrator is not a general-purpose testing tool. It is purpose-built for BFSI clients who need governed, auditable, multi-tenant test generation. The architecture choices (specialized agents, workload-aware routing, immutable audit logs) reflect the constraints of regulated financial services, not generic software testing.

Source Links

How TCS built an agentic test orchestrator with Amazon Bedrock AgentCore

Agentic AI, minus the noise.