The_Wrong_Shape_for_a_Choice

In late July 2026, the agent infrastructure market split itself in half, and nobody was pretending it hadn't.

On one side: self-hosted open-weight frameworks. LangGraph (LangChain, Python-first orchestration), Pydantic AI (Pydantic's native agent layer, validation-first), LlamaIndex (the persistent retrieval standard), CrewAI and Agno (multi-agent coordination frameworks), Browser Use (web automation). These are libraries you install, frameworks you control, stacks you build in. They assume you have infrastructure and engineering capacity. They reward that investment with precision and control.

On the other side: managed enterprise agent platforms. Salesforce Agentforce (CRM-integrated, preconfigured workflows). Google Cloud Gemini Enterprise Agent Platform (evolved from Vertex AI, enterprise auth/governance). Alibaba Agent Native Cloud (built for scale on infrastructure you don't manage). These are services you provision, platforms where agents live, systems that abstract the orchestration layer away. They assume you want reliability and managed scaling more than you want control. They reward that assumption with operational peace and native integrations.

The industry framing treats this as a strategic choice: pick your lane, commit to the abstraction level, build accordingly.

I do not agree.

The thing I keep running into is that the choice itself is the wrong shape for a production fleet. Not "pick self-hosted" and not "pick managed." Route by task, tier by tier, on the same criteria every time. Explicit rule, not fleet-wide ideology.

The_Routing_Question,_Not_the_Architecture_Question

I run twelve specialised agents across my work. They do not all live in the same framework class. Some run on Claude Sonnet (Anthropic, full context and reasoning budget, deployed as subagents in my orchestration layer). Some run on Claude Haiku (faster, cheaper, specialised for copy and design work). Some run on local models via terminal scripts (mechanical tasks, high volume, zero latency sensitivity, fire-and-forget).

That distribution is not a compromise. It is routing. And I did not realise I had a routing system until the framework bifurcation forced me to name what I was already doing.

The infrastructure choice - self-hosted versus managed, Sonnet versus Haiku versus local ornith - is determined by the same variable for every agent: what is the task complexity, and what is the cost of failure?

A code-review agent (Nix, running on Sonnet) handles pull requests where a wrong decision breaks production. The cost of getting it wrong is measured in customer impact and incident recovery. That agent lives in a full-context, high-reasoning-budget environment because the task complexity and failure cost demand it. I also pay for it proportionally. The decision to run that agent on a managed, expensive tier is not "we chose the enterprise platform" - it is "this task's failure cost justifies the overhead."

A copy-review agent (Vera) handles brand voice and messaging. The cost of getting it wrong is measured in positioning coherence and editorial integrity. That is high stakes in a different dimension - not production reliability but brand signal stability. That agent runs on Haiku (still a full language model, still capable of complex reasoning, but a model optimised for speed over raw reasoning budget) because the task complexity is lower: voice work is precise, but it does not need the reasoning depth of a debugging agent. Haiku is both sufficient and appropriate. Running Vera on Sonnet would be overspend on a task that does not justify it.

A mechanical agent running a scheduled compliance check (deterministic checks, no model reasoning, just pass/fail against a known rule set) runs on a local script and returns a numeric exit code. It does not need the managed platform overhead. It does not need the self-hosted framework complexity. It needs speed and reliability on a known domain. Forcing that task onto a full-context language model is waste and latency for zero benefit.

Three agents, three framework tiers, three routed decisions made on the same criteria applied consistently.

Why_Explicit_Routing_Matters_at_Solo_Scale

When one person is orchestrating twelve agents, the decisions cannot be ad hoc. "What model should this agent run on?" answered differently every time is a failure mode waiting to happen.

So I have a tiering protocol. It is written down. It is enforced at dispatch time.

Here is how it works:

Agents handling code review, full-system reasoning, and architectural decisions run on Sonnet. Agents handling copy, design, and brand-level decisions run on Haiku. Mechanical tasks (compliance checks, file parsing, deterministic workflows) run on free or penny-tier models behind exit-0 verification gates. When I commission an agent to do a task, I specify the model explicitly. Not by convention. Not by what model would be nice to have. By what this specific task's requirements map to. The model parameter is not optional. It is not defaulted. It is stated at dispatch time.

This does two things. First, it makes the routing decision visible and reviewable. If I am consistently commissioning agents on the wrong tier, I will see it in the logs. Second, it creates consistency for the agent that is being commissioned. An agent knows, when it starts a task, what resources and reasoning budget it is operating under. That budget constrains the complexity of the problem it can solve, and an explicit tier communicates that constraint upfront. You do not send a Haiku-tier agent to debug a distributed-tracing production incident and then get surprised when it cannot produce the depth you need.

The protocol also has guardrails. The ceiling for a subagent is Sonnet. No agent runs on the top tier (Opus). That is reserved for orchestration and thinking-partner work that only I do. Routing mechanical tasks to a separate free or penny-tier swarm-worker lane happens only when the task is genuinely mechanical - and even then, it runs behind an automated verification gate. I do not trust a single low-tier model run against a high-stakes task.

This system is not novel. It is routing. But routing only works when it is explicit. The moment it becomes implicit - "let me just use whatever model feels appropriate" - it stops being routing and starts being ad hoc judgement calls. And at solo scale, ad hoc judgement calls compound.

Applying_This_to_the_Framework_Bifurcation

Here is where the market bifurcation becomes concrete.

The self-hosted frameworks (LangGraph, Pydantic AI, LlamaIndex, CrewAI, Agno, Browser Use) are appropriate for the Sonnet tier of work. They give you full control. You can instrument them to see what is happening. You can add hooks and callbacks and validation layers. You can deploy agents that reason about their own constraints and make decisions about whether they can solve a problem or need to escalate. That investment in control is justified when the task failure cost is high enough to warrant it.

The managed enterprise platforms (Salesforce Agentforce, Google Gemini Enterprise, Alibaba Agent Native Cloud) are appropriate for certain classes of work where managed scaling and native integrations matter more than bespoke control. Salesforce Agentforce makes sense if your agents live in a CRM context - let the platform own that integration rather than building it yourself. Gemini Enterprise makes sense if your agents need enterprise auth and governance built into the platform boundary. Alibaba's platform makes sense if your scale is high enough that managed infrastructure overhead is worthwhile.

A solo operator does not need a literal foot in both camps to apply the same logic. My own twelve agents all run inside one self-hosted orchestration layer, and the tiering discipline still holds: code-review agents get the control of a full reasoning budget, copy-review agents get the speed of a lighter tier, and mechanical agents get neither, because they do not need it. The analogy to the market's self-hosted/managed split is in the routing discipline, not in a literal claim of running both.

The routing decision - which framework this agent uses - is determined by the task, not by fleet ideology.

The_Operative_Rule

If you are running more than a handful of agents, make your routing explicit. Write down what tier each type of task maps to. Specify that tier when you commission work. Audit the decisions against the rule to see where you are violating your own tier boundaries.

You do not have to choose between self-hosted and managed. You have to choose which task maps to which infrastructure. The clarity that comes from making that choice visible, each time, is what keeps a production fleet coherent when there is only one person running it.

The framework bifurcation is real. The market genuinely has split into two infrastructure classes. But at a solo operator's scale, the useful split is not between frameworks. It is between tasks and their tier requirements.

Worth separating from a related question: this piece is about where control and spend route - which framework class a given agent runs in. A harness absorbing more of the orchestration mechanics itself, regardless of which class it runs in, is a different axis entirely, not a contradiction of the one argued here.

Choose the tier. Route accordingly. Everything else follows.