Building Alfred: Production-Ready Agentic Orchestration Layer for E-commerce

loblaws · E-commerce · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise e-commerce agent orchestration

Loblaws needed a reusable production layer for agentic workflows across e-commerce, loyalty, healthcare, and retail applications, with security, privacy, observability, API integration, and model abstraction built in.

Constraints:

Many teams need to build agentic applications from a shared enterprise pattern.
The platform must integrate with 50+ platform APIs and hundreds of endpoints.
PII must be masked before provider calls and in observability data.
Conversational commerce flows need a testable chat UI and production observability.

Architecture

Alfred is a LangGraph/FastAPI orchestration template deployed on GKE, with LiteLLM model abstraction, Langfuse prompt/trace observability, AlloyDB/Postgres checkpointing, MCP servers as task-oriented API gateways, PII masking/encryption, CI/CD, and pluggable chat UI for teams building agentic apps.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  frontend-app[Frontend App] --> bff[BFF]
  bff --> alfred-microservice[Alfred Microservice]
  alfred-microservice --> langgraph-orchestrator[LangGraph Orchestrator]
  alfred-microservice --> foundation-layer[Foundation Layer]
  foundation-layer --> mcp-servers[MCP Servers]
  langgraph-orchestrator --> mcp-servers
  mcp-servers --> platform-apis[Platform APIs]
  alfred-microservice --> llm-gateway[LLM Gateway]
  alfred-microservice --> observability-layer[Observability Layer]
  alfred-microservice --> data-layer[Data Layer]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Frontend App`	Mobile or web application invoking conversational commerce flows.	`BFF`
`BFF`	Backend-for-frontend service that mediates between product UI and Alfred.	`Frontend App`, `Alfred Microservice`
`Alfred Microservice`	FastAPI orchestration service for a specific agentic application.	`BFF`, `LangGraph Orchestrator`, `Foundation Layer`, `Observability Layer`, `LLM Gateway`, `Data Layer`
`LangGraph Orchestrator`	Agent workflow graph configured through YAML.	`Alfred Microservice`, `MCP Servers`
`Foundation Layer`	Reusable template, agent utilities, pluggable chat UI, MCP, testing, and common functions.	`Alfred Microservice`, `MCP Servers`
`MCP Servers`	Task-oriented gateways over platform APIs such as cart, catalog, pricing, recommendation, and inventory.	`LangGraph Orchestrator`, `Platform APIs`
`Platform APIs`	Enterprise APIs and endpoints for commerce, loyalty, and retail capabilities.	`MCP Servers`
`LLM Gateway`	LiteLLM abstraction over OpenAI, Gemini, and other model providers.	`Alfred Microservice`
`Observability Layer`	Langfuse, metrics backend, log sinks, masking, and debugging traces.	`Alfred Microservice`
`Data Layer`	Vector database and checkpointing database in Postgres/AlloyDB.	`Alfred Microservice`

Data flow

A frontend app calls a BFF, the BFF calls the Alfred FastAPI microservice, LangGraph orchestrates agents from YAML configuration, tools are exposed through MCP/Python packages, model calls go through LiteLLM, state/checkpoints go to AlloyDB/Postgres, and observability flows through Langfuse and metrics/log layers.

“front- end application and the Alfred um micros service. And this microser is essentially a aentic orchestration application, a fast API app”transcript, stated

“the gateway to an agentic application that is doing orchestration using langraph and abstracting models using light LLM”transcript, stated

Why this architecture

Loblaws built Alfred as a reusable enterprise template so teams could start from the same secure, observable, model-abstracted orchestration layer rather than rebuilding production plumbing.

“The core goal of our Alfred is to apply a reusable pattern that can scale not just on ecom but for all our applications”transcript, stated

“our GitLab repository and any team want to build an agentic application can use copier to start their own repository and this template would include barebone project structures, MCP checkpointing like all of this all of the stuff needed for an agentic application including”transcript, stated

Models used: OpenAI models · Gemini · LiteLLM

Scale

Loblaws has over 500 colleagues across more than 50 teams.
“domains we have over 500 colleagues, 50 plus teams and many different uh interesting things we are working on. So in this talk I'll be talking about the core problems of working on enterprise systems and agentic commerce.”transcript, stated
The company operates 50+ platform APIs and hundreds of endpoints.
“platform APIs. In our case, there are 50 plus APIs, hundreds of endpoints that needs to be integrated into the stack. And finally, across a large organization, many teams are are actually interested in building similar”transcript, stated
Loblaws frames its footprint as within 10 minutes of virtually every Canadian.
“company in Canada and within 10 minutes of every Canadian there is a store uh of one of our stores actually. So you can think of the scale is massive. We have also uh different type of uh”transcript, stated

Alternatives considered (roads not taken)

Teams build separate agent apps from scratch.

Rejected because: A template provides reusable security, observability, checkpointing, chat UI, CI/CD, and model/provider abstractions.

“this template would include barebone project structures, MCP checkpointing like all of this all of the stuff needed for an agentic application including CI/CD testing”transcript, stated

Expose raw platform endpoints as tools.

Rejected because: Reliable agents need task-oriented tools that combine lower-level API calls.

“just so many of them and for a agents to perform reliably they cannot simply just call in points and tools. We have to carefully think about how we can break down a task or a workflow and combine multiple orchestration and combine them into a single tool. So we'll basically”transcript, stated

“into a single tool. So we'll basically group low-level endpoints and make them a task oriented tool. You can think of the recipe use case for example. So user is looking at a recipe talking with LM about their dinner ideas and maybe a shrimp pasta is found for recipe and”transcript, stated

Patterns

`tool-use-orchestration` (platform)

MCP servers wrap platform APIs into task-oriented tools for agents.

“model context protocol or MCP servers are are really the foundation for great agentic applications. It work as a gateway to our platform APIs”transcript, stated

`durable-execution` (state)

Alfred includes checkpointing backed by AlloyDB/Postgres for workflow context.

“We manage uh our context with checkpointing and um that is done on the alloy DB side.”transcript, stated

`privacy-preserving-processing` (security)

PII is masked before provider calls and in observability output, with encryption on data.

“mask all of the PII data. We we also provide encryption on top of all of the data.”transcript, stated

`observability-tracing` (operations)

Langfuse, metrics, log sinks, tracing, and debugging are part of every Alfred template.

“traceability and debugability options.”transcript, stated

“observability layer consisting lang fuse our matrix back end and lock syncs”transcript, stated

Tradeoffs

Platform strategy

Chose Reusable Alfred template over One-off agent implementations per team.

Rationale: The template bakes in production requirements for many teams and domains.

“use a reusable template for our teams to start new apps.”transcript, stated

Tool surface

Chose MCP task tools over Direct endpoint-level tool calls.

Rationale: Task tools combine catalog, pricing, inventory, and other APIs into operations the LLM can reliably use.

“the tool can talk with all of the platform APIs like catalog, pricing, inventory to give the users back a list of products”transcript, stated

Gotchas (what bit them)

Raw enterprise APIs are not reliable agent tools.

Root cause: Agents struggle when exposed to many low-level endpoints without task decomposition.

Resolution: Group platform endpoints into task-oriented MCP tools.

“We have to carefully think about how we can break down a task or a workflow and combine multiple orchestration”transcript, stated

Enterprise observability can leak sensitive data if not designed in.

Root cause: Model-provider messages and traces may contain PII.

Resolution: Mask PII before provider calls and in observability records.

“All of the messages going to the to the London providers are make sure that there was no PI in it”transcript, stated

Evaluation

Alfred templates include CI/CD testing, pluggable chat UI for conversational testing, Langfuse observability, API metrics, logs, and traceability/debugging.

Metrics: Tool-call traces · API metrics · Logs · Prompt/trace observability · Security validation

“including CI/CD testing and pluggable uh chat UI for testing.”transcript, stated

“A conversational commerce application is hard to test with normal um testing tools like Postman or Swagger UI”transcript, stated

Outcomes

Alfred gives Loblaws teams a reusable production agentic application starting point.
MCP servers create reusable, task-oriented access to platform APIs.
Security, privacy, observability, checkpointing, and model abstraction are included by default.

The source describes 500+ colleagues, 50+ teams, 50+ APIs, hundreds of endpoints, and multiple enterprise domains.

“MCP also provide massive reusability of the tools and without needing any code change.”transcript, stated