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
leo.indiedev@gmail.com
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:
Qwen, GLM, Kimi, etc.), so evaluating new models is a config change, not
a refactor
"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
leo.indiedev@gmail.com