The 6 AM Trading Risk Review

Weekend Agent Challenge: The 6 AM Trading Risk Review

Link to App or Repo

Source code: https://github.com/dchan-dev/aws_morning_trading_review_mail

The six runtime packages are BrainAgent, CreditMemoAgent, CreditProductsAgent, CreditRiskManageAgent, CreditTradingAgent, and FinModelAnalystAgent.

The best demo is not a chat window. It is the quiet sequence of evidence: a scheduler fires at 06:00, six research artifacts appear in S3, and a risk brief arrives before the trader asks for it. That is when an agent stops being an interesting prompt and starts becoming a system.

Details

At 6:00 every morning, before the macro desk opens, an event starts a research workflow that behaves less like a chatbot and more like a small virtual credit committee.

It gathers current market evidence, asks five specialist agents to examine the same risk question from different professional perspectives, lets a Brain Agent challenge and synthesize their conclusions, preserves the research trail in Amazon S3, and delivers a morning report by email. No analyst has to log in, copy a prompt, or wait beside a browser.

That last point is the heart of this build: the useful work happens without me.

This project is a research and decision-support demonstration. It does not execute trades, extend credit, or replace authorized risk, compliance, or investment professionals.

Vision & What the Agent Does

The first hour of a macro trader's day is expensive. Overnight moves in rates, currencies, commodities, sovereign spreads, and corporate credit must be translated into a position view before liquidity and attention move elsewhere. A normal news summary is not enough. The desk needs to know:

• What changed?
• Is the move driven by growth, inflation, liquidity, solvency, policy, positioning, or a technical flow?
• How does it migrate across sovereign bonds, corporate credit, FX, commodities, and funding markets?
• What is already priced?
• Which position has favorable carry and convexity after funding, hedging, liquidity, and execution costs?
• Which observable signal invalidates the thesis?

The 6 AM Trading Risk Review turns that process into an event-driven agent workflow.

Amazon EventBridge Scheduler invokes a small AWS Lambda function at 06:00 in the desk's configured time zone. Lambda sends a bounded morning-review request to the Brain Agent running on Amazon Bedrock AgentCore Runtime. The Brain Agent delegates the same question to five independent specialist runtimes:

The Brain Agent is not a sixth opinion that simply votes with the others. It is the orchestrator. Its prompt starts with the risk regime and policy reaction function, compares disagreements between specialists, and converts their findings into a governed morning brief: market regime, evidence, portfolio implications, candidate actions, hedges, confirmation signals, and invalidation triggers.

Each specialist has its own domain prompt and AgentCore Memory. The memory configuration separates semantic facts, user preferences, session summaries, and episodic experience. This lets the system remember how a desk wants risk expressed without pretending that yesterday's market facts are still current.

For current information, the agents can use Exa.ai web search. The Exa API key belongs in AgentCore Identity as an API-key credential provider—not in source code, a Lambda environment variable, or a prompt. The runtime retrieves the credential only when the tool needs it. Search evidence and agent outputs are written to S3 so that the final recommendation can be traced back to what each specialist saw.

When the final Brain Agent object lands in the report prefix, an S3 ObjectCreated event invokes a delivery Lambda. That function retrieves the report and sends it through Amazon Simple Email Service (Amazon SES) to the macro trader's verified address.

The trader wakes up to a completed review, not a reminder to begin one.

Demo evidence to capture: EventBridge Scheduler's successful 06:00 invocation, the six timestamped S3 artifacts, and the received SES morning report. These three screenshots make the autonomous workflow visible end to end.

How You Built It

1. I modeled the desk before choosing the agent topology

The most important design decision was not the model. It was the separation of professional lenses.

In real credit work, underwriting, portfolio risk, product structuring, market pricing, and approval documentation answer different questions. Mixing them creates familiar but dangerous category errors: treating spread as pure default probability, treating PD as the full lending decision, calling a negative cash/CDS basis an arbitrage before financing costs, or reconciling economic loss directly to IFRS 9 ECL.

