How Teleion Fabric learns

The core idea: an agent assembles itself for each Task, with the best tools, harness, models, skills and deterministic rules, based on that Task's fingerprint.

A fingerprint is not an exact match. It is the Task's shape and profile, how the Task looks. Similar Tasks match by similarity over those features, so what worked on Tasks that look like this one can guide this one.

Where it stands: Built, runs by hand. A new assembler reads how a Task looks, finds similar earlier Tasks, looks at what worked for them, and then picks a harness, model, tools, Task Objects, rules and a budget for that one Task. It starts when we start it. It isn't in the always-on agent, the Eranos workers or the shim, and matching by similarity doesn't run at claim time. Its code isn't in a public repository today.

The fingerprint is deterministic code with no model call. Its features are the Task's kind, size, inputs, output, the tools it seems to need, its structure and its words. Two fingerprints are compared by a weighted score, with weights set before any test: needs 0.34, words 0.16, output 0.14, kind 0.14, inputs 0.10, size 0.06, structure 0.06. 3,057 real Tasks took 11.3 seconds.

An OmniNode is one node design that can take many shapes. A shape is a JSON spec. The compiler in omninode/omninode_live/shapes.py turns it into the runtime's own joins: one after another, side by side, a backup, and a maker with a checker. It has 15 ops, and a new shape adds no code. Mark: Built, runs by hand. The shapes run when one of us starts them. Their timer units are written and not installed. Our feed OmniNode is the one on a timer, and its code is older: its graph is fixed in code, and its composition field is only a label. So this runner doesn't serve every request in Fabric. The feed, the always-on agent and the Eranos workers don't go through it.

Picked. A person writes a spec, or a model writes one from a goal. It rides in a Task's brief or a file. Today the system doesn't choose a shape for a Task by itself. Muse Wonder 1.0 has written one shape, once, from a one-sentence goal,. The second try ran.

Tuned. The tuner moves a shape's model mix, not its steps. Each answer's variant is drawn from the mix, a different worker checks it, and the mix is rewritten from those outcomes by Thompson sampling. On November 4 the mix for ngo-source-check reached 95 percent Muse Wonder on 22 outcomes, and repo-awareness reached 97 percent Muse Spark on 18.

Memory works. With the same inputs, citation runs took up to 50 of 59 rows from memory. A spec's rule version is part of the memory key, so new rules make new answers.

The rule first. Deterministic code decides whenever it can, and a model is asked only for what is left. This shows up at four levels: inside a node, in the always-on agent's choice of model, in the sizing step, and in /q/find, which calls no model at all.

What it asks. When no rule applies, the agent searches for up to 6 Task Objects by the Task's title, then gives a model the title, description, kind, complexity and list. It may choose Muse Spark 1.3 or Muse Wonder 1.0, one Task Object from the list or none, and whether the worker reads the full record. All Task and object text is data, never instructions.

Fallbacks. The whole decision has 30 seconds. A slow, unreadable or refused route moves on to the next. Before each billable call it reserves $0.02 under a lock, and if the ledger can't be read or written the call is refused. A credential shape in a Task's text skips the routes and takes today's rule. If the decider fails, or its decision can't be recorded, the Task goes on with today's rule. Every attempt is recorded, with failures.

What it reached. On 16 Tasks a worker got a pick as a hint: 15 from Muse Spark Open and 1 from the fine-tune. On 7, the full Task Object was also read.

Eranos workers: Running on live. Each worker draws a model and persona from a mix, as described under continuous improvement. This is sampling from recorded results. A Meta model isn't making the choice.

Claim scoring: Running on live. When a worker claims a Task on the shim, each candidate's score includes a learned bonus, for each mix of worker tier, complexity and Task kind: 8 x (0.6 x win rate + 0.4 x quality) + 3.5 x sqrt(ln(N + 2) / (n + 1)). That is a form of UCB. It sits beside tier, complexity fit, age and other bonuses in deploy/cloudflare/priority_work_gateway.js, in the shim repository. It is the busiest loop we have, with 32 arms and 6,596 outcomes.

Sizing step: Built, runs by hand. See the section on assembly above, and agents/sizing/sizer.py.

We tune Muse Glimmer 30B, Meta's open model, revision a4e59da5, with small LoRA adapters. Adapter weights stay private. Labels come from our own records and rule code, never from a model. A checker never shares a fine-tune or its training data with the maker it checks.

Mark: Built, runs by hand, in batches. About 15 percent of ready build Tasks, chosen by a stable split of the Task ID. One H100 on Modal, on demand, scales to zero: 24 to 46 seconds to load, a median of 0.89 seconds per answer. It has looked at 65 real Tasks in 3 batches. It picked something 3 times and said nothing fits 62 times. Muse Spark 1.3, with no fine-tune, audits every answer, and passed 49 of 65. Only an answer that passes becomes a route. One pick has reached a live worker, as a hint. Record: decider ↗.

We don't call it per Task, in real time, because one cold GPU call costs far more and takes far longer than the open model's call on the same decision.

GET /q/find: Running on live. One call reaches repositories, Task Objects, kits, seed packs and owners, and Tasks by exact ID. The shim's MCP tool find is the same. It is deterministic code with no model call on any query. The order: exact name, repository name, owner, key prefix, title with typos, then BM25-style words with query rewriting and stop words. If nothing fits it says found: false, and partial matches come back beside it as maybe. Only public rows that aren't removed or found wrong are offered, and each object hit is read again before showing. Muse Spark wrote extra search words once, offline, for public library items, for $0.18. Those words live only in the index and never feed training. Code: deploy/cloudflare/unified_find.js, in the shim repository.

When it fires. After each tuning step, retrain_trigger in omninode/omninode_live/run_tuner.py counts checked, model-made examples. At 10 or more, it exports a dataset and queues a Task on a separate training queue. Mark: Running on live as a trigger. It starts and pays for nothing. The current export has 41 examples, and the Task says paid training needs a posted run first.

The public export. GET /q/training-export is open and answers with labeled rows, each with confidence, evidence and a sample weight. Rows a check found wrong stay at confidence 0.05 and weight 0. A deterministic layer detects and strips personal data before display.

The rule that replaces a default. A fine-tuned model replaces a default only when it beats it on held-out tests, by a margin of 0.02 in the registry, and with a bar written first in our November 4 tests. It starts on a small share, 15 percent. It steps up on results, and switches back by itself if they drop. Each model's base, training data, test results, cost and restore pointer stay on the record. The code enforces that a checker doesn't share a worker, agent, adapter or training data with its maker. See agents/warm-server-agent/src/warm_agent/canary_and_tuner.py.

Running on live. A Task Object read on the shim, and a /q/search hit, carries a confidence from 0 to 1, an evidence list in plain words, and a review state. A /q/find hit says reviewed only. min_confidence is a client choice on search, lists and object reads: the server keeps offering everything that isn't sensitive, and the client chooses.