Bedrock AgentCore Forecast-to-PO Architecture Diagram: Zero-Shot Supply Chain Agents

The AWS Architecture Blog post of 11 September 2026 is a best-practices design, not a product SLA. It pairs Amazon Chronos2, a time-series model the post says forecasts without per-SKU training, with four LLM agents on Amazon Bedrock AgentCore. The agents call deterministic tools. One write, the decision record, crosses a Gateway and a Cedar policy. Everything else stays in process. Entry is a user prompt or a scheduled batch. The post does not name an event bus.

What this Bedrock AgentCore forecast purchase order architecture diagram shows

S3 holds one CSV per product, history and future covariates together, plus JSON for lead time, safety stock, capacity, minimum order quantity, and unit cost. SageMaker Serverless hosts Chronos2, the only external model call. Four Strands agents on AgentCore use Claude on Bedrock. The sample names Claude Sonnet 4.5. Treat that id as the sample and check Regional availability, as the post says.

The problem this architecture is solving

The post argues that a model per SKU scales training with the catalog, and that business rules then sit in spreadsheets. Chronos2, as described, is an encoder-only model in the T5 encoder style that forecasts without fine-tuning. Past-only and known future covariates go in through context_df and future_df on predict_df(). A promotion case and a no-promotion case can be compared before an order. That is the authors' reason for this model, not a public bake-off.

Their internal test reports median WAPE of 12.3 percent on 50 SKUs over four weeks, onboarding under five minutes versus two to three weeks, and about $1,091 a month always-on versus about $15 Serverless, called a 98 percent cut, at about eight seconds per SKU excluding cold start. A footnote limits the $15 figure to roughly 500 us-east-1 calls a month. The same post later targets rolling WAPE under 20 percent for the top 20 SKUs, and treats WAPE under 15 percent as a starting M5 reference to tune per catalog. Those are three separate statements, not one accuracy claim.

Main components and trust boundaries

If the same input always gives the same output, the post says, make it a tool. S3 loads, the Chronos2 call, the order formula, constraint checks, the chart, and the JSON write are tools. Covariate choice, anomaly notes, retry decisions, and the buyer summary are agent reasoning. A wrong in-process call stays in the agent. save_decision is the write downstream readers, which the post says can include an unnamed ERP integration, would treat as the order. It is the only one of eight tools on the Gateway. The chart also writes to S3, and the post leaves it in process because a bad chart must not block the record.

The Gateway checks a Cognito JWT. Cedar sees the principal and context.input. One policy allows save_decision only for the reporting identity. One forbids it when budget_used is over 50000. The post says that deny belongs on the write, not on the calculator, or the agent could recompute until it passed. Runtime is a per-session microVM, up to eight hours, idle cost zero between runs. Memory stores SKU history semantically and buyer overrides as preferences. It does not use the summary strategy. Traces go to CloudWatch. Online scores include a rubric of 1.0 silent violation, 2.0 flagged, 3.0 compliant. Accuracy waits for actual sales. Guardrails on the Supervisor are called mandatory in production. The P95-under-90-seconds target and the 95 percent rubric target are the authors' goals, not an SLA.

Request or data path, step by step

A prompt or a schedule hits the Supervisor. Its tools are the other three agents. max_node_executions is 10, enough for the sequence plus three retries, then a stop. Each specialist returns a short block, not its transcript. Preprocessing loads the CSV, stock, and config. Empty sales cells are the horizon. The agent keeps a covariate such as promotion when the prompt and the column support it, and drops a sparse column with a note.

Forecasting calls Chronos2, retrying three times with a 30-second sleep on ModelNotReadyException. The cost table separately estimates a Serverless cold start at 30 to 60 seconds. The 30-second retry sleep and that cold-start estimate stay as two separate source notes. The order tool sums P50 across the lead time, adds safety stock, subtracts on-hand stock, and lifts a small positive quantity to the minimum order. Constraints check capacity and budget. Failure text returns to the Supervisor for another pass. After three misses it asks the user. In the SKU-00142 walkthrough the post says to offer a higher budget, the shortfall, or a delayed promotion, not a silent cut. An approved decision is charted, then saved through the Gateway. Both runtime and endpoint scale to zero when idle. A later "few dollars" estimate for 10,000 SKUs is not the $15 figure.

The diagram: labeled boxes and failure or isolation edges

• Solid: prompt or schedule, Supervisor, Preprocessing, S3, Forecasting, Chronos2, constraints, Reporting, Gateway and Cedar, decision record.
• Retry: up to three constraint failures, then a person. Count lives in session memory.
• Cedar: budget_used above 50000 does not persist.
• Cold start: 30-second retry sleep and a 30–60 second cold-start estimate are both in the post. They stay separate notes, not one number on the art.
• No Gateway on the other seven tools. No named ERP API. No event bus.

What the source does not claim (preview, case study, or limits)

Hyunsoo Kim and Chloe Kwak's 11 September 2026 post is best-practice guidance at level 300. Accuracy and dollars are theirs, with the us-east-1 footnote, not a price list. The 1.3 P90/P50 line is inside an example, not a platform constant. The post names no EventBridge, no ERP vendor, and no approval product. Chronos2 does not emit the purchase order. The agents and the formula do.

How this differs from a nearby pattern on ByteDiagram

The AgentCore platform diagram is runtime, memory, and gateway in general. This post is one replenishment flow: the formula, the three-strike handoff, and the 50000 Cedar forbid are only here.

FAQ

Does this pipeline train a forecasting model per SKU?

The post says Chronos2 is zero-shot, with no fine-tune, so a new SKU has no training job. The authors' internal test cites median WAPE of 12.3 percent on 50 SKUs over four weeks. Their production target is rolling WAPE under 20 percent for the top 20 SKUs. The evaluator note treats under 15 percent as a starting M5 reference. Those three numbers are not the same claim.

Where is the human approval gate before a purchase order is saved?

No separate approval product is described. validate_constraints returns approved or not. The Supervisor may retry with new constraints up to three times, then escalate. The SKU-00142 walkthrough says to offer a higher budget, the shortfall, or a delayed promotion. Cedar on the Gateway forbids save_decision when budget_used is over 50000. Only that write is on the Gateway.

Which AgentCore services does the post actually attach?

Runtime, Gateway, Policy, Memory, Observability, and Evaluations, each for one concern. Runtime is a per-session microVM, up to eight hours, idle at zero. Gateway and Cedar guard save_decision only. Memory is semantic plus user preference, not summary. Behavior scores are online. Accuracy waits for actual sales. Costs are the authors' us-east-1 estimates, not an SLA.

Conclusion

The human gate is the three-retry limit plus the Cedar deny on the one persisted write. Treat every percentage and dollar figure as the authors' estimate. Cite the forecast-to-purchase-order post. More diagrams are on the ByteDiagram blog.