Build A Governed Amazon Trade-History Factory With Bedrock AgentCore, Strands Agents, And Backtrader

Disclaimer

Educational Purpose:

Content presented here focuses exclusively on legitimate financial planning education, aiming to improve understanding of concepts, methodologies, and analytical approaches without promoting any specific securities, strategies, or market participation decisions.

No Personalized Advice:

No personalized recommendations, solicitations, or assurances are provided, and no guarantees of future performance, outcomes, or returns are implied, expressed, or otherwise suggested under any circumstances within this educational material.

Data Limitations:

Uploaded results rely on deterministic, offline data because live data was unavailable within the sandbox environment, and therefore outputs should be interpreted as illustrative examples rather than real time analyses.

Long-Only Scope:

All research language used is long only, avoiding options, puts, short selling, or bearish strategies, ensuring the discussion remains focused on traditional asset ownership and positive directional exposure concepts overall.

Opening: Turn Backtests Into A Trade-History Factory

A single AMZN backtest can answer one research question, but an institution needs a repeatable factory. This article focuses on how every approved run should produce the same evidence pattern: policy validation, dataset reference, strategy version, parameter record, trade ledger, risk summary, exception log, and review memo.

Positioning

The voice here is an operating-model owner speaking to quants, risk managers, platform engineers, and governance reviewers. The message is that repeatability matters as much as strategy creativity: if two runs cannot be compared through the same artifact structure, the research process is not yet committee-ready.

The Client Problem Worth Solving

Financial-services teams often lose the thread between a research request and the trade records that support it. A governed factory solves that by standardizing how AMZN strategy runs are requested, approved, executed, stored, and challenged. The business problem is not only analysis speed; it is whether the evidence can be retrieved months later.

Business Outcomes This Workflow Supports

The factory design supports repeatable research intake, standardized trade ledgers, cleaner exception handling, consistent artifact storage, and easier independent challenge. Portfolio teams can compare strategies, risk teams can inspect the same fields every time, and technology teams can enforce permissions without slowing every research cycle.

Table Of Contents

• Part 1: Opening And Market Context — Establishes the AMZN timing problem, institutional review purpose, benchmark awareness, disclosure discipline, and evidence-before-allocation framing.
• Part 2: Agentic Research Architecture — Explains the Bedrock AgentCore and Strands workflow, separation of duties, tool permissions, audit artifacts, and human approval boundary.
• Part 3: Real Market Data And Benchmarks — Defines AMZN and benchmark context, adjusted OHLCV handling, calendar alignment, lineage, corporate actions, and data-quality controls.
• Part 4: Governed Trade-History Factory Implementation And Code Logic — Translates strategy logic into entry, exit, sizing, risk-control, and reviewable code-path language for institutional stakeholders.
• Part 5: Trade-Ledger Manufacturing And Position Management — Shows how ledger fields, drawdown review, turnover, and realized trade records support disciplined position-management decisions.
• Part 6: Executive Close And Governance Review — Converts the technical workflow into committee language while keeping suitability, implementation readiness, and final decisions with humans.
• Part 7: Factory Governance, Data Setup, And Architecture Detail — Groups the series focus, agentic architecture, real data setup, and governance design notes into one readable operating-model section.
• Part 8: Backtrader Harness, Agent Runtime, And Trade-History Schema — Separates the executable harness, runtime sketch, timing-governance problem, and ledger schema for cleaner technical reading.
• Part 9: Strategy Catalog And Backtrader Strategy Classes — Organizes the strategy review method and Strategy 16 through Strategy 20 code examples as one strategy-catalog section.
• Part 10: Executive Summary And Final Governance Data Notes — Closes with committee-ready summary language, production cautions, final data notes, and education-only boundaries.

Part 1: Opening And Market Context

Related summary: Establishes the AMZN timing problem, explains why backtesting belongs in institutional review, and frames the article as evidence generation rather than prediction. The section connects a profitable long-only position to risk discipline, benchmark awareness, disclosure language, and committee-ready communication.

