The Week Recipes Grew Up

Hardening the Amplifier recipe engine for production

The recipe engine

This week the recipe engine went from a local-only tool toward safe to run as a production web service

The engine lives in microsoft/amplifier-bundle-recipes as one Python module, executor.py — its module docstring reads "Recipe execution engine." It runs multi-step recipes end-to-end.

The change wasn't a rewrite. It was a handful of verifiable commits.

# modules/tool-recipes/amplifier_module_tool_recipes/executor.py
"""Recipe execution engine."""

# imports the foundation dependency:
from amplifier_foundation import ProviderPreference

Not a rewrite

Five commits on the recipes main branch did the hardening — resting on a keystone in a second repo

In the week of Jan 25-31, 2026, amplifier-bundle-recipes had 5 commits on main. The keystone they depend on — the ProviderPreference dataclass — landed in microsoft/amplifier-foundation.

Small burst, two repos. But first: what already worked?

5

recipes commits on main, Jan 25-31

2

repos: the engine + foundation

The baseline

The engine already had the hard parts before this week

By mid-January the executor already ran recipes with bounded parallelism, rate limiting, cancellation, and a first cut of provider/model selection — good enough for single-provider, local runs.

A capable baseline. So what was still missing for production?

Jan 7

Bounded parallelism + recipe-level rate limiting 997b85e1

Jan 12

Full cancellation support for the recipe executor 4a30c0f7

Jan 13

First cut of provider & model selection on recipe steps 2a602cf8

The gaps

That baseline assumed local, single-provider runs — production exposed two gaps

A single provider outage broke a run: there was no ordered fallback. And running as a backend web service, Path.cwd() returned the server's directory instead of the user's project.

Two concrete failures. The week's work closed both — starting with paths.

Provider outage broke the run. One provider going down had no fallback path.
Wrong working directory. As a web backend, Path.cwd() pointed at the server, not the user's project.

Fix #1 — paths

The wrong-paths fix was surgical: query session.working_dir, fall back to Path.cwd()

Commit 0e014938 (PR #15, merged Jan 26) has the engine query the session.working_dir capability, falling back to Path.cwd() for backward compatibility — so web deployments resolve the user's project directory.

One gap closed. Now the harder one: provider resilience.

# Before: server's directory when run as a web backend
Path.cwd()

# After (0e014938, PR #15): user's project directory
session.working_dir  # falls back to Path.cwd()

Fix #2 — shared resilience

Provider resilience moved into shared foundation, and dead code came out

On Jan 26 the engine refactored to use foundation's ProviderPreference for provider/model selection (f2c0ff4f, +22/-13) and deleted its own model_resolver.py (5fbd284e, -173 lines) to prevent context poisoning.

The engine now leans on a shared primitive — which is where the keystone comes in.

f2c0ff4f

Adopt foundation's ProviderPreference for provider/model selection +22 / -13, executor.py

5fbd284e

Remove dead model_resolver.py — context-poisoning cleanup -173 lines

The keystone

An ordered fallback chain means one provider outage no longer breaks a run

On Jan 25 foundation gained a ProviderPreference dataclass with an ordered fallback chain (984812bd, by Brian Krabach). By Jan 28 the engine added explicit provider_preferences lists with fallback order (d79e57c2, by momuno, via PR #17).

The engine tries each provider until one is available. That is production resilience.

Jan 25

ProviderPreference dataclass — ordered fallback chain, in foundation 984812bd

Jan 28

Explicit provider_preferences list with fallback order d79e57c2, +168/-8, PR #17

What it adds up to

One focused week, verified commit by commit, turned a local runner into a production engine

Correct web-deployment paths and ordered provider fallback made the engine safe to run as a backend service. The very next week — Feb 7 — convergence loops (while_condition / break_when) built on that hardened base.

The convergence work (53089b12) landed after the Jan 25 week, not within it.

Jan 25-28

Provider resilience + correct web paths — the production hardening

Feb 7

Convergence loops (while_condition/break_when) on the hardened base 53089b12

Sources

Research Methodology

Data as of: Independently re-derived from microsoft/amplifier-bundle-recipes and microsoft/amplifier-foundation for the week of Jan 25-31, 2026.

Feature status: Provider resilience — VERIFIED. Correct web-deployment paths — VERIFIED. Convergence loops — VERIFIED but dated Feb 7, 2026 (after the week).

Commands run:

gh api 'repos/microsoft/amplifier-bundle-recipes/commits?sha=main&since=2026-01-25T00:00:00Z&until=2026-02-01T00:00:00Z&per_page=100' — 5 commits
gh api --paginate 'repos/microsoft/amplifier-foundation/commits?sha=main&since=...&until=...' | jq '.[].sha' | wc -l — 34 commits
gh api repos/microsoft/amplifier-bundle-recipes/commits/{0e014938,f2c0ff4f,5fbd284e,d79e57c2} — per-commit stats and messages
git show -s --format='%ai' 984812bd — foundation ProviderPreference date (2026-01-25 20:03:20 -0800)
git show origin/main:.../executor.py | grep -n 'from amplifier_foundation import ProviderPreference' — engine dependency
git show 5fbd284e~1:.../model_resolver.py | wc -l — deleted file was 173 lines

Corrections applied: executor.py line count is snapshot-dependent (not asserted here). The legacy "51 commits" figure was not reproducible and is omitted. Convergence loops honestly dated Feb 7, 2026.

Primary contributors: Brian Krabach (984812bd, 0e014938, f2c0ff4f, 5fbd284e); Mollie Munoz / momuno (d79e57c2, PR #17).