The prompts therefore encode explicit financial identities and decision boundaries:

Expected Loss = PD × LGD × EAD

Expected Net P&L =
  Spread Alpha + Carry + Roll-Down + Catalyst Value
  - Default Loss - Hedge Cost - Funding Cost
  - Transaction Cost - Liquidity Cost - Model Error

The Credit Trading Agent must distinguish a forecast from an executable strategy. The Financial Modeling Agent must connect a macro shock to borrower cash flow instead of applying cosmetic percentage haircuts:

Macro shock → volume decline → margin compression → working-capital draw
→ covenant erosion → revolver use → refinancing dependence
→ liquidity event → default or restructuring

The Credit Memo Agent preserves source conflicts rather than averaging them into a false consensus. Material approval remains with an accountable human. This is not only prompt engineering; it is a control design.

2. I deployed specialists as separate AgentCore runtimes

All six Python agents use Strands Agents and run as HTTP runtimes on Amazon Bedrock AgentCore. The project uses CodeZip packaging and an Amazon Nova Pro model through Amazon Bedrock.

Keeping specialists in separate runtimes has practical benefits:

• prompts, memory, dependencies, and permissions can evolve independently;
• runtime identities can be restricted by role;
• one specialist can be tested or redeployed without changing the others;
• failures are visible by specialist rather than buried inside one long model turn;
• the orchestration contract stays simple: prompt in, evidence-backed Markdown out.

The Brain Agent invokes each specialist through the AgentCore data plane, collects the streamed response, and injects all five outputs into its synthesis context. It also records an explicit failure artifact when a specialist cannot respond. A partial morning report that names a missing control is safer than silently pretending the review was complete.

The initial implementation calls specialists sequentially. That is deliberately simple and easy to debug, but parallel fan-out is the next latency optimization because the five reviews are independent. In production I would use bounded concurrency, an overall deadline, and per-agent timeouts rather than unbounded parallel calls.

Coding walkthrough: inside the six AgentCore applications

The app directory is intentionally repetitive. Each specialist is an independently deployable application rather than a Python class hidden inside the orchestrator:

app/
├── BrainAgent/
├── CreditMemoAgent/
├── CreditProductsAgent/
├── CreditRiskManageAgent/
├── CreditTradingAgent/
└── FinModelAnalystAgent/

Every package owns the same runtime seams:

<Agent>/
├── main.py                 # AgentCore entrypoint, prompt, and tools
├── model/load.py           # Amazon Bedrock model configuration
├── memory/session.py       # AgentCore Memory session adapter
├── mcp_client/client.py    # Streamable HTTP MCP client
├── pyproject.toml          # Isolated runtime dependencies
└── README.md

This small amount of duplication is useful isolation. A credit-trading dependency or prompt change cannot accidentally alter the credit-memo runtime. It also creates a consistent review checklist across all six packages.

Declaring six deployable runtimes

The AgentCore project configuration maps every package to an HTTP runtime. The actual file declares all six; this shortened example shows the pattern:

{
  "name": "tradingRiskReview",
  "runtimes": [
    {
      "name": "BrainAgent",
      "build": "CodeZip",
      "entrypoint": "main.py",
      "codeLocation": "app/BrainAgent/",
      "runtimeVersion": "PYTHON_3_14",
      "networkMode": "PUBLIC",
      "protocol": "HTTP"
    },
    {
      "name": "CreditTradingAgent",
      "build": "CodeZip",
      "entrypoint": "main.py",
      "codeLocation": "app/CreditTradingAgent/",
      "runtimeVersion": "PYTHON_3_14",
      "networkMode": "PUBLIC",
      "protocol": "HTTP"
    }
  ]
}

CodeZip keeps this Python demonstration simple: the runtime packages source and dependencies without requiring an application container. A container remains the better choice when native libraries, operating-system controls, or a custom build chain become necessary.

Loading one governed model configuration

Each runtime loads the model through a small factory:

from strands.models.bedrock import BedrockModel


def load_model() -> BedrockModel:
    return BedrockModel(
        model_id="apac.amazon.nova-pro-v1:0",
        max_tokens=10000,
    )

The factory prevents model settings from being scattered through orchestration code. The 10,000-token ceiling was a practical response to specialist reports being truncated at 4,000 tokens. A larger ceiling is not permission to generate without bounds: prompts still require concise output sections, and production controls should track input tokens, output tokens, latency, and cost per run.

Building the common Strands runtime

Each specialist creates a BedrockAgentCoreApp, registers research and reasoning tools, and builds one Strands Agent per session-and-user pair:

app = BedrockAgentCoreApp()

tools = [add_numbers, exa, tavily, think]
tools.extend(client for client in mcp_clients if client)


def agent_factory():
    cache = {}

    def get_or_create_agent(session_id, user_id):
        key = f"{session_id}/{user_id}"
        if key not in cache:
            cache[key] = Agent(
                model=load_model(),
                session_manager=get_memory_session_manager(session_id, user_id),
                conversation_manager=NullConversationManager(),
                system_prompt=DEFAULT_SYSTEM_PROMPT,
                tools=tools,
            )
        return cache[key]

    return get_or_create_agent

The cache avoids rebuilding an agent repeatedly inside a warm runtime, while the composite key prevents two users in different sessions from sharing an in-memory agent instance. The durable context remains in AgentCore Memory; the process-local cache is only an optimization and must never be treated as durable state.

The specialist HTTP entrypoint is deliberately thin:

@app.entrypoint
async def invoke(payload, context):
    session_id = getattr(context, "session_id", "default-session")
    user_id = getattr(context, "user_id", "default-user")
    agent = get_or_create_agent(session_id, user_id)
    prompt = _extract_prompt(payload)

    async for event in agent.stream_async(prompt):
        if isinstance(event, dict) and "event" in event:
            yield event

_extract_prompt accepts a plain prompt, harness-style messages, or tool results. That boundary keeps transport normalization out of the financial prompt and allows the same agent package to work with local development, AgentCore invocation, and tool continuations.

Wiring AgentCore Memory by actor and session

Each package receives its deployed memory ID through an AgentCore-provided environment variable. The Brain Agent uses MEMORY_BRAINAGENTMEMORY_ID; the five specialists use their corresponding generated names.

MEMORY_ID = os.getenv("MEMORY_BRAINAGENTMEMORY_ID")
REGION = os.getenv("AWS_REGION")


def get_memory_session_manager(session_id, actor_id):
    if not MEMORY_ID:
        return None

    session_id = session_id or uuid.uuid4().hex
    retrieval_config = {
        f"/users/{actor_id}/facts": RetrievalConfig(top_k=3, relevance_score=0.5),
        f"/users/{actor_id}/preferences": RetrievalConfig(top_k=3, relevance_score=0.5),
        f"/episodes/{actor_id}/{session_id}": RetrievalConfig(top_k=5, relevance_score=0.5),
        f"/summaries/{actor_id}": RetrievalConfig(top_k=3, relevance_score=0.5),
    }

    return AgentCoreMemorySessionManager(
        AgentCoreMemoryConfig(
            memory_id=MEMORY_ID,
            session_id=session_id,
            actor_id=actor_id,
            retrieval_config=retrieval_config,
        ),
        REGION,
    )

Two details matter. First, the function degrades safely to a memory-free agent during local development when no memory ID exists. Second, retrieval paths include the actor ID, and episodic retrieval additionally includes the session ID. The namespace is part of the security model, not merely an organization convention.

Invoking specialists through the AgentCore data plane

The Brain Agent does not import specialist Python modules. It calls their deployed Runtime ARNs through the bedrock-agentcore client:

def _invoke_sub_agent_runtime(runtime_arn: str, query: str) -> str:
    payload = json.dumps({"prompt": query}).encode("utf-8")
    response = runtime_client.invoke_agent_runtime(
        agentRuntimeArn=runtime_arn,
        payload=payload,
    )
    return _extract_text_from_invoke_response(response["response"].read())

Runtime ARNs are read from environment variables so deployment configuration stays outside application logic. The implementation currently invokes the specialists in a deterministic order and catches failures independently:

calls = [
    ("credit_risk_manage_agent_tool", runtime_arns["credit_risk_manage"]),
    ("fin_model_analyst_agent_tool", runtime_arns["fin_model_analyst"]),
    ("credit_products_agent_tool", runtime_arns["credit_products"]),
    ("credit_trading_agent_tool", runtime_arns["credit_trading"]),
    ("credit_memo_agent_tool", runtime_arns["credit_memo"]),
]

outputs = {}
for tool_name, runtime_arn in calls:
    try:
        outputs[tool_name] = _invoke_sub_agent_runtime(runtime_arn, query)
    except Exception as error:
        outputs[tool_name] = f"Invocation failed: {error}"

AgentCore streams runtime responses as server-sent events. The parser reads data: records, decodes each JSON event, and joins contentBlockDelta.delta.text fragments. Parsing the protocol explicitly prevents transport metadata from being mixed into the final financial report.

The current synchronous SDK call runs inside the Brain Agent's asynchronous entrypoint. That is acceptable for a controlled demonstration, but it blocks the event loop during each specialist call. The production improvement is bounded asyncio.to_thread fan-out or an asynchronous client, with a semaphore, per-agent timeout, global deadline, and deterministic output ordering.

Synthesizing only after all five reviews return

The Brain Agent converts the five outputs into labeled context:

sections = [
    "All five required sub-agent outputs:",
    f"1) credit_risk_manage_agent_tool:\n{outputs['credit_risk_manage_agent_tool']}",
    f"2) fin_model_analyst_agent_tool:\n{outputs['fin_model_analyst_agent_tool']}",
    f"3) credit_products_agent_tool:\n{outputs['credit_products_agent_tool']}",
    f"4) credit_trading_agent_tool:\n{outputs['credit_trading_agent_tool']}",
    f"5) credit_memo_agent_tool:\n{outputs['credit_memo_agent_tool']}",
    "Synthesize these five outputs in your final answer.",
]

Labeling is important. It preserves which professional lens produced each assertion and makes missing-agent failures visible to the synthesizer. The context is appended to the original request, then the Brain Agent streams the consolidated answer back to its caller.

Persisting specialist and Brain Agent evidence

The storage helper writes UTF-8 Markdown directly to S3:

def _put_text_file_to_s3(file_name: str, content: str) -> None:
    s3_client.put_object(
        Bucket=output_bucket,
        Key=f"{output_prefix}/{file_name}",
        Body=content.encode("utf-8"),
        ContentType="text/plain; charset=utf-8",
    )

One timestamp is generated for the five specialist files, which makes them recognizable as a single batch. The Brain Agent receives a later timestamp when synthesis finishes. Upload errors are logged per artifact so one failed write does not erase the other specialist results.

The final runtime flow is therefore explicit:

normalize request
→ resolve actor and session
→ invoke five specialist runtimes
→ persist five specialist outputs
→ label and inject specialist context
→ stream Brain Agent synthesis
→ persist final Brain Agent output

3. I treated memory and live research as different data classes

AgentCore Memory is useful for stable context: desk preferences, recurring entities, prior decisions, summaries, and episodes. It is not a substitute for market data with an as-of timestamp.

Each runtime has 30-day memory resources with:

• semantic memory for durable facts;
• user-preference memory for report style and desk preferences;
• summarization memory for compressed session history;
• episodic memory for prior workflows and outcomes.

Retrieval is scoped by actor and session namespaces. This matters in financial services: one desk's preference or prior analysis must not leak into another user's session.

Exa supplies current public-web context. Every material market statement should carry source, publication time, retrieval time, and confidence. The report must clearly distinguish sourced fact, model inference, and recommended action.

