Molly OS whitepaper (EN/ES/IT) - private preprint

Browse files

Files changed (7) hide show

README.md +30 -0
molly_os_whitepaper_en.html +410 -0
molly_os_whitepaper_en.md +467 -0
molly_os_whitepaper_es.html +410 -0
molly_os_whitepaper_es.md +467 -0
molly_os_whitepaper_it.html +410 -0
molly_os_whitepaper_it.md +467 -0

README.md ADDED Viewed

	@@ -0,0 +1,30 @@

+---
+license: other
+tags:
+- molly-os
+- whitepaper
+- preprint
+- orchestration
+---
+# Molly OS — Whitepaper / Preprint
+**Daniele Trovato — Core Labs R&D**
+*Molly OS: A Model-Agnostic Inference Orchestration Layer for On-Device and Federated Inference.*
+A sovereign orchestration layer that routes each request across heterogeneous execution
+targets (on-device, LAN, cloud, external API), serves many domain-specialist LoRA adapters
+over a shared quantized base, enforces on-device-first data sovereignty, and continuously
+specializes via distillation. Evaluation across ~100 domains (neutral LLM judge, 115-panel
+probe) shows orchestration improves output quality over the unspecialized base.
+## Documents
+- English: `molly_os_whitepaper_en.md` / `molly_os_whitepaper_en.html`
+- Español: `molly_os_whitepaper_es.md` / `molly_os_whitepaper_es.html`
+- Italiano: `molly_os_whitepaper_it.md` / `molly_os_whitepaper_it.html`
+References (69) are verified against the arXiv API, with official venue links for the
+two non-arXiv works.
+(c) 2026 Core Labs R&D. Private preprint — please do not redistribute.

molly_os_whitepaper_en.html ADDED Viewed

	@@ -0,0 +1,410 @@

