Continue from Tutorial 08. Load [loom_demo] from Loom for this session. [loom_demo] is writable for your account and includes starter data, so it is a good place to try promotion before you repeat the same pattern in your project store.
This example uses the public CSV bundled with the palmerpenguins tutorial repository and promotes a reusable species-and-island count. The promoted rule lives in the shared store rather than in one chat history, so it remains available after reconnecting to [loom_demo].
Public CSV used in this tutorial:
https://raw.githubusercontent.com/mcnakhaee/palmerpenguins/master/palmerpenguins/data/penguins.csv
The CSV has 344 rows and these relevant columns: species, island, body_mass_g, and year. The verified answer for Gentoo penguins on Biscoe island is 124 rows.
The expensive part of a repeated question is almost never the answer — it is rediscovering how to answer it. Where does the data live, what are the columns called, which rows count. An agent that solves that from scratch every time pays the full cost every time, and two agents solving it separately can disagree about the same number.
Promotion stores the method, not the answer. That is why the rule below takes parameters: it is reusable behaviour, not a memorised 124.
[loom_demo] store is configured and reachable.proving a rule outlived its conversation requires leaving that conversation.
Expect this to take about twenty minutes.
loom_demo the session defaultloom_demo and make it the default for this session only. Confirm the effective session default, and do not edit ~/.loom/stores.toml.loom_demo store and changes only this session's default routing.loom_demo is now the default for this session. Persistent configuration was not changed.species is Gentoo and island is Biscoe, and returns the count.This is the boundary: Loom remembers the reusable method, not a private copy of the public data.
> Estimated LLM usage: Approximately 800 tokens for the first-pass work of locating the source, inspecting its shape, and constructing the filter. This is an external estimate, not a live per-turn measurement.
A promoted rule turns repeated reasoning into shared, named behavior. The agent still chooses when the rule applies, but it no longer needs to rediscover the source, columns, and filter on every request.
[loom_demo] as a deterministic rule calculation named count_penguins(species, island).[loom_demo] rule catalog. It creates, updates, or confirms the deterministic count_penguins(species, island) rule without storing CSV rows. A rerun confirms the same named rule rather than creating a duplicate.[loom_demo] contains the executable count_penguins(species, island) rule. A call for ("Gentoo", "Biscoe") returned count: 124 with species, island, and the rule's source description.> Estimated LLM usage: Approximately 3,000 tokens to inspect the existing rule catalog, author or update the deterministic rule, preserve the surrounding user files, and verify the result. This is an external estimate, not a live per-turn measurement.
The promoted rule is useful because the repeatable part is deterministic: fetch the same public CSV, apply the requested two-column filter, and return one count.
Start a new coding-harness session in the same repository. Make [loom_demo] the session default as shown above, but do not mention Loom, promotion, or the rule in the counting request:
[loom_demo] rule catalog, recognizes that the request matches the promoted calculation, and calls count_penguins("Adelie", "Torgersen") in the store's user-rule namespace.count_penguins("Adelie", "Torgersen") rule returned the species, island, count, and source description.> Estimated LLM usage: Approximately 50 tokens to recognize the matching promoted rule, invoke it with the requested parameters, and report the result. This is an external estimate, not a live per-turn measurement.
The plain-language request is the verification: a new session can discover and call the stored rule without being told its name or reconstructing the calculation in the conversation. The rule is parameterized, so the same stored behavior can answer a different species-and-island pair after reconnecting.
This small example saves roughly 750 tokens on each repeated query compared with the estimated 800-token first pass. In real applications, the uncaptured workflow may require reading several files, discovering schemas, joining data, reconstructing filters, and checking domain-specific constraints. Repeating that reasoning can be very expensive, while a promoted deterministic rule keeps subsequent calls compact and consistent.
The agent also checks the active store's rule-source fingerprint on every user prompt. If that fingerprint changes during a session, the hook injects the refreshed rule catalog on that turn; when it is unchanged, the hook injects no duplicate catalog.
Reconnecting proves that the rule lives in the shared store rather than in the current conversation or process. A different parameter pair also shows that it is reusable behavior, not a memorized answer.
[loom_demo] as the session default without editing stores.toml, then call count_penguins("Chinstrap", "Dream").[loom_demo], reads its rule catalog, and invokes the promoted rule.[loom_demo] became the session default for this fresh session. The promoted rule returned 68 Chinstrap penguins on Dream island, confirming that the rule persisted outside the original conversation.That is the payoff: promoted rules are shared store behavior. A connected agent does not need the original conversation to invoke the stored rule.
Deterministic does not mean opaque. Report the evidence fields the rule actually returns without inventing extra provenance.
Adelie. Island: Torgersen. Count: 52. Source: https://raw.githubusercontent.com/mcnakhaee/palmerpenguins/master/palmerpenguins/data/penguins.csv.Using a second parameter pair verifies that the rule is parameterized rather than a stored 124.
This tutorial keeps the write in [loom_demo]. When the same method becomes part of real project planning, repeat the promotion in your project store and ask the agent to verify the promoted answer there before relying on it.
Promote patterns like this when:
Do not promote one-time research, subjective choices, or fetched public data that should stay in the source system. Promote the repeatable method.
The fresh session in §3 did not find the rule. That is the interesting failure, because it is the whole claim under test. Check the session actually made [loom_demo] its default — a fresh session pointed at a different store reads a different catalog and will happily rebuild the calculation from scratch, which looks like success but proves nothing.
The fresh session rebuilt the calculation instead of calling the rule. Also a real result, and worth noticing rather than retrying until it works. It usually means the rule's name or description does not describe the request in the words a user would actually use. A promoted rule nobody recognises is not promoted in any useful sense.
The counts differ from the numbers above. Re-check the filter before suspecting the data: 344 total rows, 124 Gentoo on Biscoe, 52 Adelie on Torgersen, 68 Chinstrap on Dream. Those are stable properties of this dataset, so a mismatch points at the filter or a partially-read file.
The rule's reported source does not match the CSV you used. Report what your rule actually returns rather than what this page shows, then reconcile the two. The source it records should name the CSV it really read — the public URL above, if that is what you pointed it at. A rule whose stated provenance disagrees with the data it fetched is worth correcting in the rule, because the evidence fields are the only thing making a promoted answer auditable.
The token figures do not match what you observe. They are not supposed to. Every such figure here is labelled an external estimate, not a live per-turn measurement; the ratio between a first pass and a repeated call is the point, not the absolute numbers.