AWS Public Sector Blog

Building supply chain multi-agent workloads in AWS GovCloud (US)

Building supply chain multi-agent workloads in AWS GovCloud (US)

If you support a public sector supply chain, a shortage is a mission problem before it’s a cost problem. Your inventory position sits in a system of record. The signals that predict a shortfall don’t: a supplier advisory here, a port closure there, lead time that keeps slipping. Analysts reconcile all of it by hand, one item at a time. They usually find out too late.

Agents can carry out that reconciliation and hand back a ranked short list with the reasoning attached, and they never place an order without your approval.

This post shows how to build that on Amazon Web Services (AWS) using Amazon Bedrock, deployed in AWS GovCloud (US). You’ll deploy a working multi-agent workload, see how a supervisor coordinates specialized agents through the Converse API in Amazon Bedrock, and learn which AWS GovCloud (US) details break patterns copied from commercial Regions.

What you build

By following the steps in this post, you’ll build a read-only console that ranks items by readiness risk, backed by three agents on Amazon Bedrock.

This complements a system of record rather than replacing it. Enterprise resource planning (ERP) and inventory suites already compute reorder points well. What they don’t do is pull in outside signals and tell you which items deserve attention first. That is the gap the agents fill.

The workflow carries inventory and disruption data through ingestion, processing, and analysis, and stops for an analyst before anything is ordered. The following steps describe each stage in turn.

  1. Inventory data and external disruption signals land in an Amazon Simple Storage Service (Amazon S3) raw zone.
  2. Amazon Simple Queue Service (Amazon SQS) decouples sources from processing. Extract, transform, and load (ETL) jobs on AWS Lambda or AWS Batch normalize records into a curated dataset.
  3. Amazon Athena exposes that dataset as the read-only query surface for the agents.
  4. A supervisor orchestrates the workflow. It calls Amazon Bedrock through an AWS GovCloud (US) inference profile, bounded by Amazon Bedrock Guardrails.
  5. Three specialized agents run under it. The ETL agent fetches and validates the demand series. The analytics agent forecasts demand and scores risk. The visualization agent builds the ranked queue, drafts a brief, and proposes an action. Amazon DynamoDB holds agent state.
  6. An Application Load Balancer fronts the console on AWS Fargate. Amazon CloudFront is not available in AWS GovCloud (US), so the load balancer is the delivery layer.
  7. Amazon Cognito authenticates the user before the console is reachable. Authentication is enforced at the application layer, so an unauthenticated request never reaches the console.

When an action is warranted, the workflow pauses for an analyst to approve or reject it. No agent acts on its own.

This architecture is shown in the following diagram.

Architecture diagram, which is described in the text.

Figure 1: Multi-agent supply chain risk workflow in AWS GovCloud (US)

An analyst works from the ranked queue rather than from raw inventory records. The following screenshot shows that queue, with the highest-risk items at the top.

Risk console, which is described in the text.

Figure 2: The console ranks items by readiness risk and links each row to its location

Prerequisites

To implement the solution, you need to have the following prerequisites:

  • An AWS GovCloud (US) account with permissions for the services described in the architecture
  • The AWS Cloud Development Kit (AWS CDK) v2 and the AWS Command Line Interface (AWS CLI), both configured for us-gov-west-1
  • A container runtime (Docker or Finch), Python 3.11 or later, and Node.js 20 or later
  • Access to an Amazon Bedrock foundation model (FM), with its inference profile available to your account

Amazon Bedrock charges per token. The deployed console runs a load balancer, one AWS Fargate task, and Amazon Cognito. Remove the resources when you finish (see Cleanup).

Deploy it

Run the analytics locally first. You don’t need an AWS account for this. The example backtests a moving-average forecast against a seasonal-naive baseline and derives a decision per item:

== SKU-1001 ==
  backtest MAPE:      model(MA3)= 8.94%  baseline(seasonal)=14.46%  -> winner: model
  readiness risk:     HIGH
  recommended action: Reorder 500 and qualify an alternate supplier

Then deploy the console and agents:

git clone https://github.com/aws-samples/multi-agent-supply-chain-risk-for-govcloud && cd multi-agent-supply-chain-risk-for-govcloud
python -m venv .venv && .venv/bin/pip install -e ".[dev,bedrock]"
.venv/bin/python examples/worked_forecast.py     # local run

cd infra/cdk && npm ci
npx cdk deploy -c qualifier=<your-bootstrap-qualifier>

Create a user in the Amazon Cognito user pool the stack provisions, then sign in. The following screenshot shows the sign-in page.

Sign-in page, which is described in the text.

Figure 3: Users authenticate through Amazon Cognito before reaching the console

How the agents work

Each agent owns a small tool set. Every tool carries an autonomy classification, so the approval boundary lives in code rather than in prompt text:

class ToolAccess(str, Enum):
    AUTONOMOUS = "autonomous"          # read/compute, no side effects
    HUMAN_APPROVAL = "human_approval"  # consequential; requires sign-off

VISUALIZATION_AGENT = Agent(
    name="visualization_agent",
    tools=(
        Tool("build_view", "Assemble map markers and queue rows.", ToolAccess.AUTONOMOUS),
        Tool("draft_brief", "Draft a grounded, plain-language brief.", ToolAccess.AUTONOMOUS),
        Tool("place_reorder", "Place an order. REQUIRES human approval.",
             ToolAccess.HUMAN_APPROVAL),
    ),
)