4. I moved third-party credentials out of application code

The development log captured a common prototype-to-production transition: web search worked first, but API-key handling needed to become an identity concern.

The AgentCore project registers EXA_API_KEY as an API-key credential provider. At runtime, the Exa tool requests that credential through AgentCore Identity. The design avoids hard-coded keys and supports rotation without rebuilding an agent package.

The least-privilege rule is straightforward:

• the scheduler can invoke only the kickoff Lambda;
• the kickoff Lambda can invoke only the Brain Agent runtime;
• the Brain Agent can invoke only the five named specialist runtimes and write to its S3 prefix;
• each agent can retrieve only the Exa credential it requires;
• the delivery Lambda can read only completed report objects and call the required SES send action.

Secrets, account IDs, runtime ARNs, recipient addresses, and bucket names should be parameters or managed configuration, never examples copied into a public article.

5. I made S3 the durable handoff boundary

The Brain Agent writes timestamped Markdown artifacts for every specialist and for its own final synthesis. S3 is more than file storage here; it is the durable boundary between probabilistic research and deterministic delivery.

An actual run produces these timestamped objects:

1784285928_CreditMemoAgent_output.md
1784285928_CreditProductsAgent_output.md
1784285928_CreditRiskManageAgent_output.md
1784285928_CreditTradingAgent_output.md
1784285928_FinModelAnalystAgent_output.md
1784285934_BrainAgent_output.md

The S3 notification must filter specifically for the _BrainAgent_output.md suffix; otherwise every specialist artifact could trigger an email.

For idempotency, the delivery Lambda should derive a key from the S3 object version, then use a small durable record or object tag to prevent duplicate sends. S3 notifications and Lambda retries are at-least-once, so “send email” must never assume exactly-once delivery.

6. I used AI as an accelerator, not as the final reviewer

The development transcript shows the system evolving through short, testable changes:

1. embed specialist domain knowledge directly in each system prompt;
2. add Exa, Tavily, and reasoning tools;
3. address model output truncation by increasing the configured maximum from 4,000 to 10,000 tokens;
4. register the Exa credential with AgentCore Identity;
5. delegate from Brain Agent to all five runtimes;
6. replace local output files with timestamped S3 artifacts.

AI was effective at mechanical propagation across six similar agent packages and at drafting domain checklists. It was less reliable at architecture truth. I still had to inspect generated code for credential handling, IAM boundaries, output completeness, error behavior, and whether a financial formula was being used under the correct accounting or risk lens.

That is the real-world lesson: generation is fast; assurance remains engineering work.

AWS Services Used / Architecture Overview

Architecture

Overview

Amazon EventBridge Scheduler
Label: “6:00 AM”
→ AWS Lambda
Label: “Kickoff”
→ Amazon Bedrock AgentCore Runtime
Label: “BrainAgent”

BrainAgent invokes five parallel Amazon Bedrock AgentCore Runtime agents:
- CreditMemoAgent
- CreditProductsAgent
- CreditRiskManageAgent
- CreditTradingAgent
- FinModelAnalystAgent

Connect BrainAgent and all five agents to:
- Amazon Bedrock AgentCore Memory
- Amazon Bedrock AgentCore Identity
- Exa.ai Web Search

Label the AgentCore Identity connection:
“EXA_API_KEY”

Show all five specialist agents returning their results to BrainAgent.

BrainAgent writes six timestamped Markdown outputs to Amazon S3:
- Five specialist reports
- One BrainAgent morning report
- Include Exa.ai research and source links

Amazon S3
→ “ObjectCreated: *_BrainAgent_output.md”
→ AWS Lambda
Label: “Report Delivery”
→ Amazon Simple Email Service (Amazon SES)
→ Macro Trader
→ Email document icon
Label: “Morning Trading Risk Report”

Clearly show the final end-user output as an emailed morning report containing:
- Market risk summary
- Credit and sovereign analysis
- Trading implications
- Hedge ideas
- Confirmation and invalidation signals
- Exa.ai source links