A strong article begins with the trading problem, not the software. A long-only Amazon position can be profitable and still suffer from weak timing, unclear exit discipline, and oversized exposure. This section therefore frames backtesting as a governance tool that helps the desk explain decisions before debating allocation.

The useful content from the former delivery note is digested here: speak with evidence, name assumptions, and avoid certainty. The audience should hear what the workflow tests, what data supports it, what could fail, and what remains a human decision. That is stronger than attaching a repeated practice paragraph at the end.

Market context matters because AMZN is affected by growth appetite, broad equity regime, consumer expectations, cloud sentiment, liquidity, and valuation pressure. Benchmark awareness helps the trader avoid claiming that every gain comes from stock-specific skill.

Part 2: Agentic Research Architecture

Related summary: Explains how Bedrock AgentCore, Strands Agents, data tools, strategy generation, Backtrader execution, and result summarization form a controlled workflow. The section emphasizes tool permissions, separation of duties, audit artifacts, and human approval before any real-world portfolio decision.

The agentic architecture separates responsibilities. The orchestrator receives the request, the data tool validates OHLCV inputs, the strategy generator prepares rule logic, the Backtrader tool executes the simulation, the risk reviewer summarizes drawdown and trade behavior, and the governance checker validates policy boundaries.

The digested delivery rule appears as architecture discipline: every agent action should produce evidence. A useful run leaves a data reference, code version, parameters, timestamps, trade ledger, metrics, chart path, and exception record. These artifacts make the output reviewable by investment, technology, and risk teams.

AgentCore and Strands Agents can accelerate the research loop, but bounded authority is essential. The system can run approved tools and prepare a memo; it should not decide suitability, approve capital allocation, or convert a historical backtest into a performance promise.

Part 3: Real Market Data And Benchmarks

Related summary: Defines AMZN as the research asset and Nasdaq 100, S&P 500, and Dow Jones Industrial Average as benchmark context. The section explains adjusted OHLCV data, calendar alignment, data lineage, corporate-action handling, and why invented market prices should not be used.

Data lineage is a trading control. Adjusted prices, corporate actions, missing values, holiday calendars, vendor changes, and benchmark alignment can all change the apparent behavior of a timing rule. This section treats data engineering as part of investment governance rather than as a background task.

AMZN is the tradable asset. Nasdaq 100, S&P 500, and Dow Jones Industrial Average provide different lenses for growth regime, broad equity risk, and blue-chip sentiment. The workflow should document why each benchmark is used and where each benchmark might mislead.

The article avoids invented prices and unsupported performance claims. If data cannot be retrieved, the limitation should be stated. If production data is used, the dataset snapshot and adjustment policy should be preserved with the backtest artifacts.

Part 4: Governed Trade-History Factory Implementation And Code Logic

Related summary: Introduces the strategy examples used in this article and explains how each rule creates entry and exit conditions. The section separates signal logic from execution logic and translates code into plain-language position-management controls.

Strategy implementation should read like a control map. Entry logic explains why a long position opens. Exit logic explains why it closes. Sizing logic explains how much exposure is taken. Risk logic explains when the process overrides the signal. This makes code review accessible to non-developers.

Signal logic and execution logic should remain separate. A signal can identify favorable conditions, but the execution engine must check existing position state, available cash, commission, risk stops, and target exits. Separation improves auditability and reduces hidden behavior.

The article includes code talk inside the main strategy discussion rather than as detached notes. Each strategy should be judged by its ledger, drawdown, turnover, benchmark behavior, and operational feasibility, not by a headline return alone.

This article specifically focuses on governance, policy validation, trade-history manufacturing, exception handling, artifact storage, and executive communication. The code review should therefore evaluate whether the strategy family supports that business objective and whether its trade records are explainable enough for institutional review.

Part 5: Trade-Ledger Manufacturing And Position Management

Related summary: Explains how the trade ledger supports position-management decisions by recording entries, exits, prices, sizes, realized profit and loss, signal reasons, drawdown behavior, turnover, and risk-adjusted review.