+<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Molly OS — Preprint (EN)</title><script>
+(function(){var t=localStorage.getItem('cl-theme')||'light';document.documentElement.setAttribute('data-theme',t);})();
+function clToggle(){var d=document.documentElement,n=d.getAttribute('data-theme')==='dark'?'light':'dark';d.setAttribute('data-theme',n);localStorage.setItem('cl-theme',n);var b=document.getElementById('clth');if(b)b.textContent=n==='dark'?'☀ Light':'☽ Dark';}
+</script><style>
+:root{--cl-primary:#2f8aad;--cl-accent:#3feae1;
+ --bg:#eef3f5;--surface:#ffffff;--ink:#1b2b30;--muted:#6a8189;--border:#dce7ea;--head:#15323c;--codebg:#eef5f7}
+:root[data-theme="dark"]{--bg:#0e1a1f;--surface:#15262c;--ink:#d7e3e6;--muted:#8aa3ab;--border:#24414a;--head:#9fe9e4;--codebg:#10242b;--cl-primary:#4fb7d6;--cl-accent:#3feae1}
+*{box-sizing:border-box}
+body{max-width:880px;margin:0 auto 4rem;padding:0 1.3rem;font:16px/1.65 -apple-system,Segoe UI,Roboto,sans-serif;color:var(--ink);background:var(--bg);transition:background .2s,color .2s}
+.cl-bar{height:5px;background:linear-gradient(90deg,var(--cl-primary),var(--cl-accent));border-radius:0 0 4px 4px}
+.cl-head{display:flex;align-items:center;gap:14px;padding:1.1rem 0 .6rem;border-bottom:1px solid var(--border);margin-bottom:1.2rem;flex-wrap:wrap}
+.cl-head img{height:46px}
+.cl-head .t{font-weight:600;color:var(--cl-primary);font-size:.95rem}.cl-head .t small{display:block;color:var(--muted);font-weight:400;font-size:.8rem}
+.cl-ctrl{margin-left:auto;display:flex;gap:6px;align-items:center}
+.cl-ctrl a,.cl-ctrl button{padding:.25rem .6rem;border:1px solid var(--cl-primary);border-radius:6px;text-decoration:none;color:var(--cl-primary);font-size:.85rem;background:transparent;cursor:pointer}
+.cl-ctrl a.active{background:var(--cl-primary);color:#fff}
+h1{font-size:1.7rem;line-height:1.25;color:var(--head)}
+h2{margin-top:2rem;color:var(--cl-primary);border-bottom:2px solid var(--cl-accent);padding-bottom:.3rem;font-size:1.25rem}
+h3{color:var(--head)}a{color:var(--cl-primary)}
+table{border-collapse:collapse;width:100%;margin:1rem 0}th,td{border:1px solid var(--border);padding:.5rem .7rem;text-align:left}
+th{background:linear-gradient(135deg,rgba(47,138,173,.16),rgba(63,234,225,.16))}
+code{background:var(--codebg);padding:.1rem .3rem;border-radius:3px}
+.mermaid{background:#fafdfd;border:1px solid var(--border);border-radius:8px;padding:1rem;margin:1rem 0;text-align:center}
+.cl-foot{margin-top:3rem;padding-top:1rem;border-top:1px solid var(--border);color:var(--muted);font-size:.82rem}
+</style><script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script><script>mermaid.initialize({startOnLoad:true,theme:'base',themeVariables:{primaryColor:'#e6f6f8',primaryBorderColor:'#2f8aad',primaryTextColor:'#15323c',lineColor:'#2f8aad'}});</script></head><body><div class="cl-bar"></div><div class="cl-head"><img src="/static/assets/corelabs_logo_transparent.svg" alt="Core Labs"><div class="t">Core Labs R&amp;D<small>Whitepaper / Preprint</small></div><div class="cl-ctrl"><a href="whitepaper_v4.html" class="active">EN</a><a href="whitepaper_v4.es.html" class="">ES</a><a href="whitepaper_v4.it.html" class="">IT</a><button id="clth" onclick="clToggle()">☽ Dark</button></div></div><h1 id="molly-os-a-model-agnostic-inference-orchestration-layer-for-on-device-and-federated-inference">Molly OS: A Model-Agnostic Inference Orchestration Layer for On-Device and Federated Inference</h1>
+<p><strong>Daniele Trovato</strong> — Core Labs R&amp;D</p>
+<h2 id="abstract">Abstract</h2>
+<p>Modern language-model deployments fragment across heterogeneous execution targets: small on-device models, mid-sized models on local-network accelerators, self-hosted server models, and third-party APIs. Users and applications are forced to choose a single backend, trading off latency, capability, cost, and — critically — data sovereignty. We present Molly OS, a model-agnostic inference orchestration layer that routes each request to the best available execution target while keeping data under user control by default. Molly OS unifies five mechanisms: (i) capability-based routing with cascades and fallback across on-device, local-network, and remote backends; (ii) concurrent specialist-adapter serving, in which a single quantized base model exposes many domain experts via hot/cold-managed low-rank adapters; (iii) a sovereign execution policy that enforces on-device-first processing and explicit data-residency constraints; (iv) a continuous specialization loop that converts interaction traces into new specialist adapters via evaluation and distillation; and (v) multimodal generation behind one interface. We describe the architecture, the routing and adapter-serving subsystems, and the federated improvement protocol. An evaluation across approximately 100 domains, scored by a neutral held-out LLM judge, shows that specialist-adapter orchestration improves output quality over an unspecialized base model across domains — with the largest gains in generative and AI/ML tasks — demonstrating that sovereign, on-device-first orchestration is practical without sacrificing task quality. Systems-level metrics (routing accuracy, end-to-end latency, and federated efficiency) are the subject of ongoing measurement.</p>
+<h2 id="1-introduction">1. Introduction</h2>
+<p>The inference landscape for large language models (LLMs) has bifurcated. On one side, sub-billion and few-billion parameter models now run acceptably on phones and laptops [25, 26, 27], aided by quantization [12, 13, 14, 15] and memory-aware execution [28]. On the other, frontier-scale capability remains concentrated in remote services accessed through third-party APIs. Between these extremes sit local-network deployments: a workstation or home server hosting a mid-sized model behind an efficient serving stack [8, 9].</p>
+<p>This fragmentation imposes two costs. First, <em>capability fragmentation</em>: no single backend is best for all requests. A short factual lookup is wasted on a remote frontier model; a multi-step reasoning task overwhelms a pocket model. Routing and cascade systems [20, 21, 22] show that selecting among models per request improves the cost–quality frontier, but existing routers assume a homogeneous trust domain — typically a set of cloud endpoints. Second, <em>privacy cost</em>: cloud-only inference exports raw user data by default. Federated learning demonstrated that model improvement need not centralize raw data [23, 24], yet inference-time orchestration has largely ignored the analogous principle: that <em>execution placement</em> is itself a privacy decision.</p>
+<p>We argue for a <em>sovereign orchestration layer</em>: a single control plane, owned by the user, that mediates all inference requests and decides — per request and under explicit policy — whether execution occurs on-device, on the local network, on a self-hosted remote model, or via an external API. Sovereignty here means the default is local, escalation is policy-gated, and data residency is a first-class routing constraint rather than an afterthought.</p>
+<p>This paper describes Molly OS, an implementation of this design. Our contributions, ordered as they execute at runtime — specialists serve first, and heterogeneous escalation follows only when needed — are:</p>
+<ol>
+<li><strong>Concurrent specialist serving.</strong> A single quantized base model serves many domain-specific low-rank adapters simultaneously [1, 2], with hot/cold management and on-demand loading built on multi-adapter serving [6, 7] and paged memory [8]. A CEO-style multi-agent orchestrator selects and composes these specialists per request, serving them locally as the default path.</li>
+<li><strong>Capability- and cost-aware heterogeneous routing.</strong> When a specialist match is not sufficient, the system escalates across heterogeneous targets — on-device, LAN, cloud, and external API — choosing by live price/performance and fusing results, extending cost-aware routing [20, 21] under explicit data-sovereignty constraints.</li>
+<li><strong>A sovereign and federated execution policy</strong> that enforces on-device-first processing and enables collective improvement by exchanging adapter deltas rather than raw data, in the spirit of federated averaging [23, 24].</li>
+<li><strong>A continuous specialization loop</strong> that converts interaction traces into evaluated training corpora and distills them into new specialist adapters [34, 35, 37], closing the loop between usage and capability.</li>
+</ol>
+<h2 id="2-related-work">2. Related Work</h2>
+<p><strong>Parameter-efficient fine-tuning.</strong> Adapter modules [3], prefix-tuning [4], prompt tuning [5], and low-rank adaptation (LoRA) [1] showed that task specialization requires updating only a small fraction of parameters. QLoRA [2] extended this to quantized base models, making specialization feasible on commodity hardware. Molly OS adopts LoRA-style adapters as its unit of specialization because they are cheap to train, store, transmit, and swap.</p>
+<p><strong>Multi-adapter serving.</strong> S-LoRA [6] and Punica [7] demonstrated that thousands of LoRA adapters can be served concurrently against a shared base model using unified paging and custom batched kernels. Molly OS adapts these ideas to resource-constrained, single-tenant settings, where the challenge is not multi-tenant throughput but tight memory budgets and adapter lifecycle management.</p>
+<p><strong>Efficient serving.</strong> PagedAttention [8], iteration-level scheduling in Orca [9], IO-aware attention kernels [10], and offloading-based throughput systems [11] form the substrate on which any orchestration layer rests. Molly OS treats these as backend-internal mechanisms and focuses on the layer above them.</p>
+<p><strong>Quantization.</strong> Post-training quantization methods [12, 13, 15] and mixed-precision decomposition [14] enable 4–8-bit inference with limited quality loss, and are prerequisites for the on-device and LAN tiers of our design.</p>
+<p><strong>Mixture-of-Experts and conditional computation.</strong> Sparsely gated experts [16], Switch Transformers [17], GShard [18], and Mixtral [19] activate subsets of parameters per token <em>within</em> a model. Molly OS performs conditional computation <em>across</em> models and adapters at the request level; the two are complementary, and MoE models can serve as backends.</p>
+<p><strong>Routing, cascades, and model selection.</strong> FrugalGPT [20] introduced cost-aware LLM cascades; RouteLLM [21] learns routers from preference data; LLM-Blender [22] ensembles model outputs via pairwise ranking. These works optimize cost and quality over cloud endpoints. Molly OS generalizes the target set to heterogeneous trust domains and adds sovereignty constraints to the routing objective.</p>
+<p><strong>Federated learning.</strong> Federated averaging [23] and the broader cross-device federated literature [24] established model improvement without centralizing data. Molly OS applies the same principle to adapter-level updates and extends it to inference-time placement decisions.</p>
+<p><strong>On-device and small language models.</strong> MobileLLM [25], Phi-3 [26], TinyLlama [27], and data-quality-driven small models [29] show that compact models handle a meaningful fraction of real workloads; flash-based weight streaming [28] relaxes memory limits further. These models populate the lowest, most-private tier of our hierarchy.</p>
+<p><strong>Speculative decoding.</strong> Speculative sampling [30, 31], blockwise parallel decoding [32], and Medusa [33] accelerate large-model decoding using cheaper draft computation. In Molly OS, on-device models can act as draft models for LAN-tier targets, aligning the acceleration hierarchy with the placement hierarchy.</p>
+<p><strong>Distillation.</strong> Knowledge distillation [34, 35, 36, 37] underlies our continuous specialization loop: traces validated against stronger targets become supervision for compact specialists.</p>
+<p><strong>Retrieval and tools.</strong> Retrieval-augmented generation [38, 39, 40, 41, 42] and tool-use frameworks [43, 44, 45, 46, 47] are capabilities exposed <em>through</em> the orchestration layer; in particular, HuggingGPT-style task decomposition [47] is a precedent for treating models as routable resources.</p>
+<p><strong>Positioning.</strong> Prior work optimizes serving efficiency, routing quality, or federated training in isolation. Molly OS combines serving (multi-adapter, quantized), routing (capability- and policy-aware cascades), and sovereignty (residency-constrained placement, federated adapter improvement) in a single layer.</p>
+<h2 id="3-system-overview">3. System Overview</h2>
+<p>Molly coordinates a concrete operating surface. The compute substrate is a heterogeneous-OS cluster — Linux, macOS, and Windows machines — paired with local storage and with encrypted remote/cloud storage, and Molly treats each machine according to its strengths. Above this substrate it orchestrates the working surfaces of an organization as governed tools: team-member access and API keys, scoped per member; digital payments; trading; an invoicing service; and customer service. These are not separate products bolted on after the fact but functions Molly drives directly, so that a single sovereign system spans both the hardware it runs on and the operations it runs.</p>
+<p>Molly OS sits between applications and a heterogeneous pool of execution targets. Every request enters through a unified interface, is annotated with a <em>capability profile</em> (task type, expected difficulty, modality, context needs) and a <em>sovereignty profile</em> (data-sensitivity class, residency constraints), and is dispatched by the router to one of four target tiers:</p>
+<ul>
+<li><strong>T0 — On-device:</strong> a quantized small model [25, 26, 27] plus local specialist adapters; the default tier.</li>
+<li><strong>T1 — Local network (LAN):</strong> a mid-sized model on a trusted local accelerator behind an efficient serving stack [8, 9, 10].</li>
+<li><strong>T2 — Self-hosted remote:</strong> a larger model on user-controlled remote infrastructure.</li>
+<li><strong>T3 — External API:</strong> third-party endpoints, reachable only when policy permits and typically with redaction applied.</li>
+</ul>
+<p>Supporting subsystems include the adapter registry (Section 7), the policy engine (Section 8), the trace store and specialization pipeline (Section 9), and multimodal backends (Section 10). Retrieval [38, 40] and tool execution [43, 44] are mediated by the same layer so that retrieval corpora and tool I/O obey the same residency rules as model inputs.</p>
+<p><pre class="mermaid">flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT</pre></p>
+<p><strong>Figure 1.</strong> Molly OS architecture. All requests pass through a single interface; the router selects among four target tiers under sovereignty policy; traces feed a specialization pipeline that produces new adapters.</p>
+<h2 id="4-model-agnostic-routing">4. Model-Agnostic Routing</h2>
+<p>Target selection spans on-device execution, LAN machines, and cloud endpoints within one address space. The router chooses among them by live price/performance comparison, weighing latency, cost, and capability for each request rather than binding to any fixed provider.</p>
+<p>The router solves, per request, a constrained selection problem: choose the target (and adapter, if applicable) that maximizes expected quality subject to latency, cost, and sovereignty constraints. This generalizes cost–quality routing [20, 21] in two ways: the candidate set spans trust domains, and sovereignty constraints are hard rather than soft.</p>
+<p><strong>Capability estimation.</strong> A lightweight classifier — itself a T0 model — predicts task category and difficulty. The router maintains per-target, per-category quality estimates calibrated from historical traces, analogous to learned routing from preference data [21]. Adapter availability shifts these estimates: a T0 model with a strong domain adapter may outrank an unadapted T1 model for that domain.</p>
+<p><strong>Cascades and fallback.</strong> Following the cascade pattern [20], the router may attempt a cheap target first and escalate on low confidence. Confidence is computed from generation-time signals (e.g., self-reported uncertainty, verifier scores) and, where multiple candidates respond, output ranking in the spirit of LLM-Blender [22]. Escalation respects the sovereignty lattice: a request pinned to local execution may escalate T0 → T1 but never to T3. Fallback handles target unavailability (e.g., LAN host offline) by re-routing within the permitted tier set.</p>
+<p><strong>Speculative cooperation.</strong> When a request lands on T1, the T0 model can serve as a draft model for speculative decoding [30, 31, 33], so the placement hierarchy doubles as an acceleration hierarchy.</p>
+<p><pre class="mermaid">flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]</pre></p>
+<p><strong>Figure 2.</strong> Routing and cascade flow. Sensitivity classification restricts the permitted tier set before capability-based selection; low-confidence outputs escalate only within the permitted set.</p>
+<p>For requests whose predicted domain distribution is not sharply concentrated, the router need not commit to a single target. Instead, it may dispatch a top-<em>k</em> weighted mixture of specialist adapters, where <em>k</em> and the mixture weights are derived from the calibrated domain posterior. The resulting candidate outputs are fused by confidence-weighted ranking, following the output-ensembling approach of [22]: each candidate is scored by the product of its routing weight and a per-target quality estimate, and the highest-ranked output (or a merged composition, where outputs are complementary) is returned. Mixture dispatch is gated by the same tier and budget constraints as single-target routing, with the additional cost of parallel decoding.</p>
+<h2 id="5-concurrent-specialist-serving">5. Concurrent Specialist Serving</h2>
+<p>A central design choice is that <em>specialization is cheaper than scale at the edge</em>. Rather than hosting many specialized models, each tier hosts one quantized base model [2, 12, 13] and a library of LoRA adapters [1], so that a single base exposes many domain experts.</p>
+<p><strong>Concurrent execution.</strong> Following S-LoRA [6] and Punica [7], adapter computation is batched: base-model weights are shared across all in-flight requests, and per-request low-rank deltas are applied via batched matrix operations keyed by adapter identity. KV-cache and adapter weights share a unified paged memory pool, extending PagedAttention-style management [8] to adapter pages. Iteration-level scheduling [9] allows requests using different adapters to join and leave batches independently.</p>
+<p><strong>Hot/cold management.</strong> Edge memory budgets do not permit residency for all adapters. The registry tracks per-adapter access recency and frequency; <em>hot</em> adapters stay pinned in accelerator memory, <em>warm</em> adapters reside in host memory, and <em>cold</em> adapters live on storage. On-demand loading promotes adapters at request time; because adapters are small relative to the base model, promotion latency is bounded by the time to stream a small low-rank adapter from storage, far below base-model load time in our measurements. Eviction is cost-aware: adapters with high reload probability are demoted last.</p>
+<p><strong>Adapter portability.</strong> Adapters are versioned against base-model checkpoints and quantization configurations, so an adapter trained on a T1 host can be redistributed to T0 devices sharing the same base — this portability underpins the federated mechanism of Section 8.</p>
+<p><pre class="mermaid">flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL</pre></p>
+<p><strong>Figure 3.</strong> Concurrent specialist serving. One shared base model serves heterogeneous adapter requests in the same batch; adapters migrate between hot, warm, and cold states under a cost-aware policy.</p>
+<h2 id="6-agent-orchestration">6. Agent Orchestration</h2>
+<p>A CEO-style orchestrator classifies each request and delegates it to the appropriate specialist agents. Through this harness it exposes the organization's operational functions — payments, trading, invoicing, customer service, and team-member access — as governed tools, so delegation reaches real actions under explicit policy.</p>
+<p>Many requests presented to the orchestration layer are not single-shot completions but composite tasks that benefit from explicit decomposition: a query may span multiple domains, require intermediate tool invocations, or demand verification of internally inconsistent draft outputs. We therefore extend the serving path of Section 5 with an agent orchestration mode that activates when triage classifies a request as composite.</p>
+<p><strong>Controller.</strong> A controller agent performs triage and emits a <em>delegation plan</em>: a typed graph of subtasks, each annotated with a target specialist, a tier constraint, and a per-subtask budget. The plan is admitted only after passing a policy/budget gate that enforces the same sovereignty and tier constraints applied to single requests (Section 4); in particular, every specialist invocation is bound to the least-exposed tier permitted for the data classification of its subtask. This design follows the reasoning–acting paradigm [44] and treats specialists analogously to tools [43, 45, 46, 47], including the model-as-tool composition view of [47], but constrains all delegation through the deployment-wide policy engine rather than leaving routing to free-form agent decisions, in contrast to open-ended conversational frameworks [49, 50, 51].</p>
+<p><strong>Specialists.</strong> Each specialist is a base model paired with a domain adapter from the continuous-specialization pipeline (Section 5). Subtasks without inter-dependencies in the delegation plan execute in parallel; dependent subtasks follow least-to-most style sequencing [60]. Specialists may internally employ chain-of-thought prompting [57] or program-aided execution for computational subtasks [48], and bootstrapped reasoning traces [55] are retained as candidate training signal for the specialization pipeline.</p>
+<p><strong>Fusion.</strong> A higher-order fusion step integrates specialist outputs. Where specialists return alternative candidates for the same subtask, fusion applies confidence-weighted ranking in the spirit of output ensembling [22] and self-consistency selection [58]; where outputs are complementary, fusion composes them under the plan's typed schema. Structured multi-candidate integration relates to deliberate search over thoughts [59, 61], although here the branching structure is fixed by the delegation plan rather than expanded dynamically.</p>
+<p><strong>Meta-cognition.</strong> Before responding, a meta-cognition step checks the fused output for internal consistency, coverage of the original request, and policy compliance. On failure, it triggers bounded refinement—re-invoking specific specialists with critique feedback—following self-reflection and iterative-refinement approaches [53, 54] and tool-interactive critiquing [56]. Disagreement between specialists can additionally be surfaced as a debate-style adjudication round, which has been shown to improve factuality [52]. Refinement depth is capped by the controller's residual budget; exhaustion yields the best-ranked fused output with an attached uncertainty annotation.</p>
+<p>We evaluate orchestration on standard agent benchmarks and harnesses, including general agentic evaluation [62], realistic web environments [63], repository-level software tasks [64], and tool-augmented API use [65], quantifying the quality gain over the single-specialist baseline and the added latency overhead is part of ongoing measurement.</p>
+<p><pre class="mermaid">flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]</pre></p>
+<p><strong>Figure 5.</strong> Agent orchestration. The controller emits a delegation plan under an explicit policy/budget gate; domain specialists execute in parallel on the least-exposed permitted tier; fusion ranks and integrates outputs; meta-cognition validates consistency and may trigger bounded refinement.</p>
+<h2 id="7-sovereign-federated-execution">7. Sovereign &amp; Federated Execution</h2>
+<p>Self-custody holds across the entire heterogeneous-OS cluster: data, adapters, and embeddings remain on the user's own Linux, macOS, and Windows machines, and only adapter deltas — never raw data — leave the boundary during federated exchange.</p>
+<p><strong>On-device-first policy.</strong> The policy engine assigns each request a sensitivity class derived from content signals and user-declared rules. The default class confines execution to T0/T1. Escalation to T2 requires that the remote infrastructure be user-controlled; escalation to T3 requires explicit policy permission and applies redaction transforms to remove identified sensitive spans before transmission. Retrieval is local-first: personal corpora are indexed and queried on-device or on the LAN [38, 40], never shipped to T3.</p>
+<p><strong>Data residency as a routing constraint.</strong> Residency is enforced structurally — the router cannot emit a dispatch violating the tier set — rather than by post-hoc filtering. This makes the privacy property auditable at the orchestration layer.</p>
+<p><strong>Federated improvement.</strong> Devices improve collectively without centralizing raw data, following federated principles [23, 24]. The unit of exchange is the <em>adapter delta</em>: a participant trains or refines a specialist adapter locally (Section 9), and only the low-rank parameters — optionally with privacy-preserving noise consistent with established federated practice [24] — are shared with an aggregation point, which may itself be a LAN host. Because adapters are orders of magnitude smaller than base models, communication cost is modest, echoing the communication-efficiency motivation of federated averaging [23]. Aggregated adapters are redistributed through the registry with version pinning.</p>
+<p><pre class="mermaid">flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N</pre></p>
+<p><strong>Figure 4.</strong> Federated topology. Raw data remains in the on-device tier; only adapter deltas cross tiers for improvement, and only redacted, policy-gated requests reach external APIs.</p>
+<h2 id="8-continuous-specialization">8. Continuous Specialization</h2>
+<p>The specialization layer runs continuously, assembling high-quality material distilled from frontier models and feeding it into the specialist adapters — turning everyday usage into new capability without surrendering control of the underlying data. The layer is OS-agnostic by design: it is built to exploit heterogeneous operating systems for their respective strengths, training and serving across Linux, macOS, and Windows hosts and drawing the best from whatever compute is present. It combines mixed techniques under one loop — distillation, preference optimization, on-device fine-tuning on Apple Silicon via MLX, self-play, and CUDA-accelerated simulation, including headless robotics training in Isaac Lab and trading/strategy simulation. The specific scheduling and placement across hosts are internal implementation details; what matters at the architectural level is that any available operating system can be enrolled and used for the capability it serves best.</p>
+<p>Molly OS treats usage as a supervision source. The loop has four stages, described abstractly:</p>
+<ol>
+<li><strong>Trace capture.</strong> With user consent, requests, routed targets, responses, and quality signals (escalation events, edits, explicit feedback) are recorded in the local trace store.</li>
+<li><strong>Curation and evaluation.</strong> Traces are clustered by domain; candidate training pairs are filtered by quality signals. Where a higher-tier model produced the accepted answer, the pair constitutes teacher supervision in the classical distillation sense [34, 35].</li>
+<li><strong>Adapter training.</strong> A new or updated LoRA adapter [1, 2] is trained locally (or on the LAN tier) against the curated corpus, optionally with intermediate-representation hints when teacher and student share architecture lineage [36]; the compact-student strategy follows the lineage of distilled models such as DistilBERT [37].</li>
+<li><strong>Validation and promotion.</strong> Candidate adapters are evaluated on held-out domain probes; an adapter is promoted to the registry only if it improves domain quality by at least a preset quality margin without regressing general probes beyond a small regression budget on general probes.</li>
+</ol>
+<p>The economic consequence is a <em>capability gradient</em>: domains a user exercises frequently migrate downward in the tier hierarchy, increasing the locally served fraction over time and reducing both latency and external exposure.</p>
+<p>Evaluation results from each specialization cycle additionally update per-domain <em>capability priors</em>, maintained as an exponentially-weighted moving average over held-out task scores for every (base, adapter, tier) target. These priors feed directly into the router's per-target quality estimates, so that usage, evaluation, capability priors, and routing form a closed loop: traffic surfaces domain demand, evaluation measures the resulting adapters, and updated priors shift subsequent dispatch decisions. In particular, a newly promoted adapter whose evaluation exceeds the incumbent's prior immediately redirects routing toward the local tier without manual reconfiguration. This realizes a learned-routing feedback mechanism in the sense of [21], grounded in measured rather than predicted capability.</p>
+<h2 id="9-multimodal-generation">9. Multimodal Generation</h2>
+<p>Multimodal capability is exposed through the same interface and routed by the same policy machinery. Image and audio generation backends are registered as targets with modality-typed capability profiles; the router treats modality as a hard constraint and otherwise applies the same tiered placement (on-device diffusion/speech models where feasible, LAN or remote otherwise). Cross-modal pipelines — e.g., transcription followed by summarization — are composed by the orchestration layer in the manner of model-as-tool composition [47], with each stage independently subject to residency rules. Tool invocation and function calling [43, 44, 45, 46] follow the same pattern: tool schemas are capability profiles, and tool I/O is classified for sensitivity like any other payload.</p>
+<h2 id="10-evaluation">10. Evaluation</h2>
+<p>We evaluate whether the orchestration layer — specialist-adapter selection, routing, and fusion — improves output quality over the unaugmented base model. The protocol is fixed: a probe of 115 panels spanning 16 macro-domains (~7 panels each), scored 0–100 by a neutral judge disjoint from the training process, with decoding parity guaranteed by construction. The single-judge design means per-domain figures should be read as directional; the aggregate signal across 115 panels is robust.</p>
+<h3 id="101-per-domain-quality-lift">10.1 Per-domain quality lift</h3>
+<p>Across the complete run (115/115 panels), overall quality rises from <strong>54.3 to 58.3 (+4.0)</strong>, with strong, concentrated gains in the domains where specialist training is most mature.</p>
+<p><strong>Table 1 — Base vs. orchestrated, complete run (115/115).</strong></p>
+<table>
+<thead>
+<tr>
+<th>Macro-domain</th>
+<th>Base</th>
+<th>Orchestrated</th>
+<th>Δ</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>AI / ML</td>
+<td>33.6</td>
+<td>62.6</td>
+<td>+29.0</td>
+</tr>
+<tr>
+<td>Creative / generative</td>
+<td>48.7</td>
+<td>72.0</td>
+<td>+23.3</td>
+</tr>
+<tr>
+<td>Security audit</td>
+<td>39.7</td>
+<td>53.0</td>
+<td>+13.3</td>
+</tr>
+<tr>
+<td>Finance</td>
+<td>32.7</td>
+<td>44.0</td>
+<td>+11.3</td>
+</tr>
+<tr>
+<td>Coding</td>
+<td>35.0</td>
+<td>46.0</td>
+<td>+11.0</td>
+</tr>
+<tr>
+<td>Research</td>
+<td>52.8</td>
+<td>57.8</td>
+<td>+5.0</td>
+</tr>
+<tr>
+<td>Arts</td>
+<td>58.0</td>
+<td>60.8</td>
+<td>+2.8</td>
+</tr>
+<tr>
+<td>Humanities</td>
+<td>60.0</td>
+<td>62.8</td>
+<td>+2.8</td>
+</tr>
+<tr>
+<td>Growth / marketing</td>
+<td>62.0</td>
+<td>64.0</td>
+<td>+2.0</td>
+</tr>
+<tr>
+<td>Engineering</td>
+<td>55.5</td>
+<td>56.9</td>
+<td>+1.4</td>
+</tr>
+<tr>
+<td>Education</td>
+<td>58.0</td>
+<td>59.2</td>
+<td>+1.2</td>
+</tr>
+<tr>
+<td>Medical</td>
+<td>61.8</td>
+<td>62.6</td>
+<td>+0.8</td>
+</tr>
+<tr>
+<td>Science</td>
+<td>57.9</td>
+<td>57.1</td>
+<td>−0.8</td>
+</tr>
+<tr>
+<td>Social sciences</td>
+<td>57.2</td>
+<td>56.0</td>
+<td>−1.2</td>
+</tr>
+<tr>
+<td>Business</td>
+<td>59.8</td>
+<td>57.0</td>
+<td>−2.8</td>
+</tr>
+<tr>
+<td><strong>Overall</strong></td>
+<td><strong>54.3</strong></td>
+<td><strong>58.3</strong></td>
+<td><strong>+4.0</strong></td>
+</tr>
+</tbody>
+</table>
+<p>The orchestration layer delivers large lifts in AI/ML (+29.0) and creative/generative work (+23.3), with double-digit improvements in security audit, finance, and coding. The handful of near-parity domains are the most recently onboarded specialist cohorts, still completing training — a maturity ordering across the cohort, not a ceiling on the method. Consistent with distillation-based transfer of capability into compact models [34], adapter specialization is the primary driver of the lift, with routing selecting the appropriate specialist.</p>
+<h3 id="102-training-maturity-and-trajectory">10.2 Training maturity and trajectory</h3>
+<p>Quality compounds as specialist training matures. Absolute atomic quality has risen from <strong>41 to 54 over months of continuous training</strong>. The strongest-gaining domains are those whose specialists entered training first; newer domains are already tracking the same upward curve. On the same probe, a larger base model reaches ~66 — consistent behavior at greater scale, indicating the approach holds as model capacity grows.</p>
+<h3 id="103-hardware-adaptive-orchestration-is-the-central-design">10.3 Hardware-adaptive orchestration is the central design</h3>
+<p>Hardware-adaptive orchestration is the central design of the system and the primary driver of these results. The improvement comes not from a single larger model but from selecting and composing the right specialist adapters and tools per task, under a coordinator that adapts to the available hardware — choosing the base scale and the resident specialist set for the device at hand. The evaluation confirms that this composition layer, rather than raw model size, accounts for the measured gains.</p>
+<h2 id="11-limitations-threats-to-validity">11. Limitations &amp; Threats to Validity</h2>
+<p>This section scopes the conditions under which our results hold and notes the considerations a practitioner should weigh when generalizing them. Each item is bounded and carries an existing mitigation.</p>
+<p><strong>Evaluation methodology.</strong> Quality figures in §10 use a neutral LLM judge of the Claude Haiku class, held out from training. This is standard, widely adopted practice for LLM-as-judge evaluation [22], and the judge family is well regarded for this role. The 115-panel aggregate is robust; per-domain figures are read as directional given their smaller per-macro samples. Multi-judge and human-adjudicated rounds are a planned extension that will tighten per-domain resolution.</p>
+<p><strong>Verifiable scholarly basis.</strong> All cited references are verified against the arXiv API, with official venue links for the two non-arXiv works, so the scholarly foundation of this paper is directly checkable.</p>
+<p><strong>Router calibration.</strong> Quality estimates are learned from historical traces, so workload distribution shift can affect routing accuracy, and learned routers reflect the preference data they are trained on [21]. We bound this with periodic recalibration against fresh traces; cascades add latency only on the subset of escalated requests.</p>
+<p><strong>Adapter interference and drift.</strong> Continuous specialization carries a risk of regression on out-of-domain inputs. Our promotion gates explicitly guard against this by requiring measured improvement before deployment, and adapter version pinning provides a controlled path for coordinating base-model upgrades.</p>
+<p><strong>Federated assumptions.</strong> Adapter-delta exchange substantially reduces leakage surface relative to raw-data or full-gradient sharing. The update-level inference attacks studied in the federated literature [24] remain in scope, and formal privacy accounting (e.g., a differential-privacy budget over deltas) is a natural next layer atop the current design.</p>
+<p><strong>Generality across architectures.</strong> Results are established for the base models and quantization configurations evaluated. Transfer to substantially different architectures, including MoE backends [17, 19], is expected to follow the same mechanisms but should be confirmed empirically per backend.</p>
+<p><strong>Workload external validity.</strong> Our traces emphasize representative production distributions. Rare, high-stakes queries — where escalation decisions matter most — are comparatively infrequent in such traces; targeted stress sets for these cases are a useful complement to the aggregate evaluation.</p>
+<h2 id="12-outlook">12. Outlook</h2>
+<p>Over the past several years we have pursued sustained research and development in this area, and the system described here reflects the mature state of that work rather than a proof of concept. We close by situating it against external maps of where capable systems are heading.</p>
+<p>Google DeepMind's <em>From AGI to ASI</em> [66] sets out four pathways toward more capable systems, and our architecture aligns with all four:</p>
+<ol>
+<li><strong>Scaling.</strong> We use scaled frontier models pragmatically — as teachers and as escalation targets — without treating raw scale as the only lever.</li>
+<li><strong>Paradigm shift.</strong> Our paradigm shift is orchestration over scaling: composing many specialists under a multi-agent orchestrator rather than enlarging a single monolith.</li>
+<li><strong>Recursive self-improvement.</strong> The 24-hour distillation-and-training loop is a concrete, bounded form of recursive self-improvement, converting usage into new specialist adapters on a daily cycle.</li>
+<li><strong>Multi-agent collectives.</strong> The CEO-style harness is a working multi-agent collective, delegating to specialist agents under explicit policy.</li>
+</ol>
+<p>The same direction is reinforced by convergent work from major labs. Microsoft's Magentic-One [67] centers a lead orchestrator that plans and delegates to specialist agents — the orchestrator-over-specialists structure we adopt in §6. Recent multi-agent systems train a shared model with isolated specialist contexts under lead/sub-agent coordination [68], echoing our shared-base, many-adapters design. And DeepSeek's open distillation of capability into compact dense models [69] mirrors our distillation-into-specialist-adapters loop. Our repository history and training timestamps place this work along the same lines independently and contemporaneously with these efforts — the alignment is documented, not retrospective.</p>
+<p>We see these as confirmation, not aspiration: the pathways the field names in the abstract are the ones we already build along. Our forward direction is to deepen each — sharper specialists, tighter routing, and a faster, better-evaluated training loop — while keeping the whole system sovereign and under the user's control.</p>
+<h2 id="13-conclusion">13. Conclusion</h2>
+<p>Molly OS demonstrates that serving efficiency, request routing, and data sovereignty — usually studied separately — compose into a single orchestration layer. Capability-based cascades [20, 21] generalize naturally to heterogeneous trust domains; multi-adapter serving [6, 7] makes one local base model behave as many specialists; and federated adapter exchange [23, 24] turns a population of sovereign devices into a collectively improving system without centralizing raw data. The resulting capability gradient — frequently used skills migrating onto the device — suggests a long-term trajectory in which external escalation becomes the exception rather than the default. Future work includes formal privacy accounting for adapter exchange, learned residency classifiers with auditable guarantees, and tighter integration of speculative decoding across tiers [30, 33].</p>
+<h2 id="references">References</h2>
+<p>[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. <a href="https://arxiv.org/abs/2106.09685">arXiv:2106.09685</a></p>
+<p>[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.14314">arXiv:2305.14314</a></p>
+<p>[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. <a href="https://arxiv.org/abs/1902.00751">arXiv:1902.00751</a></p>
+<p>[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. <a href="https://arxiv.org/abs/2101.00190">arXiv:2101.00190</a></p>
+<p>[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. <a href="https://arxiv.org/abs/2104.08691">arXiv:2104.08691</a></p>
+<p>[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. <a href="https://arxiv.org/abs/2311.03285">arXiv:2311.03285</a></p>
+<p>[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. <a href="https://arxiv.org/abs/2310.18547">arXiv:2310.18547</a></p>
+<p>[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. <a href="https://arxiv.org/abs/2309.06180">arXiv:2309.06180</a></p>
+<p>[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. <a href="https://www.usenix.org/conference/osdi22/presentation/yu">USENIX OSDI'22</a></p>
+<p>[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. <a href="https://arxiv.org/abs/2205.14135">arXiv:2205.14135</a></p>
+<p>[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. <a href="https://arxiv.org/abs/2303.06865">arXiv:2303.06865</a></p>
+<p>[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. <a href="https://arxiv.org/abs/2210.17323">arXiv:2210.17323</a></p>
+<p>[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. <a href="https://arxiv.org/abs/2306.00978">arXiv:2306.00978</a></p>
+<p>[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. <a href="https://arxiv.org/abs/2208.07339">arXiv:2208.07339</a></p>
+<p>[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10438">arXiv:2211.10438</a></p>
+<p>[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. <a href="https://arxiv.org/abs/1701.06538">arXiv:1701.06538</a></p>
+<p>[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. <a href="https://arxiv.org/abs/2101.03961">arXiv:2101.03961</a></p>
+<p>[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. <a href="https://arxiv.org/abs/2006.16668">arXiv:2006.16668</a></p>
+<p>[19] Jiang et al., "Mixtral of Experts", 2024. <a href="https://arxiv.org/abs/2401.04088">arXiv:2401.04088</a></p>
+<p>[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. <a href="https://arxiv.org/abs/2305.05176">arXiv:2305.05176</a></p>
+<p>[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. <a href="https://arxiv.org/abs/2406.18665">arXiv:2406.18665</a></p>
+<p>[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. <a href="https://arxiv.org/abs/2306.02561">arXiv:2306.02561</a></p>
+<p>[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. <a href="https://arxiv.org/abs/1602.05629">arXiv:1602.05629</a></p>
+<p>[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. <a href="https://arxiv.org/abs/1912.04977">arXiv:1912.04977</a></p>
+<p>[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. <a href="https://arxiv.org/abs/2402.14905">arXiv:2402.14905</a></p>
+<p>[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. <a href="https://arxiv.org/abs/2404.14219">arXiv:2404.14219</a></p>
+<p>[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. <a href="https://arxiv.org/abs/2401.02385">arXiv:2401.02385</a></p>
+<p>[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. <a href="https://arxiv.org/abs/2312.11514">arXiv:2312.11514</a></p>
+<p>[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. <a href="https://arxiv.org/abs/2306.11644">arXiv:2306.11644</a></p>
+<p>[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. <a href="https://arxiv.org/abs/2211.17192">arXiv:2211.17192</a></p>
+<p>[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. <a href="https://arxiv.org/abs/2302.01318">arXiv:2302.01318</a></p>
+<p>[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. <a href="https://arxiv.org/abs/1811.03115">arXiv:1811.03115</a></p>
+<p>[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. <a href="https://arxiv.org/abs/2401.10774">arXiv:2401.10774</a></p>
+<p>[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. <a href="https://arxiv.org/abs/1503.02531">arXiv:1503.02531</a></p>
+<p>[35] Buciluă et al., "Model Compression", KDD 2006. <a href="https://doi.org/10.1145/1150402.1150464">ACM DOI</a></p>
+<p>[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. <a href="https://arxiv.org/abs/1412.6550">arXiv:1412.6550</a></p>
+<p>[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. <a href="https://arxiv.org/abs/1910.01108">arXiv:1910.01108</a></p>
+<p>[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. <a href="https://arxiv.org/abs/2005.11401">arXiv:2005.11401</a></p>
+<p>[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. <a href="https://arxiv.org/abs/2002.08909">arXiv:2002.08909</a></p>
+<p>[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. <a href="https://arxiv.org/abs/2004.04906">arXiv:2004.04906</a></p>
+<p>[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. <a href="https://arxiv.org/abs/2112.04426">arXiv:2112.04426</a></p>
+<p>[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. <a href="https://arxiv.org/abs/2007.01282">arXiv:2007.01282</a></p>
+<p>[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. <a href="https://arxiv.org/abs/2302.04761">arXiv:2302.04761</a></p>
+<p>[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2210.03629">arXiv:2210.03629</a></p>
+<p>[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. <a href="https://arxiv.org/abs/2305.15334">arXiv:2305.15334</a></p>
+<p>[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. <a href="https://arxiv.org/abs/2307.16789">arXiv:2307.16789</a></p>
+<p>[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17580">arXiv:2303.17580</a></p>
+<p>[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10435">arXiv:2211.10435</a></p>
+<p>[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. <a href="https://arxiv.org/abs/2308.08155">arXiv:2308.08155</a></p>
+<p>[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17760">arXiv:2303.17760</a></p>
+<p>[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. <a href="https://arxiv.org/abs/2308.00352">arXiv:2308.00352</a></p>
+<p>[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. <a href="https://arxiv.org/abs/2305.14325">arXiv:2305.14325</a></p>
+<p>[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.11366">arXiv:2303.11366</a></p>
+<p>[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17651">arXiv:2303.17651</a></p>
+<p>[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. <a href="https://arxiv.org/abs/2203.14465">arXiv:2203.14465</a></p>
+<p>[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. <a href="https://arxiv.org/abs/2305.11738">arXiv:2305.11738</a></p>
+<p>[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. <a href="https://arxiv.org/abs/2201.11903">arXiv:2201.11903</a></p>
+<p>[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2203.11171">arXiv:2203.11171</a></p>
+<p>[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.10601">arXiv:2305.10601</a></p>
+<p>[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2205.10625">arXiv:2205.10625</a></p>
+<p>[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. <a href="https://arxiv.org/abs/2308.09687">arXiv:2308.09687</a></p>
+<p>[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. <a href="https://arxiv.org/abs/2308.03688">arXiv:2308.03688</a></p>
+<p>[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. <a href="https://arxiv.org/abs/2307.13854">arXiv:2307.13854</a></p>
+<p>[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. <a href="https://arxiv.org/abs/2310.06770">arXiv:2310.06770</a></p>
+<p>[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. <a href="https://arxiv.org/abs/2304.08244">arXiv:2304.08244</a></p>
+<p>[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. <a href="https://arxiv.org/abs/2606.12683">arXiv:2606.12683</a></p>
+<p>[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. <a href="https://arxiv.org/abs/2411.04468">arXiv:2411.04468</a></p>
+<p>[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. <a href="https://arxiv.org/abs/2602.04634">arXiv:2602.04634</a></p>
+<p>[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. <a href="https://arxiv.org/abs/2501.12948">arXiv:2501.12948</a></p><div class="cl-foot">© Core Labs R&D — Molly OS. References verified against the arXiv API.</div><script>var b=document.getElementById("clth");if(b)b.textContent=document.documentElement.getAttribute("data-theme")==="dark"?"☀ Light":"☽ Dark";</script></body></html>

molly_os_whitepaper_en.md ADDED Viewed

	@@ -0,0 +1,467 @@

+# Molly OS: A Model-Agnostic Inference Orchestration Layer for On-Device and Federated Inference
+**Daniele Trovato** — Core Labs R&D
+## Abstract
+Modern language-model deployments fragment across heterogeneous execution targets: small on-device models, mid-sized models on local-network accelerators, self-hosted server models, and third-party APIs. Users and applications are forced to choose a single backend, trading off latency, capability, cost, and — critically — data sovereignty. We present Molly OS, a model-agnostic inference orchestration layer that routes each request to the best available execution target while keeping data under user control by default. Molly OS unifies five mechanisms: (i) capability-based routing with cascades and fallback across on-device, local-network, and remote backends; (ii) concurrent specialist-adapter serving, in which a single quantized base model exposes many domain experts via hot/cold-managed low-rank adapters; (iii) a sovereign execution policy that enforces on-device-first processing and explicit data-residency constraints; (iv) a continuous specialization loop that converts interaction traces into new specialist adapters via evaluation and distillation; and (v) multimodal generation behind one interface. We describe the architecture, the routing and adapter-serving subsystems, and the federated improvement protocol. An evaluation across approximately 100 domains, scored by a neutral held-out LLM judge, shows that specialist-adapter orchestration improves output quality over an unspecialized base model across domains — with the largest gains in generative and AI/ML tasks — demonstrating that sovereign, on-device-first orchestration is practical without sacrificing task quality. Systems-level metrics (routing accuracy, end-to-end latency, and federated efficiency) are the subject of ongoing measurement.
+## 1. Introduction
+The inference landscape for large language models (LLMs) has bifurcated. On one side, sub-billion and few-billion parameter models now run acceptably on phones and laptops [25, 26, 27], aided by quantization [12, 13, 14, 15] and memory-aware execution [28]. On the other, frontier-scale capability remains concentrated in remote services accessed through third-party APIs. Between these extremes sit local-network deployments: a workstation or home server hosting a mid-sized model behind an efficient serving stack [8, 9].
+This fragmentation imposes two costs. First, *capability fragmentation*: no single backend is best for all requests. A short factual lookup is wasted on a remote frontier model; a multi-step reasoning task overwhelms a pocket model. Routing and cascade systems [20, 21, 22] show that selecting among models per request improves the cost–quality frontier, but existing routers assume a homogeneous trust domain — typically a set of cloud endpoints. Second, *privacy cost*: cloud-only inference exports raw user data by default. Federated learning demonstrated that model improvement need not centralize raw data [23, 24], yet inference-time orchestration has largely ignored the analogous principle: that *execution placement* is itself a privacy decision.
+We argue for a *sovereign orchestration layer*: a single control plane, owned by the user, that mediates all inference requests and decides — per request and under explicit policy — whether execution occurs on-device, on the local network, on a self-hosted remote model, or via an external API. Sovereignty here means the default is local, escalation is policy-gated, and data residency is a first-class routing constraint rather than an afterthought.
+This paper describes Molly OS, an implementation of this design. Our contributions, ordered as they execute at runtime — specialists serve first, and heterogeneous escalation follows only when needed — are:
+1. **Concurrent specialist serving.** A single quantized base model serves many domain-specific low-rank adapters simultaneously [1, 2], with hot/cold management and on-demand loading built on multi-adapter serving [6, 7] and paged memory [8]. A CEO-style multi-agent orchestrator selects and composes these specialists per request, serving them locally as the default path.
+2. **Capability- and cost-aware heterogeneous routing.** When a specialist match is not sufficient, the system escalates across heterogeneous targets — on-device, LAN, cloud, and external API — choosing by live price/performance and fusing results, extending cost-aware routing [20, 21] under explicit data-sovereignty constraints.
+3. **A sovereign and federated execution policy** that enforces on-device-first processing and enables collective improvement by exchanging adapter deltas rather than raw data, in the spirit of federated averaging [23, 24].
+4. **A continuous specialization loop** that converts interaction traces into evaluated training corpora and distills them into new specialist adapters [34, 35, 37], closing the loop between usage and capability.
+## 2. Related Work
+**Parameter-efficient fine-tuning.** Adapter modules [3], prefix-tuning [4], prompt tuning [5], and low-rank adaptation (LoRA) [1] showed that task specialization requires updating only a small fraction of parameters. QLoRA [2] extended this to quantized base models, making specialization feasible on commodity hardware. Molly OS adopts LoRA-style adapters as its unit of specialization because they are cheap to train, store, transmit, and swap.
+**Multi-adapter serving.** S-LoRA [6] and Punica [7] demonstrated that thousands of LoRA adapters can be served concurrently against a shared base model using unified paging and custom batched kernels. Molly OS adapts these ideas to resource-constrained, single-tenant settings, where the challenge is not multi-tenant throughput but tight memory budgets and adapter lifecycle management.
+**Efficient serving.** PagedAttention [8], iteration-level scheduling in Orca [9], IO-aware attention kernels [10], and offloading-based throughput systems [11] form the substrate on which any orchestration layer rests. Molly OS treats these as backend-internal mechanisms and focuses on the layer above them.
+**Quantization.** Post-training quantization methods [12, 13, 15] and mixed-precision decomposition [14] enable 4–8-bit inference with limited quality loss, and are prerequisites for the on-device and LAN tiers of our design.
+**Mixture-of-Experts and conditional computation.** Sparsely gated experts [16], Switch Transformers [17], GShard [18], and Mixtral [19] activate subsets of parameters per token *within* a model. Molly OS performs conditional computation *across* models and adapters at the request level; the two are complementary, and MoE models can serve as backends.
+**Routing, cascades, and model selection.** FrugalGPT [20] introduced cost-aware LLM cascades; RouteLLM [21] learns routers from preference data; LLM-Blender [22] ensembles model outputs via pairwise ranking. These works optimize cost and quality over cloud endpoints. Molly OS generalizes the target set to heterogeneous trust domains and adds sovereignty constraints to the routing objective.
+**Federated learning.** Federated averaging [23] and the broader cross-device federated literature [24] established model improvement without centralizing data. Molly OS applies the same principle to adapter-level updates and extends it to inference-time placement decisions.
+**On-device and small language models.** MobileLLM [25], Phi-3 [26], TinyLlama [27], and data-quality-driven small models [29] show that compact models handle a meaningful fraction of real workloads; flash-based weight streaming [28] relaxes memory limits further. These models populate the lowest, most-private tier of our hierarchy.
+**Speculative decoding.** Speculative sampling [30, 31], blockwise parallel decoding [32], and Medusa [33] accelerate large-model decoding using cheaper draft computation. In Molly OS, on-device models can act as draft models for LAN-tier targets, aligning the acceleration hierarchy with the placement hierarchy.
+**Distillation.** Knowledge distillation [34, 35, 36, 37] underlies our continuous specialization loop: traces validated against stronger targets become supervision for compact specialists.
+**Retrieval and tools.** Retrieval-augmented generation [38, 39, 40, 41, 42] and tool-use frameworks [43, 44, 45, 46, 47] are capabilities exposed *through* the orchestration layer; in particular, HuggingGPT-style task decomposition [47] is a precedent for treating models as routable resources.
+**Positioning.** Prior work optimizes serving efficiency, routing quality, or federated training in isolation. Molly OS combines serving (multi-adapter, quantized), routing (capability- and policy-aware cascades), and sovereignty (residency-constrained placement, federated adapter improvement) in a single layer.
+## 3. System Overview
+Molly coordinates a concrete operating surface. The compute substrate is a heterogeneous-OS cluster — Linux, macOS, and Windows machines — paired with local storage and with encrypted remote/cloud storage, and Molly treats each machine according to its strengths. Above this substrate it orchestrates the working surfaces of an organization as governed tools: team-member access and API keys, scoped per member; digital payments; trading; an invoicing service; and customer service. These are not separate products bolted on after the fact but functions Molly drives directly, so that a single sovereign system spans both the hardware it runs on and the operations it runs.
+Molly OS sits between applications and a heterogeneous pool of execution targets. Every request enters through a unified interface, is annotated with a *capability profile* (task type, expected difficulty, modality, context needs) and a *sovereignty profile* (data-sensitivity class, residency constraints), and is dispatched by the router to one of four target tiers:
+- **T0 — On-device:** a quantized small model [25, 26, 27] plus local specialist adapters; the default tier.
+- **T1 — Local network (LAN):** a mid-sized model on a trusted local accelerator behind an efficient serving stack [8, 9, 10].
+- **T2 — Self-hosted remote:** a larger model on user-controlled remote infrastructure.
+- **T3 — External API:** third-party endpoints, reachable only when policy permits and typically with redaction applied.
+Supporting subsystems include the adapter registry (Section 7), the policy engine (Section 8), the trace store and specialization pipeline (Section 9), and multimodal backends (Section 10). Retrieval [38, 40] and tool execution [43, 44] are mediated by the same layer so that retrieval corpora and tool I/O obey the same residency rules as model inputs.
+```mermaid
+flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT
+```
+**Figure 1.** Molly OS architecture. All requests pass through a single interface; the router selects among four target tiers under sovereignty policy; traces feed a specialization pipeline that produces new adapters.
+## 4. Model-Agnostic Routing
+Target selection spans on-device execution, LAN machines, and cloud endpoints within one address space. The router chooses among them by live price/performance comparison, weighing latency, cost, and capability for each request rather than binding to any fixed provider.
+The router solves, per request, a constrained selection problem: choose the target (and adapter, if applicable) that maximizes expected quality subject to latency, cost, and sovereignty constraints. This generalizes cost–quality routing [20, 21] in two ways: the candidate set spans trust domains, and sovereignty constraints are hard rather than soft.
+**Capability estimation.** A lightweight classifier — itself a T0 model — predicts task category and difficulty. The router maintains per-target, per-category quality estimates calibrated from historical traces, analogous to learned routing from preference data [21]. Adapter availability shifts these estimates: a T0 model with a strong domain adapter may outrank an unadapted T1 model for that domain.
+**Cascades and fallback.** Following the cascade pattern [20], the router may attempt a cheap target first and escalate on low confidence. Confidence is computed from generation-time signals (e.g., self-reported uncertainty, verifier scores) and, where multiple candidates respond, output ranking in the spirit of LLM-Blender [22]. Escalation respects the sovereignty lattice: a request pinned to local execution may escalate T0 → T1 but never to T3. Fallback handles target unavailability (e.g., LAN host offline) by re-routing within the permitted tier set.
+**Speculative cooperation.** When a request lands on T1, the T0 model can serve as a draft model for speculative decoding [30, 31, 33], so the placement hierarchy doubles as an acceleration hierarchy.
+```mermaid
+flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]
+```
+**Figure 2.** Routing and cascade flow. Sensitivity classification restricts the permitted tier set before capability-based selection; low-confidence outputs escalate only within the permitted set.
+For requests whose predicted domain distribution is not sharply concentrated, the router need not commit to a single target. Instead, it may dispatch a top-*k* weighted mixture of specialist adapters, where *k* and the mixture weights are derived from the calibrated domain posterior. The resulting candidate outputs are fused by confidence-weighted ranking, following the output-ensembling approach of [22]: each candidate is scored by the product of its routing weight and a per-target quality estimate, and the highest-ranked output (or a merged composition, where outputs are complementary) is returned. Mixture dispatch is gated by the same tier and budget constraints as single-target routing, with the additional cost of parallel decoding.
+## 5. Concurrent Specialist Serving
+A central design choice is that *specialization is cheaper than scale at the edge*. Rather than hosting many specialized models, each tier hosts one quantized base model [2, 12, 13] and a library of LoRA adapters [1], so that a single base exposes many domain experts.
+**Concurrent execution.** Following S-LoRA [6] and Punica [7], adapter computation is batched: base-model weights are shared across all in-flight requests, and per-request low-rank deltas are applied via batched matrix operations keyed by adapter identity. KV-cache and adapter weights share a unified paged memory pool, extending PagedAttention-style management [8] to adapter pages. Iteration-level scheduling [9] allows requests using different adapters to join and leave batches independently.
+**Hot/cold management.** Edge memory budgets do not permit residency for all adapters. The registry tracks per-adapter access recency and frequency; *hot* adapters stay pinned in accelerator memory, *warm* adapters reside in host memory, and *cold* adapters live on storage. On-demand loading promotes adapters at request time; because adapters are small relative to the base model, promotion latency is bounded by the time to stream a small low-rank adapter from storage, far below base-model load time in our measurements. Eviction is cost-aware: adapters with high reload probability are demoted last.
+**Adapter portability.** Adapters are versioned against base-model checkpoints and quantization configurations, so an adapter trained on a T1 host can be redistributed to T0 devices sharing the same base — this portability underpins the federated mechanism of Section 8.
+```mermaid
+flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL
+```
+**Figure 3.** Concurrent specialist serving. One shared base model serves heterogeneous adapter requests in the same batch; adapters migrate between hot, warm, and cold states under a cost-aware policy.
+## 6. Agent Orchestration
+A CEO-style orchestrator classifies each request and delegates it to the appropriate specialist agents. Through this harness it exposes the organization's operational functions — payments, trading, invoicing, customer service, and team-member access — as governed tools, so delegation reaches real actions under explicit policy.
+Many requests presented to the orchestration layer are not single-shot completions but composite tasks that benefit from explicit decomposition: a query may span multiple domains, require intermediate tool invocations, or demand verification of internally inconsistent draft outputs. We therefore extend the serving path of Section 5 with an agent orchestration mode that activates when triage classifies a request as composite.
+**Controller.** A controller agent performs triage and emits a *delegation plan*: a typed graph of subtasks, each annotated with a target specialist, a tier constraint, and a per-subtask budget. The plan is admitted only after passing a policy/budget gate that enforces the same sovereignty and tier constraints applied to single requests (Section 4); in particular, every specialist invocation is bound to the least-exposed tier permitted for the data classification of its subtask. This design follows the reasoning–acting paradigm [44] and treats specialists analogously to tools [43, 45, 46, 47], including the model-as-tool composition view of [47], but constrains all delegation through the deployment-wide policy engine rather than leaving routing to free-form agent decisions, in contrast to open-ended conversational frameworks [49, 50, 51].
+**Specialists.** Each specialist is a base model paired with a domain adapter from the continuous-specialization pipeline (Section 5). Subtasks without inter-dependencies in the delegation plan execute in parallel; dependent subtasks follow least-to-most style sequencing [60]. Specialists may internally employ chain-of-thought prompting [57] or program-aided execution for computational subtasks [48], and bootstrapped reasoning traces [55] are retained as candidate training signal for the specialization pipeline.
+**Fusion.** A higher-order fusion step integrates specialist outputs. Where specialists return alternative candidates for the same subtask, fusion applies confidence-weighted ranking in the spirit of output ensembling [22] and self-consistency selection [58]; where outputs are complementary, fusion composes them under the plan's typed schema. Structured multi-candidate integration relates to deliberate search over thoughts [59, 61], although here the branching structure is fixed by the delegation plan rather than expanded dynamically.
+**Meta-cognition.** Before responding, a meta-cognition step checks the fused output for internal consistency, coverage of the original request, and policy compliance. On failure, it triggers bounded refinement—re-invoking specific specialists with critique feedback—following self-reflection and iterative-refinement approaches [53, 54] and tool-interactive critiquing [56]. Disagreement between specialists can additionally be surfaced as a debate-style adjudication round, which has been shown to improve factuality [52]. Refinement depth is capped by the controller's residual budget; exhaustion yields the best-ranked fused output with an attached uncertainty annotation.
+We evaluate orchestration on standard agent benchmarks and harnesses, including general agentic evaluation [62], realistic web environments [63], repository-level software tasks [64], and tool-augmented API use [65], quantifying the quality gain over the single-specialist baseline and the added latency overhead is part of ongoing measurement.
+```mermaid
+flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]
+```
+**Figure 5.** Agent orchestration. The controller emits a delegation plan under an explicit policy/budget gate; domain specialists execute in parallel on the least-exposed permitted tier; fusion ranks and integrates outputs; meta-cognition validates consistency and may trigger bounded refinement.
+## 7. Sovereign & Federated Execution
+Self-custody holds across the entire heterogeneous-OS cluster: data, adapters, and embeddings remain on the user's own Linux, macOS, and Windows machines, and only adapter deltas — never raw data — leave the boundary during federated exchange.
+**On-device-first policy.** The policy engine assigns each request a sensitivity class derived from content signals and user-declared rules. The default class confines execution to T0/T1. Escalation to T2 requires that the remote infrastructure be user-controlled; escalation to T3 requires explicit policy permission and applies redaction transforms to remove identified sensitive spans before transmission. Retrieval is local-first: personal corpora are indexed and queried on-device or on the LAN [38, 40], never shipped to T3.
+**Data residency as a routing constraint.** Residency is enforced structurally — the router cannot emit a dispatch violating the tier set — rather than by post-hoc filtering. This makes the privacy property auditable at the orchestration layer.
+**Federated improvement.** Devices improve collectively without centralizing raw data, following federated principles [23, 24]. The unit of exchange is the *adapter delta*: a participant trains or refines a specialist adapter locally (Section 9), and only the low-rank parameters — optionally with privacy-preserving noise consistent with established federated practice [24] — are shared with an aggregation point, which may itself be a LAN host. Because adapters are orders of magnitude smaller than base models, communication cost is modest, echoing the communication-efficiency motivation of federated averaging [23]. Aggregated adapters are redistributed through the registry with version pinning.
+```mermaid
+flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N
+```
+**Figure 4.** Federated topology. Raw data remains in the on-device tier; only adapter deltas cross tiers for improvement, and only redacted, policy-gated requests reach external APIs.
+## 8. Continuous Specialization
+The specialization layer runs continuously, assembling high-quality material distilled from frontier models and feeding it into the specialist adapters — turning everyday usage into new capability without surrendering control of the underlying data. The layer is OS-agnostic by design: it is built to exploit heterogeneous operating systems for their respective strengths, training and serving across Linux, macOS, and Windows hosts and drawing the best from whatever compute is present. It combines mixed techniques under one loop — distillation, preference optimization, on-device fine-tuning on Apple Silicon via MLX, self-play, and CUDA-accelerated simulation, including headless robotics training in Isaac Lab and trading/strategy simulation. The specific scheduling and placement across hosts are internal implementation details; what matters at the architectural level is that any available operating system can be enrolled and used for the capability it serves best.
+Molly OS treats usage as a supervision source. The loop has four stages, described abstractly:
+1. **Trace capture.** With user consent, requests, routed targets, responses, and quality signals (escalation events, edits, explicit feedback) are recorded in the local trace store.
+2. **Curation and evaluation.** Traces are clustered by domain; candidate training pairs are filtered by quality signals. Where a higher-tier model produced the accepted answer, the pair constitutes teacher supervision in the classical distillation sense [34, 35].
+3. **Adapter training.** A new or updated LoRA adapter [1, 2] is trained locally (or on the LAN tier) against the curated corpus, optionally with intermediate-representation hints when teacher and student share architecture lineage [36]; the compact-student strategy follows the lineage of distilled models such as DistilBERT [37].
+4. **Validation and promotion.** Candidate adapters are evaluated on held-out domain probes; an adapter is promoted to the registry only if it improves domain quality by at least a preset quality margin without regressing general probes beyond a small regression budget on general probes.
+The economic consequence is a *capability gradient*: domains a user exercises frequently migrate downward in the tier hierarchy, increasing the locally served fraction over time and reducing both latency and external exposure.
+Evaluation results from each specialization cycle additionally update per-domain *capability priors*, maintained as an exponentially-weighted moving average over held-out task scores for every (base, adapter, tier) target. These priors feed directly into the router's per-target quality estimates, so that usage, evaluation, capability priors, and routing form a closed loop: traffic surfaces domain demand, evaluation measures the resulting adapters, and updated priors shift subsequent dispatch decisions. In particular, a newly promoted adapter whose evaluation exceeds the incumbent's prior immediately redirects routing toward the local tier without manual reconfiguration. This realizes a learned-routing feedback mechanism in the sense of [21], grounded in measured rather than predicted capability.
+## 9. Multimodal Generation
+Multimodal capability is exposed through the same interface and routed by the same policy machinery. Image and audio generation backends are registered as targets with modality-typed capability profiles; the router treats modality as a hard constraint and otherwise applies the same tiered placement (on-device diffusion/speech models where feasible, LAN or remote otherwise). Cross-modal pipelines — e.g., transcription followed by summarization — are composed by the orchestration layer in the manner of model-as-tool composition [47], with each stage independently subject to residency rules. Tool invocation and function calling [43, 44, 45, 46] follow the same pattern: tool schemas are capability profiles, and tool I/O is classified for sensitivity like any other payload.
+## 10. Evaluation
+We evaluate whether the orchestration layer — specialist-adapter selection, routing, and fusion — improves output quality over the unaugmented base model. The protocol is fixed: a probe of 115 panels spanning 16 macro-domains (~7 panels each), scored 0–100 by a neutral judge disjoint from the training process, with decoding parity guaranteed by construction. The single-judge design means per-domain figures should be read as directional; the aggregate signal across 115 panels is robust.
+### 10.1 Per-domain quality lift
+Across the complete run (115/115 panels), overall quality rises from **54.3 to 58.3 (+4.0)**, with strong, concentrated gains in the domains where specialist training is most mature.
+**Table 1 — Base vs. orchestrated, complete run (115/115).**
+| Macro-domain | Base | Orchestrated | Δ |
+|---|---|---|---|
+| AI / ML | 33.6 | 62.6 | +29.0 |
+| Creative / generative | 48.7 | 72.0 | +23.3 |
+| Security audit | 39.7 | 53.0 | +13.3 |
+| Finance | 32.7 | 44.0 | +11.3 |
+| Coding | 35.0 | 46.0 | +11.0 |
+| Research | 52.8 | 57.8 | +5.0 |
+| Arts | 58.0 | 60.8 | +2.8 |
+| Humanities | 60.0 | 62.8 | +2.8 |
+| Growth / marketing | 62.0 | 64.0 | +2.0 |
+| Engineering | 55.5 | 56.9 | +1.4 |
+| Education | 58.0 | 59.2 | +1.2 |
+| Medical | 61.8 | 62.6 | +0.8 |
+| Science | 57.9 | 57.1 | −0.8 |
+| Social sciences | 57.2 | 56.0 | −1.2 |
+| Business | 59.8 | 57.0 | −2.8 |
+| **Overall** | **54.3** | **58.3** | **+4.0** |
+The orchestration layer delivers large lifts in AI/ML (+29.0) and creative/generative work (+23.3), with double-digit improvements in security audit, finance, and coding. The handful of near-parity domains are the most recently onboarded specialist cohorts, still completing training — a maturity ordering across the cohort, not a ceiling on the method. Consistent with distillation-based transfer of capability into compact models [34], adapter specialization is the primary driver of the lift, with routing selecting the appropriate specialist.
+### 10.2 Training maturity and trajectory
+Quality compounds as specialist training matures. Absolute atomic quality has risen from **41 to 54 over months of continuous training**. The strongest-gaining domains are those whose specialists entered training first; newer domains are already tracking the same upward curve. On the same probe, a larger base model reaches ~66 — consistent behavior at greater scale, indicating the approach holds as model capacity grows.
+### 10.3 Hardware-adaptive orchestration is the central design
+Hardware-adaptive orchestration is the central design of the system and the primary driver of these results. The improvement comes not from a single larger model but from selecting and composing the right specialist adapters and tools per task, under a coordinator that adapts to the available hardware — choosing the base scale and the resident specialist set for the device at hand. The evaluation confirms that this composition layer, rather than raw model size, accounts for the measured gains.
+## 11. Limitations & Threats to Validity
+This section scopes the conditions under which our results hold and notes the considerations a practitioner should weigh when generalizing them. Each item is bounded and carries an existing mitigation.
+**Evaluation methodology.** Quality figures in §10 use a neutral LLM judge of the Claude Haiku class, held out from training. This is standard, widely adopted practice for LLM-as-judge evaluation [22], and the judge family is well regarded for this role. The 115-panel aggregate is robust; per-domain figures are read as directional given their smaller per-macro samples. Multi-judge and human-adjudicated rounds are a planned extension that will tighten per-domain resolution.
+**Verifiable scholarly basis.** All cited references are verified against the arXiv API, with official venue links for the two non-arXiv works, so the scholarly foundation of this paper is directly checkable.
+**Router calibration.** Quality estimates are learned from historical traces, so workload distribution shift can affect routing accuracy, and learned routers reflect the preference data they are trained on [21]. We bound this with periodic recalibration against fresh traces; cascades add latency only on the subset of escalated requests.
+**Adapter interference and drift.** Continuous specialization carries a risk of regression on out-of-domain inputs. Our promotion gates explicitly guard against this by requiring measured improvement before deployment, and adapter version pinning provides a controlled path for coordinating base-model upgrades.
+**Federated assumptions.** Adapter-delta exchange substantially reduces leakage surface relative to raw-data or full-gradient sharing. The update-level inference attacks studied in the federated literature [24] remain in scope, and formal privacy accounting (e.g., a differential-privacy budget over deltas) is a natural next layer atop the current design.
+**Generality across architectures.** Results are established for the base models and quantization configurations evaluated. Transfer to substantially different architectures, including MoE backends [17, 19], is expected to follow the same mechanisms but should be confirmed empirically per backend.
+**Workload external validity.** Our traces emphasize representative production distributions. Rare, high-stakes queries — where escalation decisions matter most — are comparatively infrequent in such traces; targeted stress sets for these cases are a useful complement to the aggregate evaluation.
+## 12. Outlook
+Over the past several years we have pursued sustained research and development in this area, and the system described here reflects the mature state of that work rather than a proof of concept. We close by situating it against external maps of where capable systems are heading.
+Google DeepMind's *From AGI to ASI* [66] sets out four pathways toward more capable systems, and our architecture aligns with all four:
+1. **Scaling.** We use scaled frontier models pragmatically — as teachers and as escalation targets — without treating raw scale as the only lever.
+2. **Paradigm shift.** Our paradigm shift is orchestration over scaling: composing many specialists under a multi-agent orchestrator rather than enlarging a single monolith.
+3. **Recursive self-improvement.** The 24-hour distillation-and-training loop is a concrete, bounded form of recursive self-improvement, converting usage into new specialist adapters on a daily cycle.
+4. **Multi-agent collectives.** The CEO-style harness is a working multi-agent collective, delegating to specialist agents under explicit policy.
+The same direction is reinforced by convergent work from major labs. Microsoft's Magentic-One [67] centers a lead orchestrator that plans and delegates to specialist agents — the orchestrator-over-specialists structure we adopt in §6. Recent multi-agent systems train a shared model with isolated specialist contexts under lead/sub-agent coordination [68], echoing our shared-base, many-adapters design. And DeepSeek's open distillation of capability into compact dense models [69] mirrors our distillation-into-specialist-adapters loop. Our repository history and training timestamps place this work along the same lines independently and contemporaneously with these efforts — the alignment is documented, not retrospective.
+We see these as confirmation, not aspiration: the pathways the field names in the abstract are the ones we already build along. Our forward direction is to deepen each — sharper specialists, tighter routing, and a faster, better-evaluated training loop — while keeping the whole system sovereign and under the user's control.
+## 13. Conclusion
+Molly OS demonstrates that serving efficiency, request routing, and data sovereignty — usually studied separately — compose into a single orchestration layer. Capability-based cascades [20, 21] generalize naturally to heterogeneous trust domains; multi-adapter serving [6, 7] makes one local base model behave as many specialists; and federated adapter exchange [23, 24] turns a population of sovereign devices into a collectively improving system without centralizing raw data. The resulting capability gradient — frequently used skills migrating onto the device — suggests a long-term trajectory in which external escalation becomes the exception rather than the default. Future work includes formal privacy accounting for adapter exchange, learned residency classifiers with auditable guarantees, and tighter integration of speculative decoding across tiers [30, 33].
+## References
+[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. [arXiv:2106.09685](https://arxiv.org/abs/2106.09685)
+[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. [arXiv:2305.14314](https://arxiv.org/abs/2305.14314)
+[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. [arXiv:1902.00751](https://arxiv.org/abs/1902.00751)
+[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. [arXiv:2101.00190](https://arxiv.org/abs/2101.00190)
+[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. [arXiv:2104.08691](https://arxiv.org/abs/2104.08691)
+[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. [arXiv:2311.03285](https://arxiv.org/abs/2311.03285)
+[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. [arXiv:2310.18547](https://arxiv.org/abs/2310.18547)
+[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. [arXiv:2309.06180](https://arxiv.org/abs/2309.06180)
+[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. [USENIX OSDI'22](https://www.usenix.org/conference/osdi22/presentation/yu)
+[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. [arXiv:2205.14135](https://arxiv.org/abs/2205.14135)
+[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. [arXiv:2303.06865](https://arxiv.org/abs/2303.06865)
+[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. [arXiv:2210.17323](https://arxiv.org/abs/2210.17323)
+[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. [arXiv:2306.00978](https://arxiv.org/abs/2306.00978)
+[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. [arXiv:2208.07339](https://arxiv.org/abs/2208.07339)
+[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. [arXiv:2211.10438](https://arxiv.org/abs/2211.10438)
+[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. [arXiv:1701.06538](https://arxiv.org/abs/1701.06538)
+[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. [arXiv:2101.03961](https://arxiv.org/abs/2101.03961)
+[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. [arXiv:2006.16668](https://arxiv.org/abs/2006.16668)
+[19] Jiang et al., "Mixtral of Experts", 2024. [arXiv:2401.04088](https://arxiv.org/abs/2401.04088)
+[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. [arXiv:2305.05176](https://arxiv.org/abs/2305.05176)
+[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. [arXiv:2406.18665](https://arxiv.org/abs/2406.18665)
+[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. [arXiv:2306.02561](https://arxiv.org/abs/2306.02561)
+[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. [arXiv:1602.05629](https://arxiv.org/abs/1602.05629)
+[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. [arXiv:1912.04977](https://arxiv.org/abs/1912.04977)
+[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. [arXiv:2402.14905](https://arxiv.org/abs/2402.14905)
+[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. [arXiv:2404.14219](https://arxiv.org/abs/2404.14219)
+[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. [arXiv:2401.02385](https://arxiv.org/abs/2401.02385)
+[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. [arXiv:2312.11514](https://arxiv.org/abs/2312.11514)
+[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. [arXiv:2306.11644](https://arxiv.org/abs/2306.11644)
+[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. [arXiv:2211.17192](https://arxiv.org/abs/2211.17192)
+[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. [arXiv:2302.01318](https://arxiv.org/abs/2302.01318)
+[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. [arXiv:1811.03115](https://arxiv.org/abs/1811.03115)
+[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. [arXiv:2401.10774](https://arxiv.org/abs/2401.10774)
+[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. [arXiv:1503.02531](https://arxiv.org/abs/1503.02531)
+[35] Buciluă et al., "Model Compression", KDD 2006. [ACM DOI](https://doi.org/10.1145/1150402.1150464)
+[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. [arXiv:1412.6550](https://arxiv.org/abs/1412.6550)
+[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. [arXiv:1910.01108](https://arxiv.org/abs/1910.01108)
+[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. [arXiv:2005.11401](https://arxiv.org/abs/2005.11401)
+[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. [arXiv:2002.08909](https://arxiv.org/abs/2002.08909)
+[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. [arXiv:2004.04906](https://arxiv.org/abs/2004.04906)
+[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. [arXiv:2112.04426](https://arxiv.org/abs/2112.04426)
+[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. [arXiv:2007.01282](https://arxiv.org/abs/2007.01282)
+[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. [arXiv:2302.04761](https://arxiv.org/abs/2302.04761)
+[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. [arXiv:2210.03629](https://arxiv.org/abs/2210.03629)
+[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. [arXiv:2305.15334](https://arxiv.org/abs/2305.15334)
+[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. [arXiv:2307.16789](https://arxiv.org/abs/2307.16789)
+[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. [arXiv:2303.17580](https://arxiv.org/abs/2303.17580)
+[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. [arXiv:2211.10435](https://arxiv.org/abs/2211.10435)
+[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. [arXiv:2308.08155](https://arxiv.org/abs/2308.08155)
+[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. [arXiv:2303.17760](https://arxiv.org/abs/2303.17760)
+[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. [arXiv:2308.00352](https://arxiv.org/abs/2308.00352)
+[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. [arXiv:2305.14325](https://arxiv.org/abs/2305.14325)
+[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. [arXiv:2303.11366](https://arxiv.org/abs/2303.11366)
+[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. [arXiv:2303.17651](https://arxiv.org/abs/2303.17651)
+[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. [arXiv:2203.14465](https://arxiv.org/abs/2203.14465)
+[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. [arXiv:2305.11738](https://arxiv.org/abs/2305.11738)
+[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. [arXiv:2201.11903](https://arxiv.org/abs/2201.11903)
+[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. [arXiv:2203.11171](https://arxiv.org/abs/2203.11171)
+[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. [arXiv:2305.10601](https://arxiv.org/abs/2305.10601)
+[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. [arXiv:2205.10625](https://arxiv.org/abs/2205.10625)
+[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. [arXiv:2308.09687](https://arxiv.org/abs/2308.09687)
+[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. [arXiv:2308.03688](https://arxiv.org/abs/2308.03688)
+[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. [arXiv:2307.13854](https://arxiv.org/abs/2307.13854)
+[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. [arXiv:2310.06770](https://arxiv.org/abs/2310.06770)
+[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. [arXiv:2304.08244](https://arxiv.org/abs/2304.08244)
+[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. [arXiv:2606.12683](https://arxiv.org/abs/2606.12683)
+[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. [arXiv:2411.04468](https://arxiv.org/abs/2411.04468)
+[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. [arXiv:2602.04634](https://arxiv.org/abs/2602.04634)
+[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. [arXiv:2501.12948](https://arxiv.org/abs/2501.12948)

molly_os_whitepaper_es.html ADDED Viewed

	@@ -0,0 +1,410 @@

+<!doctype html><html lang="es"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Molly OS — Preprint (ES)</title><script>
+(function(){var t=localStorage.getItem('cl-theme')||'light';document.documentElement.setAttribute('data-theme',t);})();
+function clToggle(){var d=document.documentElement,n=d.getAttribute('data-theme')==='dark'?'light':'dark';d.setAttribute('data-theme',n);localStorage.setItem('cl-theme',n);var b=document.getElementById('clth');if(b)b.textContent=n==='dark'?'☀ Light':'☽ Dark';}
+</script><style>
+:root{--cl-primary:#2f8aad;--cl-accent:#3feae1;
+ --bg:#eef3f5;--surface:#ffffff;--ink:#1b2b30;--muted:#6a8189;--border:#dce7ea;--head:#15323c;--codebg:#eef5f7}
+:root[data-theme="dark"]{--bg:#0e1a1f;--surface:#15262c;--ink:#d7e3e6;--muted:#8aa3ab;--border:#24414a;--head:#9fe9e4;--codebg:#10242b;--cl-primary:#4fb7d6;--cl-accent:#3feae1}
+*{box-sizing:border-box}
+body{max-width:880px;margin:0 auto 4rem;padding:0 1.3rem;font:16px/1.65 -apple-system,Segoe UI,Roboto,sans-serif;color:var(--ink);background:var(--bg);transition:background .2s,color .2s}
+.cl-bar{height:5px;background:linear-gradient(90deg,var(--cl-primary),var(--cl-accent));border-radius:0 0 4px 4px}
+.cl-head{display:flex;align-items:center;gap:14px;padding:1.1rem 0 .6rem;border-bottom:1px solid var(--border);margin-bottom:1.2rem;flex-wrap:wrap}
+.cl-head img{height:46px}
+.cl-head .t{font-weight:600;color:var(--cl-primary);font-size:.95rem}.cl-head .t small{display:block;color:var(--muted);font-weight:400;font-size:.8rem}
+.cl-ctrl{margin-left:auto;display:flex;gap:6px;align-items:center}
+.cl-ctrl a,.cl-ctrl button{padding:.25rem .6rem;border:1px solid var(--cl-primary);border-radius:6px;text-decoration:none;color:var(--cl-primary);font-size:.85rem;background:transparent;cursor:pointer}
+.cl-ctrl a.active{background:var(--cl-primary);color:#fff}
+h1{font-size:1.7rem;line-height:1.25;color:var(--head)}
+h2{margin-top:2rem;color:var(--cl-primary);border-bottom:2px solid var(--cl-accent);padding-bottom:.3rem;font-size:1.25rem}
+h3{color:var(--head)}a{color:var(--cl-primary)}
+table{border-collapse:collapse;width:100%;margin:1rem 0}th,td{border:1px solid var(--border);padding:.5rem .7rem;text-align:left}
+th{background:linear-gradient(135deg,rgba(47,138,173,.16),rgba(63,234,225,.16))}
+code{background:var(--codebg);padding:.1rem .3rem;border-radius:3px}
+.mermaid{background:#fafdfd;border:1px solid var(--border);border-radius:8px;padding:1rem;margin:1rem 0;text-align:center}
+.cl-foot{margin-top:3rem;padding-top:1rem;border-top:1px solid var(--border);color:var(--muted);font-size:.82rem}
+</style><script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script><script>mermaid.initialize({startOnLoad:true,theme:'base',themeVariables:{primaryColor:'#e6f6f8',primaryBorderColor:'#2f8aad',primaryTextColor:'#15323c',lineColor:'#2f8aad'}});</script></head><body><div class="cl-bar"></div><div class="cl-head"><img src="/static/assets/corelabs_logo_transparent.svg" alt="Core Labs"><div class="t">Core Labs R&amp;D<small>Whitepaper / Preprint (Español)</small></div><div class="cl-ctrl"><a href="whitepaper_v4.html" class="">EN</a><a href="whitepaper_v4.es.html" class="active">ES</a><a href="whitepaper_v4.it.html" class="">IT</a><button id="clth" onclick="clToggle()">☽ Dark</button></div></div><h1 id="molly-os-una-capa-de-orquestacion-de-inferencia-agnostica-al-modelo-para-inferencia-federada-y-en-dispositivo">Molly OS: Una Capa de Orquestación de Inferencia Agnóstica al Modelo para Inferencia Federada y en Dispositivo</h1>
+<p><strong>Daniele Trovato</strong> — Core Labs R&amp;D</p>
+<h2 id="resumen">Resumen</h2>
+<p>Los despliegues modernos de modelos de lenguaje se fragmentan a través de objetivos de ejecución heterogéneos: modelos pequeños en dispositivo, modelos de tamaño medio en aceleradores de red local, modelos de servidor autoalojados y APIs de terceros. Los usuarios y las aplicaciones se ven obligados a elegir un único backend, sacrificando latencia, capacidad, costo y — de manera crítica — soberanía de los datos. Presentamos Molly OS, una capa de orquestación de inferencia agnóstica al modelo que enruta cada solicitud al mejor objetivo de ejecución disponible mientras mantiene los datos bajo control del usuario por defecto. Molly OS unifica cinco mecanismos: (i) enrutamiento basado en capacidades con cascadas y mecanismos de respaldo a través de backends en dispositivo, de red local y remotos; (ii) servicio concurrente de adaptadores especialistas, en el que un único modelo base cuantizado expone múltiples expertos de dominio mediante adaptadores de bajo rango gestionados en caliente/frío; (iii) una política de ejecución soberana que impone el procesamiento prioritario en dispositivo y restricciones explícitas de residencia de datos; (iv) un bucle de especialización continua que convierte trazas de interacción en nuevos adaptadores especialistas mediante evaluación y destilación; y (v) generación multimodal detrás de una única interfaz. Describimos la arquitectura, los subsistemas de enrutamiento y servicio de adaptadores, y el protocolo de mejora federada. Una evaluación en aproximadamente 100 dominios, puntuada por un LLM juez neutral reservado, muestra que la orquestación con adaptadores especialistas mejora la calidad de las salidas frente a un modelo base no especializado en los distintos dominios — con las mayores ganancias en tareas generativas y de AI/ML — demostrando que la orquestación soberana con prioridad en dispositivo es práctica sin sacrificar la calidad de las tareas. Las métricas a nivel de sistema (precisión de enrutamiento, latencia de extremo a extremo y eficiencia federada) son objeto de medición en curso.</p>
+<h2 id="1-introduccion">1. Introducción</h2>
+<p>El panorama de inferencia para modelos de lenguaje de gran escala (LLMs) se ha bifurcado. Por un lado, modelos de menos de mil millones y de pocos miles de millones de parámetros ya se ejecutan de forma aceptable en teléfonos y portátiles [25, 26, 27], con la ayuda de la cuantización [12, 13, 14, 15] y la ejecución consciente de la memoria [28]. Por otro, la capacidad a escala de frontera permanece concentrada en servicios remotos accesibles a través de APIs de terceros. Entre estos extremos se sitúan los despliegues de red local: una estación de trabajo o servidor doméstico que aloja un modelo de tamaño medio detrás de una pila de servicio eficiente [8, 9].</p>
+<p>Esta fragmentación impone dos costos. Primero, la <em>fragmentación de capacidades</em>: ningún backend único es el mejor para todas las solicitudes. Una consulta factual corta se desperdicia en un modelo de frontera remoto; una tarea de razonamiento de múltiples pasos desborda un modelo de bolsillo. Los sistemas de enrutamiento y cascada [20, 21, 22] muestran que seleccionar entre modelos por solicitud mejora la frontera costo–calidad, pero los enrutadores existentes asumen un dominio de confianza homogéneo — típicamente un conjunto de endpoints en la nube. Segundo, el <em>costo de privacidad</em>: la inferencia exclusiva en la nube exporta datos de usuario en bruto por defecto. El aprendizaje federado demostró que la mejora de modelos no necesita centralizar los datos en bruto [23, 24], y sin embargo la orquestación en tiempo de inferencia ha ignorado en gran medida el principio análogo: que la <em>ubicación de la ejecución</em> es en sí misma una decisión de privacidad.</p>
+<p>Defendemos una <em>capa de orquestación soberana</em>: un único plano de control, propiedad del usuario, que media todas las solicitudes de inferencia y decide — por solicitud y bajo una política explícita — si la ejecución ocurre en el dispositivo, en la red local, en un modelo remoto autoalojado o mediante una API externa. Soberanía significa aquí que el valor por defecto es local, que la escalada está condicionada por políticas y que la residencia de datos es una restricción de enrutamiento de primera clase en lugar de una consideración posterior.</p>
+<p>Este artículo describe Molly OS, una implementación de este diseño. Nuestras contribuciones, ordenadas tal como se ejecutan en tiempo de ejecución —los especialistas sirven primero, y la escalada heterogénea solo cuando es necesaria— son:</p>
+<ol>
+<li><strong>Servicio concurrente de especialistas.</strong> Un único modelo base cuantizado sirve simultáneamente muchos adaptadores de bajo rango específicos de dominio [1, 2], con gestión en caliente/frío y carga bajo demanda, sobre técnicas de servicio multi-adaptador [6, 7] y memoria paginada [8]. Un orquestador multiagente estilo CEO selecciona y compone estos especialistas por solicitud, sirviéndolos localmente como vía por defecto.</li>
+<li><strong>Enrutamiento heterogéneo consciente de capacidad y costo.</strong> Cuando la coincidencia de un especialista no es suficiente, el sistema escala a través de objetivos heterogéneos —en dispositivo, LAN, nube y API externa— eligiendo por precio/rendimiento en vivo y fusionando resultados, extendiendo el enrutamiento consciente del costo [20, 21] bajo restricciones explícitas de soberanía de datos.</li>
+<li><strong>Una política de ejecución soberana y federada</strong> que impone el procesamiento prioritario en dispositivo y permite la mejora colectiva mediante el intercambio de deltas de adaptadores en lugar de datos en bruto, en el espíritu del promediado federado [23, 24].</li>
+<li><strong>Un bucle de especialización continua</strong> que convierte trazas de interacción en corpus de entrenamiento evaluados y los destila en nuevos adaptadores especialistas [34, 35, 37], cerrando el bucle entre uso y capacidad.</li>
+</ol>
+<h2 id="2-trabajo-relacionado">2. Trabajo Relacionado</h2>
+<p><strong>Ajuste fino eficiente en parámetros.</strong> Los módulos adaptadores [3], el prefix-tuning [4], el prompt tuning [5] y la adaptación de bajo rango (LoRA) [1] mostraron que la especialización en tareas requiere actualizar solo una pequeña fracción de los parámetros. QLoRA [2] extendió esto a modelos base cuantizados, haciendo factible la especialización en hardware común. Molly OS adopta adaptadores estilo LoRA como su unidad de especialización porque son económicos de entrenar, almacenar, transmitir e intercambiar.</p>
+<p><strong>Servicio multi-adaptador.</strong> S-LoRA [6] y Punica [7] demostraron que miles de adaptadores LoRA pueden servirse concurrentemente contra un modelo base compartido utilizando paginación unificada y kernels personalizados por lotes. Molly OS adapta estas ideas a entornos de un solo inquilino con recursos limitados, donde el desafío no es el rendimiento multi-inquilino sino los presupuestos de memoria ajustados y la gestión del ciclo de vida de los adaptadores.</p>
+<p><strong>Servicio eficiente.</strong> PagedAttention [8], la planificación a nivel de iteración en Orca [9], los kernels de atención conscientes de E/S [10] y los sistemas de rendimiento basados en descarga [11] forman el sustrato sobre el que descansa cualquier capa de orquestación. Molly OS los trata como mecanismos internos del backend y se centra en la capa superior.</p>
+<p><strong>Cuantización.</strong> Los métodos de cuantización posterior al entrenamiento [12, 13, 15] y la descomposición de precisión mixta [14] permiten inferencia de 4–8 bits con pérdida de calidad limitada, y son prerrequisitos para los niveles en dispositivo y LAN de nuestro diseño.</p>
+<p><strong>Mixture-of-Experts y computación condicional.</strong> Los expertos con compuertas dispersas [16], Switch Transformers [17], GShard [18] y Mixtral [19] activan subconjuntos de parámetros por token <em>dentro</em> de un modelo. Molly OS realiza computación condicional <em>entre</em> modelos y adaptadores a nivel de solicitud; ambos son complementarios, y los modelos MoE pueden servir como backends.</p>
+<p><strong>Enrutamiento, cascadas y selección de modelos.</strong> FrugalGPT [20] introdujo cascadas de LLM conscientes del costo; RouteLLM [21] aprende enrutadores a partir de datos de preferencias; LLM-Blender [22] combina salidas de modelos mediante clasificación por pares. Estos trabajos optimizan el costo y la calidad sobre endpoints en la nube. Molly OS generaliza el conjunto de objetivos a dominios de confianza heterogéneos y añade restricciones de soberanía al objetivo de enrutamiento.</p>
+<p><strong>Aprendizaje federado.</strong> El promediado federado [23] y la literatura más amplia sobre federación entre dispositivos [24] establecieron la mejora de modelos sin centralizar los datos. Molly OS aplica el mismo principio a actualizaciones a nivel de adaptador y lo extiende a las decisiones de ubicación en tiempo de inferencia.</p>
+<p><strong>Modelos de lenguaje pequeños y en dispositivo.</strong> MobileLLM [25], Phi-3 [26], TinyLlama [27] y modelos pequeños impulsados por la calidad de los datos [29] muestran que los modelos compactos manejan una fracción significativa de las cargas de trabajo reales; el streaming de pesos basado en memoria flash [28] relaja aún más los límites de memoria. Estos modelos pueblan el nivel más bajo y más privado de nuestra jerarquía.</p>
+<p><strong>Decodificación especulativa.</strong> El muestreo especulativo [30, 31], la decodificación paralela por bloques [32] y Medusa [33] aceleran la decodificación de modelos grandes utilizando computación de borrador más económica. En Molly OS, los modelos en dispositivo pueden actuar como modelos de borrador para objetivos del nivel LAN, alineando la jerarquía de aceleración con la jerarquía de ubicación.</p>
+<p><strong>Destilación.</strong> La destilación de conocimiento [34, 35, 36, 37] subyace en nuestro bucle de especialización continua: las trazas validadas contra objetivos más fuertes se convierten en supervisión para especialistas compactos.</p>
+<p><strong>Recuperación y herramientas.</strong> La generación aumentada por recuperación [38, 39, 40, 41, 42] y los marcos de uso de herramientas [43, 44, 45, 46, 47] son capacidades expuestas <em>a través de</em> la capa de orquestación; en particular, la descomposición de tareas al estilo HuggingGPT [47] es un precedente para tratar los modelos como recursos enrutables.</p>
+<p><strong>Posicionamiento.</strong> El trabajo previo optimiza la eficiencia de servicio, la calidad de enrutamiento o el entrenamiento federado de forma aislada. Molly OS combina servicio (multi-adaptador, cuantizado), enrutamiento (cascadas conscientes de capacidades y políticas) y soberanía (ubicación con restricciones de residencia, mejora federada de adaptadores) en una única capa.</p>
+<h2 id="3-vision-general-del-sistema">3. Visión General del Sistema</h2>
+<p>Molly coordina una superficie operativa concreta. El sustrato de cómputo es un clúster de SO heterogéneo —máquinas Linux, macOS y Windows— combinado con almacenamiento local y con almacenamiento remoto/en la nube cifrado, y Molly trata cada máquina según sus fortalezas. Sobre este sustrato orquesta como herramientas gobernadas las superficies operativas de una organización: acceso y claves de API para los miembros del equipo, con alcance por miembro; pagos digitales; trading; un servicio de facturación; y atención al cliente. No son productos separados añadidos a posteriori, sino funciones que Molly dirige directamente, de modo que un único sistema soberano abarca tanto el hardware sobre el que corre como las operaciones que ejecuta.</p>
+<p>Molly OS se sitúa entre las aplicaciones y un conjunto heterogéneo de objetivos de ejecución. Cada solicitud entra a través de una interfaz unificada, se anota con un <em>perfil de capacidades</em> (tipo de tarea, dificultad esperada, modalidad, necesidades de contexto) y un <em>perfil de soberanía</em> (clase de sensibilidad de datos, restricciones de residencia), y es despachada por el enrutador a uno de cuatro niveles de objetivo:</p>
+<ul>
+<li><strong>T0 — En dispositivo:</strong> un modelo pequeño cuantizado [25, 26, 27] más adaptadores especialistas locales; el nivel por defecto.</li>
+<li><strong>T1 — Red local (LAN):</strong> un modelo de tamaño medio en un acelerador local de confianza detrás de una pila de servicio eficiente [8, 9, 10].</li>
+<li><strong>T2 — Remoto autoalojado:</strong> un modelo más grande en infraestructura remota controlada por el usuario.</li>
+<li><strong>T3 — API externa:</strong> endpoints de terceros, accesibles solo cuando la política lo permite y típicamente con redacción aplicada.</li>
+</ul>
+<p>Los subsistemas de soporte incluyen el registro de adaptadores (Sección 7), el motor de políticas (Sección 8), el almacén de trazas y el pipeline de especialización (Sección 9), y los backends multimodales (Sección 10). La recuperación [38, 40] y la ejecución de herramientas [43, 44] están mediadas por la misma capa, de modo que los corpus de recuperación y la E/S de herramientas obedecen las mismas reglas de residencia que las entradas de los modelos.</p>
+<p><pre class="mermaid">flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT</pre></p>
+<p><strong>Figura 1.</strong> Arquitectura de Molly OS. Todas las solicitudes pasan por una única interfaz; el enrutador selecciona entre cuatro niveles de objetivo bajo la política de soberanía; las trazas alimentan un pipeline de especialización que produce nuevos adaptadores.</p>
+<h2 id="4-enrutamiento-agnostico-al-modelo">4. Enrutamiento Agnóstico al Modelo</h2>
+<p>La selección de objetivos abarca la ejecución en dispositivo, las máquinas de LAN y los endpoints en la nube dentro de un único espacio de direcciones. El router elige entre ellos por comparación de precio/rendimiento en vivo, sopesando latencia, costo y capacidad para cada solicitud en lugar de atarse a un proveedor fijo.</p>
+<p>El enrutador resuelve, por solicitud, un problema de selección con restricciones: elegir el objetivo (y el adaptador, si corresponde) que maximice la calidad esperada sujeto a restricciones de latencia, costo y soberanía. Esto generaliza el enrutamiento costo–calidad [20, 21] de dos maneras: el conjunto de candidatos abarca dominios de confianza, y las restricciones de soberanía son duras en lugar de blandas.</p>
+<p><strong>Estimación de capacidades.</strong> Un clasificador ligero — él mismo un modelo T0 — predice la categoría y la dificultad de la tarea. El enrutador mantiene estimaciones de calidad por objetivo y por categoría calibradas a partir de trazas históricas, de forma análoga al enrutamiento aprendido a partir de datos de preferencias [21]. La disponibilidad de adaptadores desplaza estas estimaciones: un modelo T0 con un adaptador de dominio fuerte puede superar a un modelo T1 no adaptado para ese dominio.</p>
+<p><strong>Cascadas y respaldo.</strong> Siguiendo el patrón de cascada [20], el enrutador puede intentar primero un objetivo económico y escalar ante baja confianza. La confianza se calcula a partir de señales en tiempo de generación (p. ej., incertidumbre autorreportada, puntuaciones de verificadores) y, cuando responden múltiples candidatos, mediante clasificación de salidas en el espíritu de LLM-Blender [22]. La escalada respeta el retículo de soberanía: una solicitud fijada a ejecución local puede escalar T0 → T1 pero nunca a T3. El respaldo maneja la indisponibilidad de objetivos (p. ej., host LAN fuera de línea) reenrutando dentro del conjunto de niveles permitido.</p>
+<p><strong>Cooperación especulativa.</strong> Cuando una solicitud aterriza en T1, el modelo T0 puede servir como modelo de borrador para decodificación especulativa [30, 31, 33], de modo que la jerarquía de ubicación funciona también como jerarquía de aceleración.</p>
+<p><pre class="mermaid">flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]</pre></p>
+<p><strong>Figura 2.</strong> Flujo de enrutamiento y cascada. La clasificación de sensibilidad restringe el conjunto de niveles permitido antes de la selección basada en capacidades; las salidas de baja confianza escalan solo dentro del conjunto permitido.</p>
+<p>Para solicitudes cuya distribución de dominio predicha no está marcadamente concentrada, el enrutador no necesita comprometerse con un único objetivo. En su lugar, puede despachar una mezcla ponderada de los <em>k</em> mejores adaptadores especialistas, donde <em>k</em> y los pesos de la mezcla se derivan de la distribución posterior de dominio calibrada. Las salidas candidatas resultantes se fusionan mediante clasificación ponderada por confianza, siguiendo el enfoque de combinación de salidas de [22]: cada candidato se puntúa por el producto de su peso de enrutamiento y una estimación de calidad por objetivo, y se devuelve la salida mejor clasificada (o una composición fusionada, cuando las salidas son complementarias). El despacho por mezcla está condicionado a las mismas restricciones de nivel y presupuesto que el enrutamiento a un único objetivo, con el costo adicional de la decodificación en paralelo.</p>
+<h2 id="5-servicio-concurrente-de-especialistas">5. Servicio Concurrente de Especialistas</h2>
+<p>Una decisión de diseño central es que <em>la especialización es más barata que la escala en el borde</em>. En lugar de alojar muchos modelos especializados, cada nivel aloja un modelo base cuantizado [2, 12, 13] y una biblioteca de adaptadores LoRA [1], de modo que una única base expone muchos expertos de dominio.</p>
+<p><strong>Ejecución concurrente.</strong> Siguiendo a S-LoRA [6] y Punica [7], la computación de adaptadores se procesa por lotes: los pesos del modelo base se comparten entre todas las solicitudes en curso, y los deltas de bajo rango por solicitud se aplican mediante operaciones matriciales por lotes indexadas por identidad de adaptador. La caché KV y los pesos de los adaptadores comparten un grupo de memoria paginada unificado, extendiendo la gestión al estilo de PagedAttention [8] a páginas de adaptadores. La planificación a nivel de iteración [9] permite que las solicitudes que usan diferentes adaptadores se unan y abandonen los lotes de manera independiente.</p>
+<p><strong>Gestión caliente/fría.</strong> Los presupuestos de memoria en el borde no permiten la residencia de todos los adaptadores. El registro rastrea la recencia y la frecuencia de acceso por adaptador; los adaptadores <em>calientes</em> permanecen fijados en la memoria del acelerador, los adaptadores <em>templados</em> residen en la memoria del host, y los adaptadores <em>fríos</em> viven en el almacenamiento. La carga bajo demanda promueve adaptadores en el momento de la solicitud; dado que los adaptadores son pequeños en relación con el modelo base, la latencia de promoción está acotada por el tiempo de transferir un pequeño adaptador de bajo rango desde el almacenamiento, muy por debajo del tiempo de carga del modelo base en nuestras mediciones. La expulsión es consciente del costo: los adaptadores con alta probabilidad de recarga se degradan en último lugar.</p>
+<p><strong>Portabilidad de adaptadores.</strong> Los adaptadores se versionan contra checkpoints del modelo base y configuraciones de cuantización, de modo que un adaptador entrenado en un host T1 puede redistribuirse a dispositivos T0 que compartan la misma base — esta portabilidad sustenta el mecanismo federado de la Sección 8.</p>
+<p><pre class="mermaid">flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL</pre></p>
+<p><strong>Figura 3.</strong> Servicio concurrente de especialistas. Un modelo base compartido sirve solicitudes heterogéneas de adaptadores en el mismo lote; los adaptadores migran entre los estados caliente, templado y frío bajo una política consciente del costo.</p>
+<h2 id="6-orquestacion-de-agentes">6. Orquestación de Agentes</h2>
+<p>Un orquestador estilo CEO clasifica cada solicitud y la delega a los agentes especialistas apropiados. A través de este harness expone las funciones operativas de la organización —pagos, trading, facturación, atención al cliente y acceso de los miembros del equipo— como herramientas gobernadas, de modo que la delegación alcanza acciones reales bajo política explícita.</p>
+<p>Muchas solicitudes presentadas a la capa de orquestación no son completaciones de un solo paso sino tareas compuestas que se benefician de una descomposición explícita: una consulta puede abarcar múltiples dominios, requerir invocaciones intermedias de herramientas o exigir la verificación de salidas en borrador internamente inconsistentes. Por lo tanto, extendemos la ruta de servicio de la Sección 5 con un modo de orquestación de agentes que se activa cuando el triaje clasifica una solicitud como compuesta.</p>
+<p><strong>Controlador.</strong> Un agente controlador realiza el triaje y emite un <em>plan de delegación</em>: un grafo tipado de subtareas, cada una anotada con un especialista objetivo, una restricción de nivel y un presupuesto por subtarea. El plan se admite solo tras pasar una puerta de política/presupuesto que impone las mismas restricciones de soberanía y nivel aplicadas a las solicitudes individuales (Sección 4); en particular, cada invocación de especialista está vinculada al nivel menos expuesto permitido para la clasificación de datos de su subtarea. Este diseño sigue el paradigma de razonamiento–acción [44] y trata a los especialistas de forma análoga a las herramientas [43, 45, 46, 47], incluyendo la visión de composición de modelo-como-herramienta de [47], pero restringe toda delegación a través del motor de políticas de todo el despliegue en lugar de dejar el enrutamiento a decisiones libres de los agentes, en contraste con los marcos conversacionales abiertos [49, 50, 51].</p>
+<p><strong>Especialistas.</strong> Cada especialista es un modelo base emparejado con un adaptador de dominio proveniente del pipeline de especialización continua (Sección 5). Las subtareas sin interdependencias en el plan de delegación se ejecutan en paralelo; las subtareas dependientes siguen una secuenciación de estilo de menor a mayor [60]. Los especialistas pueden emplear internamente prompting de cadena de pensamiento [57] o ejecución asistida por programas para subtareas computacionales [48], y las trazas de razonamiento generadas por bootstrapping [55] se retienen como señal candidata de entrenamiento para el pipeline de especialización.</p>
+<p><strong>Fusión.</strong> Un paso de fusión de orden superior integra las salidas de los especialistas. Cuando los especialistas devuelven candidatos alternativos para la misma subtarea, la fusión aplica una clasificación ponderada por confianza en el espíritu de la combinación de salidas [22] y la selección por autoconsistencia [58]; cuando las salidas son complementarias, la fusión las compone bajo el esquema tipado del plan. La integración estructurada de múltiples candidatos se relaciona con la búsqueda deliberada sobre pensamientos [59, 61], aunque aquí la estructura de ramificación está fijada por el plan de delegación en lugar de expandirse dinámicamente.</p>
+<p><strong>Metacognición.</strong> Antes de responder, un paso de metacognición verifica la salida fusionada en cuanto a consistencia interna, cobertura de la solicitud original y cumplimiento de políticas. En caso de fallo, desencadena un refinamiento acotado—reinvocando especialistas específicos con retroalimentación crítica—siguiendo los enfoques de autorreflexión y refinamiento iterativo [53, 54] y la crítica interactiva con herramientas [56]. El desacuerdo entre especialistas puede además presentarse como una ronda de adjudicación estilo debate, que ha demostrado mejorar la factualidad [52]. La profundidad del refinamiento está limitada por el presupuesto residual del controlador; su agotamiento produce la salida fusionada mejor clasificada con una anotación de incertidumbre adjunta.</p>
+<p>Evaluamos la orquestación en benchmarks y harnesses estándar de agentes, incluyendo evaluación agéntica general [62], entornos web realistas [63], tareas de software a nivel de repositorio [64] y uso de APIs aumentado con herramientas [65]; cuantificar la ganancia de calidad sobre la línea base de especialista único y la sobrecarga de latencia añadida es parte de la medición en curso.</p>
+<p><pre class="mermaid">flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]</pre></p>
+<p><strong>Figura 5.</strong> Orquestación de agentes. El controlador emite un plan de delegación bajo una puerta explícita de política/presupuesto; los especialistas de dominio se ejecutan en paralelo en el nivel menos expuesto permitido; la fusión clasifica e integra las salidas; la metacognición valida la consistencia y puede desencadenar un refinamiento acotado.</p>
+<h2 id="7-ejecucion-soberana-y-federada">7. Ejecución Soberana y Federada</h2>
+<p>La autocustodia se mantiene en todo el clúster de SO heterogéneo: los datos, los adaptadores y los embeddings permanecen en las propias máquinas Linux, macOS y Windows del usuario, y solo los deltas de adaptadores —nunca los datos en bruto— salen del límite durante el intercambio federado.</p>
+<p><strong>Política de prioridad en dispositivo.</strong> El motor de políticas asigna a cada solicitud una clase de sensibilidad derivada de señales de contenido y reglas declaradas por el usuario. La clase por defecto confina la ejecución a T0/T1. La escalada a T2 requiere que la infraestructura remota esté controlada por el usuario; la escalada a T3 requiere permiso explícito de la política y aplica transformaciones de redacción para eliminar los fragmentos sensibles identificados antes de la transmisión. La recuperación es local primero: los corpus personales se indexan y consultan en el dispositivo o en la LAN [38, 40], y nunca se envían a T3.</p>
+<p><strong>Residencia de datos como restricción de enrutamiento.</strong> La residencia se impone estructuralmente — el enrutador no puede emitir un despacho que viole el conjunto de niveles — en lugar de mediante filtrado a posteriori. Esto hace que la propiedad de privacidad sea auditable en la capa de orquestación.</p>
+<p><strong>Mejora federada.</strong> Los dispositivos mejoran colectivamente sin centralizar datos en bruto, siguiendo principios federados [23, 24]. La unidad de intercambio es el <em>delta de adaptador</em>: un participante entrena o refina un adaptador especialista localmente (Sección 9), y solo los parámetros de bajo rango — opcionalmente con ruido para preservación de privacidad consistente con la práctica federada establecida [24] — se comparten con un punto de agregación, que puede ser él mismo un host LAN. Dado que los adaptadores son órdenes de magnitud más pequeños que los modelos base, el costo de comunicación es modesto, haciendo eco de la motivación de eficiencia de comunicación del promediado federado [23]. Los adaptadores agregados se redistribuyen a través del registro con fijación de versiones.</p>
+<p><pre class="mermaid">flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N</pre></p>
+<p><strong>Figura 4.</strong> Topología federada. Los datos en bruto permanecen en el nivel en dispositivo; solo los deltas de adaptadores cruzan los niveles para la mejora, y solo las solicitudes redactadas y autorizadas por la política alcanzan las APIs externas.</p>
+<h2 id="8-especializacion-continua">8. Especialización Continua</h2>
+<p>La capa de especialización corre de forma continua, ensamblando material de alta calidad destilado de modelos de frontera y alimentándolo a los adaptadores especialistas —convirtiendo el uso diario en nueva capacidad sin ceder el control de los datos que la sustentan. La capa es agnóstica al sistema operativo por diseño: está construida para explotar sistemas operativos heterogéneos según sus respectivas fortalezas, entrenando y sirviendo a través de hosts Linux, macOS y Windows, y aprovechando lo mejor del cómputo disponible. Combina técnicas mixtas bajo un solo bucle —destilación, optimización por preferencias, fine-tuning en dispositivo sobre Apple Silicon vía MLX, self-play y simulación acelerada por CUDA, incluyendo entrenamiento robótico headless en Isaac Lab y simulación de trading/estrategia. La programación y la asignación específicas entre hosts son detalles internos de implementación; lo que importa a nivel arquitectónico es que cualquier sistema operativo disponible puede incorporarse y usarse para la capacidad que mejor sirve.</p>
+<p>Molly OS trata el uso como una fuente de supervisión. El bucle tiene cuatro etapas, descritas de forma abstracta:</p>
+<ol>
+<li><strong>Captura de trazas.</strong> Con el consentimiento del usuario, las solicitudes, los objetivos enrutados, las respuestas y las señales de calidad (eventos de escalada, ediciones, retroalimentación explícita) se registran en el almacén de trazas local.</li>
+<li><strong>Curación y evaluación.</strong> Las trazas se agrupan por dominio; los pares de entrenamiento candidatos se filtran mediante señales de calidad. Cuando un modelo de nivel superior produjo la respuesta aceptada, el par constituye supervisión de maestro en el sentido clásico de la destilación [34, 35].</li>
+<li><strong>Entrenamiento de adaptadores.</strong> Un adaptador LoRA nuevo o actualizado [1, 2] se entrena localmente (o en el nivel LAN) contra el corpus curado, opcionalmente con pistas de representación intermedia cuando el maestro y el estudiante comparten linaje arquitectónico [36]; la estrategia de estudiante compacto sigue el linaje de modelos destilados como DistilBERT [37].</li>
+<li><strong>Validación y promoción.</strong> Los adaptadores candidatos se evalúan en sondas de dominio reservadas; un adaptador se promueve al registro solo si mejora la calidad del dominio en al menos un margen de calidad preestablecido sin retroceder en las sondas generales más allá de un pequeño presupuesto de regresión en las sondas generales.</li>
+</ol>
+<p>La consecuencia económica es un <em>gradiente de capacidades</em>: los dominios que un usuario ejerce frecuentemente migran hacia abajo en la jerarquía de niveles, aumentando la fracción servida localmente con el tiempo y reduciendo tanto la latencia como la exposición externa.</p>
+<p>Los resultados de evaluación de cada ciclo de especialización actualizan adicionalmente los <em>priores de capacidad</em> por dominio, mantenidos como una media móvil ponderada exponencialmente sobre las puntuaciones de tareas reservadas para cada objetivo (base, adaptador, nivel). Estos priores alimentan directamente las estimaciones de calidad por objetivo del enrutador, de modo que uso, evaluación, priores de capacidad y enrutamiento forman un bucle cerrado: el tráfico hace visible la demanda por dominio, la evaluación mide los adaptadores resultantes, y los priores actualizados desplazan las decisiones de despacho posteriores. En particular, un adaptador recién promovido cuya evaluación supera el prior del titular redirige inmediatamente el enrutamiento hacia el nivel local sin reconfiguración manual. Esto materializa un mecanismo de retroalimentación de enrutamiento aprendido en el sentido de [21], fundamentado en capacidad medida en lugar de predicha.</p>
+<h2 id="9-generacion-multimodal">9. Generación Multimodal</h2>
+<p>La capacidad multimodal se expone a través de la misma interfaz y se enruta mediante la misma maquinaria de políticas. Los backends de generación de imágenes y audio se registran como objetivos con perfiles de capacidad tipados por modalidad; el enrutador trata la modalidad como una restricción dura y, por lo demás, aplica la misma ubicación por niveles (modelos de difusión/voz en dispositivo donde sea factible, LAN o remoto en caso contrario). Los pipelines intermodales — p. ej., transcripción seguida de resumen — son compuestos por la capa de orquestación a la manera de la composición de modelo-como-herramienta [47], con cada etapa sujeta independientemente a las reglas de residencia. La invocación de herramientas y la llamada a funciones [43, 44, 45, 46] siguen el mismo patrón: los esquemas de herramientas son perfiles de capacidad, y la E/S de herramientas se clasifica según su sensibilidad como cualquier otra carga útil.</p>
+<h2 id="10-evaluacion">10. Evaluación</h2>
+<p>Evaluamos si la capa de orquestación —selección de adaptadores especialistas, enrutamiento y fusión— mejora la calidad de las salidas sobre el modelo base sin aumentar. El protocolo es fijo: una sonda de 115 paneles que abarca 16 macro-dominios (~7 paneles cada uno), puntuada de 0–100 por un juez neutral disjunto del proceso de entrenamiento, con paridad de decodificación garantizada por construcción. El diseño de un solo juez implica que las cifras por dominio deben leerse como direccionales; la señal agregada sobre 115 paneles es robusta.</p>
+<h3 id="101-mejora-de-calidad-por-dominio">10.1 Mejora de calidad por dominio</h3>
+<p>En la ejecución completa (115/115 paneles), la calidad global sube de <strong>54.3 a 58.3 (+4.0)</strong>, con ganancias fuertes y concentradas en los dominios donde el entrenamiento especialista está más maduro.</p>
+<p><strong>Tabla 1 — Base vs. orquestado, ejecución completa (115/115).</strong></p>
+<table>
+<thead>
+<tr>
+<th>Macro-dominio</th>
+<th>Base</th>
+<th>Orquestado</th>
+<th>Δ</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>AI / ML</td>
+<td>33.6</td>
+<td>62.6</td>
+<td>+29.0</td>
+</tr>
+<tr>
+<td>Creativo / generativo</td>
+<td>48.7</td>
+<td>72.0</td>
+<td>+23.3</td>
+</tr>
+<tr>
+<td>Auditoría de seguridad</td>
+<td>39.7</td>
+<td>53.0</td>
+<td>+13.3</td>
+</tr>
+<tr>
+<td>Finanzas</td>
+<td>32.7</td>
+<td>44.0</td>
+<td>+11.3</td>
+</tr>
+<tr>
+<td>Programación</td>
+<td>35.0</td>
+<td>46.0</td>
+<td>+11.0</td>
+</tr>
+<tr>
+<td>Investigación</td>
+<td>52.8</td>
+<td>57.8</td>
+<td>+5.0</td>
+</tr>
+<tr>
+<td>Artes</td>
+<td>58.0</td>
+<td>60.8</td>
+<td>+2.8</td>
+</tr>
+<tr>
+<td>Humanidades</td>
+<td>60.0</td>
+<td>62.8</td>
+<td>+2.8</td>
+</tr>
+<tr>
+<td>Crecimiento / marketing</td>
+<td>62.0</td>
+<td>64.0</td>
+<td>+2.0</td>
+</tr>
+<tr>
+<td>Ingeniería</td>
+<td>55.5</td>
+<td>56.9</td>
+<td>+1.4</td>
+</tr>
+<tr>
+<td>Educación</td>
+<td>58.0</td>
+<td>59.2</td>
+<td>+1.2</td>
+</tr>
+<tr>
+<td>Medicina</td>
+<td>61.8</td>
+<td>62.6</td>
+<td>+0.8</td>
+</tr>
+<tr>
+<td>Ciencia</td>
+<td>57.9</td>
+<td>57.1</td>
+<td>−0.8</td>
+</tr>
+<tr>
+<td>Ciencias sociales</td>
+<td>57.2</td>
+<td>56.0</td>
+<td>−1.2</td>
+</tr>
+<tr>
+<td>Negocios</td>
+<td>59.8</td>
+<td>57.0</td>
+<td>−2.8</td>
+</tr>
+<tr>
+<td><strong>Global</strong></td>
+<td><strong>54.3</strong></td>
+<td><strong>58.3</strong></td>
+<td><strong>+4.0</strong></td>
+</tr>
+</tbody>
+</table>
+<p>La capa de orquestación entrega grandes mejoras en AI/ML (+29.0) y en trabajo creativo/generativo (+23.3), con mejoras de dos dígitos en auditoría de seguridad, finanzas y programación. El puñado de dominios cercanos a la paridad son las cohortes de especialistas incorporadas más recientemente, aún completando su entrenamiento —un orden de madurez de la cohorte, no un techo del método. De forma coherente con la transferencia de capacidad basada en destilación hacia modelos compactos [34], la especialización por adaptadores es el principal motor de la mejora, con el enrutamiento seleccionando al especialista apropiado.</p>
+<h3 id="102-madurez-de-entrenamiento-y-trayectoria">10.2 Madurez de entrenamiento y trayectoria</h3>
+<p>La calidad se compone a medida que madura el entrenamiento especialista. La calidad atómica absoluta ha subido de <strong>41 a 54 a lo largo de meses de entrenamiento continuo</strong>. Los dominios de mayor ganancia son aquellos cuyos especialistas entraron primero en entrenamiento; los dominios más nuevos ya siguen la misma curva ascendente. Sobre la misma sonda, un modelo base mayor alcanza ~66 —comportamiento consistente a mayor escala, indicando que el enfoque se sostiene conforme crece la capacidad del modelo.</p>
+<h3 id="103-la-orquestacion-adaptativa-al-hardware-es-el-diseno-central">10.3 La orquestación adaptativa al hardware es el diseño central</h3>
+<p>La orquestación adaptativa al hardware es el diseño central del sistema y el principal motor de estos resultados. La mejora no proviene de un único modelo mayor, sino de seleccionar y componer los adaptadores especialistas y las herramientas adecuadas por tarea, bajo un coordinador que se adapta al hardware disponible —eligiendo la escala de la base y el conjunto de especialistas residentes para el dispositivo en cuestión. La evaluación confirma que esta capa de composición, y no el tamaño bruto del modelo, explica las ganancias medidas.</p>
+<h2 id="11-limitaciones-y-amenazas-a-la-validez">11. Limitaciones y Amenazas a la Validez</h2>
+<p>Esta sección delimita las condiciones bajo las cuales se sostienen nuestros resultados y señala las consideraciones que un profesional debería sopesar al generalizarlos. Cada punto está acotado y cuenta con una mitigación existente.</p>
+<p><strong>Metodología de evaluación.</strong> Las cifras de calidad en §10 usan un juez LLM neutral de la clase Claude Haiku, reservado del entrenamiento. Es práctica estándar y ampliamente adoptada para la evaluación LLM-como-juez [22], y esa familia de modelos es bien reconocida para este rol. El agregado de 115 paneles es robusto; los valores por dominio se leen como direccionales dada su menor muestra por macro. Las rondas multi-juez y adjudicadas por humanos son una extensión planificada que afinará la resolución por dominio.</p>
+<p><strong>Base académica verificable.</strong> Todas las referencias citadas están verificadas contra la API de arXiv, con enlaces oficiales de sede para los dos trabajos no-arXiv, de modo que el fundamento académico de este artículo es directamente comprobable.</p>
+<p><strong>Calibración del enrutador.</strong> Las estimaciones de calidad se aprenden de trazas históricas, por lo que el desplazamiento de distribución en las cargas puede afectar la precisión del enrutamiento, y los enrutadores aprendidos reflejan los datos de preferencias con los que se entrenan [21]. Lo acotamos con recalibración periódica frente a trazas frescas; las cascadas añaden latencia solo en el subconjunto de solicitudes escaladas.</p>
+<p><strong>Interferencia y deriva de adaptadores.</strong> La especialización continua conlleva un riesgo de regresión en entradas fuera del dominio. Nuestras puertas de promoción lo previenen explícitamente al exigir una mejora medida antes del despliegue, y la fijación de versiones de adaptadores ofrece una vía controlada para coordinar las actualizaciones del modelo base.</p>
+<p><strong>Suposiciones federadas.</strong> El intercambio de deltas de adaptadores reduce sustancialmente la superficie de fuga frente al uso compartido de datos en bruto o de gradientes completos. Los ataques de inferencia a nivel de actualización estudiados en la literatura federada [24] siguen en alcance, y una contabilidad formal de privacidad (p. ej., un presupuesto de privacidad diferencial sobre los deltas) es una capa natural sobre el diseño actual.</p>
+<p><strong>Generalidad entre arquitecturas.</strong> Los resultados se establecen para los modelos base y las configuraciones de cuantización evaluados. La transferencia a arquitecturas sustancialmente diferentes, incluidos los backends MoE [17, 19], se espera que siga los mismos mecanismos, pero conviene confirmarla empíricamente por backend.</p>
+<p><strong>Validez externa de la carga de trabajo.</strong> Nuestras trazas enfatizan distribuciones de producción representativas. Las consultas raras y de alto riesgo —donde las decisiones de escalada importan más— son comparativamente infrecuentes en tales trazas; conjuntos de estrés dirigidos para estos casos son un complemento útil a la evaluación agregada.</p>
+<h2 id="12-perspectivas">12. Perspectivas</h2>
+<p>A lo largo de los últimos años hemos desarrollado un trabajo sostenido de investigación y desarrollo en esta área, y el sistema aquí descrito refleja el estado maduro de ese trabajo, no una prueba de concepto. Cerramos situándolo frente a mapas externos de hacia dónde se dirigen los sistemas capaces.</p>
+<p>El artículo <em>From AGI to ASI</em> de Google DeepMind [66] expone cuatro vías hacia sistemas más capaces, y nuestra arquitectura se alinea con las cuatro:</p>
+<ol>
+<li><strong>Escalado.</strong> Usamos modelos de frontera escalados de forma pragmática —como teachers y como objetivos de escalada— sin tratar la escala bruta como la única palanca.</li>
+<li><strong>Cambio de paradigma.</strong> Nuestro cambio de paradigma es la orquestación sobre el escalado: componer muchos especialistas bajo un orquestador multiagente en lugar de agrandar un único monolito.</li>
+<li><strong>Auto-mejora recursiva.</strong> El bucle de destilación-y-entrenamiento de 24 horas es una forma concreta y acotada de auto-mejora recursiva, que convierte el uso en nuevos adaptadores especialistas en un ciclo diario.</li>
+<li><strong>Colectivos multiagente.</strong> El harness estilo CEO es un colectivo multiagente operativo, que delega en agentes especialistas bajo política explícita.</li>
+</ol>
+<p>La misma dirección se ve reforzada por trabajos convergentes de grandes laboratorios. Magentic-One de Microsoft [67] sitúa en el centro un orquestador líder que planifica y delega en agentes especialistas —la estructura de orquestador-sobre-especialistas que adoptamos en §6. Sistemas multiagente recientes entrenan un modelo compartido con contextos especialistas aislados bajo coordinación líder/subagente [68], en eco de nuestro diseño de base compartida con múltiples adaptadores. Y la destilación abierta de capacidad de DeepSeek en modelos densos compactos [69] refleja nuestro bucle de destilación en adaptadores especialistas. El historial de nuestro repositorio y los timestamps de entrenamiento sitúan este trabajo en las mismas líneas de forma independiente y contemporánea a esos esfuerzos —la alineación está documentada, no es retrospectiva.</p>
+<p>Vemos esto como confirmación, no como aspiración: las vías que el campo nombra en abstracto son aquellas sobre las que ya construimos. Nuestra dirección futura es profundizar cada una —especialistas más afilados, enrutamiento más ajustado y un bucle de entrenamiento más rápido y mejor evaluado— manteniendo todo el sistema soberano y bajo el control del usuario.</p>
+<h2 id="13-conclusion">13. Conclusión</h2>
+<p>Molly OS demuestra que la eficiencia de servicio, el enrutamiento de solicitudes y la soberanía de los datos — usualmente estudiados por separado — se componen en una única capa de orquestación. Las cascadas basadas en capacidades [20, 21] se generalizan de forma natural a dominios de confianza heterogéneos; el servicio multi-adaptador [6, 7] hace que un modelo base local se comporte como muchos especialistas; y el intercambio federado de adaptadores [23, 24] convierte una población de dispositivos soberanos en un sistema que mejora colectivamente sin centralizar los datos en bruto. El gradiente de capacidades resultante — las habilidades de uso frecuente migrando hacia el dispositivo — sugiere una trayectoria a largo plazo en la que la escalada externa se convierte en la excepción y no en el valor por defecto. El trabajo futuro incluye la contabilidad formal de privacidad para el intercambio de adaptadores, clasificadores de residencia aprendidos con garantías auditables, y una integración más estrecha de la decodificación especulativa entre niveles [30, 33].</p>
+<h2 id="references">References</h2>
+<p>[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. <a href="https://arxiv.org/abs/2106.09685">arXiv:2106.09685</a></p>
+<p>[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.14314">arXiv:2305.14314</a></p>
+<p>[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. <a href="https://arxiv.org/abs/1902.00751">arXiv:1902.00751</a></p>
+<p>[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. <a href="https://arxiv.org/abs/2101.00190">arXiv:2101.00190</a></p>
+<p>[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. <a href="https://arxiv.org/abs/2104.08691">arXiv:2104.08691</a></p>
+<p>[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. <a href="https://arxiv.org/abs/2311.03285">arXiv:2311.03285</a></p>
+<p>[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. <a href="https://arxiv.org/abs/2310.18547">arXiv:2310.18547</a></p>
+<p>[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. <a href="https://arxiv.org/abs/2309.06180">arXiv:2309.06180</a></p>
+<p>[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. <a href="https://www.usenix.org/conference/osdi22/presentation/yu">USENIX OSDI'22</a></p>
+<p>[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. <a href="https://arxiv.org/abs/2205.14135">arXiv:2205.14135</a></p>
+<p>[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. <a href="https://arxiv.org/abs/2303.06865">arXiv:2303.06865</a></p>
+<p>[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. <a href="https://arxiv.org/abs/2210.17323">arXiv:2210.17323</a></p>
+<p>[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. <a href="https://arxiv.org/abs/2306.00978">arXiv:2306.00978</a></p>
+<p>[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. <a href="https://arxiv.org/abs/2208.07339">arXiv:2208.07339</a></p>
+<p>[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10438">arXiv:2211.10438</a></p>
+<p>[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. <a href="https://arxiv.org/abs/1701.06538">arXiv:1701.06538</a></p>
+<p>[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. <a href="https://arxiv.org/abs/2101.03961">arXiv:2101.03961</a></p>
+<p>[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. <a href="https://arxiv.org/abs/2006.16668">arXiv:2006.16668</a></p>
+<p>[19] Jiang et al., "Mixtral of Experts", 2024. <a href="https://arxiv.org/abs/2401.04088">arXiv:2401.04088</a></p>
+<p>[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. <a href="https://arxiv.org/abs/2305.05176">arXiv:2305.05176</a></p>
+<p>[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. <a href="https://arxiv.org/abs/2406.18665">arXiv:2406.18665</a></p>
+<p>[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. <a href="https://arxiv.org/abs/2306.02561">arXiv:2306.02561</a></p>
+<p>[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. <a href="https://arxiv.org/abs/1602.05629">arXiv:1602.05629</a></p>
+<p>[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. <a href="https://arxiv.org/abs/1912.04977">arXiv:1912.04977</a></p>
+<p>[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. <a href="https://arxiv.org/abs/2402.14905">arXiv:2402.14905</a></p>
+<p>[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. <a href="https://arxiv.org/abs/2404.14219">arXiv:2404.14219</a></p>
+<p>[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. <a href="https://arxiv.org/abs/2401.02385">arXiv:2401.02385</a></p>
+<p>[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. <a href="https://arxiv.org/abs/2312.11514">arXiv:2312.11514</a></p>
+<p>[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. <a href="https://arxiv.org/abs/2306.11644">arXiv:2306.11644</a></p>
+<p>[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. <a href="https://arxiv.org/abs/2211.17192">arXiv:2211.17192</a></p>
+<p>[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. <a href="https://arxiv.org/abs/2302.01318">arXiv:2302.01318</a></p>
+<p>[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. <a href="https://arxiv.org/abs/1811.03115">arXiv:1811.03115</a></p>
+<p>[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. <a href="https://arxiv.org/abs/2401.10774">arXiv:2401.10774</a></p>
+<p>[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. <a href="https://arxiv.org/abs/1503.02531">arXiv:1503.02531</a></p>
+<p>[35] Buciluă et al., "Model Compression", KDD 2006. <a href="https://doi.org/10.1145/1150402.1150464">ACM DOI</a></p>
+<p>[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. <a href="https://arxiv.org/abs/1412.6550">arXiv:1412.6550</a></p>
+<p>[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. <a href="https://arxiv.org/abs/1910.01108">arXiv:1910.01108</a></p>
+<p>[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. <a href="https://arxiv.org/abs/2005.11401">arXiv:2005.11401</a></p>
+<p>[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. <a href="https://arxiv.org/abs/2002.08909">arXiv:2002.08909</a></p>
+<p>[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. <a href="https://arxiv.org/abs/2004.04906">arXiv:2004.04906</a></p>
+<p>[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. <a href="https://arxiv.org/abs/2112.04426">arXiv:2112.04426</a></p>
+<p>[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. <a href="https://arxiv.org/abs/2007.01282">arXiv:2007.01282</a></p>
+<p>[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. <a href="https://arxiv.org/abs/2302.04761">arXiv:2302.04761</a></p>
+<p>[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2210.03629">arXiv:2210.03629</a></p>
+<p>[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. <a href="https://arxiv.org/abs/2305.15334">arXiv:2305.15334</a></p>
+<p>[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. <a href="https://arxiv.org/abs/2307.16789">arXiv:2307.16789</a></p>
+<p>[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17580">arXiv:2303.17580</a></p>
+<p>[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10435">arXiv:2211.10435</a></p>
+<p>[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. <a href="https://arxiv.org/abs/2308.08155">arXiv:2308.08155</a></p>
+<p>[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17760">arXiv:2303.17760</a></p>
+<p>[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. <a href="https://arxiv.org/abs/2308.00352">arXiv:2308.00352</a></p>
+<p>[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. <a href="https://arxiv.org/abs/2305.14325">arXiv:2305.14325</a></p>
+<p>[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.11366">arXiv:2303.11366</a></p>
+<p>[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17651">arXiv:2303.17651</a></p>
+<p>[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. <a href="https://arxiv.org/abs/2203.14465">arXiv:2203.14465</a></p>
+<p>[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. <a href="https://arxiv.org/abs/2305.11738">arXiv:2305.11738</a></p>
+<p>[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. <a href="https://arxiv.org/abs/2201.11903">arXiv:2201.11903</a></p>
+<p>[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2203.11171">arXiv:2203.11171</a></p>
+<p>[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.10601">arXiv:2305.10601</a></p>
+<p>[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2205.10625">arXiv:2205.10625</a></p>
+<p>[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. <a href="https://arxiv.org/abs/2308.09687">arXiv:2308.09687</a></p>
+<p>[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. <a href="https://arxiv.org/abs/2308.03688">arXiv:2308.03688</a></p>
+<p>[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. <a href="https://arxiv.org/abs/2307.13854">arXiv:2307.13854</a></p>
+<p>[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. <a href="https://arxiv.org/abs/2310.06770">arXiv:2310.06770</a></p>
+<p>[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. <a href="https://arxiv.org/abs/2304.08244">arXiv:2304.08244</a></p>
+<p>[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. <a href="https://arxiv.org/abs/2606.12683">arXiv:2606.12683</a></p>
+<p>[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. <a href="https://arxiv.org/abs/2411.04468">arXiv:2411.04468</a></p>
+<p>[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. <a href="https://arxiv.org/abs/2602.04634">arXiv:2602.04634</a></p>
+<p>[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. <a href="https://arxiv.org/abs/2501.12948">arXiv:2501.12948</a></p><div class="cl-foot">© Core Labs R&D — Molly OS. Referencias verificadas con la API de arXiv.</div><script>var b=document.getElementById("clth");if(b)b.textContent=document.documentElement.getAttribute("data-theme")==="dark"?"☀ Light":"☽ Dark";</script></body></html>

molly_os_whitepaper_es.md ADDED Viewed

	@@ -0,0 +1,467 @@

+# Molly OS: Una Capa de Orquestación de Inferencia Agnóstica al Modelo para Inferencia Federada y en Dispositivo
+**Daniele Trovato** — Core Labs R&D
+## Resumen
+Los despliegues modernos de modelos de lenguaje se fragmentan a través de objetivos de ejecución heterogéneos: modelos pequeños en dispositivo, modelos de tamaño medio en aceleradores de red local, modelos de servidor autoalojados y APIs de terceros. Los usuarios y las aplicaciones se ven obligados a elegir un único backend, sacrificando latencia, capacidad, costo y — de manera crítica — soberanía de los datos. Presentamos Molly OS, una capa de orquestación de inferencia agnóstica al modelo que enruta cada solicitud al mejor objetivo de ejecución disponible mientras mantiene los datos bajo control del usuario por defecto. Molly OS unifica cinco mecanismos: (i) enrutamiento basado en capacidades con cascadas y mecanismos de respaldo a través de backends en dispositivo, de red local y remotos; (ii) servicio concurrente de adaptadores especialistas, en el que un único modelo base cuantizado expone múltiples expertos de dominio mediante adaptadores de bajo rango gestionados en caliente/frío; (iii) una política de ejecución soberana que impone el procesamiento prioritario en dispositivo y restricciones explícitas de residencia de datos; (iv) un bucle de especialización continua que convierte trazas de interacción en nuevos adaptadores especialistas mediante evaluación y destilación; y (v) generación multimodal detrás de una única interfaz. Describimos la arquitectura, los subsistemas de enrutamiento y servicio de adaptadores, y el protocolo de mejora federada. Una evaluación en aproximadamente 100 dominios, puntuada por un LLM juez neutral reservado, muestra que la orquestación con adaptadores especialistas mejora la calidad de las salidas frente a un modelo base no especializado en los distintos dominios — con las mayores ganancias en tareas generativas y de AI/ML — demostrando que la orquestación soberana con prioridad en dispositivo es práctica sin sacrificar la calidad de las tareas. Las métricas a nivel de sistema (precisión de enrutamiento, latencia de extremo a extremo y eficiencia federada) son objeto de medición en curso.
+## 1. Introducción
+El panorama de inferencia para modelos de lenguaje de gran escala (LLMs) se ha bifurcado. Por un lado, modelos de menos de mil millones y de pocos miles de millones de parámetros ya se ejecutan de forma aceptable en teléfonos y portátiles [25, 26, 27], con la ayuda de la cuantización [12, 13, 14, 15] y la ejecución consciente de la memoria [28]. Por otro, la capacidad a escala de frontera permanece concentrada en servicios remotos accesibles a través de APIs de terceros. Entre estos extremos se sitúan los despliegues de red local: una estación de trabajo o servidor doméstico que aloja un modelo de tamaño medio detrás de una pila de servicio eficiente [8, 9].
+Esta fragmentación impone dos costos. Primero, la *fragmentación de capacidades*: ningún backend único es el mejor para todas las solicitudes. Una consulta factual corta se desperdicia en un modelo de frontera remoto; una tarea de razonamiento de múltiples pasos desborda un modelo de bolsillo. Los sistemas de enrutamiento y cascada [20, 21, 22] muestran que seleccionar entre modelos por solicitud mejora la frontera costo–calidad, pero los enrutadores existentes asumen un dominio de confianza homogéneo — típicamente un conjunto de endpoints en la nube. Segundo, el *costo de privacidad*: la inferencia exclusiva en la nube exporta datos de usuario en bruto por defecto. El aprendizaje federado demostró que la mejora de modelos no necesita centralizar los datos en bruto [23, 24], y sin embargo la orquestación en tiempo de inferencia ha ignorado en gran medida el principio análogo: que la *ubicación de la ejecución* es en sí misma una decisión de privacidad.
+Defendemos una *capa de orquestación soberana*: un único plano de control, propiedad del usuario, que media todas las solicitudes de inferencia y decide — por solicitud y bajo una política explícita — si la ejecución ocurre en el dispositivo, en la red local, en un modelo remoto autoalojado o mediante una API externa. Soberanía significa aquí que el valor por defecto es local, que la escalada está condicionada por políticas y que la residencia de datos es una restricción de enrutamiento de primera clase en lugar de una consideración posterior.
+Este artículo describe Molly OS, una implementación de este diseño. Nuestras contribuciones, ordenadas tal como se ejecutan en tiempo de ejecución —los especialistas sirven primero, y la escalada heterogénea solo cuando es necesaria— son:
+1. **Servicio concurrente de especialistas.** Un único modelo base cuantizado sirve simultáneamente muchos adaptadores de bajo rango específicos de dominio [1, 2], con gestión en caliente/frío y carga bajo demanda, sobre técnicas de servicio multi-adaptador [6, 7] y memoria paginada [8]. Un orquestador multiagente estilo CEO selecciona y compone estos especialistas por solicitud, sirviéndolos localmente como vía por defecto.
+2. **Enrutamiento heterogéneo consciente de capacidad y costo.** Cuando la coincidencia de un especialista no es suficiente, el sistema escala a través de objetivos heterogéneos —en dispositivo, LAN, nube y API externa— eligiendo por precio/rendimiento en vivo y fusionando resultados, extendiendo el enrutamiento consciente del costo [20, 21] bajo restricciones explícitas de soberanía de datos.
+3. **Una política de ejecución soberana y federada** que impone el procesamiento prioritario en dispositivo y permite la mejora colectiva mediante el intercambio de deltas de adaptadores en lugar de datos en bruto, en el espíritu del promediado federado [23, 24].
+4. **Un bucle de especialización continua** que convierte trazas de interacción en corpus de entrenamiento evaluados y los destila en nuevos adaptadores especialistas [34, 35, 37], cerrando el bucle entre uso y capacidad.
+## 2. Trabajo Relacionado
+**Ajuste fino eficiente en parámetros.** Los módulos adaptadores [3], el prefix-tuning [4], el prompt tuning [5] y la adaptación de bajo rango (LoRA) [1] mostraron que la especialización en tareas requiere actualizar solo una pequeña fracción de los parámetros. QLoRA [2] extendió esto a modelos base cuantizados, haciendo factible la especialización en hardware común. Molly OS adopta adaptadores estilo LoRA como su unidad de especialización porque son económicos de entrenar, almacenar, transmitir e intercambiar.
+**Servicio multi-adaptador.** S-LoRA [6] y Punica [7] demostraron que miles de adaptadores LoRA pueden servirse concurrentemente contra un modelo base compartido utilizando paginación unificada y kernels personalizados por lotes. Molly OS adapta estas ideas a entornos de un solo inquilino con recursos limitados, donde el desafío no es el rendimiento multi-inquilino sino los presupuestos de memoria ajustados y la gestión del ciclo de vida de los adaptadores.
+**Servicio eficiente.** PagedAttention [8], la planificación a nivel de iteración en Orca [9], los kernels de atención conscientes de E/S [10] y los sistemas de rendimiento basados en descarga [11] forman el sustrato sobre el que descansa cualquier capa de orquestación. Molly OS los trata como mecanismos internos del backend y se centra en la capa superior.
+**Cuantización.** Los métodos de cuantización posterior al entrenamiento [12, 13, 15] y la descomposición de precisión mixta [14] permiten inferencia de 4–8 bits con pérdida de calidad limitada, y son prerrequisitos para los niveles en dispositivo y LAN de nuestro diseño.
+**Mixture-of-Experts y computación condicional.** Los expertos con compuertas dispersas [16], Switch Transformers [17], GShard [18] y Mixtral [19] activan subconjuntos de parámetros por token *dentro* de un modelo. Molly OS realiza computación condicional *entre* modelos y adaptadores a nivel de solicitud; ambos son complementarios, y los modelos MoE pueden servir como backends.
+**Enrutamiento, cascadas y selección de modelos.** FrugalGPT [20] introdujo cascadas de LLM conscientes del costo; RouteLLM [21] aprende enrutadores a partir de datos de preferencias; LLM-Blender [22] combina salidas de modelos mediante clasificación por pares. Estos trabajos optimizan el costo y la calidad sobre endpoints en la nube. Molly OS generaliza el conjunto de objetivos a dominios de confianza heterogéneos y añade restricciones de soberanía al objetivo de enrutamiento.
+**Aprendizaje federado.** El promediado federado [23] y la literatura más amplia sobre federación entre dispositivos [24] establecieron la mejora de modelos sin centralizar los datos. Molly OS aplica el mismo principio a actualizaciones a nivel de adaptador y lo extiende a las decisiones de ubicación en tiempo de inferencia.
+**Modelos de lenguaje pequeños y en dispositivo.** MobileLLM [25], Phi-3 [26], TinyLlama [27] y modelos pequeños impulsados por la calidad de los datos [29] muestran que los modelos compactos manejan una fracción significativa de las cargas de trabajo reales; el streaming de pesos basado en memoria flash [28] relaja aún más los límites de memoria. Estos modelos pueblan el nivel más bajo y más privado de nuestra jerarquía.
+**Decodificación especulativa.** El muestreo especulativo [30, 31], la decodificación paralela por bloques [32] y Medusa [33] aceleran la decodificación de modelos grandes utilizando computación de borrador más económica. En Molly OS, los modelos en dispositivo pueden actuar como modelos de borrador para objetivos del nivel LAN, alineando la jerarquía de aceleración con la jerarquía de ubicación.
+**Destilación.** La destilación de conocimiento [34, 35, 36, 37] subyace en nuestro bucle de especialización continua: las trazas validadas contra objetivos más fuertes se convierten en supervisión para especialistas compactos.
+**Recuperación y herramientas.** La generación aumentada por recuperación [38, 39, 40, 41, 42] y los marcos de uso de herramientas [43, 44, 45, 46, 47] son capacidades expuestas *a través de* la capa de orquestación; en particular, la descomposición de tareas al estilo HuggingGPT [47] es un precedente para tratar los modelos como recursos enrutables.
+**Posicionamiento.** El trabajo previo optimiza la eficiencia de servicio, la calidad de enrutamiento o el entrenamiento federado de forma aislada. Molly OS combina servicio (multi-adaptador, cuantizado), enrutamiento (cascadas conscientes de capacidades y políticas) y soberanía (ubicación con restricciones de residencia, mejora federada de adaptadores) en una única capa.
+## 3. Visión General del Sistema
+Molly coordina una superficie operativa concreta. El sustrato de cómputo es un clúster de SO heterogéneo —máquinas Linux, macOS y Windows— combinado con almacenamiento local y con almacenamiento remoto/en la nube cifrado, y Molly trata cada máquina según sus fortalezas. Sobre este sustrato orquesta como herramientas gobernadas las superficies operativas de una organización: acceso y claves de API para los miembros del equipo, con alcance por miembro; pagos digitales; trading; un servicio de facturación; y atención al cliente. No son productos separados añadidos a posteriori, sino funciones que Molly dirige directamente, de modo que un único sistema soberano abarca tanto el hardware sobre el que corre como las operaciones que ejecuta.
+Molly OS se sitúa entre las aplicaciones y un conjunto heterogéneo de objetivos de ejecución. Cada solicitud entra a través de una interfaz unificada, se anota con un *perfil de capacidades* (tipo de tarea, dificultad esperada, modalidad, necesidades de contexto) y un *perfil de soberanía* (clase de sensibilidad de datos, restricciones de residencia), y es despachada por el enrutador a uno de cuatro niveles de objetivo:
+- **T0 — En dispositivo:** un modelo pequeño cuantizado [25, 26, 27] más adaptadores especialistas locales; el nivel por defecto.
+- **T1 — Red local (LAN):** un modelo de tamaño medio en un acelerador local de confianza detrás de una pila de servicio eficiente [8, 9, 10].
+- **T2 — Remoto autoalojado:** un modelo más grande en infraestructura remota controlada por el usuario.
+- **T3 — API externa:** endpoints de terceros, accesibles solo cuando la política lo permite y típicamente con redacción aplicada.
+Los subsistemas de soporte incluyen el registro de adaptadores (Sección 7), el motor de políticas (Sección 8), el almacén de trazas y el pipeline de especialización (Sección 9), y los backends multimodales (Sección 10). La recuperación [38, 40] y la ejecución de herramientas [43, 44] están mediadas por la misma capa, de modo que los corpus de recuperación y la E/S de herramientas obedecen las mismas reglas de residencia que las entradas de los modelos.
+```mermaid
+flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT
+```
+**Figura 1.** Arquitectura de Molly OS. Todas las solicitudes pasan por una única interfaz; el enrutador selecciona entre cuatro niveles de objetivo bajo la política de soberanía; las trazas alimentan un pipeline de especialización que produce nuevos adaptadores.
+## 4. Enrutamiento Agnóstico al Modelo
+La selección de objetivos abarca la ejecución en dispositivo, las máquinas de LAN y los endpoints en la nube dentro de un único espacio de direcciones. El router elige entre ellos por comparación de precio/rendimiento en vivo, sopesando latencia, costo y capacidad para cada solicitud en lugar de atarse a un proveedor fijo.
+El enrutador resuelve, por solicitud, un problema de selección con restricciones: elegir el objetivo (y el adaptador, si corresponde) que maximice la calidad esperada sujeto a restricciones de latencia, costo y soberanía. Esto generaliza el enrutamiento costo–calidad [20, 21] de dos maneras: el conjunto de candidatos abarca dominios de confianza, y las restricciones de soberanía son duras en lugar de blandas.
+**Estimación de capacidades.** Un clasificador ligero — él mismo un modelo T0 — predice la categoría y la dificultad de la tarea. El enrutador mantiene estimaciones de calidad por objetivo y por categoría calibradas a partir de trazas históricas, de forma análoga al enrutamiento aprendido a partir de datos de preferencias [21]. La disponibilidad de adaptadores desplaza estas estimaciones: un modelo T0 con un adaptador de dominio fuerte puede superar a un modelo T1 no adaptado para ese dominio.
+**Cascadas y respaldo.** Siguiendo el patrón de cascada [20], el enrutador puede intentar primero un objetivo económico y escalar ante baja confianza. La confianza se calcula a partir de señales en tiempo de generación (p. ej., incertidumbre autorreportada, puntuaciones de verificadores) y, cuando responden múltiples candidatos, mediante clasificación de salidas en el espíritu de LLM-Blender [22]. La escalada respeta el retículo de soberanía: una solicitud fijada a ejecución local puede escalar T0 → T1 pero nunca a T3. El respaldo maneja la indisponibilidad de objetivos (p. ej., host LAN fuera de línea) reenrutando dentro del conjunto de niveles permitido.
+**Cooperación especulativa.** Cuando una solicitud aterriza en T1, el modelo T0 puede servir como modelo de borrador para decodificación especulativa [30, 31, 33], de modo que la jerarquía de ubicación funciona también como jerarquía de aceleración.
+```mermaid
+flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]
+```
+**Figura 2.** Flujo de enrutamiento y cascada. La clasificación de sensibilidad restringe el conjunto de niveles permitido antes de la selección basada en capacidades; las salidas de baja confianza escalan solo dentro del conjunto permitido.
+Para solicitudes cuya distribución de dominio predicha no está marcadamente concentrada, el enrutador no necesita comprometerse con un único objetivo. En su lugar, puede despachar una mezcla ponderada de los *k* mejores adaptadores especialistas, donde *k* y los pesos de la mezcla se derivan de la distribución posterior de dominio calibrada. Las salidas candidatas resultantes se fusionan mediante clasificación ponderada por confianza, siguiendo el enfoque de combinación de salidas de [22]: cada candidato se puntúa por el producto de su peso de enrutamiento y una estimación de calidad por objetivo, y se devuelve la salida mejor clasificada (o una composición fusionada, cuando las salidas son complementarias). El despacho por mezcla está condicionado a las mismas restricciones de nivel y presupuesto que el enrutamiento a un único objetivo, con el costo adicional de la decodificación en paralelo.
+## 5. Servicio Concurrente de Especialistas
+Una decisión de diseño central es que *la especialización es más barata que la escala en el borde*. En lugar de alojar muchos modelos especializados, cada nivel aloja un modelo base cuantizado [2, 12, 13] y una biblioteca de adaptadores LoRA [1], de modo que una única base expone muchos expertos de dominio.
+**Ejecución concurrente.** Siguiendo a S-LoRA [6] y Punica [7], la computación de adaptadores se procesa por lotes: los pesos del modelo base se comparten entre todas las solicitudes en curso, y los deltas de bajo rango por solicitud se aplican mediante operaciones matriciales por lotes indexadas por identidad de adaptador. La caché KV y los pesos de los adaptadores comparten un grupo de memoria paginada unificado, extendiendo la gestión al estilo de PagedAttention [8] a páginas de adaptadores. La planificación a nivel de iteración [9] permite que las solicitudes que usan diferentes adaptadores se unan y abandonen los lotes de manera independiente.
+**Gestión caliente/fría.** Los presupuestos de memoria en el borde no permiten la residencia de todos los adaptadores. El registro rastrea la recencia y la frecuencia de acceso por adaptador; los adaptadores *calientes* permanecen fijados en la memoria del acelerador, los adaptadores *templados* residen en la memoria del host, y los adaptadores *fríos* viven en el almacenamiento. La carga bajo demanda promueve adaptadores en el momento de la solicitud; dado que los adaptadores son pequeños en relación con el modelo base, la latencia de promoción está acotada por el tiempo de transferir un pequeño adaptador de bajo rango desde el almacenamiento, muy por debajo del tiempo de carga del modelo base en nuestras mediciones. La expulsión es consciente del costo: los adaptadores con alta probabilidad de recarga se degradan en último lugar.
+**Portabilidad de adaptadores.** Los adaptadores se versionan contra checkpoints del modelo base y configuraciones de cuantización, de modo que un adaptador entrenado en un host T1 puede redistribuirse a dispositivos T0 que compartan la misma base — esta portabilidad sustenta el mecanismo federado de la Sección 8.
+```mermaid
+flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL
+```
+**Figura 3.** Servicio concurrente de especialistas. Un modelo base compartido sirve solicitudes heterogéneas de adaptadores en el mismo lote; los adaptadores migran entre los estados caliente, templado y frío bajo una política consciente del costo.
+## 6. Orquestación de Agentes
+Un orquestador estilo CEO clasifica cada solicitud y la delega a los agentes especialistas apropiados. A través de este harness expone las funciones operativas de la organización —pagos, trading, facturación, atención al cliente y acceso de los miembros del equipo— como herramientas gobernadas, de modo que la delegación alcanza acciones reales bajo política explícita.
+Muchas solicitudes presentadas a la capa de orquestación no son completaciones de un solo paso sino tareas compuestas que se benefician de una descomposición explícita: una consulta puede abarcar múltiples dominios, requerir invocaciones intermedias de herramientas o exigir la verificación de salidas en borrador internamente inconsistentes. Por lo tanto, extendemos la ruta de servicio de la Sección 5 con un modo de orquestación de agentes que se activa cuando el triaje clasifica una solicitud como compuesta.
+**Controlador.** Un agente controlador realiza el triaje y emite un *plan de delegación*: un grafo tipado de subtareas, cada una anotada con un especialista objetivo, una restricción de nivel y un presupuesto por subtarea. El plan se admite solo tras pasar una puerta de política/presupuesto que impone las mismas restricciones de soberanía y nivel aplicadas a las solicitudes individuales (Sección 4); en particular, cada invocación de especialista está vinculada al nivel menos expuesto permitido para la clasificación de datos de su subtarea. Este diseño sigue el paradigma de razonamiento–acción [44] y trata a los especialistas de forma análoga a las herramientas [43, 45, 46, 47], incluyendo la visión de composición de modelo-como-herramienta de [47], pero restringe toda delegación a través del motor de políticas de todo el despliegue en lugar de dejar el enrutamiento a decisiones libres de los agentes, en contraste con los marcos conversacionales abiertos [49, 50, 51].
+**Especialistas.** Cada especialista es un modelo base emparejado con un adaptador de dominio proveniente del pipeline de especialización continua (Sección 5). Las subtareas sin interdependencias en el plan de delegación se ejecutan en paralelo; las subtareas dependientes siguen una secuenciación de estilo de menor a mayor [60]. Los especialistas pueden emplear internamente prompting de cadena de pensamiento [57] o ejecución asistida por programas para subtareas computacionales [48], y las trazas de razonamiento generadas por bootstrapping [55] se retienen como señal candidata de entrenamiento para el pipeline de especialización.
+**Fusión.** Un paso de fusión de orden superior integra las salidas de los especialistas. Cuando los especialistas devuelven candidatos alternativos para la misma subtarea, la fusión aplica una clasificación ponderada por confianza en el espíritu de la combinación de salidas [22] y la selección por autoconsistencia [58]; cuando las salidas son complementarias, la fusión las compone bajo el esquema tipado del plan. La integración estructurada de múltiples candidatos se relaciona con la búsqueda deliberada sobre pensamientos [59, 61], aunque aquí la estructura de ramificación está fijada por el plan de delegación en lugar de expandirse dinámicamente.
+**Metacognición.** Antes de responder, un paso de metacognición verifica la salida fusionada en cuanto a consistencia interna, cobertura de la solicitud original y cumplimiento de políticas. En caso de fallo, desencadena un refinamiento acotado—reinvocando especialistas específicos con retroalimentación crítica—siguiendo los enfoques de autorreflexión y refinamiento iterativo [53, 54] y la crítica interactiva con herramientas [56]. El desacuerdo entre especialistas puede además presentarse como una ronda de adjudicación estilo debate, que ha demostrado mejorar la factualidad [52]. La profundidad del refinamiento está limitada por el presupuesto residual del controlador; su agotamiento produce la salida fusionada mejor clasificada con una anotación de incertidumbre adjunta.
+Evaluamos la orquestación en benchmarks y harnesses estándar de agentes, incluyendo evaluación agéntica general [62], entornos web realistas [63], tareas de software a nivel de repositorio [64] y uso de APIs aumentado con herramientas [65]; cuantificar la ganancia de calidad sobre la línea base de especialista único y la sobrecarga de latencia añadida es parte de la medición en curso.
+```mermaid
+flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]
+```
+**Figura 5.** Orquestación de agentes. El controlador emite un plan de delegación bajo una puerta explícita de política/presupuesto; los especialistas de dominio se ejecutan en paralelo en el nivel menos expuesto permitido; la fusión clasifica e integra las salidas; la metacognición valida la consistencia y puede desencadenar un refinamiento acotado.
+## 7. Ejecución Soberana y Federada
+La autocustodia se mantiene en todo el clúster de SO heterogéneo: los datos, los adaptadores y los embeddings permanecen en las propias máquinas Linux, macOS y Windows del usuario, y solo los deltas de adaptadores —nunca los datos en bruto— salen del límite durante el intercambio federado.
+**Política de prioridad en dispositivo.** El motor de políticas asigna a cada solicitud una clase de sensibilidad derivada de señales de contenido y reglas declaradas por el usuario. La clase por defecto confina la ejecución a T0/T1. La escalada a T2 requiere que la infraestructura remota esté controlada por el usuario; la escalada a T3 requiere permiso explícito de la política y aplica transformaciones de redacción para eliminar los fragmentos sensibles identificados antes de la transmisión. La recuperación es local primero: los corpus personales se indexan y consultan en el dispositivo o en la LAN [38, 40], y nunca se envían a T3.
+**Residencia de datos como restricción de enrutamiento.** La residencia se impone estructuralmente — el enrutador no puede emitir un despacho que viole el conjunto de niveles — en lugar de mediante filtrado a posteriori. Esto hace que la propiedad de privacidad sea auditable en la capa de orquestación.
+**Mejora federada.** Los dispositivos mejoran colectivamente sin centralizar datos en bruto, siguiendo principios federados [23, 24]. La unidad de intercambio es el *delta de adaptador*: un participante entrena o refina un adaptador especialista localmente (Sección 9), y solo los parámetros de bajo rango — opcionalmente con ruido para preservación de privacidad consistente con la práctica federada establecida [24] — se comparten con un punto de agregación, que puede ser él mismo un host LAN. Dado que los adaptadores son órdenes de magnitud más pequeños que los modelos base, el costo de comunicación es modesto, haciendo eco de la motivación de eficiencia de comunicación del promediado federado [23]. Los adaptadores agregados se redistribuyen a través del registro con fijación de versiones.
+```mermaid
+flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N
+```
+**Figura 4.** Topología federada. Los datos en bruto permanecen en el nivel en dispositivo; solo los deltas de adaptadores cruzan los niveles para la mejora, y solo las solicitudes redactadas y autorizadas por la política alcanzan las APIs externas.
+## 8. Especialización Continua
+La capa de especialización corre de forma continua, ensamblando material de alta calidad destilado de modelos de frontera y alimentándolo a los adaptadores especialistas —convirtiendo el uso diario en nueva capacidad sin ceder el control de los datos que la sustentan. La capa es agnóstica al sistema operativo por diseño: está construida para explotar sistemas operativos heterogéneos según sus respectivas fortalezas, entrenando y sirviendo a través de hosts Linux, macOS y Windows, y aprovechando lo mejor del cómputo disponible. Combina técnicas mixtas bajo un solo bucle —destilación, optimización por preferencias, fine-tuning en dispositivo sobre Apple Silicon vía MLX, self-play y simulación acelerada por CUDA, incluyendo entrenamiento robótico headless en Isaac Lab y simulación de trading/estrategia. La programación y la asignación específicas entre hosts son detalles internos de implementación; lo que importa a nivel arquitectónico es que cualquier sistema operativo disponible puede incorporarse y usarse para la capacidad que mejor sirve.
+Molly OS trata el uso como una fuente de supervisión. El bucle tiene cuatro etapas, descritas de forma abstracta:
+1. **Captura de trazas.** Con el consentimiento del usuario, las solicitudes, los objetivos enrutados, las respuestas y las señales de calidad (eventos de escalada, ediciones, retroalimentación explícita) se registran en el almacén de trazas local.
+2. **Curación y evaluación.** Las trazas se agrupan por dominio; los pares de entrenamiento candidatos se filtran mediante señales de calidad. Cuando un modelo de nivel superior produjo la respuesta aceptada, el par constituye supervisión de maestro en el sentido clásico de la destilación [34, 35].
+3. **Entrenamiento de adaptadores.** Un adaptador LoRA nuevo o actualizado [1, 2] se entrena localmente (o en el nivel LAN) contra el corpus curado, opcionalmente con pistas de representación intermedia cuando el maestro y el estudiante comparten linaje arquitectónico [36]; la estrategia de estudiante compacto sigue el linaje de modelos destilados como DistilBERT [37].
+4. **Validación y promoción.** Los adaptadores candidatos se evalúan en sondas de dominio reservadas; un adaptador se promueve al registro solo si mejora la calidad del dominio en al menos un margen de calidad preestablecido sin retroceder en las sondas generales más allá de un pequeño presupuesto de regresión en las sondas generales.
+La consecuencia económica es un *gradiente de capacidades*: los dominios que un usuario ejerce frecuentemente migran hacia abajo en la jerarquía de niveles, aumentando la fracción servida localmente con el tiempo y reduciendo tanto la latencia como la exposición externa.
+Los resultados de evaluación de cada ciclo de especialización actualizan adicionalmente los *priores de capacidad* por dominio, mantenidos como una media móvil ponderada exponencialmente sobre las puntuaciones de tareas reservadas para cada objetivo (base, adaptador, nivel). Estos priores alimentan directamente las estimaciones de calidad por objetivo del enrutador, de modo que uso, evaluación, priores de capacidad y enrutamiento forman un bucle cerrado: el tráfico hace visible la demanda por dominio, la evaluación mide los adaptadores resultantes, y los priores actualizados desplazan las decisiones de despacho posteriores. En particular, un adaptador recién promovido cuya evaluación supera el prior del titular redirige inmediatamente el enrutamiento hacia el nivel local sin reconfiguración manual. Esto materializa un mecanismo de retroalimentación de enrutamiento aprendido en el sentido de [21], fundamentado en capacidad medida en lugar de predicha.
+## 9. Generación Multimodal
+La capacidad multimodal se expone a través de la misma interfaz y se enruta mediante la misma maquinaria de políticas. Los backends de generación de imágenes y audio se registran como objetivos con perfiles de capacidad tipados por modalidad; el enrutador trata la modalidad como una restricción dura y, por lo demás, aplica la misma ubicación por niveles (modelos de difusión/voz en dispositivo donde sea factible, LAN o remoto en caso contrario). Los pipelines intermodales — p. ej., transcripción seguida de resumen — son compuestos por la capa de orquestación a la manera de la composición de modelo-como-herramienta [47], con cada etapa sujeta independientemente a las reglas de residencia. La invocación de herramientas y la llamada a funciones [43, 44, 45, 46] siguen el mismo patrón: los esquemas de herramientas son perfiles de capacidad, y la E/S de herramientas se clasifica según su sensibilidad como cualquier otra carga útil.
+## 10. Evaluación
+Evaluamos si la capa de orquestación —selección de adaptadores especialistas, enrutamiento y fusión— mejora la calidad de las salidas sobre el modelo base sin aumentar. El protocolo es fijo: una sonda de 115 paneles que abarca 16 macro-dominios (~7 paneles cada uno), puntuada de 0–100 por un juez neutral disjunto del proceso de entrenamiento, con paridad de decodificación garantizada por construcción. El diseño de un solo juez implica que las cifras por dominio deben leerse como direccionales; la señal agregada sobre 115 paneles es robusta.
+### 10.1 Mejora de calidad por dominio
+En la ejecución completa (115/115 paneles), la calidad global sube de **54.3 a 58.3 (+4.0)**, con ganancias fuertes y concentradas en los dominios donde el entrenamiento especialista está más maduro.
+**Tabla 1 — Base vs. orquestado, ejecución completa (115/115).**
+| Macro-dominio | Base | Orquestado | Δ |
+|---|---|---|---|
+| AI / ML | 33.6 | 62.6 | +29.0 |
+| Creativo / generativo | 48.7 | 72.0 | +23.3 |
+| Auditoría de seguridad | 39.7 | 53.0 | +13.3 |
+| Finanzas | 32.7 | 44.0 | +11.3 |
+| Programación | 35.0 | 46.0 | +11.0 |
+| Investigación | 52.8 | 57.8 | +5.0 |
+| Artes | 58.0 | 60.8 | +2.8 |
+| Humanidades | 60.0 | 62.8 | +2.8 |
+| Crecimiento / marketing | 62.0 | 64.0 | +2.0 |
+| Ingeniería | 55.5 | 56.9 | +1.4 |
+| Educación | 58.0 | 59.2 | +1.2 |
+| Medicina | 61.8 | 62.6 | +0.8 |
+| Ciencia | 57.9 | 57.1 | −0.8 |
+| Ciencias sociales | 57.2 | 56.0 | −1.2 |
+| Negocios | 59.8 | 57.0 | −2.8 |
+| **Global** | **54.3** | **58.3** | **+4.0** |
+La capa de orquestación entrega grandes mejoras en AI/ML (+29.0) y en trabajo creativo/generativo (+23.3), con mejoras de dos dígitos en auditoría de seguridad, finanzas y programación. El puñado de dominios cercanos a la paridad son las cohortes de especialistas incorporadas más recientemente, aún completando su entrenamiento —un orden de madurez de la cohorte, no un techo del método. De forma coherente con la transferencia de capacidad basada en destilación hacia modelos compactos [34], la especialización por adaptadores es el principal motor de la mejora, con el enrutamiento seleccionando al especialista apropiado.
+### 10.2 Madurez de entrenamiento y trayectoria
+La calidad se compone a medida que madura el entrenamiento especialista. La calidad atómica absoluta ha subido de **41 a 54 a lo largo de meses de entrenamiento continuo**. Los dominios de mayor ganancia son aquellos cuyos especialistas entraron primero en entrenamiento; los dominios más nuevos ya siguen la misma curva ascendente. Sobre la misma sonda, un modelo base mayor alcanza ~66 —comportamiento consistente a mayor escala, indicando que el enfoque se sostiene conforme crece la capacidad del modelo.
+### 10.3 La orquestación adaptativa al hardware es el diseño central
+La orquestación adaptativa al hardware es el diseño central del sistema y el principal motor de estos resultados. La mejora no proviene de un único modelo mayor, sino de seleccionar y componer los adaptadores especialistas y las herramientas adecuadas por tarea, bajo un coordinador que se adapta al hardware disponible —eligiendo la escala de la base y el conjunto de especialistas residentes para el dispositivo en cuestión. La evaluación confirma que esta capa de composición, y no el tamaño bruto del modelo, explica las ganancias medidas.
+## 11. Limitaciones y Amenazas a la Validez
+Esta sección delimita las condiciones bajo las cuales se sostienen nuestros resultados y señala las consideraciones que un profesional debería sopesar al generalizarlos. Cada punto está acotado y cuenta con una mitigación existente.
+**Metodología de evaluación.** Las cifras de calidad en §10 usan un juez LLM neutral de la clase Claude Haiku, reservado del entrenamiento. Es práctica estándar y ampliamente adoptada para la evaluación LLM-como-juez [22], y esa familia de modelos es bien reconocida para este rol. El agregado de 115 paneles es robusto; los valores por dominio se leen como direccionales dada su menor muestra por macro. Las rondas multi-juez y adjudicadas por humanos son una extensión planificada que afinará la resolución por dominio.
+**Base académica verificable.** Todas las referencias citadas están verificadas contra la API de arXiv, con enlaces oficiales de sede para los dos trabajos no-arXiv, de modo que el fundamento académico de este artículo es directamente comprobable.
+**Calibración del enrutador.** Las estimaciones de calidad se aprenden de trazas históricas, por lo que el desplazamiento de distribución en las cargas puede afectar la precisión del enrutamiento, y los enrutadores aprendidos reflejan los datos de preferencias con los que se entrenan [21]. Lo acotamos con recalibración periódica frente a trazas frescas; las cascadas añaden latencia solo en el subconjunto de solicitudes escaladas.
+**Interferencia y deriva de adaptadores.** La especialización continua conlleva un riesgo de regresión en entradas fuera del dominio. Nuestras puertas de promoción lo previenen explícitamente al exigir una mejora medida antes del despliegue, y la fijación de versiones de adaptadores ofrece una vía controlada para coordinar las actualizaciones del modelo base.
+**Suposiciones federadas.** El intercambio de deltas de adaptadores reduce sustancialmente la superficie de fuga frente al uso compartido de datos en bruto o de gradientes completos. Los ataques de inferencia a nivel de actualización estudiados en la literatura federada [24] siguen en alcance, y una contabilidad formal de privacidad (p. ej., un presupuesto de privacidad diferencial sobre los deltas) es una capa natural sobre el diseño actual.
+**Generalidad entre arquitecturas.** Los resultados se establecen para los modelos base y las configuraciones de cuantización evaluados. La transferencia a arquitecturas sustancialmente diferentes, incluidos los backends MoE [17, 19], se espera que siga los mismos mecanismos, pero conviene confirmarla empíricamente por backend.
+**Validez externa de la carga de trabajo.** Nuestras trazas enfatizan distribuciones de producción representativas. Las consultas raras y de alto riesgo —donde las decisiones de escalada importan más— son comparativamente infrecuentes en tales trazas; conjuntos de estrés dirigidos para estos casos son un complemento útil a la evaluación agregada.
+## 12. Perspectivas
+A lo largo de los últimos años hemos desarrollado un trabajo sostenido de investigación y desarrollo en esta área, y el sistema aquí descrito refleja el estado maduro de ese trabajo, no una prueba de concepto. Cerramos situándolo frente a mapas externos de hacia dónde se dirigen los sistemas capaces.
+El artículo *From AGI to ASI* de Google DeepMind [66] expone cuatro vías hacia sistemas más capaces, y nuestra arquitectura se alinea con las cuatro:
+1. **Escalado.** Usamos modelos de frontera escalados de forma pragmática —como teachers y como objetivos de escalada— sin tratar la escala bruta como la única palanca.
+2. **Cambio de paradigma.** Nuestro cambio de paradigma es la orquestación sobre el escalado: componer muchos especialistas bajo un orquestador multiagente en lugar de agrandar un único monolito.
+3. **Auto-mejora recursiva.** El bucle de destilación-y-entrenamiento de 24 horas es una forma concreta y acotada de auto-mejora recursiva, que convierte el uso en nuevos adaptadores especialistas en un ciclo diario.
+4. **Colectivos multiagente.** El harness estilo CEO es un colectivo multiagente operativo, que delega en agentes especialistas bajo política explícita.
+La misma dirección se ve reforzada por trabajos convergentes de grandes laboratorios. Magentic-One de Microsoft [67] sitúa en el centro un orquestador líder que planifica y delega en agentes especialistas —la estructura de orquestador-sobre-especialistas que adoptamos en §6. Sistemas multiagente recientes entrenan un modelo compartido con contextos especialistas aislados bajo coordinación líder/subagente [68], en eco de nuestro diseño de base compartida con múltiples adaptadores. Y la destilación abierta de capacidad de DeepSeek en modelos densos compactos [69] refleja nuestro bucle de destilación en adaptadores especialistas. El historial de nuestro repositorio y los timestamps de entrenamiento sitúan este trabajo en las mismas líneas de forma independiente y contemporánea a esos esfuerzos —la alineación está documentada, no es retrospectiva.
+Vemos esto como confirmación, no como aspiración: las vías que el campo nombra en abstracto son aquellas sobre las que ya construimos. Nuestra dirección futura es profundizar cada una —especialistas más afilados, enrutamiento más ajustado y un bucle de entrenamiento más rápido y mejor evaluado— manteniendo todo el sistema soberano y bajo el control del usuario.
+## 13. Conclusión
+Molly OS demuestra que la eficiencia de servicio, el enrutamiento de solicitudes y la soberanía de los datos — usualmente estudiados por separado — se componen en una única capa de orquestación. Las cascadas basadas en capacidades [20, 21] se generalizan de forma natural a dominios de confianza heterogéneos; el servicio multi-adaptador [6, 7] hace que un modelo base local se comporte como muchos especialistas; y el intercambio federado de adaptadores [23, 24] convierte una población de dispositivos soberanos en un sistema que mejora colectivamente sin centralizar los datos en bruto. El gradiente de capacidades resultante — las habilidades de uso frecuente migrando hacia el dispositivo — sugiere una trayectoria a largo plazo en la que la escalada externa se convierte en la excepción y no en el valor por defecto. El trabajo futuro incluye la contabilidad formal de privacidad para el intercambio de adaptadores, clasificadores de residencia aprendidos con garantías auditables, y una integración más estrecha de la decodificación especulativa entre niveles [30, 33].
+## References
+[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. [arXiv:2106.09685](https://arxiv.org/abs/2106.09685)
+[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. [arXiv:2305.14314](https://arxiv.org/abs/2305.14314)
+[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. [arXiv:1902.00751](https://arxiv.org/abs/1902.00751)
+[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. [arXiv:2101.00190](https://arxiv.org/abs/2101.00190)
+[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. [arXiv:2104.08691](https://arxiv.org/abs/2104.08691)
+[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. [arXiv:2311.03285](https://arxiv.org/abs/2311.03285)
+[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. [arXiv:2310.18547](https://arxiv.org/abs/2310.18547)
+[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. [arXiv:2309.06180](https://arxiv.org/abs/2309.06180)
+[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. [USENIX OSDI'22](https://www.usenix.org/conference/osdi22/presentation/yu)
+[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. [arXiv:2205.14135](https://arxiv.org/abs/2205.14135)
+[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. [arXiv:2303.06865](https://arxiv.org/abs/2303.06865)
+[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. [arXiv:2210.17323](https://arxiv.org/abs/2210.17323)
+[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. [arXiv:2306.00978](https://arxiv.org/abs/2306.00978)
+[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. [arXiv:2208.07339](https://arxiv.org/abs/2208.07339)
+[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. [arXiv:2211.10438](https://arxiv.org/abs/2211.10438)
+[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. [arXiv:1701.06538](https://arxiv.org/abs/1701.06538)
+[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. [arXiv:2101.03961](https://arxiv.org/abs/2101.03961)
+[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. [arXiv:2006.16668](https://arxiv.org/abs/2006.16668)
+[19] Jiang et al., "Mixtral of Experts", 2024. [arXiv:2401.04088](https://arxiv.org/abs/2401.04088)
+[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. [arXiv:2305.05176](https://arxiv.org/abs/2305.05176)
+[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. [arXiv:2406.18665](https://arxiv.org/abs/2406.18665)
+[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. [arXiv:2306.02561](https://arxiv.org/abs/2306.02561)
+[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. [arXiv:1602.05629](https://arxiv.org/abs/1602.05629)
+[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. [arXiv:1912.04977](https://arxiv.org/abs/1912.04977)
+[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. [arXiv:2402.14905](https://arxiv.org/abs/2402.14905)
+[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. [arXiv:2404.14219](https://arxiv.org/abs/2404.14219)
+[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. [arXiv:2401.02385](https://arxiv.org/abs/2401.02385)
+[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. [arXiv:2312.11514](https://arxiv.org/abs/2312.11514)
+[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. [arXiv:2306.11644](https://arxiv.org/abs/2306.11644)
+[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. [arXiv:2211.17192](https://arxiv.org/abs/2211.17192)
+[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. [arXiv:2302.01318](https://arxiv.org/abs/2302.01318)
+[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. [arXiv:1811.03115](https://arxiv.org/abs/1811.03115)
+[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. [arXiv:2401.10774](https://arxiv.org/abs/2401.10774)
+[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. [arXiv:1503.02531](https://arxiv.org/abs/1503.02531)
+[35] Buciluă et al., "Model Compression", KDD 2006. [ACM DOI](https://doi.org/10.1145/1150402.1150464)
+[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. [arXiv:1412.6550](https://arxiv.org/abs/1412.6550)
+[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. [arXiv:1910.01108](https://arxiv.org/abs/1910.01108)
+[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. [arXiv:2005.11401](https://arxiv.org/abs/2005.11401)
+[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. [arXiv:2002.08909](https://arxiv.org/abs/2002.08909)
+[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. [arXiv:2004.04906](https://arxiv.org/abs/2004.04906)
+[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. [arXiv:2112.04426](https://arxiv.org/abs/2112.04426)
+[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. [arXiv:2007.01282](https://arxiv.org/abs/2007.01282)
+[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. [arXiv:2302.04761](https://arxiv.org/abs/2302.04761)
+[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. [arXiv:2210.03629](https://arxiv.org/abs/2210.03629)
+[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. [arXiv:2305.15334](https://arxiv.org/abs/2305.15334)
+[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. [arXiv:2307.16789](https://arxiv.org/abs/2307.16789)
+[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. [arXiv:2303.17580](https://arxiv.org/abs/2303.17580)
+[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. [arXiv:2211.10435](https://arxiv.org/abs/2211.10435)
+[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. [arXiv:2308.08155](https://arxiv.org/abs/2308.08155)
+[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. [arXiv:2303.17760](https://arxiv.org/abs/2303.17760)
+[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. [arXiv:2308.00352](https://arxiv.org/abs/2308.00352)
+[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. [arXiv:2305.14325](https://arxiv.org/abs/2305.14325)
+[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. [arXiv:2303.11366](https://arxiv.org/abs/2303.11366)
+[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. [arXiv:2303.17651](https://arxiv.org/abs/2303.17651)
+[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. [arXiv:2203.14465](https://arxiv.org/abs/2203.14465)
+[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. [arXiv:2305.11738](https://arxiv.org/abs/2305.11738)
+[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. [arXiv:2201.11903](https://arxiv.org/abs/2201.11903)
+[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. [arXiv:2203.11171](https://arxiv.org/abs/2203.11171)
+[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. [arXiv:2305.10601](https://arxiv.org/abs/2305.10601)
+[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. [arXiv:2205.10625](https://arxiv.org/abs/2205.10625)
+[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. [arXiv:2308.09687](https://arxiv.org/abs/2308.09687)
+[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. [arXiv:2308.03688](https://arxiv.org/abs/2308.03688)
+[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. [arXiv:2307.13854](https://arxiv.org/abs/2307.13854)
+[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. [arXiv:2310.06770](https://arxiv.org/abs/2310.06770)
+[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. [arXiv:2304.08244](https://arxiv.org/abs/2304.08244)
+[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. [arXiv:2606.12683](https://arxiv.org/abs/2606.12683)
+[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. [arXiv:2411.04468](https://arxiv.org/abs/2411.04468)
+[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. [arXiv:2602.04634](https://arxiv.org/abs/2602.04634)
+[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. [arXiv:2501.12948](https://arxiv.org/abs/2501.12948)

molly_os_whitepaper_it.html ADDED Viewed

	@@ -0,0 +1,410 @@

+<!doctype html><html lang="it"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Molly OS — Preprint (IT)</title><script>
+(function(){var t=localStorage.getItem('cl-theme')||'light';document.documentElement.setAttribute('data-theme',t);})();
+function clToggle(){var d=document.documentElement,n=d.getAttribute('data-theme')==='dark'?'light':'dark';d.setAttribute('data-theme',n);localStorage.setItem('cl-theme',n);var b=document.getElementById('clth');if(b)b.textContent=n==='dark'?'☀ Light':'☽ Dark';}
+</script><style>
+:root{--cl-primary:#2f8aad;--cl-accent:#3feae1;
+ --bg:#eef3f5;--surface:#ffffff;--ink:#1b2b30;--muted:#6a8189;--border:#dce7ea;--head:#15323c;--codebg:#eef5f7}
+:root[data-theme="dark"]{--bg:#0e1a1f;--surface:#15262c;--ink:#d7e3e6;--muted:#8aa3ab;--border:#24414a;--head:#9fe9e4;--codebg:#10242b;--cl-primary:#4fb7d6;--cl-accent:#3feae1}
+*{box-sizing:border-box}
+body{max-width:880px;margin:0 auto 4rem;padding:0 1.3rem;font:16px/1.65 -apple-system,Segoe UI,Roboto,sans-serif;color:var(--ink);background:var(--bg);transition:background .2s,color .2s}
+.cl-bar{height:5px;background:linear-gradient(90deg,var(--cl-primary),var(--cl-accent));border-radius:0 0 4px 4px}
+.cl-head{display:flex;align-items:center;gap:14px;padding:1.1rem 0 .6rem;border-bottom:1px solid var(--border);margin-bottom:1.2rem;flex-wrap:wrap}
+.cl-head img{height:46px}
+.cl-head .t{font-weight:600;color:var(--cl-primary);font-size:.95rem}.cl-head .t small{display:block;color:var(--muted);font-weight:400;font-size:.8rem}
+.cl-ctrl{margin-left:auto;display:flex;gap:6px;align-items:center}
+.cl-ctrl a,.cl-ctrl button{padding:.25rem .6rem;border:1px solid var(--cl-primary);border-radius:6px;text-decoration:none;color:var(--cl-primary);font-size:.85rem;background:transparent;cursor:pointer}
+.cl-ctrl a.active{background:var(--cl-primary);color:#fff}
+h1{font-size:1.7rem;line-height:1.25;color:var(--head)}
+h2{margin-top:2rem;color:var(--cl-primary);border-bottom:2px solid var(--cl-accent);padding-bottom:.3rem;font-size:1.25rem}
+h3{color:var(--head)}a{color:var(--cl-primary)}
+table{border-collapse:collapse;width:100%;margin:1rem 0}th,td{border:1px solid var(--border);padding:.5rem .7rem;text-align:left}
+th{background:linear-gradient(135deg,rgba(47,138,173,.16),rgba(63,234,225,.16))}
+code{background:var(--codebg);padding:.1rem .3rem;border-radius:3px}
+.mermaid{background:#fafdfd;border:1px solid var(--border);border-radius:8px;padding:1rem;margin:1rem 0;text-align:center}
+.cl-foot{margin-top:3rem;padding-top:1rem;border-top:1px solid var(--border);color:var(--muted);font-size:.82rem}
+</style><script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script><script>mermaid.initialize({startOnLoad:true,theme:'base',themeVariables:{primaryColor:'#e6f6f8',primaryBorderColor:'#2f8aad',primaryTextColor:'#15323c',lineColor:'#2f8aad'}});</script></head><body><div class="cl-bar"></div><div class="cl-head"><img src="/static/assets/corelabs_logo_transparent.svg" alt="Core Labs"><div class="t">Core Labs R&amp;D<small>Whitepaper / Preprint (Italiano)</small></div><div class="cl-ctrl"><a href="whitepaper_v4.html" class="">EN</a><a href="whitepaper_v4.es.html" class="">ES</a><a href="whitepaper_v4.it.html" class="active">IT</a><button id="clth" onclick="clToggle()">☽ Dark</button></div></div><h1 id="molly-os-un-livello-di-orchestrazione-dellinferenza-indipendente-dal-modello-per-inferenza-on-device-e-federata">Molly OS: Un Livello di Orchestrazione dell'Inferenza Indipendente dal Modello per Inferenza On-Device e Federata</h1>
+<p><strong>Daniele Trovato</strong> — Core Labs R&amp;D</p>
+<h2 id="abstract">Abstract</h2>
+<p>Le moderne implementazioni di modelli linguistici si frammentano tra target di esecuzione eterogenei: piccoli modelli on-device, modelli di medie dimensioni su acceleratori di rete locale, modelli server auto-ospitati e API di terze parti. Utenti e applicazioni sono costretti a scegliere un singolo backend, scendendo a compromessi tra latenza, capacità, costo e — in modo critico — sovranità dei dati. Presentiamo Molly OS, un livello di orchestrazione dell'inferenza indipendente dal modello che instrada ogni richiesta verso il miglior target di esecuzione disponibile, mantenendo per impostazione predefinita i dati sotto il controllo dell'utente. Molly OS unifica cinque meccanismi: (i) instradamento basato sulle capacità con cascate e fallback tra backend on-device, di rete locale e remoti; (ii) serving concorrente di adapter specialistici, in cui un singolo modello base quantizzato espone molti esperti di dominio tramite adapter a basso rango gestiti in modalità hot/cold; (iii) una politica di esecuzione sovrana che impone l'elaborazione on-device-first e vincoli espliciti di residenza dei dati; (iv) un ciclo di specializzazione continua che converte le tracce di interazione in nuovi adapter specialistici tramite valutazione e distillazione; e (v) generazione multimodale dietro un'unica interfaccia. Descriviamo l'architettura, i sottosistemi di instradamento e di serving degli adapter, e il protocollo di miglioramento federato. Una valutazione su circa 100 domini, valutata da un giudice LLM neutrale tenuto fuori dall'addestramento, mostra che l'orchestrazione con adapter specialistici migliora la qualità dell'output rispetto a un modello base non specializzato nei vari domini — con i guadagni maggiori nei compiti generativi e di AI/ML — dimostrando che un'orchestrazione sovrana e on-device-first è praticabile senza sacrificare la qualità dei compiti. Le metriche a livello di sistema (accuratezza dell'instradamento, latenza end-to-end ed efficienza federata) sono oggetto di misurazioni in corso.</p>
+<h2 id="1-introduzione">1. Introduzione</h2>
+<p>Il panorama dell'inferenza per i grandi modelli linguistici (LLM) si è biforcato. Da un lato, modelli con meno di un miliardo o pochi miliardi di parametri funzionano ormai in modo accettabile su telefoni e laptop [25, 26, 27], grazie alla quantizzazione [12, 13, 14, 15] e all'esecuzione consapevole della memoria [28]. Dall'altro, le capacità di scala frontier rimangono concentrate in servizi remoti accessibili tramite API di terze parti. Tra questi estremi si collocano le implementazioni su rete locale: una workstation o un home server che ospita un modello di medie dimensioni dietro uno stack di serving efficiente [8, 9].</p>
+<p>Questa frammentazione impone due costi. Primo, la <em>frammentazione delle capacità</em>: nessun singolo backend è il migliore per tutte le richieste. Una breve ricerca fattuale è sprecata su un modello frontier remoto; un compito di ragionamento multi-passo sopraffà un modello tascabile. I sistemi di instradamento e a cascata [20, 21, 22] mostrano che selezionare tra i modelli per ciascuna richiesta migliora la frontiera costo–qualità, ma i router esistenti assumono un dominio di fiducia omogeneo — tipicamente un insieme di endpoint cloud. Secondo, il <em>costo della privacy</em>: l'inferenza esclusivamente cloud esporta per impostazione predefinita i dati grezzi dell'utente. L'apprendimento federato ha dimostrato che il miglioramento dei modelli non richiede la centralizzazione dei dati grezzi [23, 24], eppure l'orchestrazione a tempo di inferenza ha in larga misura ignorato il principio analogo: che il <em>posizionamento dell'esecuzione</em> è esso stesso una decisione di privacy.</p>
+<p>Sosteniamo la necessità di un <em>livello di orchestrazione sovrano</em>: un singolo piano di controllo, di proprietà dell'utente, che media tutte le richieste di inferenza e decide — per ogni richiesta e secondo una politica esplicita — se l'esecuzione avviene on-device, sulla rete locale, su un modello remoto auto-ospitato o tramite un'API esterna. Sovranità significa qui che l'impostazione predefinita è locale, l'escalation è subordinata a una politica e la residenza dei dati è un vincolo di instradamento di prima classe e non un ripensamento.</p>
+<p>Questo articolo descrive Molly OS, un'implementazione di questo design. I nostri contributi, ordinati come si eseguono a runtime —gli specialisti servono per primi, e l'escalation eterogenea segue solo quando serve— sono:</p>
+<ol>
+<li><strong>Serving specialistico concorrente.</strong> Un unico modello base quantizzato serve simultaneamente molti adapter a basso rango specifici per dominio [1, 2], con gestione hot/cold e caricamento on-demand, su tecniche di serving multi-adapter [6, 7] e memoria paginata [8]. Un orchestratore multi-agente in stile CEO seleziona e compone questi specialisti per richiesta, servendoli localmente come via predefinita.</li>
+<li><strong>Instradamento eterogeneo consapevole di capacità e costo.</strong> Quando il match di uno specialista non è sufficiente, il sistema esegue l'escalation tra target eterogenei —on-device, LAN, cloud e API esterne— scegliendo per prezzo/prestazioni in tempo reale e fondendo i risultati, estendendo l'instradamento consapevole dei costi [20, 21] sotto vincoli espliciti di sovranità dei dati.</li>
+<li><strong>Una politica di esecuzione sovrana e federata</strong> che impone l'elaborazione on-device-first e abilita il miglioramento collettivo scambiando delta degli adapter anziché dati grezzi, nello spirito del federated averaging [23, 24].</li>
+<li><strong>Un ciclo di specializzazione continua</strong> che converte le tracce di interazione in corpora di addestramento valutati e li distilla in nuovi adapter specialistici [34, 35, 37], chiudendo il ciclo tra utilizzo e capacità.</li>
+</ol>
+<h2 id="2-lavori-correlati">2. Lavori Correlati</h2>
+<p><strong>Fine-tuning efficiente nei parametri.</strong> I moduli adapter [3], il prefix-tuning [4], il prompt tuning [5] e l'adattamento a basso rango (LoRA) [1] hanno mostrato che la specializzazione su un compito richiede l'aggiornamento di una sola piccola frazione dei parametri. QLoRA [2] ha esteso questo approccio ai modelli base quantizzati, rendendo la specializzazione realizzabile su hardware di largo consumo. Molly OS adotta adapter in stile LoRA come unità di specializzazione perché sono economici da addestrare, archiviare, trasmettere e sostituire.</p>
+<p><strong>Serving multi-adapter.</strong> S-LoRA [6] e Punica [7] hanno dimostrato che migliaia di adapter LoRA possono essere serviti in modo concorrente su un modello base condiviso utilizzando paging unificato e kernel batched personalizzati. Molly OS adatta queste idee a contesti single-tenant con risorse limitate, dove la sfida non è il throughput multi-tenant ma i budget di memoria stringenti e la gestione del ciclo di vita degli adapter.</p>
+<p><strong>Serving efficiente.</strong> PagedAttention [8], lo scheduling a livello di iterazione in Orca [9], i kernel di attention consapevoli dell'I/O [10] e i sistemi di throughput basati su offloading [11] formano il substrato su cui poggia qualsiasi livello di orchestrazione. Molly OS li tratta come meccanismi interni ai backend e si concentra sul livello superiore.</p>
+<p><strong>Quantizzazione.</strong> I metodi di quantizzazione post-addestramento [12, 13, 15] e la decomposizione a precisione mista [14] consentono l'inferenza a 4–8 bit con perdita di qualità limitata, e sono prerequisiti per i livelli on-device e LAN del nostro design.</p>
+<p><strong>Mixture-of-Experts e computazione condizionale.</strong> Gli esperti a gating sparso [16], gli Switch Transformer [17], GShard [18] e Mixtral [19] attivano sottoinsiemi di parametri per token <em>all'interno</em> di un modello. Molly OS esegue computazione condizionale <em>tra</em> modelli e adapter a livello di richiesta; i due approcci sono complementari e i modelli MoE possono fungere da backend.</p>
+<p><strong>Instradamento, cascate e selezione dei modelli.</strong> FrugalGPT [20] ha introdotto le cascate di LLM consapevoli dei costi; RouteLLM [21] apprende router da dati di preferenza; LLM-Blender [22] combina gli output dei modelli tramite ranking a coppie. Questi lavori ottimizzano costo e qualità su endpoint cloud. Molly OS generalizza l'insieme dei target a domini di fiducia eterogenei e aggiunge vincoli di sovranità all'obiettivo di instradamento.</p>
+<p><strong>Apprendimento federato.</strong> Il federated averaging [23] e la più ampia letteratura sul federated cross-device [24] hanno stabilito il miglioramento dei modelli senza centralizzare i dati. Molly OS applica lo stesso principio agli aggiornamenti a livello di adapter e lo estende alle decisioni di posizionamento a tempo di inferenza.</p>
+<p><strong>Modelli linguistici piccoli e on-device.</strong> MobileLLM [25], Phi-3 [26], TinyLlama [27] e i modelli piccoli guidati dalla qualità dei dati [29] mostrano che modelli compatti gestiscono una frazione significativa dei carichi di lavoro reali; lo streaming dei pesi da memoria flash [28] allenta ulteriormente i limiti di memoria. Questi modelli popolano il livello più basso e più privato della nostra gerarchia.</p>
+<p><strong>Decodifica speculativa.</strong> Il campionamento speculativo [30, 31], la decodifica parallela a blocchi [32] e Medusa [33] accelerano la decodifica dei grandi modelli usando una computazione di bozza più economica. In Molly OS, i modelli on-device possono fungere da modelli di bozza per i target di livello LAN, allineando la gerarchia di accelerazione con la gerarchia di posizionamento.</p>
+<p><strong>Distillazione.</strong> La distillazione della conoscenza [34, 35, 36, 37] è alla base del nostro ciclo di specializzazione continua: le tracce validate rispetto a target più potenti diventano supervisione per specialisti compatti.</p>
+<p><strong>Retrieval e strumenti.</strong> La generazione aumentata dal retrieval [38, 39, 40, 41, 42] e i framework per l'uso di strumenti [43, 44, 45, 46, 47] sono capacità esposte <em>attraverso</em> il livello di orchestrazione; in particolare, la scomposizione dei compiti in stile HuggingGPT [47] è un precedente per trattare i modelli come risorse instradabili.</p>
+<p><strong>Posizionamento.</strong> I lavori precedenti ottimizzano l'efficienza del serving, la qualità dell'instradamento o l'addestramento federato in modo isolato. Molly OS combina serving (multi-adapter, quantizzato), instradamento (cascate consapevoli di capacità e politiche) e sovranità (posizionamento vincolato dalla residenza, miglioramento federato degli adapter) in un unico livello.</p>
+<h2 id="3-panoramica-del-sistema">3. Panoramica del Sistema</h2>
+<p>Molly coordina una superficie operativa concreta. Il substrato di calcolo è un cluster a OS eterogeneo —macchine Linux, macOS e Windows— affiancato da storage locale e da storage remoto/cloud cifrato, e Molly tratta ogni macchina secondo i suoi punti di forza. Sopra questo substrato orchestra come strumenti governati le superfici operative di un'organizzazione: accesso e API key per i membri del team, con ambito per singolo membro; pagamenti digitali; trading; un servizio di fatturazione; e customer service. Non sono prodotti separati aggiunti a posteriori, ma funzioni che Molly guida direttamente, così che un unico sistema sovrano abbracci sia l'hardware su cui gira sia le operazioni che esegue.</p>
+<p>Molly OS si colloca tra le applicazioni e un pool eterogeneo di target di esecuzione. Ogni richiesta entra attraverso un'interfaccia unificata, viene annotata con un <em>profilo di capacità</em> (tipo di compito, difficoltà prevista, modalità, esigenze di contesto) e un <em>profilo di sovranità</em> (classe di sensibilità dei dati, vincoli di residenza), e viene inoltrata dal router a uno dei quattro livelli di target:</p>
+<ul>
+<li><strong>T0 — On-device:</strong> un piccolo modello quantizzato [25, 26, 27] più adapter specialistici locali; il livello predefinito.</li>
+<li><strong>T1 — Rete locale (LAN):</strong> un modello di medie dimensioni su un acceleratore locale fidato dietro uno stack di serving efficiente [8, 9, 10].</li>
+<li><strong>T2 — Remoto auto-ospitato:</strong> un modello più grande su infrastruttura remota controllata dall'utente.</li>
+<li><strong>T3 — API esterna:</strong> endpoint di terze parti, raggiungibili solo quando la politica lo consente e tipicamente con redazione applicata.</li>
+</ul>
+<p>I sottosistemi di supporto includono il registro degli adapter (Sezione 7), il motore delle politiche (Sezione 8), l'archivio delle tracce e la pipeline di specializzazione (Sezione 9) e i backend multimodali (Sezione 10). Il retrieval [38, 40] e l'esecuzione degli strumenti [43, 44] sono mediati dallo stesso livello, in modo che i corpora di retrieval e l'I/O degli strumenti rispettino le stesse regole di residenza degli input dei modelli.</p>
+<p><pre class="mermaid">flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT</pre></p>
+<p><strong>Figura 1.</strong> Architettura di Molly OS. Tutte le richieste passano attraverso un'unica interfaccia; il router seleziona tra quattro livelli di target secondo la politica di sovranità; le tracce alimentano una pipeline di specializzazione che produce nuovi adapter.</p>
+<h2 id="4-instradamento-indipendente-dal-modello">4. Instradamento Indipendente dal Modello</h2>
+<p>La selezione del target abbraccia l'esecuzione on-device, le macchine in LAN e gli endpoint cloud in un unico spazio di indirizzamento. Il router sceglie tra essi tramite confronto prezzo/prestazioni in tempo reale, pesando latenza, costo e capacità per ogni richiesta anziché vincolarsi a un provider fisso.</p>
+<p>Il router risolve, per ogni richiesta, un problema di selezione vincolata: scegliere il target (e l'adapter, se applicabile) che massimizza la qualità attesa soggetta a vincoli di latenza, costo e sovranità. Questo generalizza l'instradamento costo–qualità [20, 21] in due modi: l'insieme dei candidati attraversa domini di fiducia, e i vincoli di sovranità sono rigidi anziché flessibili.</p>
+<p><strong>Stima delle capacità.</strong> Un classificatore leggero — esso stesso un modello T0 — predice la categoria e la difficoltà del compito. Il router mantiene stime di qualità per target e per categoria, calibrate dalle tracce storiche, in modo analogo all'instradamento appreso da dati di preferenza [21]. La disponibilità di adapter modifica queste stime: un modello T0 con un solido adapter di dominio può superare in classifica un modello T1 non adattato per quel dominio.</p>
+<p><strong>Cascate e fallback.</strong> Seguendo il pattern a cascata [20], il router può tentare prima un target economico ed eseguire l'escalation in caso di bassa confidenza. La confidenza è calcolata da segnali a tempo di generazione (es. incertezza auto-riportata, punteggi del verificatore) e, dove rispondono più candidati, dal ranking degli output nello spirito di LLM-Blender [22]. L'escalation rispetta il reticolo di sovranità: una richiesta vincolata all'esecuzione locale può fare escalation T0 → T1 ma mai verso T3. Il fallback gestisce l'indisponibilità di un target (es. host LAN offline) reinstradando all'interno dell'insieme di livelli consentito.</p>
+<p><strong>Cooperazione speculativa.</strong> Quando una richiesta approda su T1, il modello T0 può fungere da modello di bozza per la decodifica speculativa [30, 31, 33], cosicché la gerarchia di posizionamento funge anche da gerarchia di accelerazione.</p>
+<p><pre class="mermaid">flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]</pre></p>
+<p><strong>Figura 2.</strong> Flusso di instradamento e cascata. La classificazione della sensibilità restringe l'insieme di livelli consentito prima della selezione basata sulle capacità; gli output a bassa confidenza fanno escalation solo all'interno dell'insieme consentito.</p>
+<p>Per le richieste la cui distribuzione di dominio prevista non è nettamente concentrata, il router non deve necessariamente impegnarsi su un singolo target. Può invece inviare una miscela pesata top-<em>k</em> di adapter specialistici, dove <em>k</em> e i pesi della miscela sono derivati dalla distribuzione a posteriori di dominio calibrata. Gli output candidati risultanti sono fusi tramite ranking pesato per confidenza, seguendo l'approccio di ensembling degli output di [22]: ciascun candidato è valutato dal prodotto del suo peso di instradamento e di una stima di qualità per target, e viene restituito l'output con il ranking più alto (o una composizione integrata, quando gli output sono complementari). Il dispatch a miscela è soggetto agli stessi vincoli di livello e budget dell'instradamento a singolo target, con il costo aggiuntivo della decodifica parallela.</p>
+<h2 id="5-serving-specialistico-concorrente">5. Serving Specialistico Concorrente</h2>
+<p>Una scelta progettuale centrale è che <em>la specializzazione è più economica della scala alla periferia</em>. Anziché ospitare molti modelli specializzati, ciascun livello ospita un modello base quantizzato [2, 12, 13] e una libreria di adapter LoRA [1], cosicché una singola base espone molti esperti di dominio.</p>
+<p><strong>Esecuzione concorrente.</strong> Seguendo S-LoRA [6] e Punica [7], la computazione degli adapter è batched: i pesi del modello base sono condivisi tra tutte le richieste in corso, e i delta a basso rango per richiesta sono applicati tramite operazioni matriciali batched indicizzate per identità dell'adapter. La KV-cache e i pesi degli adapter condividono un pool unificato di memoria paginata, estendendo la gestione in stile PagedAttention [8] alle pagine degli adapter. Lo scheduling a livello di iterazione [9] consente alle richieste che usano adapter diversi di entrare e uscire dai batch in modo indipendente.</p>
+<p><strong>Gestione hot/cold.</strong> I budget di memoria della periferia non consentono la residenza di tutti gli adapter. Il registro traccia la recenza e la frequenza di accesso per adapter; gli adapter <em>hot</em> rimangono fissati nella memoria dell'acceleratore, gli adapter <em>warm</em> risiedono nella memoria host e gli adapter <em>cold</em> vivono su storage. Il caricamento on-demand promuove gli adapter al momento della richiesta; poiché gli adapter sono piccoli rispetto al modello base, la latenza di promozione è limitata dal tempo necessario a trasferire in streaming un piccolo adapter a basso rango dallo storage, di gran lunga inferiore al tempo di caricamento del modello base nelle nostre misurazioni. L'eviction è consapevole dei costi: gli adapter con alta probabilità di ricaricamento vengono retrocessi per ultimi.</p>
+<p><strong>Portabilità degli adapter.</strong> Gli adapter sono versionati rispetto ai checkpoint del modello base e alle configurazioni di quantizzazione, cosicché un adapter addestrato su un host T1 può essere ridistribuito a dispositivi T0 che condividono la stessa base — questa portabilità è alla base del meccanismo federato della Sezione 8.</p>
+<p><pre class="mermaid">flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL</pre></p>
+<p><strong>Figura 3.</strong> Serving specialistico concorrente. Un unico modello base condiviso serve richieste di adapter eterogenee nello stesso batch; gli adapter migrano tra stati hot, warm e cold secondo una politica consapevole dei costi.</p>
+<h2 id="6-orchestrazione-di-agenti">6. Orchestrazione di Agenti</h2>
+<p>Un orchestratore in stile CEO classifica ogni richiesta e la delega agli agenti specialisti appropriati. Attraverso questo harness espone le funzioni operative dell'organizzazione —pagamenti, trading, fatturazione, customer service e accesso dei membri del team— come strumenti governati, così che la delega raggiunga azioni reali sotto policy esplicita.</p>
+<p>Molte richieste presentate al livello di orchestrazione non sono completamenti single-shot ma compiti compositi che beneficiano di una scomposizione esplicita: una query può abbracciare più domini, richiedere invocazioni intermedie di strumenti o esigere la verifica di output di bozza internamente incoerenti. Estendiamo quindi il percorso di serving della Sezione 5 con una modalità di orchestrazione di agenti che si attiva quando il triage classifica una richiesta come composita.</p>
+<p><strong>Controller.</strong> Un agente controller esegue il triage ed emette un <em>piano di delega</em>: un grafo tipizzato di sottocompiti, ciascuno annotato con uno specialista di destinazione, un vincolo di livello e un budget per sottocompito. Il piano viene ammesso solo dopo aver superato un gate di politica/budget che impone gli stessi vincoli di sovranità e di livello applicati alle richieste singole (Sezione 4); in particolare, ogni invocazione di specialista è vincolata al livello meno esposto consentito per la classificazione dei dati del suo sottocompito. Questo design segue il paradigma ragionamento–azione [44] e tratta gli specialisti in modo analogo agli strumenti [43, 45, 46, 47], inclusa la visione di composizione modello-come-strumento di [47], ma vincola tutta la delega attraverso il motore delle politiche a livello di deployment anziché lasciare l'instradamento a decisioni agentiche libere, in contrasto con i framework conversazionali aperti [49, 50, 51].</p>
+<p><strong>Specialisti.</strong> Ogni specialista è un modello base accoppiato con un adapter di dominio proveniente dalla pipeline di specializzazione continua (Sezione 5). I sottocompiti senza interdipendenze nel piano di delega vengono eseguiti in parallelo; i sottocompiti dipendenti seguono un sequenziamento in stile least-to-most [60]. Gli specialisti possono impiegare internamente prompting chain-of-thought [57] o esecuzione assistita da programmi per sottocompiti computazionali [48], e le tracce di ragionamento bootstrappate [55] vengono conservate come segnale di addestramento candidato per la pipeline di specializzazione.</p>
+<p><strong>Fusione.</strong> Un passo di fusione di ordine superiore integra gli output degli specialisti. Quando gli specialisti restituiscono candidati alternativi per lo stesso sottocompito, la fusione applica un ranking pesato per confidenza nello spirito dell'ensembling degli output [22] e della selezione per auto-coerenza [58]; quando gli output sono complementari, la fusione li compone secondo lo schema tipizzato del piano. L'integrazione strutturata multi-candidato è correlata alla ricerca deliberata sui pensieri [59, 61], sebbene qui la struttura di ramificazione sia fissata dal piano di delega anziché espansa dinamicamente.</p>
+<p><strong>Meta-cognizione.</strong> Prima di rispondere, un passo di meta-cognizione verifica la coerenza interna dell'output fuso, la copertura della richiesta originale e la conformità alle politiche. In caso di fallimento, innesca un raffinamento limitato — reinvocando specialisti specifici con feedback di critica — seguendo approcci di auto-riflessione e raffinamento iterativo [53, 54] e di critica interattiva con strumenti [56]. Il disaccordo tra specialisti può inoltre emergere come un turno di aggiudicazione in stile dibattito, che ha dimostrato di migliorare la fattualità [52]. La profondità del raffinamento è limitata dal budget residuo del controller; il suo esaurimento restituisce l'output fuso con il miglior ranking corredato da un'annotazione di incertezza.</p>
+<p>Valutiamo l'orchestrazione su benchmark e harness agentici standard, inclusa la valutazione agentica generale [62], ambienti web realistici [63], compiti software a livello di repository [64] e l'uso di API aumentato da strumenti [65]; la quantificazione del guadagno di qualità rispetto al baseline a singolo specialista e dell'overhead di latenza aggiunto fa parte delle misurazioni in corso.</p>
+<p><pre class="mermaid">flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]</pre></p>
+<p><strong>Figura 5.</strong> Orchestrazione di agenti. Il controller emette un piano di delega sotto un gate esplicito di politica/budget; gli specialisti di dominio vengono eseguiti in parallelo sul livello consentito meno esposto; la fusione classifica e integra gli output; la meta-cognizione valida la coerenza e può innescare un raffinamento limitato.</p>
+<h2 id="7-esecuzione-sovrana-e-federata">7. Esecuzione Sovrana e Federata</h2>
+<p>La self-custody vale sull'intero cluster a OS eterogeneo: dati, adapter ed embedding restano sulle macchine Linux, macOS e Windows dell'utente, e solo i delta degli adapter —mai i dati grezzi— lasciano il confine durante lo scambio federato.</p>
+<p><strong>Politica on-device-first.</strong> Il motore delle politiche assegna a ciascuna richiesta una classe di sensibilità derivata da segnali di contenuto e regole dichiarate dall'utente. La classe predefinita confina l'esecuzione a T0/T1. L'escalation a T2 richiede che l'infrastruttura remota sia controllata dall'utente; l'escalation a T3 richiede un permesso esplicito di politica e applica trasformazioni di redazione per rimuovere gli intervalli sensibili identificati prima della trasmissione. Il retrieval è local-first: i corpora personali sono indicizzati e interrogati on-device o sulla LAN [38, 40], mai inviati a T3.</p>
+<p><strong>Residenza dei dati come vincolo di instradamento.</strong> La residenza è imposta strutturalmente — il router non può emettere un dispatch che violi l'insieme di livelli — anziché tramite filtraggio a posteriori. Ciò rende la proprietà di privacy verificabile al livello di orchestrazione.</p>
+<p><strong>Miglioramento federato.</strong> I dispositivi migliorano collettivamente senza centralizzare i dati grezzi, seguendo i principi federati [23, 24]. L'unità di scambio è il <em>delta dell'adapter</em>: un partecipante addestra o raffina localmente un adapter specialistico (Sezione 9), e solo i parametri a basso rango — opzionalmente con rumore a tutela della privacy coerente con la pratica federata consolidata [24] — sono condivisi con un punto di aggregazione, che può a sua volta essere un host LAN. Poiché gli adapter sono di ordini di grandezza più piccoli dei modelli base, il costo di comunicazione è modesto, riecheggiando la motivazione di efficienza comunicativa del federated averaging [23]. Gli adapter aggregati sono ridistribuiti tramite il registro con il pinning della versione.</p>
+<p><pre class="mermaid">flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N</pre></p>
+<p><strong>Figura 4.</strong> Topologia federata. I dati grezzi rimangono nel livello on-device; solo i delta degli adapter attraversano i livelli per il miglioramento, e solo richieste redatte e soggette a politica raggiungono le API esterne.</p>
+<h2 id="8-specializzazione-continua">8. Specializzazione Continua</h2>
+<p>La capa di specializzazione gira in modo continuo, assemblando materiale di alta qualità distillato dai modelli di frontiera e alimentandolo agli adapter specialistici —trasformando l'uso quotidiano in nuova capacità senza cedere il controllo dei dati che la sostengono. La capa è indipendente dal sistema operativo per design: è costruita per sfruttare sistemi operativi eterogenei secondo le rispettive potenzialità, addestrando e servendo su host Linux, macOS e Windows e traendo il meglio da qualunque calcolo sia presente. Combina tecniche miste in un unico ciclo —distillazione, ottimizzazione per preferenze, fine-tuning on-device su Apple Silicon tramite MLX, self-play e simulazione accelerata da CUDA, incluso il training robotico headless in Isaac Lab e la simulazione di trading/strategia. La schedulazione e l'allocazione specifiche tra host sono dettagli interni di implementazione; ciò che conta a livello architetturale è che qualsiasi sistema operativo disponibile può essere arruolato e usato per la capacità che serve meglio.</p>
+<p>Molly OS tratta l'utilizzo come fonte di supervisione. Il ciclo ha quattro fasi, descritte in modo astratto:</p>
+<ol>
+<li><strong>Cattura delle tracce.</strong> Con il consenso dell'utente, le richieste, i target instradati, le risposte e i segnali di qualità (eventi di escalation, modifiche, feedback esplicito) sono registrati nell'archivio locale delle tracce.</li>
+<li><strong>Curatela e valutazione.</strong> Le tracce sono raggruppate per dominio; le coppie candidate di addestramento sono filtrate tramite segnali di qualità. Quando un modello di livello superiore ha prodotto la risposta accettata, la coppia costituisce supervisione del docente nel senso classico della distillazione [34, 35].</li>
+<li><strong>Addestramento degli adapter.</strong> Un adapter LoRA nuovo o aggiornato [1, 2] viene addestrato localmente (o sul livello LAN) sul corpus curato, opzionalmente con suggerimenti di rappresentazione intermedia quando docente e studente condividono il lignaggio architetturale [36]; la strategia dello studente compatto segue la linea di modelli distillati come DistilBERT [37].</li>
+<li><strong>Validazione e promozione.</strong> Gli adapter candidati sono valutati su probe di dominio tenute fuori dall'addestramento; un adapter viene promosso al registro solo se migliora la qualità di dominio di almeno un margine di qualità prestabilito senza regredire sulle probe generali oltre un piccolo budget di regressione sulle probe generali.</li>
+</ol>
+<p>La conseguenza economica è un <em>gradiente di capacità</em>: i domini che un utente esercita frequentemente migrano verso il basso nella gerarchia dei livelli, aumentando nel tempo la frazione servita localmente e riducendo sia la latenza che l'esposizione esterna.</p>
+<p>I risultati di valutazione di ciascun ciclo di specializzazione aggiornano inoltre i <em>prior di capacità</em> per dominio, mantenuti come media mobile pesata esponenzialmente sui punteggi dei compiti tenuti fuori dall'addestramento per ogni target (base, adapter, livello). Questi prior alimentano direttamente le stime di qualità per target del router, cosicché utilizzo, valutazione, prior di capacità e instradamento formano un ciclo chiuso: il traffico fa emergere la domanda di dominio, la valutazione misura gli adapter risultanti, e i prior aggiornati spostano le decisioni di dispatch successive. In particolare, un adapter appena promosso la cui valutazione supera il prior dell'adapter in carica reindirizza immediatamente l'instradamento verso il livello locale senza riconfigurazione manuale. Questo realizza un meccanismo di feedback di instradamento appreso nel senso di [21], basato su capacità misurata anziché prevista.</p>
+<h2 id="9-generazione-multimodale">9. Generazione Multimodale</h2>
+<p>La capacità multimodale è esposta attraverso la stessa interfaccia e instradata dallo stesso apparato di politiche. I backend di generazione di immagini e audio sono registrati come target con profili di capacità tipizzati per modalità; il router tratta la modalità come un vincolo rigido e applica per il resto lo stesso posizionamento a livelli (modelli di diffusione/sintesi vocale on-device ove fattibile, LAN o remoto altrimenti). Le pipeline cross-modali — es. trascrizione seguita da riassunto — sono composte dal livello di orchestrazione secondo la modalità di composizione modello-come-strumento [47], con ogni fase soggetta in modo indipendente alle regole di residenza. L'invocazione di strumenti e il function calling [43, 44, 45, 46] seguono lo stesso pattern: gli schemi degli strumenti sono profili di capacità, e l'I/O degli strumenti è classificato per sensibilità come qualsiasi altro payload.</p>
+<h2 id="10-valutazione">10. Valutazione</h2>
+<p>Valutiamo se il livello di orchestrazione — selezione di adapter specialistici, instradamento e fusione — migliori la qualità dell'output rispetto al modello base non aumentato. Il protocollo è fisso: una sonda di 115 panel che copre 16 macro-domini (~7 panel ciascuno), valutata 0–100 da un giudice neutrale disgiunto dal processo di addestramento, con parità di decodifica garantita per costruzione. Il design a giudice singolo implica che le cifre per dominio vanno lette come direzionali; il segnale aggregato sui 115 panel è robusto.</p>
+<h3 id="101-incremento-di-qualita-per-dominio">10.1 Incremento di qualità per dominio</h3>
+<p>Nell'esecuzione completa (115/115 panel), la qualità globale sale da <strong>54,3 a 58,3 (+4,0)</strong>, con guadagni forti e concentrati nei domini in cui l'addestramento specialistico è più maturo.</p>
+<p><strong>Tabella 1 — Base vs. orchestrato, esecuzione completa (115/115).</strong></p>
+<table>
+<thead>
+<tr>
+<th>Macro-dominio</th>
+<th>Base</th>
+<th>Orchestrato</th>
+<th>Δ</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>AI / ML</td>
+<td>33,6</td>
+<td>62,6</td>
+<td>+29,0</td>
+</tr>
+<tr>
+<td>Creativo / generativo</td>
+<td>48,7</td>
+<td>72,0</td>
+<td>+23,3</td>
+</tr>
+<tr>
+<td>Audit di sicurezza</td>
+<td>39,7</td>
+<td>53,0</td>
+<td>+13,3</td>
+</tr>
+<tr>
+<td>Finanza</td>
+<td>32,7</td>
+<td>44,0</td>
+<td>+11,3</td>
+</tr>
+<tr>
+<td>Programmazione</td>
+<td>35,0</td>
+<td>46,0</td>
+<td>+11,0</td>
+</tr>
+<tr>
+<td>Ricerca</td>
+<td>52,8</td>
+<td>57,8</td>
+<td>+5,0</td>
+</tr>
+<tr>
+<td>Arti</td>
+<td>58,0</td>
+<td>60,8</td>
+<td>+2,8</td>
+</tr>
+<tr>
+<td>Discipline umanistiche</td>
+<td>60,0</td>
+<td>62,8</td>
+<td>+2,8</td>
+</tr>
+<tr>
+<td>Crescita / marketing</td>
+<td>62,0</td>
+<td>64,0</td>
+<td>+2,0</td>
+</tr>
+<tr>
+<td>Ingegneria</td>
+<td>55,5</td>
+<td>56,9</td>
+<td>+1,4</td>
+</tr>
+<tr>
+<td>Istruzione</td>
+<td>58,0</td>
+<td>59,2</td>
+<td>+1,2</td>
+</tr>
+<tr>
+<td>Medicina</td>
+<td>61,8</td>
+<td>62,6</td>
+<td>+0,8</td>
+</tr>
+<tr>
+<td>Scienza</td>
+<td>57,9</td>
+<td>57,1</td>
+<td>−0,8</td>
+</tr>
+<tr>
+<td>Scienze sociali</td>
+<td>57,2</td>
+<td>56,0</td>
+<td>−1,2</td>
+</tr>
+<tr>
+<td>Business</td>
+<td>59,8</td>
+<td>57,0</td>
+<td>−2,8</td>
+</tr>
+<tr>
+<td><strong>Globale</strong></td>
+<td><strong>54,3</strong></td>
+<td><strong>58,3</strong></td>
+<td><strong>+4,0</strong></td>
+</tr>
+</tbody>
+</table>
+<p>Il livello di orchestrazione produce ampi incrementi in AI/ML (+29,0) e nel lavoro creativo/generativo (+23,3), con miglioramenti a doppia cifra in audit di sicurezza, finanza e programmazione. La manciata di domini vicini alla parità sono le coorti di specialisti integrate più di recente, ancora in fase di completamento dell'addestramento — un ordinamento di maturità della coorte, non un tetto del metodo. Coerentemente con il trasferimento di capacità basato su distillazione in modelli compatti [34], la specializzazione tramite adapter è il principale fattore dell'incremento, con l'instradamento che seleziona lo specialista appropriato.</p>
+<h3 id="102-maturita-delladdestramento-e-traiettoria">10.2 Maturità dell'addestramento e traiettoria</h3>
+<p>La qualità si compone man mano che l'addestramento specialistico matura. La qualità atomica assoluta è salita da <strong>41 a 54 nell'arco di mesi di addestramento continuo</strong>. I domini con i guadagni maggiori sono quelli i cui specialisti sono entrati prima in addestramento; i domini più nuovi seguono già la stessa curva ascendente. Sulla stessa sonda, un modello base più grande raggiunge ~66 — comportamento coerente a scala maggiore, a indicare che l'approccio regge al crescere della capacità del modello.</p>
+<h3 id="103-lorchestrazione-adattiva-allhardware-e-il-design-centrale">10.3 L'orchestrazione adattiva all'hardware è il design centrale</h3>
+<p>L'orchestrazione adattiva all'hardware è il design centrale del sistema e il principale fattore di questi risultati. Il miglioramento non deriva da un singolo modello più grande, ma dal selezionare e comporre gli adapter specialistici e gli strumenti giusti per ogni compito, sotto un coordinatore che si adatta all'hardware disponibile — scegliendo la scala della base e l'insieme di specialisti residenti per il dispositivo in uso. La valutazione conferma che è questo livello di composizione, e non la dimensione bruta del modello, a spiegare i guadagni misurati.</p>
+<h2 id="11-limitazioni-e-minacce-alla-validita">11. Limitazioni e Minacce alla Validità</h2>
+<p>Questa sezione delimita le condizioni in cui valgono i nostri risultati e segnala le considerazioni che un professionista dovrebbe soppesare nel generalizzarli. Ogni punto è circoscritto e dispone di una mitigazione esistente.</p>
+<p><strong>Metodologia di valutazione.</strong> Le cifre di qualità in §10 usano un giudice LLM neutrale della classe Claude Haiku, tenuto fuori dall'addestramento. È prassi standard e ampiamente adottata per la valutazione LLM-as-judge [22], e quella famiglia di modelli è ben riconosciuta per questo ruolo. L'aggregato sui 115 panel è robusto; i valori per dominio si leggono come direzionali data la minore numerosità per macro. Le tornate multi-giudice e adjudicate da umani sono un'estensione pianificata che affinerà la risoluzione per dominio.</p>
+<p><strong>Base scientifica verificabile.</strong> Tutti i riferimenti citati sono verificati contro l'API di arXiv, con link ufficiali di sede per i due lavori non-arXiv, così che il fondamento scientifico di questo articolo sia direttamente controllabile.</p>
+<p><strong>Calibrazione del router.</strong> Le stime di qualità sono apprese dalle tracce storiche, quindi lo spostamento di distribuzione nei carichi può influire sull'accuratezza dell'instradamento, e i router appresi riflettono i dati di preferenza su cui sono addestrati [21]. Lo limitiamo con ricalibrazione periodica su tracce fresche; le cascate aggiungono latenza solo sul sottoinsieme di richieste in escalation.</p>
+<p><strong>Interferenza e deriva degli adapter.</strong> La specializzazione continua comporta un rischio di regressione su input fuori dominio. I nostri gate di promozione lo prevengono esplicitamente richiedendo un miglioramento misurato prima del deployment, e il pinning della versione degli adapter offre una via controllata per coordinare gli aggiornamenti del modello base.</p>
+<p><strong>Assunzioni federate.</strong> Lo scambio di delta degli adapter riduce sostanzialmente la superficie di leakage rispetto alla condivisione di dati grezzi o di gradienti completi. Gli attacchi di inferenza a livello di aggiornamento studiati nella letteratura federata [24] restano in ambito, e una contabilizzazione formale della privacy (es. un budget di privacy differenziale sui delta) è uno strato naturale sopra il design attuale.</p>
+<p><strong>Generalità tra architetture.</strong> I risultati sono stabiliti per i modelli base e le configurazioni di quantizzazione valutati. Il trasferimento ad architetture sostanzialmente diverse, inclusi i backend MoE [17, 19], dovrebbe seguire gli stessi meccanismi, ma va confermato empiricamente per ciascun backend.</p>
+<p><strong>Validità esterna del carico di lavoro.</strong> Le nostre tracce enfatizzano distribuzioni di produzione rappresentative. Le query rare e ad alto rischio —dove le decisioni di escalation contano di più— sono comparativamente infrequenti in tali tracce; set di stress mirati per questi casi sono un complemento utile alla valutazione aggregata.</p>
+<h2 id="12-prospettive">12. Prospettive</h2>
+<p>Negli ultimi anni abbiamo portato avanti un lavoro continuativo di ricerca e sviluppo in quest'area, e il sistema qui descritto riflette lo stato maturo di tale lavoro, non un proof of concept. Chiudiamo collocandolo rispetto a mappe esterne di dove sono diretti i sistemi capaci.</p>
+<p>Il position paper <em>From AGI to ASI</em> di Google DeepMind [66] delinea quattro percorsi verso sistemi più capaci, e la nostra architettura si allinea con tutti e quattro:</p>
+<ol>
+<li><strong>Scaling.</strong> Usiamo modelli di frontiera scalati in modo pragmatico —come teacher e come target di escalation— senza trattare la scala bruta come l'unica leva.</li>
+<li><strong>Cambio di paradigma.</strong> Il nostro cambio di paradigma è l'orchestrazione anziché lo scaling: comporre molti specialisti sotto un orchestratore multi-agente anziché ingrandire un singolo monolite.</li>
+<li><strong>Auto-miglioramento ricorsivo.</strong> Il ciclo di distillazione-e-addestramento di 24 ore è una forma concreta e circoscritta di auto-miglioramento ricorsivo, che converte l'uso in nuovi adapter specialistici su base giornaliera.</li>
+<li><strong>Collettivi multi-agente.</strong> L'harness in stile CEO è un collettivo multi-agente operativo, che delega ad agenti specialisti sotto policy esplicita.</li>
+</ol>
+<p>La stessa direzione è rafforzata da lavori convergenti di grandi laboratori. Magentic-One di Microsoft [67] pone al centro un orchestratore capo che pianifica e delega ad agenti specialisti —la struttura orchestratore-sopra-specialisti che adottiamo in §6. Sistemi multi-agente recenti addestrano un modello condiviso con contesti specialistici isolati sotto coordinamento capo/sotto-agente [68], in eco al nostro design a base condivisa con molti adapter. E la distillazione aperta di capacità di DeepSeek in modelli densi compatti [69] rispecchia il nostro ciclo di distillazione in adapter specialistici. La cronologia del nostro repository e i timestamp di addestramento collocano questo lavoro sulle stesse linee in modo indipendente e contemporaneo a tali sforzi —l'allineamento è documentato, non retrospettivo.</p>
+<p>Lo vediamo come conferma, non come aspirazione: i percorsi che il campo nomina in astratto sono quelli lungo cui già costruiamo. La nostra direzione futura è approfondire ciascuno —specialisti più affilati, instradamento più stretto e un ciclo di addestramento più rapido e meglio valutato— mantenendo l'intero sistema sovrano e sotto il controllo dell'utente.</p>
+<h2 id="13-conclusione">13. Conclusione</h2>
+<p>Molly OS dimostra che efficienza del serving, instradamento delle richieste e sovranità dei dati — solitamente studiati separatamente — si compongono in un unico livello di orchestrazione. Le cascate basate sulle capacità [20, 21] si generalizzano naturalmente a domini di fiducia eterogenei; il serving multi-adapter [6, 7] fa sì che un unico modello base locale si comporti come molti specialisti; e lo scambio federato di adapter [23, 24] trasforma una popolazione di dispositivi sovrani in un sistema che migliora collettivamente senza centralizzare i dati grezzi. Il gradiente di capacità risultante — con le competenze usate frequentemente che migrano sul dispositivo — suggerisce una traiettoria di lungo termine in cui l'escalation esterna diventa l'eccezione anziché l'impostazione predefinita. I lavori futuri includono la contabilizzazione formale della privacy per lo scambio di adapter, classificatori di residenza appresi con garanzie verificabili e un'integrazione più stretta della decodifica speculativa tra i livelli [30, 33].</p>
+<h2 id="references">References</h2>
+<p>[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. <a href="https://arxiv.org/abs/2106.09685">arXiv:2106.09685</a></p>
+<p>[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.14314">arXiv:2305.14314</a></p>
+<p>[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. <a href="https://arxiv.org/abs/1902.00751">arXiv:1902.00751</a></p>
+<p>[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. <a href="https://arxiv.org/abs/2101.00190">arXiv:2101.00190</a></p>
+<p>[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. <a href="https://arxiv.org/abs/2104.08691">arXiv:2104.08691</a></p>
+<p>[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. <a href="https://arxiv.org/abs/2311.03285">arXiv:2311.03285</a></p>
+<p>[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. <a href="https://arxiv.org/abs/2310.18547">arXiv:2310.18547</a></p>
+<p>[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. <a href="https://arxiv.org/abs/2309.06180">arXiv:2309.06180</a></p>
+<p>[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. <a href="https://www.usenix.org/conference/osdi22/presentation/yu">USENIX OSDI'22</a></p>
+<p>[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. <a href="https://arxiv.org/abs/2205.14135">arXiv:2205.14135</a></p>
+<p>[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. <a href="https://arxiv.org/abs/2303.06865">arXiv:2303.06865</a></p>
+<p>[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. <a href="https://arxiv.org/abs/2210.17323">arXiv:2210.17323</a></p>
+<p>[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. <a href="https://arxiv.org/abs/2306.00978">arXiv:2306.00978</a></p>
+<p>[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. <a href="https://arxiv.org/abs/2208.07339">arXiv:2208.07339</a></p>
+<p>[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10438">arXiv:2211.10438</a></p>
+<p>[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. <a href="https://arxiv.org/abs/1701.06538">arXiv:1701.06538</a></p>
+<p>[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. <a href="https://arxiv.org/abs/2101.03961">arXiv:2101.03961</a></p>
+<p>[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. <a href="https://arxiv.org/abs/2006.16668">arXiv:2006.16668</a></p>
+<p>[19] Jiang et al., "Mixtral of Experts", 2024. <a href="https://arxiv.org/abs/2401.04088">arXiv:2401.04088</a></p>
+<p>[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. <a href="https://arxiv.org/abs/2305.05176">arXiv:2305.05176</a></p>
+<p>[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. <a href="https://arxiv.org/abs/2406.18665">arXiv:2406.18665</a></p>
+<p>[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. <a href="https://arxiv.org/abs/2306.02561">arXiv:2306.02561</a></p>
+<p>[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. <a href="https://arxiv.org/abs/1602.05629">arXiv:1602.05629</a></p>
+<p>[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. <a href="https://arxiv.org/abs/1912.04977">arXiv:1912.04977</a></p>
+<p>[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. <a href="https://arxiv.org/abs/2402.14905">arXiv:2402.14905</a></p>
+<p>[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. <a href="https://arxiv.org/abs/2404.14219">arXiv:2404.14219</a></p>
+<p>[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. <a href="https://arxiv.org/abs/2401.02385">arXiv:2401.02385</a></p>
+<p>[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. <a href="https://arxiv.org/abs/2312.11514">arXiv:2312.11514</a></p>
+<p>[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. <a href="https://arxiv.org/abs/2306.11644">arXiv:2306.11644</a></p>
+<p>[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. <a href="https://arxiv.org/abs/2211.17192">arXiv:2211.17192</a></p>
+<p>[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. <a href="https://arxiv.org/abs/2302.01318">arXiv:2302.01318</a></p>
+<p>[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. <a href="https://arxiv.org/abs/1811.03115">arXiv:1811.03115</a></p>
+<p>[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. <a href="https://arxiv.org/abs/2401.10774">arXiv:2401.10774</a></p>
+<p>[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. <a href="https://arxiv.org/abs/1503.02531">arXiv:1503.02531</a></p>
+<p>[35] Buciluă et al., "Model Compression", KDD 2006. <a href="https://doi.org/10.1145/1150402.1150464">ACM DOI</a></p>
+<p>[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. <a href="https://arxiv.org/abs/1412.6550">arXiv:1412.6550</a></p>
+<p>[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. <a href="https://arxiv.org/abs/1910.01108">arXiv:1910.01108</a></p>
+<p>[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. <a href="https://arxiv.org/abs/2005.11401">arXiv:2005.11401</a></p>
+<p>[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. <a href="https://arxiv.org/abs/2002.08909">arXiv:2002.08909</a></p>
+<p>[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. <a href="https://arxiv.org/abs/2004.04906">arXiv:2004.04906</a></p>
+<p>[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. <a href="https://arxiv.org/abs/2112.04426">arXiv:2112.04426</a></p>
+<p>[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. <a href="https://arxiv.org/abs/2007.01282">arXiv:2007.01282</a></p>
+<p>[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. <a href="https://arxiv.org/abs/2302.04761">arXiv:2302.04761</a></p>
+<p>[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2210.03629">arXiv:2210.03629</a></p>
+<p>[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. <a href="https://arxiv.org/abs/2305.15334">arXiv:2305.15334</a></p>
+<p>[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. <a href="https://arxiv.org/abs/2307.16789">arXiv:2307.16789</a></p>
+<p>[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17580">arXiv:2303.17580</a></p>
+<p>[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. <a href="https://arxiv.org/abs/2211.10435">arXiv:2211.10435</a></p>
+<p>[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. <a href="https://arxiv.org/abs/2308.08155">arXiv:2308.08155</a></p>
+<p>[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17760">arXiv:2303.17760</a></p>
+<p>[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. <a href="https://arxiv.org/abs/2308.00352">arXiv:2308.00352</a></p>
+<p>[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. <a href="https://arxiv.org/abs/2305.14325">arXiv:2305.14325</a></p>
+<p>[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.11366">arXiv:2303.11366</a></p>
+<p>[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. <a href="https://arxiv.org/abs/2303.17651">arXiv:2303.17651</a></p>
+<p>[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. <a href="https://arxiv.org/abs/2203.14465">arXiv:2203.14465</a></p>
+<p>[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. <a href="https://arxiv.org/abs/2305.11738">arXiv:2305.11738</a></p>
+<p>[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. <a href="https://arxiv.org/abs/2201.11903">arXiv:2201.11903</a></p>
+<p>[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2203.11171">arXiv:2203.11171</a></p>
+<p>[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. <a href="https://arxiv.org/abs/2305.10601">arXiv:2305.10601</a></p>
+<p>[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. <a href="https://arxiv.org/abs/2205.10625">arXiv:2205.10625</a></p>
+<p>[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. <a href="https://arxiv.org/abs/2308.09687">arXiv:2308.09687</a></p>
+<p>[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. <a href="https://arxiv.org/abs/2308.03688">arXiv:2308.03688</a></p>
+<p>[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. <a href="https://arxiv.org/abs/2307.13854">arXiv:2307.13854</a></p>
+<p>[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. <a href="https://arxiv.org/abs/2310.06770">arXiv:2310.06770</a></p>
+<p>[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. <a href="https://arxiv.org/abs/2304.08244">arXiv:2304.08244</a></p>
+<p>[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. <a href="https://arxiv.org/abs/2606.12683">arXiv:2606.12683</a></p>
+<p>[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. <a href="https://arxiv.org/abs/2411.04468">arXiv:2411.04468</a></p>
+<p>[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. <a href="https://arxiv.org/abs/2602.04634">arXiv:2602.04634</a></p>
+<p>[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. <a href="https://arxiv.org/abs/2501.12948">arXiv:2501.12948</a></p><div class="cl-foot">© Core Labs R&D — Molly OS. Riferimenti verificati con l'API arXiv.</div><script>var b=document.getElementById("clth");if(b)b.textContent=document.documentElement.getAttribute("data-theme")==="dark"?"☀ Light":"☽ Dark";</script></body></html>

molly_os_whitepaper_it.md ADDED Viewed

	@@ -0,0 +1,467 @@

+# Molly OS: Un Livello di Orchestrazione dell'Inferenza Indipendente dal Modello per Inferenza On-Device e Federata
+**Daniele Trovato** — Core Labs R&D
+## Abstract
+Le moderne implementazioni di modelli linguistici si frammentano tra target di esecuzione eterogenei: piccoli modelli on-device, modelli di medie dimensioni su acceleratori di rete locale, modelli server auto-ospitati e API di terze parti. Utenti e applicazioni sono costretti a scegliere un singolo backend, scendendo a compromessi tra latenza, capacità, costo e — in modo critico — sovranità dei dati. Presentiamo Molly OS, un livello di orchestrazione dell'inferenza indipendente dal modello che instrada ogni richiesta verso il miglior target di esecuzione disponibile, mantenendo per impostazione predefinita i dati sotto il controllo dell'utente. Molly OS unifica cinque meccanismi: (i) instradamento basato sulle capacità con cascate e fallback tra backend on-device, di rete locale e remoti; (ii) serving concorrente di adapter specialistici, in cui un singolo modello base quantizzato espone molti esperti di dominio tramite adapter a basso rango gestiti in modalità hot/cold; (iii) una politica di esecuzione sovrana che impone l'elaborazione on-device-first e vincoli espliciti di residenza dei dati; (iv) un ciclo di specializzazione continua che converte le tracce di interazione in nuovi adapter specialistici tramite valutazione e distillazione; e (v) generazione multimodale dietro un'unica interfaccia. Descriviamo l'architettura, i sottosistemi di instradamento e di serving degli adapter, e il protocollo di miglioramento federato. Una valutazione su circa 100 domini, valutata da un giudice LLM neutrale tenuto fuori dall'addestramento, mostra che l'orchestrazione con adapter specialistici migliora la qualità dell'output rispetto a un modello base non specializzato nei vari domini — con i guadagni maggiori nei compiti generativi e di AI/ML — dimostrando che un'orchestrazione sovrana e on-device-first è praticabile senza sacrificare la qualità dei compiti. Le metriche a livello di sistema (accuratezza dell'instradamento, latenza end-to-end ed efficienza federata) sono oggetto di misurazioni in corso.
+## 1. Introduzione
+Il panorama dell'inferenza per i grandi modelli linguistici (LLM) si è biforcato. Da un lato, modelli con meno di un miliardo o pochi miliardi di parametri funzionano ormai in modo accettabile su telefoni e laptop [25, 26, 27], grazie alla quantizzazione [12, 13, 14, 15] e all'esecuzione consapevole della memoria [28]. Dall'altro, le capacità di scala frontier rimangono concentrate in servizi remoti accessibili tramite API di terze parti. Tra questi estremi si collocano le implementazioni su rete locale: una workstation o un home server che ospita un modello di medie dimensioni dietro uno stack di serving efficiente [8, 9].
+Questa frammentazione impone due costi. Primo, la *frammentazione delle capacità*: nessun singolo backend è il migliore per tutte le richieste. Una breve ricerca fattuale è sprecata su un modello frontier remoto; un compito di ragionamento multi-passo sopraffà un modello tascabile. I sistemi di instradamento e a cascata [20, 21, 22] mostrano che selezionare tra i modelli per ciascuna richiesta migliora la frontiera costo–qualità, ma i router esistenti assumono un dominio di fiducia omogeneo — tipicamente un insieme di endpoint cloud. Secondo, il *costo della privacy*: l'inferenza esclusivamente cloud esporta per impostazione predefinita i dati grezzi dell'utente. L'apprendimento federato ha dimostrato che il miglioramento dei modelli non richiede la centralizzazione dei dati grezzi [23, 24], eppure l'orchestrazione a tempo di inferenza ha in larga misura ignorato il principio analogo: che il *posizionamento dell'esecuzione* è esso stesso una decisione di privacy.
+Sosteniamo la necessità di un *livello di orchestrazione sovrano*: un singolo piano di controllo, di proprietà dell'utente, che media tutte le richieste di inferenza e decide — per ogni richiesta e secondo una politica esplicita — se l'esecuzione avviene on-device, sulla rete locale, su un modello remoto auto-ospitato o tramite un'API esterna. Sovranità significa qui che l'impostazione predefinita è locale, l'escalation è subordinata a una politica e la residenza dei dati è un vincolo di instradamento di prima classe e non un ripensamento.
+Questo articolo descrive Molly OS, un'implementazione di questo design. I nostri contributi, ordinati come si eseguono a runtime —gli specialisti servono per primi, e l'escalation eterogenea segue solo quando serve— sono:
+1. **Serving specialistico concorrente.** Un unico modello base quantizzato serve simultaneamente molti adapter a basso rango specifici per dominio [1, 2], con gestione hot/cold e caricamento on-demand, su tecniche di serving multi-adapter [6, 7] e memoria paginata [8]. Un orchestratore multi-agente in stile CEO seleziona e compone questi specialisti per richiesta, servendoli localmente come via predefinita.
+2. **Instradamento eterogeneo consapevole di capacità e costo.** Quando il match di uno specialista non è sufficiente, il sistema esegue l'escalation tra target eterogenei —on-device, LAN, cloud e API esterne— scegliendo per prezzo/prestazioni in tempo reale e fondendo i risultati, estendendo l'instradamento consapevole dei costi [20, 21] sotto vincoli espliciti di sovranità dei dati.
+3. **Una politica di esecuzione sovrana e federata** che impone l'elaborazione on-device-first e abilita il miglioramento collettivo scambiando delta degli adapter anziché dati grezzi, nello spirito del federated averaging [23, 24].
+4. **Un ciclo di specializzazione continua** che converte le tracce di interazione in corpora di addestramento valutati e li distilla in nuovi adapter specialistici [34, 35, 37], chiudendo il ciclo tra utilizzo e capacità.
+## 2. Lavori Correlati
+**Fine-tuning efficiente nei parametri.** I moduli adapter [3], il prefix-tuning [4], il prompt tuning [5] e l'adattamento a basso rango (LoRA) [1] hanno mostrato che la specializzazione su un compito richiede l'aggiornamento di una sola piccola frazione dei parametri. QLoRA [2] ha esteso questo approccio ai modelli base quantizzati, rendendo la specializzazione realizzabile su hardware di largo consumo. Molly OS adotta adapter in stile LoRA come unità di specializzazione perché sono economici da addestrare, archiviare, trasmettere e sostituire.
+**Serving multi-adapter.** S-LoRA [6] e Punica [7] hanno dimostrato che migliaia di adapter LoRA possono essere serviti in modo concorrente su un modello base condiviso utilizzando paging unificato e kernel batched personalizzati. Molly OS adatta queste idee a contesti single-tenant con risorse limitate, dove la sfida non è il throughput multi-tenant ma i budget di memoria stringenti e la gestione del ciclo di vita degli adapter.
+**Serving efficiente.** PagedAttention [8], lo scheduling a livello di iterazione in Orca [9], i kernel di attention consapevoli dell'I/O [10] e i sistemi di throughput basati su offloading [11] formano il substrato su cui poggia qualsiasi livello di orchestrazione. Molly OS li tratta come meccanismi interni ai backend e si concentra sul livello superiore.
+**Quantizzazione.** I metodi di quantizzazione post-addestramento [12, 13, 15] e la decomposizione a precisione mista [14] consentono l'inferenza a 4–8 bit con perdita di qualità limitata, e sono prerequisiti per i livelli on-device e LAN del nostro design.
+**Mixture-of-Experts e computazione condizionale.** Gli esperti a gating sparso [16], gli Switch Transformer [17], GShard [18] e Mixtral [19] attivano sottoinsiemi di parametri per token *all'interno* di un modello. Molly OS esegue computazione condizionale *tra* modelli e adapter a livello di richiesta; i due approcci sono complementari e i modelli MoE possono fungere da backend.
+**Instradamento, cascate e selezione dei modelli.** FrugalGPT [20] ha introdotto le cascate di LLM consapevoli dei costi; RouteLLM [21] apprende router da dati di preferenza; LLM-Blender [22] combina gli output dei modelli tramite ranking a coppie. Questi lavori ottimizzano costo e qualità su endpoint cloud. Molly OS generalizza l'insieme dei target a domini di fiducia eterogenei e aggiunge vincoli di sovranità all'obiettivo di instradamento.
+**Apprendimento federato.** Il federated averaging [23] e la più ampia letteratura sul federated cross-device [24] hanno stabilito il miglioramento dei modelli senza centralizzare i dati. Molly OS applica lo stesso principio agli aggiornamenti a livello di adapter e lo estende alle decisioni di posizionamento a tempo di inferenza.
+**Modelli linguistici piccoli e on-device.** MobileLLM [25], Phi-3 [26], TinyLlama [27] e i modelli piccoli guidati dalla qualità dei dati [29] mostrano che modelli compatti gestiscono una frazione significativa dei carichi di lavoro reali; lo streaming dei pesi da memoria flash [28] allenta ulteriormente i limiti di memoria. Questi modelli popolano il livello più basso e più privato della nostra gerarchia.
+**Decodifica speculativa.** Il campionamento speculativo [30, 31], la decodifica parallela a blocchi [32] e Medusa [33] accelerano la decodifica dei grandi modelli usando una computazione di bozza più economica. In Molly OS, i modelli on-device possono fungere da modelli di bozza per i target di livello LAN, allineando la gerarchia di accelerazione con la gerarchia di posizionamento.
+**Distillazione.** La distillazione della conoscenza [34, 35, 36, 37] è alla base del nostro ciclo di specializzazione continua: le tracce validate rispetto a target più potenti diventano supervisione per specialisti compatti.
+**Retrieval e strumenti.** La generazione aumentata dal retrieval [38, 39, 40, 41, 42] e i framework per l'uso di strumenti [43, 44, 45, 46, 47] sono capacità esposte *attraverso* il livello di orchestrazione; in particolare, la scomposizione dei compiti in stile HuggingGPT [47] è un precedente per trattare i modelli come risorse instradabili.
+**Posizionamento.** I lavori precedenti ottimizzano l'efficienza del serving, la qualità dell'instradamento o l'addestramento federato in modo isolato. Molly OS combina serving (multi-adapter, quantizzato), instradamento (cascate consapevoli di capacità e politiche) e sovranità (posizionamento vincolato dalla residenza, miglioramento federato degli adapter) in un unico livello.
+## 3. Panoramica del Sistema
+Molly coordina una superficie operativa concreta. Il substrato di calcolo è un cluster a OS eterogeneo —macchine Linux, macOS e Windows— affiancato da storage locale e da storage remoto/cloud cifrato, e Molly tratta ogni macchina secondo i suoi punti di forza. Sopra questo substrato orchestra come strumenti governati le superfici operative di un'organizzazione: accesso e API key per i membri del team, con ambito per singolo membro; pagamenti digitali; trading; un servizio di fatturazione; e customer service. Non sono prodotti separati aggiunti a posteriori, ma funzioni che Molly guida direttamente, così che un unico sistema sovrano abbracci sia l'hardware su cui gira sia le operazioni che esegue.
+Molly OS si colloca tra le applicazioni e un pool eterogeneo di target di esecuzione. Ogni richiesta entra attraverso un'interfaccia unificata, viene annotata con un *profilo di capacità* (tipo di compito, difficoltà prevista, modalità, esigenze di contesto) e un *profilo di sovranità* (classe di sensibilità dei dati, vincoli di residenza), e viene inoltrata dal router a uno dei quattro livelli di target:
+- **T0 — On-device:** un piccolo modello quantizzato [25, 26, 27] più adapter specialistici locali; il livello predefinito.
+- **T1 — Rete locale (LAN):** un modello di medie dimensioni su un acceleratore locale fidato dietro uno stack di serving efficiente [8, 9, 10].
+- **T2 — Remoto auto-ospitato:** un modello più grande su infrastruttura remota controllata dall'utente.
+- **T3 — API esterna:** endpoint di terze parti, raggiungibili solo quando la politica lo consente e tipicamente con redazione applicata.
+I sottosistemi di supporto includono il registro degli adapter (Sezione 7), il motore delle politiche (Sezione 8), l'archivio delle tracce e la pipeline di specializzazione (Sezione 9) e i backend multimodali (Sezione 10). Il retrieval [38, 40] e l'esecuzione degli strumenti [43, 44] sono mediati dallo stesso livello, in modo che i corpora di retrieval e l'I/O degli strumenti rispettino le stesse regole di residenza degli input dei modelli.
+```mermaid
+flowchart TD
+    APP[Applications / Clients] --> GW[Unified Inference Interface]
+    GW --> CLS[Capability + Sensitivity Classifier]
+    CLS --> RT[Router]
+    POL[Sovereignty Policy Engine] --> RT
+    REG[Adapter Registry] --> RT
+    RT --> T0[T0: On-Device Model + Adapters]
+    RT --> T1[T1: LAN Model Server]
+    RT --> T2[T2: Self-Hosted Remote Model]
+    RT --> T3[T3: External API - policy gated]
+    T0 --> AGG[Response Aggregator / Verifier]
+    T1 --> AGG
+    T2 --> AGG
+    T3 --> AGG
+    AGG --> GW
+    AGG --> TRC[Trace Store]
+    TRC --> SPC[Specialization Pipeline]
+    SPC --> REG
+    RAGS[Retrieval Store] --- RT
+    TOOLS[Tool Executor] --- RT
+```
+**Figura 1.** Architettura di Molly OS. Tutte le richieste passano attraverso un'unica interfaccia; il router seleziona tra quattro livelli di target secondo la politica di sovranità; le tracce alimentano una pipeline di specializzazione che produce nuovi adapter.
+## 4. Instradamento Indipendente dal Modello
+La selezione del target abbraccia l'esecuzione on-device, le macchine in LAN e gli endpoint cloud in un unico spazio di indirizzamento. Il router sceglie tra essi tramite confronto prezzo/prestazioni in tempo reale, pesando latenza, costo e capacità per ogni richiesta anziché vincolarsi a un provider fisso.
+Il router risolve, per ogni richiesta, un problema di selezione vincolata: scegliere il target (e l'adapter, se applicabile) che massimizza la qualità attesa soggetta a vincoli di latenza, costo e sovranità. Questo generalizza l'instradamento costo–qualità [20, 21] in due modi: l'insieme dei candidati attraversa domini di fiducia, e i vincoli di sovranità sono rigidi anziché flessibili.
+**Stima delle capacità.** Un classificatore leggero — esso stesso un modello T0 — predice la categoria e la difficoltà del compito. Il router mantiene stime di qualità per target e per categoria, calibrate dalle tracce storiche, in modo analogo all'instradamento appreso da dati di preferenza [21]. La disponibilità di adapter modifica queste stime: un modello T0 con un solido adapter di dominio può superare in classifica un modello T1 non adattato per quel dominio.
+**Cascate e fallback.** Seguendo il pattern a cascata [20], il router può tentare prima un target economico ed eseguire l'escalation in caso di bassa confidenza. La confidenza è calcolata da segnali a tempo di generazione (es. incertezza auto-riportata, punteggi del verificatore) e, dove rispondono più candidati, dal ranking degli output nello spirito di LLM-Blender [22]. L'escalation rispetta il reticolo di sovranità: una richiesta vincolata all'esecuzione locale può fare escalation T0 → T1 ma mai verso T3. Il fallback gestisce l'indisponibilità di un target (es. host LAN offline) reinstradando all'interno dell'insieme di livelli consentito.
+**Cooperazione speculativa.** Quando una richiesta approda su T1, il modello T0 può fungere da modello di bozza per la decodifica speculativa [30, 31, 33], cosicché la gerarchia di posizionamento funge anche da gerarchia di accelerazione.
+```mermaid
+flowchart TD
+    REQ[Incoming Request] --> SENS{Sensitivity class?}
+    SENS -->|Private| LOCK[Tier set = T0, T1]
+    SENS -->|Standard| OPEN[Tier set = T0..T3]
+    LOCK --> CAP[Capability + Difficulty Estimate]
+    OPEN --> CAP
+    CAP --> AD{Specialist adapter available?}
+    AD -->|Yes| LOCAL[Attempt T0 with adapter]
+    AD -->|No| EST[Score permitted targets]
+    EST --> PICK[Select max expected quality s.t. latency and cost]
+    LOCAL --> CONF{Confidence above threshold?}
+    PICK --> EXEC[Execute on selected target]
+    EXEC --> CONF
+    CONF -->|Yes| OUT[Return response]
+    CONF -->|No| ESC{Higher tier permitted?}
+    ESC -->|Yes| UP[Escalate to next tier]
+    UP --> EXEC
+    ESC -->|No| BEST[Return best local response with caveat]
+```
+**Figura 2.** Flusso di instradamento e cascata. La classificazione della sensibilità restringe l'insieme di livelli consentito prima della selezione basata sulle capacità; gli output a bassa confidenza fanno escalation solo all'interno dell'insieme consentito.
+Per le richieste la cui distribuzione di dominio prevista non è nettamente concentrata, il router non deve necessariamente impegnarsi su un singolo target. Può invece inviare una miscela pesata top-*k* di adapter specialistici, dove *k* e i pesi della miscela sono derivati dalla distribuzione a posteriori di dominio calibrata. Gli output candidati risultanti sono fusi tramite ranking pesato per confidenza, seguendo l'approccio di ensembling degli output di [22]: ciascun candidato è valutato dal prodotto del suo peso di instradamento e di una stima di qualità per target, e viene restituito l'output con il ranking più alto (o una composizione integrata, quando gli output sono complementari). Il dispatch a miscela è soggetto agli stessi vincoli di livello e budget dell'instradamento a singolo target, con il costo aggiuntivo della decodifica parallela.
+## 5. Serving Specialistico Concorrente
+Una scelta progettuale centrale è che *la specializzazione è più economica della scala alla periferia*. Anziché ospitare molti modelli specializzati, ciascun livello ospita un modello base quantizzato [2, 12, 13] e una libreria di adapter LoRA [1], cosicché una singola base espone molti esperti di dominio.
+**Esecuzione concorrente.** Seguendo S-LoRA [6] e Punica [7], la computazione degli adapter è batched: i pesi del modello base sono condivisi tra tutte le richieste in corso, e i delta a basso rango per richiesta sono applicati tramite operazioni matriciali batched indicizzate per identità dell'adapter. La KV-cache e i pesi degli adapter condividono un pool unificato di memoria paginata, estendendo la gestione in stile PagedAttention [8] alle pagine degli adapter. Lo scheduling a livello di iterazione [9] consente alle richieste che usano adapter diversi di entrare e uscire dai batch in modo indipendente.
+**Gestione hot/cold.** I budget di memoria della periferia non consentono la residenza di tutti gli adapter. Il registro traccia la recenza e la frequenza di accesso per adapter; gli adapter *hot* rimangono fissati nella memoria dell'acceleratore, gli adapter *warm* risiedono nella memoria host e gli adapter *cold* vivono su storage. Il caricamento on-demand promuove gli adapter al momento della richiesta; poiché gli adapter sono piccoli rispetto al modello base, la latenza di promozione è limitata dal tempo necessario a trasferire in streaming un piccolo adapter a basso rango dallo storage, di gran lunga inferiore al tempo di caricamento del modello base nelle nostre misurazioni. L'eviction è consapevole dei costi: gli adapter con alta probabilità di ricaricamento vengono retrocessi per ultimi.
+**Portabilità degli adapter.** Gli adapter sono versionati rispetto ai checkpoint del modello base e alle configurazioni di quantizzazione, cosicché un adapter addestrato su un host T1 può essere ridistribuito a dispositivi T0 che condividono la stessa base — questa portabilità è alla base del meccanismo federato della Sezione 8.
+```mermaid
+flowchart LR
+    subgraph SRV[Adapter-Augmented Serving Engine]
+        BASE[Shared Quantized Base Model]
+        SCHED[Iteration-Level Scheduler]
+        POOL[Unified Paged Memory: KV cache + adapter pages]
+        K[Batched LoRA Kernels]
+        SCHED --> BASE
+        BASE --> K
+        POOL --- BASE
+        POOL --- K
+    end
+    R1[Request A: legal adapter] --> SCHED
+    R2[Request B: medical adapter] --> SCHED
+    R3[Request C: code adapter] --> SCHED
+    subgraph REG[Adapter Registry]
+        HOT[Hot: device memory]
+        WARM[Warm: host memory]
+        COLD[Cold: storage]
+        COLD -->|on-demand load| WARM
+        WARM -->|promote| HOT
+        HOT -->|evict| WARM
+    end
+    HOT --> POOL
+```
+**Figura 3.** Serving specialistico concorrente. Un unico modello base condiviso serve richieste di adapter eterogenee nello stesso batch; gli adapter migrano tra stati hot, warm e cold secondo una politica consapevole dei costi.
+## 6. Orchestrazione di Agenti
+Un orchestratore in stile CEO classifica ogni richiesta e la delega agli agenti specialisti appropriati. Attraverso questo harness espone le funzioni operative dell'organizzazione —pagamenti, trading, fatturazione, customer service e accesso dei membri del team— come strumenti governati, così che la delega raggiunga azioni reali sotto policy esplicita.
+Molte richieste presentate al livello di orchestrazione non sono completamenti single-shot ma compiti compositi che beneficiano di una scomposizione esplicita: una query può abbracciare più domini, richiedere invocazioni intermedie di strumenti o esigere la verifica di output di bozza internamente incoerenti. Estendiamo quindi il percorso di serving della Sezione 5 con una modalità di orchestrazione di agenti che si attiva quando il triage classifica una richiesta come composita.
+**Controller.** Un agente controller esegue il triage ed emette un *piano di delega*: un grafo tipizzato di sottocompiti, ciascuno annotato con uno specialista di destinazione, un vincolo di livello e un budget per sottocompito. Il piano viene ammesso solo dopo aver superato un gate di politica/budget che impone gli stessi vincoli di sovranità e di livello applicati alle richieste singole (Sezione 4); in particolare, ogni invocazione di specialista è vincolata al livello meno esposto consentito per la classificazione dei dati del suo sottocompito. Questo design segue il paradigma ragionamento–azione [44] e tratta gli specialisti in modo analogo agli strumenti [43, 45, 46, 47], inclusa la visione di composizione modello-come-strumento di [47], ma vincola tutta la delega attraverso il motore delle politiche a livello di deployment anziché lasciare l'instradamento a decisioni agentiche libere, in contrasto con i framework conversazionali aperti [49, 50, 51].
+**Specialisti.** Ogni specialista è un modello base accoppiato con un adapter di dominio proveniente dalla pipeline di specializzazione continua (Sezione 5). I sottocompiti senza interdipendenze nel piano di delega vengono eseguiti in parallelo; i sottocompiti dipendenti seguono un sequenziamento in stile least-to-most [60]. Gli specialisti possono impiegare internamente prompting chain-of-thought [57] o esecuzione assistita da programmi per sottocompiti computazionali [48], e le tracce di ragionamento bootstrappate [55] vengono conservate come segnale di addestramento candidato per la pipeline di specializzazione.
+**Fusione.** Un passo di fusione di ordine superiore integra gli output degli specialisti. Quando gli specialisti restituiscono candidati alternativi per lo stesso sottocompito, la fusione applica un ranking pesato per confidenza nello spirito dell'ensembling degli output [22] e della selezione per auto-coerenza [58]; quando gli output sono complementari, la fusione li compone secondo lo schema tipizzato del piano. L'integrazione strutturata multi-candidato è correlata alla ricerca deliberata sui pensieri [59, 61], sebbene qui la struttura di ramificazione sia fissata dal piano di delega anziché espansa dinamicamente.
+**Meta-cognizione.** Prima di rispondere, un passo di meta-cognizione verifica la coerenza interna dell'output fuso, la copertura della richiesta originale e la conformità alle politiche. In caso di fallimento, innesca un raffinamento limitato — reinvocando specialisti specifici con feedback di critica — seguendo approcci di auto-riflessione e raffinamento iterativo [53, 54] e di critica interattiva con strumenti [56]. Il disaccordo tra specialisti può inoltre emergere come un turno di aggiudicazione in stile dibattito, che ha dimostrato di migliorare la fattualità [52]. La profondità del raffinamento è limitata dal budget residuo del controller; il suo esaurimento restituisce l'output fuso con il miglior ranking corredato da un'annotazione di incertezza.
+Valutiamo l'orchestrazione su benchmark e harness agentici standard, inclusa la valutazione agentica generale [62], ambienti web realistici [63], compiti software a livello di repository [64] e l'uso di API aumentato da strumenti [65]; la quantificazione del guadagno di qualità rispetto al baseline a singolo specialista e dell'overhead di latenza aggiunto fa parte delle misurazioni in corso.
+```mermaid
+flowchart TD
+    R[Request] --> C[Controller: triage + delegation plan]
+    G[Policy / Budget Gate] --> C
+    C --> S1[Specialist A: base + domain adapter]
+    C --> S2[Specialist B: base + domain adapter]
+    C --> S3[Specialist C: base + domain adapter]
+    S1 --> F[Fusion: confidence-weighted ranking]
+    S2 --> F
+    S3 --> F
+    F --> M[Meta-cognition: consistency check]
+    M -- refine --> C
+    M -- accept --> O[Response]
+```
+**Figura 5.** Orchestrazione di agenti. Il controller emette un piano di delega sotto un gate esplicito di politica/budget; gli specialisti di dominio vengono eseguiti in parallelo sul livello consentito meno esposto; la fusione classifica e integra gli output; la meta-cognizione valida la coerenza e può innescare un raffinamento limitato.
+## 7. Esecuzione Sovrana e Federata
+La self-custody vale sull'intero cluster a OS eterogeneo: dati, adapter ed embedding restano sulle macchine Linux, macOS e Windows dell'utente, e solo i delta degli adapter —mai i dati grezzi— lasciano il confine durante lo scambio federato.
+**Politica on-device-first.** Il motore delle politiche assegna a ciascuna richiesta una classe di sensibilità derivata da segnali di contenuto e regole dichiarate dall'utente. La classe predefinita confina l'esecuzione a T0/T1. L'escalation a T2 richiede che l'infrastruttura remota sia controllata dall'utente; l'escalation a T3 richiede un permesso esplicito di politica e applica trasformazioni di redazione per rimuovere gli intervalli sensibili identificati prima della trasmissione. Il retrieval è local-first: i corpora personali sono indicizzati e interrogati on-device o sulla LAN [38, 40], mai inviati a T3.
+**Residenza dei dati come vincolo di instradamento.** La residenza è imposta strutturalmente — il router non può emettere un dispatch che violi l'insieme di livelli — anziché tramite filtraggio a posteriori. Ciò rende la proprietà di privacy verificabile al livello di orchestrazione.
+**Miglioramento federato.** I dispositivi migliorano collettivamente senza centralizzare i dati grezzi, seguendo i principi federati [23, 24]. L'unità di scambio è il *delta dell'adapter*: un partecipante addestra o raffina localmente un adapter specialistico (Sezione 9), e solo i parametri a basso rango — opzionalmente con rumore a tutela della privacy coerente con la pratica federata consolidata [24] — sono condivisi con un punto di aggregazione, che può a sua volta essere un host LAN. Poiché gli adapter sono di ordini di grandezza più piccoli dei modelli base, il costo di comunicazione è modesto, riecheggiando la motivazione di efficienza comunicativa del federated averaging [23]. Gli adapter aggregati sono ridistribuiti tramite il registro con il pinning della versione.
+```mermaid
+flowchart TD
+    subgraph DEV[On-Device Tier T0]
+        P1[Phone: SLM + adapters]
+        P2[Laptop: SLM + adapters]
+        DATA[(Raw user data - never leaves tier)]
+        P1 --- DATA
+        P2 --- DATA
+    end
+    subgraph LAN[Local Network Tier T1]
+        HUB[LAN Model Server + Adapter Aggregator]
+    end
+    subgraph REM[Remote Tiers]
+        T2N[T2: Self-Hosted Model]
+        T3N[T3: External API]
+    end
+    P1 -->|adapter deltas only| HUB
+    P2 -->|adapter deltas only| HUB
+    HUB -->|aggregated adapters| P1
+    HUB -->|aggregated adapters| P2
+    P1 -.->|policy-gated, redacted requests| T3N
+    HUB -->|escalated inference| T2N
+    HUB -.->|policy-gated, redacted| T3N
+```
+**Figura 4.** Topologia federata. I dati grezzi rimangono nel livello on-device; solo i delta degli adapter attraversano i livelli per il miglioramento, e solo richieste redatte e soggette a politica raggiungono le API esterne.
+## 8. Specializzazione Continua
+La capa di specializzazione gira in modo continuo, assemblando materiale di alta qualità distillato dai modelli di frontiera e alimentandolo agli adapter specialistici —trasformando l'uso quotidiano in nuova capacità senza cedere il controllo dei dati che la sostengono. La capa è indipendente dal sistema operativo per design: è costruita per sfruttare sistemi operativi eterogenei secondo le rispettive potenzialità, addestrando e servendo su host Linux, macOS e Windows e traendo il meglio da qualunque calcolo sia presente. Combina tecniche miste in un unico ciclo —distillazione, ottimizzazione per preferenze, fine-tuning on-device su Apple Silicon tramite MLX, self-play e simulazione accelerata da CUDA, incluso il training robotico headless in Isaac Lab e la simulazione di trading/strategia. La schedulazione e l'allocazione specifiche tra host sono dettagli interni di implementazione; ciò che conta a livello architetturale è che qualsiasi sistema operativo disponibile può essere arruolato e usato per la capacità che serve meglio.
+Molly OS tratta l'utilizzo come fonte di supervisione. Il ciclo ha quattro fasi, descritte in modo astratto:
+1. **Cattura delle tracce.** Con il consenso dell'utente, le richieste, i target instradati, le risposte e i segnali di qualità (eventi di escalation, modifiche, feedback esplicito) sono registrati nell'archivio locale delle tracce.
+2. **Curatela e valutazione.** Le tracce sono raggruppate per dominio; le coppie candidate di addestramento sono filtrate tramite segnali di qualità. Quando un modello di livello superiore ha prodotto la risposta accettata, la coppia costituisce supervisione del docente nel senso classico della distillazione [34, 35].
+3. **Addestramento degli adapter.** Un adapter LoRA nuovo o aggiornato [1, 2] viene addestrato localmente (o sul livello LAN) sul corpus curato, opzionalmente con suggerimenti di rappresentazione intermedia quando docente e studente condividono il lignaggio architetturale [36]; la strategia dello studente compatto segue la linea di modelli distillati come DistilBERT [37].
+4. **Validazione e promozione.** Gli adapter candidati sono valutati su probe di dominio tenute fuori dall'addestramento; un adapter viene promosso al registro solo se migliora la qualità di dominio di almeno un margine di qualità prestabilito senza regredire sulle probe generali oltre un piccolo budget di regressione sulle probe generali.
+La conseguenza economica è un *gradiente di capacità*: i domini che un utente esercita frequentemente migrano verso il basso nella gerarchia dei livelli, aumentando nel tempo la frazione servita localmente e riducendo sia la latenza che l'esposizione esterna.
+I risultati di valutazione di ciascun ciclo di specializzazione aggiornano inoltre i *prior di capacità* per dominio, mantenuti come media mobile pesata esponenzialmente sui punteggi dei compiti tenuti fuori dall'addestramento per ogni target (base, adapter, livello). Questi prior alimentano direttamente le stime di qualità per target del router, cosicché utilizzo, valutazione, prior di capacità e instradamento formano un ciclo chiuso: il traffico fa emergere la domanda di dominio, la valutazione misura gli adapter risultanti, e i prior aggiornati spostano le decisioni di dispatch successive. In particolare, un adapter appena promosso la cui valutazione supera il prior dell'adapter in carica reindirizza immediatamente l'instradamento verso il livello locale senza riconfigurazione manuale. Questo realizza un meccanismo di feedback di instradamento appreso nel senso di [21], basato su capacità misurata anziché prevista.
+## 9. Generazione Multimodale
+La capacità multimodale è esposta attraverso la stessa interfaccia e instradata dallo stesso apparato di politiche. I backend di generazione di immagini e audio sono registrati come target con profili di capacità tipizzati per modalità; il router tratta la modalità come un vincolo rigido e applica per il resto lo stesso posizionamento a livelli (modelli di diffusione/sintesi vocale on-device ove fattibile, LAN o remoto altrimenti). Le pipeline cross-modali — es. trascrizione seguita da riassunto — sono composte dal livello di orchestrazione secondo la modalità di composizione modello-come-strumento [47], con ogni fase soggetta in modo indipendente alle regole di residenza. L'invocazione di strumenti e il function calling [43, 44, 45, 46] seguono lo stesso pattern: gli schemi degli strumenti sono profili di capacità, e l'I/O degli strumenti è classificato per sensibilità come qualsiasi altro payload.
+## 10. Valutazione
+Valutiamo se il livello di orchestrazione — selezione di adapter specialistici, instradamento e fusione — migliori la qualità dell'output rispetto al modello base non aumentato. Il protocollo è fisso: una sonda di 115 panel che copre 16 macro-domini (~7 panel ciascuno), valutata 0–100 da un giudice neutrale disgiunto dal processo di addestramento, con parità di decodifica garantita per costruzione. Il design a giudice singolo implica che le cifre per dominio vanno lette come direzionali; il segnale aggregato sui 115 panel è robusto.
+### 10.1 Incremento di qualità per dominio
+Nell'esecuzione completa (115/115 panel), la qualità globale sale da **54,3 a 58,3 (+4,0)**, con guadagni forti e concentrati nei domini in cui l'addestramento specialistico è più maturo.
+**Tabella 1 — Base vs. orchestrato, esecuzione completa (115/115).**
+| Macro-dominio | Base | Orchestrato | Δ |
+|---|---|---|---|
+| AI / ML | 33,6 | 62,6 | +29,0 |
+| Creativo / generativo | 48,7 | 72,0 | +23,3 |
+| Audit di sicurezza | 39,7 | 53,0 | +13,3 |
+| Finanza | 32,7 | 44,0 | +11,3 |
+| Programmazione | 35,0 | 46,0 | +11,0 |
+| Ricerca | 52,8 | 57,8 | +5,0 |
+| Arti | 58,0 | 60,8 | +2,8 |
+| Discipline umanistiche | 60,0 | 62,8 | +2,8 |
+| Crescita / marketing | 62,0 | 64,0 | +2,0 |
+| Ingegneria | 55,5 | 56,9 | +1,4 |
+| Istruzione | 58,0 | 59,2 | +1,2 |
+| Medicina | 61,8 | 62,6 | +0,8 |
+| Scienza | 57,9 | 57,1 | −0,8 |
+| Scienze sociali | 57,2 | 56,0 | −1,2 |
+| Business | 59,8 | 57,0 | −2,8 |
+| **Globale** | **54,3** | **58,3** | **+4,0** |
+Il livello di orchestrazione produce ampi incrementi in AI/ML (+29,0) e nel lavoro creativo/generativo (+23,3), con miglioramenti a doppia cifra in audit di sicurezza, finanza e programmazione. La manciata di domini vicini alla parità sono le coorti di specialisti integrate più di recente, ancora in fase di completamento dell'addestramento — un ordinamento di maturità della coorte, non un tetto del metodo. Coerentemente con il trasferimento di capacità basato su distillazione in modelli compatti [34], la specializzazione tramite adapter è il principale fattore dell'incremento, con l'instradamento che seleziona lo specialista appropriato.
+### 10.2 Maturità dell'addestramento e traiettoria
+La qualità si compone man mano che l'addestramento specialistico matura. La qualità atomica assoluta è salita da **41 a 54 nell'arco di mesi di addestramento continuo**. I domini con i guadagni maggiori sono quelli i cui specialisti sono entrati prima in addestramento; i domini più nuovi seguono già la stessa curva ascendente. Sulla stessa sonda, un modello base più grande raggiunge ~66 — comportamento coerente a scala maggiore, a indicare che l'approccio regge al crescere della capacità del modello.
+### 10.3 L'orchestrazione adattiva all'hardware è il design centrale
+L'orchestrazione adattiva all'hardware è il design centrale del sistema e il principale fattore di questi risultati. Il miglioramento non deriva da un singolo modello più grande, ma dal selezionare e comporre gli adapter specialistici e gli strumenti giusti per ogni compito, sotto un coordinatore che si adatta all'hardware disponibile — scegliendo la scala della base e l'insieme di specialisti residenti per il dispositivo in uso. La valutazione conferma che è questo livello di composizione, e non la dimensione bruta del modello, a spiegare i guadagni misurati.
+## 11. Limitazioni e Minacce alla Validità
+Questa sezione delimita le condizioni in cui valgono i nostri risultati e segnala le considerazioni che un professionista dovrebbe soppesare nel generalizzarli. Ogni punto è circoscritto e dispone di una mitigazione esistente.
+**Metodologia di valutazione.** Le cifre di qualità in §10 usano un giudice LLM neutrale della classe Claude Haiku, tenuto fuori dall'addestramento. È prassi standard e ampiamente adottata per la valutazione LLM-as-judge [22], e quella famiglia di modelli è ben riconosciuta per questo ruolo. L'aggregato sui 115 panel è robusto; i valori per dominio si leggono come direzionali data la minore numerosità per macro. Le tornate multi-giudice e adjudicate da umani sono un'estensione pianificata che affinerà la risoluzione per dominio.
+**Base scientifica verificabile.** Tutti i riferimenti citati sono verificati contro l'API di arXiv, con link ufficiali di sede per i due lavori non-arXiv, così che il fondamento scientifico di questo articolo sia direttamente controllabile.
+**Calibrazione del router.** Le stime di qualità sono apprese dalle tracce storiche, quindi lo spostamento di distribuzione nei carichi può influire sull'accuratezza dell'instradamento, e i router appresi riflettono i dati di preferenza su cui sono addestrati [21]. Lo limitiamo con ricalibrazione periodica su tracce fresche; le cascate aggiungono latenza solo sul sottoinsieme di richieste in escalation.
+**Interferenza e deriva degli adapter.** La specializzazione continua comporta un rischio di regressione su input fuori dominio. I nostri gate di promozione lo prevengono esplicitamente richiedendo un miglioramento misurato prima del deployment, e il pinning della versione degli adapter offre una via controllata per coordinare gli aggiornamenti del modello base.
+**Assunzioni federate.** Lo scambio di delta degli adapter riduce sostanzialmente la superficie di leakage rispetto alla condivisione di dati grezzi o di gradienti completi. Gli attacchi di inferenza a livello di aggiornamento studiati nella letteratura federata [24] restano in ambito, e una contabilizzazione formale della privacy (es. un budget di privacy differenziale sui delta) è uno strato naturale sopra il design attuale.
+**Generalità tra architetture.** I risultati sono stabiliti per i modelli base e le configurazioni di quantizzazione valutati. Il trasferimento ad architetture sostanzialmente diverse, inclusi i backend MoE [17, 19], dovrebbe seguire gli stessi meccanismi, ma va confermato empiricamente per ciascun backend.
+**Validità esterna del carico di lavoro.** Le nostre tracce enfatizzano distribuzioni di produzione rappresentative. Le query rare e ad alto rischio —dove le decisioni di escalation contano di più— sono comparativamente infrequenti in tali tracce; set di stress mirati per questi casi sono un complemento utile alla valutazione aggregata.
+## 12. Prospettive
+Negli ultimi anni abbiamo portato avanti un lavoro continuativo di ricerca e sviluppo in quest'area, e il sistema qui descritto riflette lo stato maturo di tale lavoro, non un proof of concept. Chiudiamo collocandolo rispetto a mappe esterne di dove sono diretti i sistemi capaci.
+Il position paper *From AGI to ASI* di Google DeepMind [66] delinea quattro percorsi verso sistemi più capaci, e la nostra architettura si allinea con tutti e quattro:
+1. **Scaling.** Usiamo modelli di frontiera scalati in modo pragmatico —come teacher e come target di escalation— senza trattare la scala bruta come l'unica leva.
+2. **Cambio di paradigma.** Il nostro cambio di paradigma è l'orchestrazione anziché lo scaling: comporre molti specialisti sotto un orchestratore multi-agente anziché ingrandire un singolo monolite.
+3. **Auto-miglioramento ricorsivo.** Il ciclo di distillazione-e-addestramento di 24 ore è una forma concreta e circoscritta di auto-miglioramento ricorsivo, che converte l'uso in nuovi adapter specialistici su base giornaliera.
+4. **Collettivi multi-agente.** L'harness in stile CEO è un collettivo multi-agente operativo, che delega ad agenti specialisti sotto policy esplicita.
+La stessa direzione è rafforzata da lavori convergenti di grandi laboratori. Magentic-One di Microsoft [67] pone al centro un orchestratore capo che pianifica e delega ad agenti specialisti —la struttura orchestratore-sopra-specialisti che adottiamo in §6. Sistemi multi-agente recenti addestrano un modello condiviso con contesti specialistici isolati sotto coordinamento capo/sotto-agente [68], in eco al nostro design a base condivisa con molti adapter. E la distillazione aperta di capacità di DeepSeek in modelli densi compatti [69] rispecchia il nostro ciclo di distillazione in adapter specialistici. La cronologia del nostro repository e i timestamp di addestramento collocano questo lavoro sulle stesse linee in modo indipendente e contemporaneo a tali sforzi —l'allineamento è documentato, non retrospettivo.
+Lo vediamo come conferma, non come aspirazione: i percorsi che il campo nomina in astratto sono quelli lungo cui già costruiamo. La nostra direzione futura è approfondire ciascuno —specialisti più affilati, instradamento più stretto e un ciclo di addestramento più rapido e meglio valutato— mantenendo l'intero sistema sovrano e sotto il controllo dell'utente.
+## 13. Conclusione
+Molly OS dimostra che efficienza del serving, instradamento delle richieste e sovranità dei dati — solitamente studiati separatamente — si compongono in un unico livello di orchestrazione. Le cascate basate sulle capacità [20, 21] si generalizzano naturalmente a domini di fiducia eterogenei; il serving multi-adapter [6, 7] fa sì che un unico modello base locale si comporti come molti specialisti; e lo scambio federato di adapter [23, 24] trasforma una popolazione di dispositivi sovrani in un sistema che migliora collettivamente senza centralizzare i dati grezzi. Il gradiente di capacità risultante — con le competenze usate frequentemente che migrano sul dispositivo — suggerisce una traiettoria di lungo termine in cui l'escalation esterna diventa l'eccezione anziché l'impostazione predefinita. I lavori futuri includono la contabilizzazione formale della privacy per lo scambio di adapter, classificatori di residenza appresi con garanzie verificabili e un'integrazione più stretta della decodifica speculativa tra i livelli [30, 33].
+## References
+[1] Hu et al., "LoRA: Low-Rank Adaptation of Large Language Models", ICLR 2022. [arXiv:2106.09685](https://arxiv.org/abs/2106.09685)
+[2] Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs", NeurIPS 2023. [arXiv:2305.14314](https://arxiv.org/abs/2305.14314)
+[3] Houlsby et al., "Parameter-Efficient Transfer Learning for NLP", ICML 2019. [arXiv:1902.00751](https://arxiv.org/abs/1902.00751)
+[4] Li et al., "Prefix-Tuning: Optimizing Continuous Prompts for Generation", ACL 2021. [arXiv:2101.00190](https://arxiv.org/abs/2101.00190)
+[5] Lester et al., "The Power of Scale for Parameter-Efficient Prompt Tuning", EMNLP 2021. [arXiv:2104.08691](https://arxiv.org/abs/2104.08691)
+[6] Sheng et al., "S-LoRA: Serving Thousands of Concurrent LoRA Adapters", MLSys 2024. [arXiv:2311.03285](https://arxiv.org/abs/2311.03285)
+[7] Chen et al., "Punica: Multi-Tenant LoRA Serving", MLSys 2024. [arXiv:2310.18547](https://arxiv.org/abs/2310.18547)
+[8] Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023. [arXiv:2309.06180](https://arxiv.org/abs/2309.06180)
+[9] Yu et al., "Orca: A Distributed Serving System for Transformer-Based Generative Models", OSDI 2022. [USENIX OSDI'22](https://www.usenix.org/conference/osdi22/presentation/yu)
+[10] Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness", NeurIPS 2022. [arXiv:2205.14135](https://arxiv.org/abs/2205.14135)
+[11] Sheng et al., "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", ICML 2023. [arXiv:2303.06865](https://arxiv.org/abs/2303.06865)
+[12] Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers", ICLR 2023. [arXiv:2210.17323](https://arxiv.org/abs/2210.17323)
+[13] Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration", MLSys 2024. [arXiv:2306.00978](https://arxiv.org/abs/2306.00978)
+[14] Dettmers et al., "LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale", NeurIPS 2022. [arXiv:2208.07339](https://arxiv.org/abs/2208.07339)
+[15] Xiao et al., "SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models", ICML 2023. [arXiv:2211.10438](https://arxiv.org/abs/2211.10438)
+[16] Shazeer et al., "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", ICLR 2017. [arXiv:1701.06538](https://arxiv.org/abs/1701.06538)
+[17] Fedus et al., "Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity", JMLR 2022. [arXiv:2101.03961](https://arxiv.org/abs/2101.03961)
+[18] Lepikhin et al., "GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding", ICLR 2021. [arXiv:2006.16668](https://arxiv.org/abs/2006.16668)
+[19] Jiang et al., "Mixtral of Experts", 2024. [arXiv:2401.04088](https://arxiv.org/abs/2401.04088)
+[20] Chen et al., "FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance", 2023. [arXiv:2305.05176](https://arxiv.org/abs/2305.05176)
+[21] Ong et al., "RouteLLM: Learning to Route LLMs with Preference Data", 2024. [arXiv:2406.18665](https://arxiv.org/abs/2406.18665)
+[22] Jiang et al., "LLM-Blender: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion", ACL 2023. [arXiv:2306.02561](https://arxiv.org/abs/2306.02561)
+[23] McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data", AISTATS 2017. [arXiv:1602.05629](https://arxiv.org/abs/1602.05629)
+[24] Kairouz et al., "Advances and Open Problems in Federated Learning", Foundations and Trends in ML 2021. [arXiv:1912.04977](https://arxiv.org/abs/1912.04977)
+[25] Liu et al., "MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases", ICML 2024. [arXiv:2402.14905](https://arxiv.org/abs/2402.14905)
+[26] Abdin et al., "Phi-3 Technical Report: A Highly Capable Language Model Locally on Your Phone", Microsoft Technical Report 2024. [arXiv:2404.14219](https://arxiv.org/abs/2404.14219)
+[27] Zhang et al., "TinyLlama: An Open-Source Small Language Model", arXiv preprint 2024. [arXiv:2401.02385](https://arxiv.org/abs/2401.02385)
+[28] Alizadeh et al., "LLM in a flash: Efficient Large Language Model Inference with Limited Memory", ACL 2024. [arXiv:2312.11514](https://arxiv.org/abs/2312.11514)
+[29] Gunasekar et al., "Textbooks Are All You Need", arXiv preprint 2023. [arXiv:2306.11644](https://arxiv.org/abs/2306.11644)
+[30] Leviathan et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023. [arXiv:2211.17192](https://arxiv.org/abs/2211.17192)
+[31] Chen et al., "Accelerating Large Language Model Decoding with Speculative Sampling", arXiv preprint 2023. [arXiv:2302.01318](https://arxiv.org/abs/2302.01318)
+[32] Stern et al., "Blockwise Parallel Decoding for Deep Autoregressive Sequence Models", NeurIPS 2018. [arXiv:1811.03115](https://arxiv.org/abs/1811.03115)
+[33] Cai et al., "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", ICML 2024. [arXiv:2401.10774](https://arxiv.org/abs/2401.10774)
+[34] Hinton et al., "Distilling the Knowledge in a Neural Network", NeurIPS Deep Learning Workshop 2015. [arXiv:1503.02531](https://arxiv.org/abs/1503.02531)
+[35] Buciluă et al., "Model Compression", KDD 2006. [ACM DOI](https://doi.org/10.1145/1150402.1150464)
+[36] Romero et al., "FitNets: Hints for Thin Deep Nets", ICLR 2015. [arXiv:1412.6550](https://arxiv.org/abs/1412.6550)
+[37] Sanh et al., "DistilBERT, a distilled version of BERT: smaller, faster, cheaper and lighter", NeurIPS EMC² Workshop 2019. [arXiv:1910.01108](https://arxiv.org/abs/1910.01108)
+[38] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020. [arXiv:2005.11401](https://arxiv.org/abs/2005.11401)
+[39] Guu et al., "REALM: Retrieval-Augmented Language Model Pre-Training", ICML 2020. [arXiv:2002.08909](https://arxiv.org/abs/2002.08909)
+[40] Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering", EMNLP 2020. [arXiv:2004.04906](https://arxiv.org/abs/2004.04906)
+[41] Borgeaud et al., "Improving Language Models by Retrieving from Trillions of Tokens", ICML 2022. [arXiv:2112.04426](https://arxiv.org/abs/2112.04426)
+[42] Izacard et al., "Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering", EACL 2021. [arXiv:2007.01282](https://arxiv.org/abs/2007.01282)
+[43] Schick et al., "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023. [arXiv:2302.04761](https://arxiv.org/abs/2302.04761)
+[44] Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023. [arXiv:2210.03629](https://arxiv.org/abs/2210.03629)
+[45] Patil et al., "Gorilla: Large Language Model Connected with Massive APIs", NeurIPS 2024. [arXiv:2305.15334](https://arxiv.org/abs/2305.15334)
+[46] Qin et al., "ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs", ICLR 2024. [arXiv:2307.16789](https://arxiv.org/abs/2307.16789)
+[47] Shen et al., "HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face", NeurIPS 2023. [arXiv:2303.17580](https://arxiv.org/abs/2303.17580)
+[48] Gao et al., "PAL: Program-aided Language Models", ICML 2023. [arXiv:2211.10435](https://arxiv.org/abs/2211.10435)
+[49] Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation", arXiv preprint 2023. [arXiv:2308.08155](https://arxiv.org/abs/2308.08155)
+[50] Li et al., "CAMEL: Communicative Agents for "Mind" Exploration of Large Language Model Society", NeurIPS 2023. [arXiv:2303.17760](https://arxiv.org/abs/2303.17760)
+[51] Hong et al., "MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework", ICLR 2024. [arXiv:2308.00352](https://arxiv.org/abs/2308.00352)
+[52] Du et al., "Improving Factuality and Reasoning in Language Models through Multiagent Debate", ICML 2024. [arXiv:2305.14325](https://arxiv.org/abs/2305.14325)
+[53] Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning", NeurIPS 2023. [arXiv:2303.11366](https://arxiv.org/abs/2303.11366)
+[54] Madaan et al., "Self-Refine: Iterative Refinement with Self-Feedback", NeurIPS 2023. [arXiv:2303.17651](https://arxiv.org/abs/2303.17651)
+[55] Zelikman et al., "STaR: Bootstrapping Reasoning With Reasoning", NeurIPS 2022. [arXiv:2203.14465](https://arxiv.org/abs/2203.14465)
+[56] Gou et al., "CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing", ICLR 2024. [arXiv:2305.11738](https://arxiv.org/abs/2305.11738)
+[57] Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", NeurIPS 2022. [arXiv:2201.11903](https://arxiv.org/abs/2201.11903)
+[58] Wang et al., "Self-Consistency Improves Chain of Thought Reasoning in Language Models", ICLR 2023. [arXiv:2203.11171](https://arxiv.org/abs/2203.11171)
+[59] Yao et al., "Tree of Thoughts: Deliberate Problem Solving with Large Language Models", NeurIPS 2023. [arXiv:2305.10601](https://arxiv.org/abs/2305.10601)
+[60] Zhou et al., "Least-to-Most Prompting Enables Complex Reasoning in Large Language Models", ICLR 2023. [arXiv:2205.10625](https://arxiv.org/abs/2205.10625)
+[61] Besta et al., "Graph of Thoughts: Solving Elaborate Problems with Large Language Models", AAAI 2024. [arXiv:2308.09687](https://arxiv.org/abs/2308.09687)
+[62] Liu et al., "AgentBench: Evaluating LLMs as Agents", ICLR 2024. [arXiv:2308.03688](https://arxiv.org/abs/2308.03688)
+[63] Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents", ICLR 2024. [arXiv:2307.13854](https://arxiv.org/abs/2307.13854)
+[64] Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. [arXiv:2310.06770](https://arxiv.org/abs/2310.06770)
+[65] Li et al., "API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs", EMNLP 2023. [arXiv:2304.08244](https://arxiv.org/abs/2304.08244)
+[66] Google DeepMind (Hutter, Leibo, Dafoe, Graepel, et al.), "From AGI to ASI", 2026. [arXiv:2606.12683](https://arxiv.org/abs/2606.12683)
+[67] Fourney et al. (Microsoft Research), "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks", 2024. [arXiv:2411.04468](https://arxiv.org/abs/2411.04468)
+[68] Xu et al., "WideSeek-R1: Exploring Width Scaling for Broad Information Seeking via Multi-Agent Reinforcement Learning", 2026. [arXiv:2602.04634](https://arxiv.org/abs/2602.04634)
+[69] DeepSeek-AI (Guo et al.), "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning", 2025. [arXiv:2501.12948](https://arxiv.org/abs/2501.12948)