AI Labs
All examples
AWS

Orchestrated Agents on AWS Bedrock

Uses Bedrock Agent Runtime when configured, otherwise runs a multi-step orchestration (context → intent → answer) via Converse.

OrchestrationEnterprise

Target outcomes

  • Enable an AWS-only posture while still supporting multi-step orchestration
  • Prove value with smaller orchestrations before provisioning full agent tooling

Initiative playbook

Typical delivery arc for this pattern in enterprise programs.

  1. 1
    Discovery2 to 4 wks

    Decide between Bedrock Agents vs a lighter orchestrated pipeline; align on IAM boundaries and data residency constraints.

  2. 2
    Pilot6 to 8 wks

    Start with orchestrated steps (retrieve/context, classify, answer) to validate usefulness before provisioning full agent tooling.

  3. 3
    Scaleongoing

    Move to Bedrock Agents with guardrails and KB-backed retrieval; add per-team roles and production-grade observability.

Business use case

Problem

AWS-first teams want an orchestration pattern that can start small (few steps) and grow into a fully-managed agent platform without rewriting every app.

Who benefits

  • Platform teams, standardize how agents are invoked and audited
  • Security, IAM boundaries enforced per environment/workload
  • Product teams, faster iteration with incremental orchestration steps

Success metrics

  • Prove value with a deterministic multi-step pipeline before provisioning full agents
  • Maintain an AWS-only posture for data residency and IAM controls
  • Provide per-step timing for performance and spend reviews

Solution

This demo supports two modes:

  • Bedrock Agent mode (when BEDROCK_AGENT_ID and BEDROCK_AGENT_ALIAS_ID are set)
  • Orchestrated Converse mode (default) that runs a small multi-step pipeline and returns a timeline

Technical implementation

Stack

  • @aws-sdk/client-bedrock-agent-runtime (Agent mode)
  • @aws-sdk/client-bedrock-runtime (Converse mode)

Architecture

Production-shaped fork: use a Bedrock Agent when you have one; otherwise a smaller retrieve → classify → answer pipeline for early pilots.

How it runs
Drawing the flow…

Implementation highlights

  • Degrades gracefully: agent runtime when available, smaller orchestrations otherwise
  • Returns a step timeline so the orchestration is visible for governance and tuning

Outcomes and learnings

  • Early pilots can use lighter orchestrations to validate workflows before provisioning full agent tools/KBs
  • Explicit step timelines make performance budgeting practical (p95 by step)
  • IAM should be least-privilege and environment-specific for public demos

Where else this applies

Multi-step Bedrock flows matter when you need agent-like behaviour but want to phase in Bedrock Agents, guardrails, and KBs on your timeline.

Supply chain exception handling

Retrieve shipment context, classify exception type, propose resolution playbooks.

Cloud cost anomaly triage

Pull CUR context, classify spike drivers, suggest remediation runbooks.

Security operations copilot

Retrieve runbooks and ticket history, classify incident type, draft containment steps for analyst approval.

Product support macros

Orchestrate retrieval and response before suggesting Zendesk macro text.

Using this stack elsewhere

Start with an orchestrated pipeline in Lambda or Step Functions calling Converse; promote to Bedrock Agents when tool use and memory requirements justify the ops overhead.

Live demo

The demo is the same code path described above, not a simplified mock UI. Add keys in .env.local when you are ready; the narrative and diagrams stand on their own without them.

Business

Shows the agent path when you have one, and a smaller pipeline when you do not, honest about early pilots.

Technical

InvokeAgent when BEDROCK_AGENT_ID is set; else retrieve → classify → converse with a step timeline.

Bedrock agent orchestration

Retrieve → classify → answer via AI Gateway (Bedrock model slug).

Live