Alfred gives teams a reusable template for building and operating agentic applications across Loblaw Digital's e-commerce and other digital properties.
2
MCP servers turn many low-level platform APIs into task-oriented tools that agents can call reliably, such as finding all products needed for a recipe.
3
Loblaw Digital monitors traditional APIs, MCP servers, and LLM activity with separate systems, while using evaluation sets, budgets, and prompt replay to manage quality and cost.
Summary
Mefta Sadat explains how Loblaw Digital built Alfred, a reusable orchestration layer for agentic applications. The system sits between front-end applications and Loblaw's platform APIs, coordinating agents, tools, prompts, models, context, security, and observability. Alfred applications run as FastAPI services on Google Kubernetes Engine, use LangGraph for workflow logic, LiteLLM for model access, Langfuse for prompt management and LLM traces, and AlloyDB for checkpointing. Teams start from a Copier template that includes CI/CD, testing, MCP support, a chat UI, and common utilities. Sadat argues that MCP is useful when it groups many low-level endpoints into task-oriented tools, such as turning catalog, pricing, and inventory calls into one tool for assembling a recipe's shopping list. In the Q&A, he describes evaluation sets for replaying workflows, FastMCP for building servers, separate monitoring systems, team and project budgets, and routing simpler requests to smaller models. Agentic checkout remains a future step because users still move into Loblaw's application to complete checkout.
Agentic commerce becomes difficult when prototypes meet enterprise systems
Loblaw Digital wants users to chat about products, receive recommendations, add items to a cart, and complete shopping workflows such as turning a recipe into a set of ingredients. Sadat says prototypes are easy to make, while production requires work across cloud services, databases, privacy, security, and many technology stacks. The agent also has to connect to more than 50 platform APIs and hundreds of endpoints. Since many teams want to build similar applications, Loblaw Digital needed a shared starting point instead of having each team assemble the same infrastructure.
Alfred provides a reusable production template for agent applications
Alfred is Loblaw Digital's orchestration layer for agentic workflows. Sadat describes it as a reusable pattern that can support e-commerce, loyalty, healthcare, and other applications. Teams start with a Copier template containing the project structure, CI/CD, testing, MCP support, checkpointing, and a chat UI for testing. Agents and their connections to tools or other agents are configured through YAML. The template also applies shared practices for prompt management, guardrails, workflow logic, security, observability, and model-provider abstraction.
The architecture separates the application gateway from orchestration and platform tools
A front-end application calls a backend-for-frontend service, which calls an Alfred FastAPI microservice. That service runs orchestration with LangGraph and accesses models through LiteLLM. The foundation layer exposes platform capabilities through MCP servers or Python packages and includes a reusable chat UI and utility package. Langfuse, metrics, and logs make up the observability layer. LiteLLM provides the model gateway, while vector storage and PostgreSQL provide data and checkpointing. The services run on Google Cloud components, including Google Kubernetes Engine.
A built-in chat UI makes conversational workflows easier to test
Every Alfred FastAPI microservice includes a pluggable chat UI delivered through a Python package. Sadat shows a user asking for milk under a given price, with the agent calling a catalog search MCP tool and returning products from different brands and providers. The UI lets teams test conversational behavior directly instead of relying only on tools such as Postman or Swagger UI. Tools can also be imported from shared packages, allowing teams to reuse existing capabilities rather than implement them again.
MCP turns many platform endpoints into task-oriented tools
Loblaw Digital has platform APIs for carts, customers, catalogs, pricing, recommendations, and inventory. Sadat says agents should not call these low-level endpoints directly for every workflow. MCP servers group them into tools that match a user task. For a shrimp pasta recipe, one tool can use catalog, pricing, and inventory APIs to find the ingredients and return the products needed. This lets agents work with a smaller, more useful interface while preserving the existing platform services underneath.
MCP also makes tools and interface components reusable
New MCP tools can become available to Alfred applications without code changes in each application. Loblaw Digital is also exploring protocols and SDKs that return interface components with tool responses. In the shopping example, an MCP response can provide product lists, store lists, or recommendations that the chat interface renders directly. The recipe flow lets a user choose a store, review the products needed for the recipe, add them to the cart, and then move into the Loblaw application for checkout. Fully agentic checkout is a future step.
Quality control depends on replaying workflows against evaluation sets
In the Q&A, Sadat explains that Loblaw Digital creates evaluation sets for workflows such as the recipe example. The team replays a sequence of prompts and responses and checks whether the workflow returns the expected kind of result. They adjust tool descriptions, tool parameter descriptions, and system prompts when behavior needs improvement. Langfuse helps manage prompt versions and replay the validation set after changes. This is how the team works toward consistent results from a nondeterministic system.
Monitoring and budgets remain split across several systems
Loblaw Digital uses Grafana and Prometheus for standard API metrics, separate dashboards for MCP server activity and tool-call success, and Langfuse for LLM monitoring. Sadat says there is no single system covering all of these areas. The team tracks latency, success rate, and cost. LiteLLM allows budgets and alerts for model providers, with limits assigned by team and project. Alfred can route simple requests to smaller models such as Gemini 2.5 Flash-Lite and use reasoning-focused models for harder tasks. Feedback loops for agents to self-improve are not part of the system yet.
"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."Mefta Sadat12:37
Who should watch
You are building shopping or service agents that need to call many existing enterprise APIs and want a shared architecture for multiple teams.
Your agent prototype works in a demo, but you need practical patterns for templates, tool security, checkpointing, prompt versioning, and workflow tests.
You are deciding how to structure MCP servers, monitor LLM applications, or assign model budgets across teams and projects.