Step 1 — EventBridge Scheduler starts the unattended 6 AM run

Amazon EventBridge Scheduler is the system clock. At 06:00 in the macro desk's configured time zone, it invokes the kickoff Lambda with a stable morning-review request. A representative payload is:

{
  "reportType": "morning-trading-risk-review",
  "asOf": "scheduled-invocation-time",
  "prompt": "Analyze the overnight macro, sovereign, credit, FX, commodity, liquidity, and policy-risk regime. Produce position implications, hedges, confirmation signals, and invalidation triggers."
}

The schedule owns timing, retry policy, and dead-letter handling. It does not contain financial logic. Using an explicit schedule time zone prevents a London, New York, Hong Kong, or Tokyo desk report from drifting when UTC offsets change.

Step 2 — The kickoff Lambda invokes only the Brain Agent

The kickoff Lambda is a thin adapter between EventBridge Scheduler and AgentCore Runtime. It validates the scheduled payload, creates a correlation or run ID, and calls the Brain Agent with InvokeAgentRuntime.

Its responsibility ends after successful runtime invocation. It does not call Exa, run specialist prompts, write reports, or send email. This keeps the event integration deterministic and leaves agent orchestration inside AgentCore.

Conceptually, the invocation boundary is:

response = agentcore_client.invoke_agent_runtime(
    agentRuntimeArn=brain_agent_runtime_arn,
    payload=json.dumps({"prompt": morning_review_prompt}).encode("utf-8"),
)

The Lambda execution role needs permission to invoke the Brain Agent runtime, but it does not need access to the Exa credential or the five specialist runtimes.

Step 3 — BrainAgent orchestrates five specialist AgentCore runtimes

The Brain Agent receives one market-risk question and fans it out to the five runtime ARNs configured for the application:

BrainAgent
├── CreditRiskManageAgent
├── FinModelAnalystAgent
├── CreditProductsAgent
├── CreditTradingAgent
└── CreditMemoAgent

Every specialist receives the same base question, but its system prompt forces a different institutional lens:

1. CreditRiskManageAgent quantifies borrower and portfolio risk through PD, LGD, EAD, expected loss, rating migration, concentration, limits, and covenants.
2. FinModelAnalystAgent tests repayment capacity through normalized cash flow, leverage, liquidity runway, debt service, Monte Carlo scenarios, and reverse stress.
3. CreditProductsAgent evaluates facility structure, collateral, guarantees, seniority, CDS mechanics, counterparty exposure, suitability, and residual product risk.
4. CreditTradingAgent turns the market view into candidate expressions after carry, funding, liquidity, transaction cost, cash/CDS basis, hedge sizing, and execution risk.
5. CreditMemoAgent organizes evidence, conflicting facts, risks, mitigants, exceptions, conditions, and source lineage into a reviewer-ready record.

The current demo invokes these runtimes in a deterministic sequence. The Brain Agent parses each streamed AgentCore response, records each result independently, labels the output by specialist, and injects all five reports into its own synthesis prompt. If one invocation fails, the failure is preserved as an explicit result rather than silently omitted.

This produces two levels of output:

• five deep specialist reports that preserve the individual risk lenses;
• one Brain Agent morning brief that compares the specialists and turns disagreement into portfolio implications, possible hedges, confirmation signals, and invalidation triggers.

Step 4 — Every agent combines prompt, memory, identity, and current Exa research

Each of the six agents has four context layers:

Specialist system prompt
        +
AgentCore Memory
        +
AgentCore Identity credential
        +
Current Exa.ai web evidence
        =
Evidence-backed specialist output

Special prompt: Each main.py contains a domain-specific DEFAULT_SYSTEM_PROMPT. The prompts encode professional responsibilities, formulas, required report sections, decision boundaries, and human-approval limits.

