Suggestion: a note on model portability — "Own Your Model Layer" via OpenAI-compatible endpoints

Hi Dex and team,

First off — thank you for this guide. The framing that production agents are "mostly deterministic code with LLM steps" matches what I've experienced building with frameworks, and Factor 2 / Factor 3 / Factor 8 saved me from at least two bad architectural decisions.

I'd like to suggest a small addition that fits naturally into the existing philosophy: a short note on model portability — you could call it "Own Your Model Layer."

The gap I noticed:

The guide covers owning your prompts, context window, and control flow, but the model access layer itself is often the last piece still coupled to a single vendor — one provider's SDK, one API key, one pricing model. When a better model ships (or a provider has an outage), teams end up doing plumbing work across their codebase instead of just switching.

What I'd suggest:

A brief mention (honorable-mentions level, not a new factor) that treating model access as a swappable OpenAI-compatible endpoint keeps agents portable:

• One base URL + one key → access to many models (GPT, Gemini, DeepSeek, Qwen, GLM, Kimi, etc.), so evaluating new models is a config change, not a refactor
• Built-in routing and fallback between providers aligns with the "small, focused agents" mindset — each agent can pin the model that suits it, without vendor lock-in

(Context: I'm the developer of AnyLLM, an OpenAI-compatible API gateway that puts 24+ Chinese and international models behind a single key, with pass-through pricing. Happy to contribute a PR with a vendor-neutral write-up of the pattern — no product placement required, a generic "OpenAI-compatible gateway" example works fine for the guide.)

Would a short section like this fit the guide's scope, or would the maintainers prefer keeping provider topics entirely out?

— Leo Bennett [email protected]