Validate AML investigations with evidence-grounded agents

AML Analysis with the Agents SDK on Amazon Bedrock

This notebook demonstrates one synthetic anti-money-laundering (AML) analysis with the OpenAI Agents SDK and GPT-5.6 Sol on Amazon Bedrock. The default path uses a deterministic offline assessment so a top-to-bottom run makes no model call. An explicit opt-in runs the agent with read-only tools. Both paths validate material claims against deterministic calculations.

An alert starts an investigation. It does not prove wrongdoing. The model proposes an assessment. Application code verifies the structured claims and controls workflow state. A qualified human decides whether optional drafting may begin. All data is synthetic. Nothing here files a Suspicious Activity Report (SAR) or implements production compliance policy.

Workflow boundaries

The notebook keeps deterministic evidence, model proposals, application controls, and human authority in separate boundaries.

1. Start the notebook

The default offline path requires Python 3.10 or newer and uv. The optional paid Bedrock paths also require AWS credentials through the standard credential chain and access to openai.gpt-5.6-sol. From a clone of openai/openai-cookbook, run:

cd /path/to/openai-cookbook
unset VIRTUAL_ENV
export AWS_REGION=us-east-2
uv run --with jupyterlab jupyter lab

Open this notebook at examples/partners/AWS/evidence_grounded_aml_agent_with_bedrock.ipynb. The default run keeps both paid flags disabled. To run the analysis agent, set RUN_ANALYSIS_DEMO=true before starting Jupyter. To run the optional drafting agent, set RUN_DRAFTING_DEMO=true. Set AWS_PROFILE first if your organization uses a named profile. Never paste AWS credentials into the notebook.

2. Configure Amazon Bedrock

Both paid demonstrations require an explicit environment flag. When either flag is enabled, the SDK uses the AWS credential chain and a separate client lists models through the Bedrock Mantle discovery endpoint before paid inference. With both flags disabled, this cell constructs no client and makes no AWS call.

3. Load the synthetic case

The case has three same-day cash credits followed by an outbound wire. A factory creates a fresh typed case for each application context. The amounts make the calculations easy to reproduce; they are demonstration rules, not regulatory thresholds.

4. Define the output and evidence tools

The output schema makes the material claims machine-checkable. Each finding carries its evidence IDs and computed values. The validator recomputes those values because a valid transaction ID alone does not prove support.

A typed InvestigationContext scopes one tenant, case, analysis, and review history. Each request creates its own context instance, passes it through Runner.run(..., context=...), and lets tools access it through RunContextWrapper. The context is not itself model input; each read-only tool controls which fields it returns.

Two tools return source facts, and one applies transparent demo checks. The checks identify signals for investigation, not intent, wrongdoing, or a filing requirement.

5. Run the analysis agent

The instructions require all three tools and a typed result. With RUN_ANALYSIS_DEMO=true, Runner.run manages the paid model and tool loop. The default path uses a labeled deterministic fixture with simulated tool-call evidence so the remaining validation and review cells run without AWS credentials or paid inference. The fixture does not prove Agents SDK orchestration.

6. Validate support, not just citation syntax

The validator performs three distinct checks:

1. Citation validity: every evidence ID exists in this case.
2. Claim support: each finding type uses the exact transactions and computed values returned by deterministic application code.
3. Structured authority: drafting_authorized must remain false, and filing_decision must remain NOT_DETERMINED.

The schema prevents the model from granting drafting authority or making a filing decision through those structured fields. The validator does not classify every possible free-form paraphrase. A qualified reviewer still evaluates the narrative, information gaps, relevance, and disposition. Production systems should add expert-reviewed datasets, trace grading, adversarial cases, and policy-specific tests.

7. Exercise negative cases

These local tests demonstrate failure behavior without additional model calls. A fabricated amount can use real transaction IDs and still be unsupported. Invalid IDs, a missing tool call, a structured authority claim, and a rejected review are separate failure modes.

8. Preserve rejection and require explicit re-review

The application now owns the approval boundary. It first stores the validated assessment, records a rejection, and proves drafting remains blocked. A revised assessment is then submitted as a new revision and reviewed again. The original rejection stays in review_history; it is never reset or overwritten.

The synthetic reviewer alias and typed context keep the example visible in one notebook. A concurrent service must create a separate context for every request and tenant. Production systems must derive reviewer identity from authentication, authorize the case and operation, persist revisions and decisions durably, and maintain an independently governed audit record.

9. Define the drafting agent only after approval

The notebook defines the drafting agent after the application gate. The agent can read the current approved analysis and source evidence. It has no tool for approval, state changes, or filing. Running it is optional and adds one paid inference call. Set RUN_DRAFTING_DEMO=true before starting Jupyter. Evidence-tool exceptions propagate instead of becoming model-visible error outputs. Before storing a draft, application code verifies from the raw run-item payloads that every required evidence call produced an output, then checks the current case ID, evidence IDs, and disclaimer. Local negative tests cover a missing tool output and a mismatched case without making a model call. A qualified reviewer must still confirm that each narrative claim has support.

10. What this example establishes

• With explicit opt-in, the Agents SDK runs a bounded model and tool loop through Amazon Bedrock.
• The default offline fixture makes no AWS or model call and does not prove Agents SDK orchestration.
• A typed context scopes tools and workflow state to one request and tenant.
• Pydantic makes material findings structured, but correctness comes from deterministic support checks.
• Valid IDs and supported claims are tested separately.
• Rejected work remains rejected until a revised analysis receives an explicit re-review.
• Structured fields keep drafting authority false and the filing decision undetermined.
• Drafting is downstream of application-owned approval, and filing stays out of scope.

This notebook is a learning asset, not a production AML system. Real deployments need institution-approved policy, identity and authorization, protected data handling, durable workflow and audit records, evals reviewed by domain experts, monitoring, incident response, and legal and compliance review. A separate companion document should cover AgentCore deployment and full AWS infrastructure.

References

• OpenAI models in Amazon Bedrock
• OpenAI Agents SDK guide
• OpenAI Agents SDK for Python
• Evaluate agent workflows
• GPT-5.6 Sol model documentation
• Amazon Bedrock GPT-5.6 Sol model card
• FinCEN Suspicious Activity Reports