Memory: Each runtime has its own AgentCore Memory resource. Actor- and session-scoped namespaces retrieve semantic facts, report preferences, session summaries, and relevant episodes without mixing users or desks. Memory provides continuity; it does not replace current market evidence.

Identity: EXA_API_KEY is registered as an AgentCore API-key credential provider. The API key remains outside source code and prompts. Runtime permissions should allow each agent to retrieve only this required credential, enabling centralized rotation and reducing secret exposure.

Web search: The Strands tool set includes Exa for current public-web research. The agents use it to investigate overnight market moves, policy announcements, issuer developments, sovereign yields, credit spreads, commodity shocks, and other information required by their specialist prompts.

The output must preserve the difference between:

• a sourced fact with URL and publication or retrieval time;
• a model inference based on multiple facts;
• a risk judgment;
• a proposed action requiring human approval.

That separation is especially important in financial services because a plausible statement without an as-of date can become stale before the report reaches the desk.

Step 5 — Agent outputs and Exa-derived research are persisted to S3

The Brain Agent persists every specialist response before generating the final synthesis. This preserves the evidence even if a later synthesis or delivery step fails.

One run in the demo produces:

1784285928_CreditMemoAgent_output.md
1784285928_CreditProductsAgent_output.md
1784285928_CreditRiskManageAgent_output.md
1784285928_CreditTradingAgent_output.md
1784285928_FinModelAnalystAgent_output.md
1784285934_BrainAgent_output.md

The five specialist files share the delegation timestamp. The Brain Agent file has a later timestamp because it is written after all specialist results have been assembled and synthesized.

The Markdown reports contain the agents' Exa-informed findings and source references. For stronger production lineage, raw Exa queries and responses can additionally be persisted as JSON beside the report, with retrieval timestamps, URLs, content hashes, and the specialist that requested the evidence.

S3 is the workflow's durable handoff:

agent research completed
→ specialist artifacts stored
→ Brain Agent synthesis stored
→ final-report object event emitted
→ delivery begins

This boundary means an email failure does not require rerunning costly market research. The report can be safely redelivered from the immutable S3 object.

Step 6 — The final S3 object triggers Lambda and SES delivery

The S3 event notification must filter for the final Brain Agent filename suffix:

_BrainAgent_output.md

Without that filter, all five specialist uploads would also invoke the delivery Lambda and the trader could receive six incomplete emails.

The report-delivery Lambda validates the bucket, object key, object version, and event type; reads the UTF-8 Markdown report; creates a desk-friendly email subject containing the report date and correlation ID; and calls Amazon SES.

S3 ObjectCreated
→ validate final-report key
→ check object-version idempotency
→ read Brain Agent report
→ format email
→ send through SES
→ record delivery result

S3 event notifications and Lambda retries provide at-least-once delivery, not exactly-once delivery. The Lambda must therefore use the S3 object version or another durable idempotency key before calling SES. A retry should resend a failed delivery, but a duplicate event for an already delivered object must not send a second morning report.

The macro trader finally receives one report containing:

• overnight risk-regime summary;
• sovereign rates, credit, FX, commodity, and liquidity observations;
• specialist disagreements and confidence limits;
• portfolio and product implications;
• candidate hedges or position changes;
• confirmation signals and invalidation triggers;
• source links and as-of timestamps;
• a clear statement that trading and credit actions require authorized human approval.

Service responsibilities

Amazon EventBridge Scheduler

Owns the 06:00 trigger. I use a named time zone rather than mentally converting local desk time to UTC. This avoids seasonal drift where daylight-saving time applies. The schedule should have a retry policy and dead-letter queue, with a flexible time window disabled when the report has a hard market-open deadline.

AWS Lambda

The kickoff function creates a run ID, assembles the bounded request, and invokes the Brain Agent. It should not contain agent logic. The delivery function handles S3 event validation, idempotency, report retrieval, MIME construction, and SES delivery. Keeping these functions deterministic makes them easier to test than embedding email behavior in an LLM runtime.

Amazon Bedrock AgentCore Runtime