The supervisor hands each agent’s tools to a foundation model through the Converse API. The model chooses which tool to call and in what order, reacting to each result. Nothing here follows a fixed script.

One AWS GovCloud (US) difference will stop you immediately. Converse requires an inference profile ID. Amazon Bedrock rejects the on-demand model ID.

DEFAULT_REGION = "us-gov-west-1"
DEFAULT_MODEL_ID = "us-gov.anthropic.claude-sonnet-4-5-20250929-v1:0"

response = client.converse(
    modelId=DEFAULT_MODEL_ID,
    system=[{"text": SYSTEM_PROMPT}],
    messages=messages,
    toolConfig=build_tool_config(),
)

When the model proposes a consequential action, the loop stops and returns it for approval instead of executing it:

for tool_use in tool_uses:
    if requires_human_approval(tool_use["name"]):
        return AdapterResult(
            stopped_for_approval=True,
            pending_action={"tool": tool_use["name"], "input": tool_use.get("input", {})},
        )
    tool_results.append(execute_tool(tool_use))

The ranking itself is a weighted blend of three inputs: stockout pressure from the forecast and reorder point, the external disruption signal, and mission criticality, which the sample data carries as a flag on each item in the system of record. Every item shows its score, its primary driver, and a plain-language rationale, as shown in the following screenshot. A reviewer can tell why an item sits where it does.

Location detail, which is described in the text.

Figure 4: Selecting a location shows its risk score, inventory position, and primary driver

Customize it for your needs

Treat the deployed stack as a starting point. Five changes cover most adaptations, and each one is restricted to a single layer:

  1. Point it at your data – Swap the sample connectors for your inventory source and whichever disruption feeds you trust. The agents read a curated dataset through Amazon Athena, so all they need is a table rather than a schema rewrite.
  2. Tune the risk model – The weighting exists in a single function. Adjust it or replace the forecast with statsmodels, Prophet, or an Amazon SageMaker AI endpoint. Whatever you choose should exceed a documented baseline for mean absolute percentage error (MAPE) before you rely on it.
  3. Scope permissions tightly – The repository ships one AWS Identity and Access Management (IAM) role per layer, each validated with IAM Access Analyzer. Two details require attention. The Converse API authorizes against bedrock:InvokeModel because there is no bedrock:Converse action. And an AWS GovCloud (US) system-defined inference profile can route to either us-gov-west-1 or us-gov-east-1, so the policy has to list the model Amazon Resource Name (ARN) in both Regions. Omit one and the service denies the call. Agent data access stays read-only over the curated prefix.
  4. Harden the transport – The reference console serves over HTTP on an internal load balancer for demonstration. Before real users touch it, terminate TLS at the load balancer with a certificate from AWS Certificate Manager, redirect port 80 to 443, mark session cookies Secure, and add Strict-Transport-Security.
  5. Add an agent – Define it with its tools and register it with the supervisor. A notification agent is a natural next step. Another option is a context-retrieval agent over Amazon Bedrock Knowledge Bases. The supervisor enforces the approval boundary centrally, so anything you add inherits it.

The structure travels. Ranking grant applications, triaging compliance findings, prioritizing maintenance: the pattern fits many workflows where an agent gathers cross-source data and recommends an action for a person to authorize.

Cleanup

Destroy the stack to stop charges, then remove the image repository if you no longer need it:

cd infra/cdk && npx cdk destroy -c qualifier=<your-bootstrap-qualifier>
aws ecr delete-repository --repository-name supply-chain-console \
  --force --region us-gov-west-1

Confirm in the AWS Management Console that the AWS CloudFormation stack and the Amazon Elastic Container Registry (Amazon ECR) repository are gone.

Conclusion

You can deploy agentic AI workloads in AWS GovCloud (US) today, provided you account for its specifics: invoke Amazon Bedrock through an inference profile, scope model and data permissions to what each agent needs, deliver the application behind a load balancer, and keep a person in the loop for consequential actions. Start with the local run, deploy the stack, then point it at your own data.

Additional resources

Please note that this post is intended for informational purposes. The approach described might not be suitable for every organization or compliance program. Evaluate it against your organization’s compliance needs and any applicable regulatory obligations.

Francisco Zabala

Francisco Zabala

Francisco is a data scientist and machine learning engineer at AWS, specializing in computer vision for hybrid edge-cloud applications. His expertise lies in the development of deep learning algorithms for analyzing imagery and building AI/ML solutions for US federal customers.

Brooks Brenkus

Brooks Brenkus

Brooks Brenkus is a Senior Manager, Technical Business Development at Amazon Web Services (AWS), where he leads product development for AWS Professional Services in the Worldwide Public Sector. He concentrates on turning repeatable engagement patterns into scalable offerings, accounting for the specialized requirements of US federal environments.

Jenny Close

Jenny Close

Jenny Close is a Senior AWS Professional Services Sales Manager, where she helps Worldwide Public Sector customers adopt products that accelerate their missions. She works closely with US federal customers, whose procurement, security, and compliance requirements often call for a different approach than commercial engagements.