The trade ledger is the desk memory system. It records entry date, exit date, price, size, gross profit and loss, entry reason, and exit reason. Without a ledger, the strategy is only a story. With a ledger, the committee can inspect the actual sequence of simulated decisions.

Drawdown review must come before return celebration. A strategy can look attractive in total return while being difficult to hold through real stress. The ledger and drawdown path help reviewers decide whether the rule fits the mandate and risk tolerance.

The former practice-note message is digested into the review process: explain the data source, date range, strategy rule, benchmark context, risk metric, and ledger before any conclusion. The article keeps this inside the position-management section because it changes how the evidence should be read.

Part 6: Executive Close And Governance Review

Related summary: Converts the technical workflow into committee language. The section explains how agents accelerate research without replacing accountability, how evidence should be challenged, and how professionals remain responsible for suitability, risk tolerance, data quality, implementation readiness, and final capital decisions.

The close converts factory design into committee language. A committee needs to know whether every AMZN research run produced a request record, policy result, dataset reference, strategy version, trade ledger, risk summary, exception log, and retained artifact path.

The agent does not replace the professional. Agentic tools can standardize execution and storage, but reviewers still own approval, challenge, suitability language, and final capital decisions.

A disciplined close avoids promotional language. The message is: trust the factory only when the artifacts can be found, rerun, compared, and challenged.

Part 7: Factory Governance, Data Setup, And Architecture Detail

Related summary: Groups the series focus, agentic architecture, real data setup, and governance design notes into one readable operating-model section.

Series Focus

This article concentrates on governance, policy validation, trade-history manufacturing, and executive communication. It is one part of a four-post technical series. The structure is publication-ready and avoids exposing draft instructions. It keeps the speaking-coach intent while turning the message into polished sections for financial-services audiences.

Agentic Architecture With Bedrock AgentCore And Strands Agents

The architecture separates judgment from automation. A Quant Orchestrator receives a research request and coordinates specialist tools. A Strategy Generator writes or retrieves Backtrader strategy classes. A Market Data Tool retrieves daily OHLCV data for AMZN, ^NDX, ^GSPC, and ^DJI. A Risk Summary Agent calculates return, drawdown, exposure, trade count, win rate, profit factor, and benchmark-relative behavior. A Governance Agent checks the policy boundary: long-only common equity, no derivatives, no unsupported performance promise.

This design fits institutional research because it creates traceability. The model does not secretly decide the portfolio. Instead, the agent calls approved tools, logs inputs and outputs, and returns a memo that a human committee can challenge. The code examples use Backtrader because it provides an event-driven research engine, technical indicators, analyzers, order handling, and trade statistics.

Real Data Setup

The examples use Amazon common stock as the tradable asset and three benchmark indices as context: Nasdaq 100 for growth and technology regime, S&P 500 for broad U.S. equity regime, and Dow Jones Industrial Average for blue-chip risk sentiment. The executable harness downloads real daily data through yfinance when run in your environment. The article does not invent market prices or fabricated performance numbers.

Part 8: Backtrader Harness, Agent Runtime, And Trade-History Schema

Related summary: Separates the executable harness, runtime sketch, timing-governance problem, and ledger schema for cleaner technical reading.

Reusable Backtrader Harness For Twenty-Year Trade History

## file: run_amzn_long_only_backtest.py
## Educational research only. Not investment advice.

import json
from pathlib import Path
from typing import Dict, Type

import backtrader as bt
import pandas as pd
import yfinance as yf

START_DATE = "2006-06-19"
END_DATE = "2026-06-19"
TICKERS = ["AMZN", "^NDX", "^GSPC", "^DJI"]