Hosts the Brain Agent and five specialist agents. Runtime boundaries provide independent packaging, IAM roles, environment configuration, and operational visibility. The Brain Agent is responsible for orchestration and synthesis; specialists are responsible for depth.

AgentCore Identity

Stores and brokers the Exa API-key credential provider. The agents request credentials at execution time, keeping third-party secrets outside prompts and source control.

AgentCore Memory

Provides session-aware retrieval for facts, preferences, summaries, and episodes. Namespaces are scoped by actor and session to preserve tenant boundaries.

Amazon S3

Stores immutable research artifacts and acts as the completion event source. Enable encryption, bucket-owner-enforced object ownership, block public access, versioning, lifecycle retention, and—where policy requires it—Object Lock. Avoid sensitive borrower data in object keys because keys appear in logs and events.

Amazon SES

Sends the final report from a verified identity. Production access, recipient governance, bounce/complaint handling, and suppression-list behavior must be configured before relying on the channel. Sensitive reports may be better delivered as short-lived authenticated links rather than full email attachments.

Operational controls I would require before production

• A run-level deadline so a late report cannot masquerade as a current one.
• CloudWatch alarms for missed schedules, Lambda errors, AgentCore invocation failures, incomplete manifests, and SES rejects.
• Correlation IDs propagated from Scheduler through Lambda, all six runtimes, S3 metadata, and the email subject.
• Reserved concurrency or another overlap guard so a delayed run does not collide with the next schedule.
• Explicit source timestamps and a stale-data warning in the report.
• S3 event filtering plus idempotent email delivery.
• Prompt and model versioning for reproducibility.
• Redaction and classification controls before public-web queries.
• Human approval for trades, limits, credit decisions, and external distribution.

Implemented core versus delivery integration

The repository currently contains the six AgentCore runtimes, specialist prompts, memory definitions, Exa tooling configuration, runtime-to-runtime orchestration, and S3 output logic. The EventBridge Scheduler, kickoff Lambda, S3-triggered delivery Lambda, and SES resources are the surrounding event-driven integration described in this architecture and should be added as infrastructure as code before calling the full workflow deployed.

That distinction is intentional. A credible engineering write-up should separate running code from the target production design.

What You Learned

Multi-agent value comes from disagreement, not headcount

Five agents repeating the same market summary would only multiply cost and confidence. The useful design gives each agent a distinct mandate and asks the Brain Agent to expose disagreements. A trader learns more when the fundamental analyst says “repayment capacity is improving” while the trading agent says “the spread already prices perfection.”

Financial prompts need decision boundaries

Domain vocabulary alone is not expertise. Strong prompts define the decision, required evidence, equations, failure modes, and authority limit. PD, IFRS 9 ECL, fair value, regulatory capital, and tradable alpha can all describe the same exposure while answering different questions.

A morning brief is a deadline system

At 10 AM, a perfect 6 AM report may be worthless. Latency budgets, timeout behavior, stale-data labels, partial-result policy, and delivery alarms are product requirements—not operational polish.

Event-driven does not mean exactly once

Scheduler retries, Lambda retries, AgentCore failures, and duplicate S3 notifications are normal distributed-system behavior. Run IDs, manifests, object versions, and idempotent delivery turn those realities into controlled outcomes.

Memory is not truth

Memory improves continuity, but current market claims still need fresh sources and timestamps. Long-lived preferences and short-lived prices require different retention, retrieval, and validation rules.

Identity is part of tool design

Connecting a web-search tool is easy. Connecting it without leaking credentials, over-granting IAM permissions, or making rotation a deployment event is the real engineering task. AgentCore Identity makes credential access explicit and auditable.

AI development still needs adversarial review

AI shortened implementation time, especially across repeated agent structures. It also made it easy to produce code that looked complete before reliability and security questions were answered. The senior-engineering move is to ask, repeatedly: What happens on retry? What is the source of truth? Which claim is unverified? Who is authorized to act?