Nobody ships a release by hand. One engineer writes the build file. A farm of identical workers runs it ten thousand times a night. The engineer is expensive and runs rarely; the workers are cheap and run all the time. On November 9, 2026, Meta described its two newest models in the same shape: "Muse Wonder plans, Muse Ember handles the volume."
We build agents this way, and if you do too, the vendor news from that Monday changes your parts list more than your architecture. What it does not change is the wiring, and the wiring is where the real decisions live. This post is a build guide for that wiring: how we write the rules the planner produces, how we route each task category, how we keep a local executor from silently falling back to the cloud, and how we accept a new executor before it touches production volume.
A planner/executor split is an agent design in which a capable model plans the work and writes the rules for a kind of task, and a smaller, cheaper model executes those rules across many items. It is not a fallback chain where the small model steps in when the big one fails. The two models do different jobs on every run, and each can be chosen, priced and replaced on its own.
What Meta and Anthropic shipped on November 9
TechCrunch's Russell Brandom reported Meta's release of Muse Ember that day. According to the report, Meta calls Ember its lightest and most cost-efficient model so far, "designed for complex reasoning execution and the work agents repeat all day: tool calls, coding subtasks, routing, extraction, and long document parsing." Input price: 10 cents per million tokens. The output price was not in the coverage we reviewed, so every Ember figure in this post is the input half only.
The report also sketches the pairing in practice. In a customer-support agent, a heavier model establishes rules for a category of issue, and a lighter model applies those rules "across tens of thousands of cases." Meta trained Ember to read screenshots, charts and scanned documents, and to work from voice memos, meeting recordings and video without a separate model.
Anthropic shipped Claude Fable 5.2 and Claude Mythos 5.2 the same day. The announcement lists Fable at $8 per million input tokens and $40 per million output in standard mode, and gives it two roles that map onto the same split: "Advisor (where Haiku, Sonnet, or Opus models consult it to help solve harder problems)" and "Orchestrator (where it delegates simpler tasks to smaller models)." The same post tells users to start most coding and knowledge work on Claude Opus 5.5 and move "upward to Fable or Mythos, or downward to Claude Sonnet 5.5 or Claude Haiku 5.5" depending on the job.
One pricing detail in that announcement is worth copying into your own evaluation sheets. Anthropic compares per task, not per token: on its coding benchmark, Fable 5.2 at High effort scored "about level with Opus 5.5 at Max effort, for roughly half the cost per task." The number that matters for a finished item depends on how many tokens the model burns getting there, which a price sheet alone will not tell you.
So two vendors, on one Monday, told customers to stop running one model for everything. Neither said where the cheap half should live or who keeps the rules. That part lands on whoever builds the agent, which is the rest of this post.
Which half of the split reads the sensitive data?
Before any routing decision, look at what each half actually touches.
The planner sees a sample. To write extraction rules for refund requests it needs the policy, a handful of example tickets, maybe the edge cases a person flagged last month. It runs a few times a day, or a few times a week when the policy changes.
The executor sees the whole queue. A support desk handling 30,000 tickets a month means the executor reads all 30,000, plus whatever it pulls in to act on them: order history, the attached screenshot, the scanned invoice, the voice memo a field rep left. Meta's own list of Ember's jobs (extraction, long document parsing, tool calls) is a list of work that requires reading the underlying data in full. The multimodal pitch sharpens it: a model that takes call recordings and signed-contract photos is reading exactly the material a confidentiality clause is written about.
So the two halves have opposite profiles. Planner: low volume, high judgment, narrow exposure. Executor: high volume, rule-following, broad exposure. When someone asks whether your agent "sends data to the cloud," the accurate answer depends on which half they mean. In most planner/executor builds, nearly all of the data flows through the executor.
That is the question to hold onto while wiring: the agent you are building will read every invoice, ticket or contract your company handles. Where should the half that reads everything run?
Will a local executor pay for itself?
Run the arithmetic before deciding, because the answer is unflattering to the local option.
Take a document-extraction job: 30,000 items a month at about 4,000 input tokens each (our assumption; scanned pages and long threads run higher). That is 120 million input tokens a month. At Ember's reported $0.10 per million, the input side costs about $12 a month. The same input on Fable 5.2 at $8 per million is about $960. Both figures leave out output tokens, retries and caching, and Ember's output price is unverified, so treat them as the input half of the bill only.
Twelve dollars a month is two coffees. A machine under the desk does not pay for itself on token savings at this scale, and a build guide that pretends otherwise is selling you something. The executor layer is now cheap to rent.
Which moves the question. If renting the executor costs almost nothing, the reasons to run it on your own hardware have to come from somewhere other than the bill. Two survive contact with the arithmetic: where the data goes, and who keeps the rules.
Where the sovereign-avatar standard points
Those two reasons have names in a framework we use for all of this. A sovereign AI avatar is an AI agent that runs on compute its owner controls, keeps its data and memory in the owner's domain, works within permissions the owner sets, and keeps a memory that survives a change of model. Two of its criteria map directly onto the two halves of the split.
Criterion one says inference runs on compute the owner controls. Applied to this design it points at the executor: the layer that reads everything, follows rules rather than improvising, and happens to be what small local-capable models are now built for. Put the executor on owned hardware and the bulk of the data stays in the building, while the planner, which sees a sample, can stay on the best hosted model you can afford.
Criterion six says memory belongs to the owner and follows the avatar, whichever model is underneath. Applied to this design it points at the rules, and the rules deserve their own section.
The planner still sees samples, so keep its view small. Three habits cover most of it. Replace names, amounts and identifiers in sample documents with placeholders that keep their format (a twelve-digit number stays twelve digits). Describe recurring edge cases in words, "some suppliers print the VAT number in the footer," instead of attaching the documents where they occur. Log every sample sent to the hosted planner, with the date and who approved it, so exposure is a list you can read instead of a guess.
How we write a rules file an executor can follow
In TechCrunch's support-desk example, the heavy model "establishes rules" and the light model applies them across tens of thousands of cases. We treat those rules as a file, in the same way the build farm treats its build file: the one artifact worth keeping when every machine around it gets swapped.
The shape matters more than the syntax. Ours look roughly like this (illustrative, trimmed):
# rules/invoice_extraction.yaml -- versioned, reviewed like code
version: 14
approved_by: finance-lead
approved_on: 2026-11-07
fields:
- name: supplier_name # string
- name: invoice_number # string
- name: invoice_date # date, must not be in the future
- name: net_amount # money
- name: vat_amount # money
- name: vat_number # string; some suppliers print it in the footer
checks:
- "net_amount + vat_amount == gross_amount" # to the cent
- "invoice_date <= today"
on_check_failure: route_to_human # never guess
A page or two covers a task category. Every line usually stands for a mistake someone caught once, which is why it is the piece of work a team least wants to redo.
Three handling habits make the file an asset instead of a liability. Keep it as text the team can read, review and diff, one file per task category. Version it like code, so a planner revision shows up as a diff a person approves. Store it with the agent's memory, outside any single vendor account, so a new executor or a new planner reads the same file.
One more column earns its place: where each rule came from. A comment like # source: ticket 4812, 2026-09 next to the footer-VAT rule tells the next maintainer the line is load-bearing and which case breaks if it goes. Planners propose rules, people approve them, and the file remembers why.
Where the file lives decides how free you are later. Rules that exist only inside one vendor's orchestration product, generated by the planner and fed to the executor without ever becoming a file you hold, mean that swapping the executor regenerates them and swapping the planner means hoping for compatible output. Rules that live as plain versioned files next to the agent carry over unchanged through either swap. That is agent memory ownership applied to one team: context that lives with the avatar survives a model change, and context that lives inside a tool leaves with the tool.
The file also makes debugging honest. When a baseline run fails, you can tell whether the rule was wrong or the executor misread a correct rule, because the rule sits there in plain text. Inside a vendor's orchestration layer, those two failures look identical.
How we route tasks without a silent cloud fallback
Routing starts with task categories, not models. For each category, three facts decide placement: items per month, data sensitivity, and how open-ended the task is. The table below is illustrative; the rows are typical of a small professional-services firm.
Before moving a category local, check throughput. The invoice row is 30,000 items a month, about 1,000 a day. At 20 seconds per invoice end to end (an assumption; measure on your own documents and hardware) that is about 5.6 hours of work a day, which fits overnight with room to spare. At 60 seconds it becomes about 17 hours a day, and the box has no headroom left for anything else. The acceptance run below gives you the real seconds-per-item figure, and that figure decides whether one machine is enough.
The last column is the one frameworks get wrong by default. The classic failure in multi-model agents is the silent fallback: the local executor times out, the harness retries on a hosted model without telling anyone, and 30,000 sensitive documents leave the building over a weekend because a GPU driver crashed. If a category is local for data reasons, its failure policy is "queue and wait" or "hold for a person," never "try the cloud."
Here is that policy as code. It is not tied to any product's API; it is the logic we want in whatever harness runs the agent:
from dataclasses import dataclass
@dataclass
class Route:
executor: str # "local" or a hosted model name
on_failure: str # "queue", "hold", or "retry_hosted"
ROUTES = {
"invoice_extraction": Route("local", "queue"),
"ticket_triage": Route("local", "queue"),
"contract_compare": Route("local", "hold"),
"web_research": Route("hosted-mid", "retry_hosted"),
}
class ExecutorUnavailable(Exception):
pass
def run(task_category, item, executors, queue, review):
route = ROUTES[task_category]
try:
return executors[route.executor](item)
except ExecutorUnavailable:
if route.on_failure == "queue":
queue.put((task_category, item)) # data stays put
return None
if route.on_failure == "hold":
review.put((task_category, item)) # a person decides
return None
if route.on_failure == "retry_hosted":
return executors["hosted-backup"](item)
raise
Two details are deliberate. The failure policy hangs on the task category, not the model, so changing a category's executor never changes what happens when it breaks. And there is no default branch that sends work to a hosted model; a category opts into that explicitly, in a diff someone reviews.
A queue policy needs one more piece to be safe: visibility. Work that waits silently is work that disappears. Whatever runs the queue should expose its depth, and someone should get a message when the oldest item passes an age threshold, say four hours during business hours. The failure this prevents is mundane. The box went down on Friday, the queue ate the weekend's invoices, and nobody noticed until a supplier called about a late payment. An alert on queue age turns that into a Monday-morning task instead of an apology.
How we accept an executor before it goes live
A cheap executor is only cheap when it gets the job right, and benchmark scores say little about whether a model pulls the right VAT number from your suppliers' scanned invoices. Each category gets its own acceptance run against a baseline, and the baseline is 50 recent items with human-checked outputs.
The run itself is mechanical. In pseudocode, because the harness varies:
# 50 recent items with human-checked outputs live in golden/
run-agent --rules rules/invoice_extraction.yaml \
--input golden/items/ --output candidate/
compare-fields golden/expected/ candidate/ \
--report acceptance-2026-11.md # match rate, tool calls, retries, cost/item
Compare field by field: for extraction, the share of fields that match exactly; for triage, the share of tickets landing in the same queue; for comparisons, the share of clauses a reviewer agrees with. Count tool calls and retries per item, because a model that loops costs more than its price suggests. Measure cost per item on the same set, with token assumptions written down.
The composition of those 50 items decides what the test can see. Pull them from the live queue and keep the mix honest: clean typed invoices, bad scans, the supplier who prints the VAT number in the footer. Refresh a third of the set every quarter so it tracks what the queue looks like now. Items the executor once failed on stay in the set permanently; they are the regression suite. The report from each run records four numbers per category, match rate, tool calls per item, retries per item, cost per item, along with the model version and the rules file version the run used. Having both versions on one line is what keeps the next argument short.
Set the bar before the run. "No new errors on items the current executor gets right" is our default for extraction; drafting can be looser. Write the result and the date next to the routing table, so that six months on, anyone can see why invoices run where they run.
When the local executor misses the bar, two options are defensible. Keep the category on a hosted executor and accept where the data goes, in writing. Or split the category again: the local model handles the items it passes (clean, typed invoices), and only items failing a check go to a person, or to a hosted model with per-batch approval. That keeps most of the volume local and makes the exceptions explicit. Lowering the bar until the local model passes, without saying so, is the one move that costs you the whole point of the test.
Rerun the acceptance whenever either model changes. A new planner writes rules that read differently; a new executor follows the same rules differently. The baseline makes both visible.
When the hosted executor is the better call
A local executor wins when:
the category reads client data, personal data or anything under a confidentiality clause
volume is steady and high, so the machine stays busy
the task is well specified and a smaller model passes the baseline
work has to continue through an internet outage
the failure policy you want is "wait," never "send it somewhere else"
A hosted executor wins when:the data is public or already published
volume is low or spiky, so a machine would sit idle
the task needs a capability local models lack, such as reading poor scans reliably, and the hosted model passes where the local one fails
at prices like Ember's input rate, the monthly bill is smaller than the time cost of maintaining a machine
nobody on the team wants to own patches and uptime for another box
What this wiring fixes, and what it leaves open
The split plus an owned rules file addresses two risks. Data concentration risk drops, because the layer that reads everything can sit on hardware the owner controls while only redacted samples reach the hosted planner. Executor lock-in drops, because a rules file the team holds lets either model be replaced without starting over.
Everything else stays where it was. Planner quality risk remains: a bad rule from the hosted planner gets applied 30,000 times by a faithful executor, so rule changes need human review. The capability gap remains: on the hardest inputs, hosted frontier models still beat anything that fits in an office machine, and the acceptance run is how you find out which categories that affects. Running your own executor adds the operational work a hosted API hides, patches and disks and locked-down remote access. And redacting samples before they reach the planner is a separate job this design does not do for you.
How KarmaBox runs the split
Our own product, KarmaBox, is built around this split. It is a device with 128 GB of unified memory that sits in the owner's office and hosts a team of avatars, and it maps onto the guide above in four places.
Models route per task: routine, high-volume work goes to local models on the device, where it carries no per-token cost, and harder tasks go to a hosted frontier model. That is the routing table expressed as a per-avatar choice, and multi-model routing is the mechanism behind it.
Device mode is the no-silent-fallback policy as a setting: every model and tool call goes to the on-device model, and if that model is unavailable the call fails instead of falling back to the cloud. An owner who wants invoice extraction to stay local sets that avatar to device mode and lets the research avatar use cloud models.
Memory follows the avatar, so a rules file kept with the avatar survives a change of either model, across cloud models, local models and the owner's own GPU. On the hardest problems a hosted frontier model is still ahead, which is why the planner side often stays in the cloud.
If you wire your own agents this way, which task category moves to a local executor first, and what is its failure policy?
Sources
TechCrunch, Russell Brandom, "Meta releases Muse Ember, a new lightweight model for agent execution," November 9, 2026.
Anthropic, "Introducing Claude Fable 5.2 and Claude Mythos 5.2," November 9, 2026.
Top comments (0)