class TradeLoggerMixin:
    params = dict(risk_per_trade=0.10, stop_loss_pct=0.12, take_profit_pct=0.35)

    def __init__(self):
        self.order = None
        self.entry_price = None
        self.trade_rows = []

    def long_size(self):
        price = self.data0.close[0]
        if price <= 0:
            return 0
        return int((self.broker.getcash() * self.p.risk_per_trade) / price)

    def buy_long(self, reason):
        if self.position or self.order:
            return
        size = self.long_size()
        if size > 0:
            self.entry_reason = reason
            self.order = self.buy(size=size)

    def close_long(self, reason):
        if self.position and not self.order:
            self.exit_reason = reason
            self.order = self.close()

    def risk_exit_check(self):
        if not self.position or self.entry_price is None:
            return
        close = self.data0.close[0]
        if close <= self.entry_price * (1 - self.p.stop_loss_pct):
            self.close_long("risk_stop")
        elif close >= self.entry_price * (1 + self.p.take_profit_pct):
            self.close_long("profit_target")

    def notify_order(self, order):
        if order.status == order.Completed:
            dt = self.data0.datetime.date(0).isoformat()
            if order.isbuy():
                self.entry_date = dt
                self.entry_price = order.executed.price
                self.entry_size = order.executed.size
            else:
                exit_price = order.executed.price
                pnl = (exit_price - self.entry_price) * self.entry_size
                self.trade_rows.append({
                    "entry_date": self.entry_date,
                    "exit_date": dt,
                    "entry_price": round(self.entry_price, 4),
                    "exit_price": round(exit_price, 4),
                    "size": int(self.entry_size),
                    "gross_pnl": round(pnl, 2),
                    "entry_reason": getattr(self, "entry_reason", "signal"),
                    "exit_reason": getattr(self, "exit_reason", "signal"),
                })
                self.entry_price = None
            self.order = None
        elif order.status in [order.Canceled, order.Margin, order.Rejected]:
            self.order = None

    def stop(self):
        self.rets = list(self.trade_rows)

def download_data() -> Dict[str, pd.DataFrame]:
    raw = yf.download(TICKERS, start=START_DATE, end=END_DATE, auto_adjust=True, group_by="ticker", progress=False)
    out = {}
    for ticker in TICKERS:
        frame = raw[ticker].dropna().copy()
        frame.columns = [c.lower() for c in frame.columns]
        frame.index = pd.to_datetime(frame.index)
        out[ticker] = frame
    return out

def run_backtest(strategy_cls: Type[bt.Strategy], strategy_name: str, cash: float = 100000.0):
    data = download_data()
    cerebro = bt.Cerebro(stdstats=False)
    cerebro.broker.setcash(cash)
    cerebro.broker.setcommission(commission=0.0005)
    cerebro.adddata(bt.feeds.PandasData(dataname=data["AMZN"]), name="AMZN")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^NDX"]), name="NDX")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^GSPC"]), name="SPX")
    cerebro.adddata(bt.feeds.PandasData(dataname=data["^DJI"]), name="DJI")
    cerebro.addstrategy(strategy_cls)
    cerebro.addanalyzer(bt.analyzers.SharpeRatio, _name="sharpe", timeframe=bt.TimeFrame.Days)
    cerebro.addanalyzer(bt.analyzers.DrawDown, _name="drawdown")
    cerebro.addanalyzer(bt.analyzers.TradeAnalyzer, _name="trades")
    result = cerebro.run()[0]
    final_value = cerebro.broker.getvalue()
    out_dir = Path("backtest_outputs")
    out_dir.mkdir(exist_ok=True)
    trade_file = out_dir / f"{strategy_name}_trade_history_2006_2026.csv"
    pd.DataFrame(getattr(result, "rets", [])).to_csv(trade_file, index=False)
    report = {
        "strategy": strategy_name,
        "start": START_DATE,
        "end": END_DATE,
        "initial_cash": cash,
        "final_value": final_value,
        "total_return_pct": round((final_value / cash - 1) * 100, 2),
        "sharpe": result.analyzers.sharpe.get_analysis(),
        "drawdown": result.analyzers.drawdown.get_analysis(),
        "trade_analyzer": result.analyzers.trades.get_analysis(),
        "trade_history_file": str(trade_file),
    }
    with open(out_dir / f"{strategy_name}_summary.json", "w") as f:
        json.dump(report, f, indent=2, default=str)
    return report

Agent Runtime Sketch

## file: quant_agent_runtime.py
## Illustrative pattern; adapt IAM, networking, approvals, and logging for production.

from bedrock_agentcore import BedrockAgentCoreApp
from strands import Agent, tool

app = BedrockAgentCoreApp()

ALLOWED = {
    "breakout_55": "Breakout55Strategy",
    "ema_cross": "EMACrossStrategy",
    "multi_factor": "MultiFactorEnsembleStrategy",
}

@tool
def validate_policy(strategy_key: str, side: str, derivatives: bool) -> dict:
    if side.lower() != "long_only":
        return {"ok": False, "reason": "Only long-only equity research is allowed."}
    if derivatives:
        return {"ok": False, "reason": "Derivative instruments are outside this workflow."}
    if strategy_key not in ALLOWED:
        return {"ok": False, "reason": "Strategy is not approved in the registry."}
    return {"ok": True, "reason": "Policy accepted."}

@tool
def run_registered_backtest(strategy_key: str) -> dict:
    return {"status": "submitted", "strategy": ALLOWED[strategy_key], "artifact_prefix": f"s3://research/amzn/{strategy_key}/"}

agent = Agent(tools=[validate_policy, run_registered_backtest])

@app.entrypoint
def invoke(payload):
    return agent(payload.get("request", "Run approved AMZN long-only backtest."))

if __name__ == "__main__":
    app.run()

Business Problem: Timing Is A Governance Problem

An Amazon position can be profitable over a long horizon and still be poorly managed. Institutions therefore need process language, not only performance language. The research team should show what was bought, when it was bought, why it was bought, when it was sold, why it was sold, and how the decision behaved relative to major equity benchmarks. The agentic workflow makes this evidence easier to generate and easier to challenge.

Twenty-Year Trade History Schema

The trade history matters because it prevents vague storytelling. A committee can inspect whether profits came from many repeatable trades or one unusual period, whether exits reduced damage in bear regimes, whether benchmark filters helped, and whether turnover would survive realistic implementation costs.

Executive Speaking Close

The final message is factory-specific: one useful backtest is not enough if the process cannot repeat it. AgentCore and Strands Agents can help manufacture consistent review records, while Backtrader can produce the trade ledger. Human reviewers still decide whether the evidence is complete.

Sources And Data Notes

• Real-data workflow: executable examples download daily OHLCV data for AMZN, ^NDX, ^GSPC, and ^DJI using yfinance.
• Time range: 2006-06-19 to 2026-06-19, subject to market holidays and data-provider availability.
• AWS design pattern: Bedrock AgentCore runtime for agent orchestration, Strands Agents for tool coordination, and AWS governed data patterns for lineage, access, and artifact storage.
• Education only: not individualized advice, not a solicitation, and not a guarantee of performance.

Applied Main-Article Detail 1: Trade-History Factory Design

A governed factory creates the same artifact pattern every time: input record, strategy version, parameters, data snapshot, trade ledger, risk metrics, chart package, exception log, and review memo. Repeatability is the point.

Applied Main-Article Detail 2: Policy Validation Before Execution

Policy validation should occur before the backtest runs. The workflow should confirm symbol scope, long-only behavior, permitted strategy key, and no unsupported instrument logic. This prevents research output from violating the operating boundary.

Applied Main-Article Detail 3: Exception Handling As Governance

A failed data download, missing benchmark, zero-trade strategy, rejected order, or analyzer error should become a visible exception. The factory should not hide operational problems behind a polished summary.

Applied Main-Article Detail 4: Artifact Storage And Retrieval

The value of a factory is retrieval. A committee should be able to find the exact ledger, chart, code, and parameter set that produced a statement. This is where AWS data controls and agent logs become business evidence.

Applied Main-Article Detail 5: Executive Communication Layer

The executive layer should summarize what happened without overclaiming. It should show what was tested, what controls were applied, what records were generated, what failed, and what decision remains human.

Applied Main-Article Detail 6: Audit-Ready Lifecycle

An audit-ready lifecycle spans request, validation, execution, review, approval, retention, and rerun. The article frames the factory as a lifecycle, not only as a code notebook.

Institutional Review Lens 1: Evidence Package Design

A complete evidence package should include the research question, data source, adjustment policy, symbol list, code version, parameter set, trade ledger, drawdown profile, metrics summary, exception log, and disclosure language. This makes the backtest reviewable across investment, risk, technology, and compliance teams.

Institutional Review Lens 2: Human Challenge Workflow

The workflow is successful when it invites challenge. Reviewers should ask whether the data is clean, the rule has economic rationale, the benchmark is appropriate, the parameters are stable, the costs are realistic, and the conclusion is limited to what the evidence supports.

Institutional Review Lens 3: Long-Only Policy Boundary

The article keeps the policy boundary long-only. That boundary focuses the workflow on timing, sizing, exits, and evidence quality rather than complex instrument construction. It also gives the governance agent a clear rule for rejecting unsupported requests.

Institutional Review Lens 4: Chart And Ledger Interpretation

Charts are useful, but the ledger is the audit trail. An equity curve can hide concentration, and a single return number can hide turnover. The article therefore treats charts, ledgers, and metrics as complementary evidence, not as interchangeable proof.

Institutional Review Lens 5: Production Readiness Checklist

A notebook is not production. Production readiness requires controlled data access, versioned code, parameter records, repeatable runs, exception handling, artifact storage, approval workflow, and monitoring. Agentic tooling should support those controls rather than bypass them.

Institutional Review Lens 6: Failure Mode Disclosure

Professional articles should name failure modes early. Trend rules can whipsaw, momentum can exhaust, volatility filters can lag, and benchmark filters can exclude fast recoveries. Naming these risks increases credibility and helps the committee prepare useful questions.

Part 9: Strategy Catalog And Backtrader Strategy Classes

Related summary: Organizes the strategy review method and Strategy 16 through Strategy 20 code examples as one strategy-catalog section.

Strategy Review Method Before Reading The Records

Before reading the strategy records, use the same evidence sequence for every rule: confirm the data, identify the entry condition, identify the exit condition, inspect the sizing assumption, review drawdown, compare benchmark behavior, and record the lesson learned. This sentence replaces the repeated delivery note by turning it into a method used inside the article.

Strategy Catalog In This Article

• Strategy 16: StochasticStrengthStrategy — Stochastic strength continuation.
• Strategy 17: CCIMomentumStrategy — Commodity Channel Index momentum entry.
• Strategy 18: IchimokuLongStrategy — Ichimoku cloud trend filter.
• Strategy 19: ParabolicSARStrategy — Parabolic SAR trend-following entry.
• Strategy 20: MultiFactorEnsembleStrategy — Trend, momentum, and market-regime ensemble.

Strategy 16: StochasticStrengthStrategy

Research purpose. Stochastic strength continuation. This strategy is written as a long-only AMZN timing example. It can enter a long position, close a long position, or stay in cash. It does not create short exposure and it does not use options, puts, swaps, futures, margin, or other derivative instruments.

Position-management review. For StochasticStrengthStrategy, the desk should evaluate whether stochastic strength continuation adds useful timing evidence after costs, drawdown, and benchmark context. The review should inspect how often the rule trades, whether exits are understandable, whether the holding period fits the mandate, and whether the signal contributes insight beyond simply holding AMZN through every regime.

Backtrader code. Add this class below the reusable harness, then run run_backtest(StochasticStrengthStrategy, "StochasticStrengthStrategy") in a controlled research environment.

class StochasticStrengthStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(period=14, period_dfast=3, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.stoch = bt.ind.StochasticFast(self.data0, period=self.p.period, period_dfast=self.p.period_dfast)
        self.trend = bt.ind.SMA(self.data0.close, period=100)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.data0.close[0] > self.trend[0] and self.stoch.percK[0] > self.stoch.percD[0] and self.stoch.percK[-1] <= self.stoch.percD[-1]:
            self.buy_long("stochastic_strength_cross")
        elif self.position and self.stoch.percK[0] < self.stoch.percD[0]:
            self.close_long("stochastic_cross_exit")

The agent review for StochasticStrengthStrategy should summarize the signal path, ledger completeness, risk-control activity, and long-only policy status for this specific strategy run.

Strategy 17: CCIMomentumStrategy

Research purpose. Commodity Channel Index momentum entry. This strategy is written as a long-only AMZN timing example. It can enter a long position, close a long position, or stay in cash. It does not create short exposure and it does not use options, puts, swaps, futures, margin, or other derivative instruments.

Position-management review. For CCIMomentumStrategy, the desk should evaluate whether commodity channel index momentum entry adds useful timing evidence after costs, drawdown, and benchmark context. The review should inspect how often the rule trades, whether exits are understandable, whether the holding period fits the mandate, and whether the signal contributes insight beyond simply holding AMZN through every regime.

Backtrader code. Add this class below the reusable harness, then run run_backtest(CCIMomentumStrategy, "CCIMomentumStrategy") in a controlled research environment.

class CCIMomentumStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(period=20, entry=100, exit=0, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.cci = bt.ind.CCI(self.data0, period=self.p.period)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.cci[0] > self.p.entry and self.cci[-1] <= self.p.entry:
            self.buy_long("cci_momentum_break")
        elif self.position and self.cci[0] < self.p.exit:
            self.close_long("cci_zero_exit")

The agent review for CCIMomentumStrategy should summarize the signal path, ledger completeness, risk-control activity, and long-only policy status for this specific strategy run.

Strategy 18: IchimokuLongStrategy

Research purpose. Ichimoku cloud trend filter. This strategy is written as a long-only AMZN timing example. It can enter a long position, close a long position, or stay in cash. It does not create short exposure and it does not use options, puts, swaps, futures, margin, or other derivative instruments.

Position-management review. For IchimokuLongStrategy, the desk should evaluate whether ichimoku cloud trend filter adds useful timing evidence after costs, drawdown, and benchmark context. The review should inspect how often the rule trades, whether exits are understandable, whether the holding period fits the mandate, and whether the signal contributes insight beyond simply holding AMZN through every regime.

Backtrader code. Add this class below the reusable harness, then run run_backtest(IchimokuLongStrategy, "IchimokuLongStrategy") in a controlled research environment.

class IchimokuLongStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(risk_per_trade=0.08)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.ichi = bt.ind.Ichimoku(self.data0)
    def next(self):
        self.risk_exit_check()
        cloud_top = max(self.ichi.senkou_span_a[0], self.ichi.senkou_span_b[0])
        cloud_bottom = min(self.ichi.senkou_span_a[0], self.ichi.senkou_span_b[0])
        if not self.position and self.data0.close[0] > cloud_top and self.ichi.tenkan_sen[0] > self.ichi.kijun_sen[0]:
            self.buy_long("ichimoku_cloud_break")
        elif self.position and self.data0.close[0] < cloud_bottom:
            self.close_long("ichimoku_cloud_exit")

The agent review for IchimokuLongStrategy should summarize the signal path, ledger completeness, risk-control activity, and long-only policy status for this specific strategy run.

Strategy 19: ParabolicSARStrategy

Research purpose. Parabolic SAR trend-following entry. This strategy is written as a long-only AMZN timing example. It can enter a long position, close a long position, or stay in cash. It does not create short exposure and it does not use options, puts, swaps, futures, margin, or other derivative instruments.

Position-management review. For ParabolicSARStrategy, the desk should evaluate whether parabolic sar trend-following entry adds useful timing evidence after costs, drawdown, and benchmark context. The review should inspect how often the rule trades, whether exits are understandable, whether the holding period fits the mandate, and whether the signal contributes insight beyond simply holding AMZN through every regime.

Backtrader code. Add this class below the reusable harness, then run run_backtest(ParabolicSARStrategy, "ParabolicSARStrategy") in a controlled research environment.

class ParabolicSARStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(af=0.02, afmax=0.20, risk_per_trade=0.07)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.psar = bt.ind.ParabolicSAR(self.data0, af=self.p.af, afmax=self.p.afmax)
    def next(self):
        self.risk_exit_check()
        if not self.position and self.data0.close[0] > self.psar[0] and self.data0.close[-1] <= self.psar[-1]:
            self.buy_long("psar_flip_positive")
        elif self.position and self.data0.close[0] < self.psar[0]:
            self.close_long("psar_flip_exit")

The agent review for ParabolicSARStrategy should summarize the signal path, ledger completeness, risk-control activity, and long-only policy status for this specific strategy run.

Strategy 20: MultiFactorEnsembleStrategy

Research purpose. Trend, momentum, and market-regime ensemble. This strategy is written as a long-only AMZN timing example. It can enter a long position, close a long position, or stay in cash. It does not create short exposure and it does not use options, puts, swaps, futures, margin, or other derivative instruments.

Position-management review. For MultiFactorEnsembleStrategy, the desk should evaluate whether trend, momentum, and market-regime ensemble adds useful timing evidence after costs, drawdown, and benchmark context. The review should inspect how often the rule trades, whether exits are understandable, whether the holding period fits the mandate, and whether the signal contributes insight beyond simply holding AMZN through every regime.

Backtrader code. Add this class below the reusable harness, then run run_backtest(MultiFactorEnsembleStrategy, "MultiFactorEnsembleStrategy") in a controlled research environment.

class MultiFactorEnsembleStrategy(TradeLoggerMixin, bt.Strategy):
    params = dict(risk_per_trade=0.09)
    def __init__(self):
        TradeLoggerMixin.__init__(self)
        self.ma50 = bt.ind.SMA(self.data0.close, period=50)
        self.ma200 = bt.ind.SMA(self.data0.close, period=200)
        self.rsi = bt.ind.RSI(self.data0.close, period=14)
        self.macd = bt.ind.MACD(self.data0.close)
        self.spx200 = bt.ind.SMA(self.data2.close, period=200)
    def next(self):
        self.risk_exit_check()
        score = int(self.data0.close[0] > self.ma50[0]) + int(self.ma50[0] > self.ma200[0]) + int(self.rsi[0] > 50) + int(self.macd.macd[0] > self.macd.signal[0]) + int(self.data2.close[0] > self.spx200[0])
        if not self.position and score >= 4:
            self.buy_long("ensemble_score_entry")
        elif self.position and score <= 2:
            self.close_long("ensemble_score_exit")

The agent review for MultiFactorEnsembleStrategy should summarize the signal path, ledger completeness, risk-control activity, and long-only policy status for this specific strategy run.

Part 10: Executive Summary And Final Governance Data Notes

Related summary: Closes with committee-ready summary language, production cautions, final data notes, and education-only boundaries.

Executive Summary For Committee Use

This factory article should be read as an operating-model design, not as a search for one preferred AMZN signal. Its central question is whether each strategy run leaves enough evidence for rerun, challenge, retention, and comparison.

The final decision remains human. Agentic tooling can standardize request handling, policy checks, ledger generation, and artifact storage, but it cannot decide whether the produced evidence is sufficient for portfolio action.

Final Governance Data Notes

• Real-data workflow: executable examples should use approved daily OHLCV data for AMZN, Nasdaq 100, S&P 500, and Dow Jones Industrial Average.
• Time range: the example design uses a twenty-year research window and should record exact start and end dates in every run.
• AWS design pattern: Bedrock AgentCore runtime can host agent orchestration, while Strands Agents can coordinate tool use and result review.
• Education only: not individualized advice, not a solicitation, and not a guarantee of performance.