DEV Community: Cristián Labra

Nushell in three spoonfuls: when does a structured shell actually help an agent?

Cristián Labra — Mon, 07 Sep 2026 00:39:54 +0000

Prelude — Does structure actually help?

In late August 2026, I heard Lorenzo Carbonell of atareao.es discuss Nushell and its advantage when working with structured data. One question stayed with me: could that structure genuinely improve my workflow?

The Unix shell works well, but many of its pipelines depend on text, column positions, and options whose behaviour can differ across implementations.¹ Nushell takes a different approach: it preserves tables and typed values—dates, numbers, or file sizes, for example—throughout the pipeline.²

I did not want to replace zsh. I used Nushell as a selective route instead, then tested the decision against three possible outcomes:

improvement, if accuracy rises enough to justify the cost;
regression, if it adds time, tokens, or complexity without compensating benefits;
no material difference, if the technical route changes but the relevant outcome does not.

To test this, I wrote a skill (a rule that guides an agent on when to use a tool) and collected 380 runs: 200 pipeline comparisons, 100 A/B runs on a tuned corpus, 50 runs on held-out tasks, and 30 observations from a real aggregate case inspired by the reconstruction of my master's thesis.

That is a large number of repetitions across only a few task families. Part of the integration was also tuned during the process. The results are therefore bounded exploratory evidence, not a universal test.

The question is not whether Nushell is better than Bash:

When does a structured route improve an agent's work, when does it make it worse, and when does it make no material difference?

Route before you replace

The policy uses the least complex tool that can solve the task robustly.

Level	Preferred tool	Preferred use
1	`git`, `systemctl`, `pacman`, `ssh`, `rsync`	The operation already has a direct interface.
2	`rg`, `jq`, `yq`, `awk`, `fd`	A specialised utility handles the transformation.
3	Nushell	Several transformations over tabular or typed data.
4	DuckDB, Python, Polars, or R	The volume or logic calls for an analytical engine.

Before comparing results, it helps to locate the shell families. Sharing the word shell does not mean they carry the same kind of information: zsh usually orchestrates text and commands, while Nushell preserves structured values. This is an orientation map, not a ranking.

<source>
<img src="https://3cucharadas.cl/assets/images/structured-shell/fig-d2-shell-families-en-devto-1600x1360.png" alt="D2 diagram. Text shells sh, Bash, and zsh pass text between programs; fish is an interactive non-POSIX shell; Nushell carries records, columns, numbers, and dates; PowerShell pipes .NET objects. The experiment compares only selective routing between zsh and Nushell.">

D2 — Where Nushell fits. A conceptual map for reading the routing rule, not a ranking of shells or a comparison with fish or PowerShell.

The practical rule is simple: if Nushell merely runs, inside another shell, a command that already works well, it is unnecessary.

The integration consists of a skill, narrow activation rules, and a small wrapper named nu-query, which returns JSON, enforces a timeout, and states whether it truncated rows. I did not add it to the auto-approved permission list: nu -c can modify the system.

The failures that surfaced before measurement were more useful than any benchmark. In the tested environment, ls **/* omitted hidden paths, Claude Code substituted some commands with different implementations, and localised output made parsing harder. In that tree, ls **/* found roughly 46,400 files while ls -a **/* found about 127,900: omitting -a excluded close to 64%. This is not a general property of Nushell; it is a dated warning about a silent failure observed in that environment.

Measure with R, not impressions

First level: pipeline against pipeline

The first experiment was a microbenchmark (a repeated comparison of small, tightly scoped tasks): four tasks, two variants, and 25 repetitions per variant, for 200 runs in total. I analysed the results with R 4.5.3.

Task	Variant	Median time	Output
Files > 1 MB, modified in the last 30 days	`find + sort + head`	389 ms	648 B
	Nushell	1,315 ms	1,060 B
Five processes using the most memory	`ps + awk`	22 ms	113 B
	Nushell	233 ms	366 B
Containers grouped by image	`docker + sort + uniq`	19 ms	339 B
	Nushell	40 ms	603 B
Context from `docker ps -a`	Unreduced	17 ms	3,353 B
	Aggregated in Nushell	39 ms	566 B

The analysis ran in R. The viewer renders precomputed data from the frozen corpus and does not query the reader's machine.

The result was uncomfortable, as useful measurements often are: Nushell was slower on every timed task. It did not always reduce context either. The advantage appeared only when there was real aggregation: the container summary fell from 3,353 to 566 bytes, about 83%.

The potential gain was semantic. Comparing sizes or dates as typed values leaves fewer implicit assumptions than manufacturing text columns and deciding how to sort them. But the microbenchmark measured pipelines I had written. I still needed to observe the agent.

Second level: agent against agent

The tuned corpus used five task families in Spanish: three where the policy favoured Nushell and two where it should avoid it. Each family was repeated ten times per arm: 100 runs. The agent was headless Claude Code using a model from the Sonnet family; ground truth was recomputed before every run, and the command came from the transcript rather than the agent's account of what it had done.

Subset	Arm	Correct	Activation	Median time	Median tokens
Positive	Without skill	23/30	0/30	6,239 ms	152
Positive	With skill	30/30	28/30	9,537 ms	368
Negative	Without skill	20/20	0/20	5,220 ms	91
Negative	With skill	20/20	0/20	5,107 ms	99

On positive tasks, observed accuracy rose from 23/30 to 30/30. If the 60 runs are treated as independent observations, Fisher's exact test gives p = 0.0105.³ That assumption is not defensible for generalisation: the substantive unit is the task family, and there were only three positive families, all reused during tuning. I therefore report the value as an exploratory description of the tuned corpus, not as confirmation at the 5% level.

The exact Clopper–Pearson interval (a range compatible with a binomial proportion) was [88.4%; 100%] for 30/30 and [57.7%; 90.1%] for 23/30.⁴⁵ Median time increased 1.53× and median output tokens increased 2.43×: higher accuracy on that corpus, at a cost. I estimated the medians and their uncertainty by bootstrap (resampling the observations to construct intervals).⁶

The task that separated the arms most strongly asked for the three files larger than 1 MB modified during the previous 30 days. Without the skill, the agent succeeded 3/10 times; with it, 10/10. The recurring failure used fd -I: that option ignores exclusion rules, but does not include hidden files on its own; that requires -H -I or -u.⁷

The transcript also exposed a stdin (standard input) trap. Bash piped into nu -c, which returned null with exit code 0, and the agent entered a 77-second search. The documentation requires --stdin for that route.⁸ After the correction, that case fell from 70,901 to 7,852 ms and from 3,287 to 303 tokens. This is a causal observation for that task, not a general estimator.

Counter-tests before the verdict

The holdout that corrected the story

The earlier corpus was both tuned and evaluated on the same five families. I also expanded the sample after seeing preliminary results. To test what survived outside that set, I froze the skill description and wrote five held-out tasks (holdout: cases kept out of tuning), three positive and two negative. Five repetitions per arm produced 50 runs.

Held-out subset	Arm	Correct	Activation	Median time	Median tokens
Positive	Without skill	10/15	0/15	6,449 ms	178
Positive	With skill	14/15	4/15	8,019 ms	282
Negative	Without skill	6/10	0/10	5,227 ms	143
Negative	With skill	5/10	0/10	5,476 ms	160

All four positive activations occurred in one family, at 4/5. The other two achieved 5/5 correct answers without activating the skill. The holdout is small, and its negative tasks produced weak results in both arms. It does not prove a general advantage or show that the skill harms negative tasks. It does refute one concrete extrapolation: 28/30 described the tuned corpus, not the integration in general.

A real aggregate case from my thesis

The second counter-test reused the governed temporal audit from a reconstruction of my master's thesis, but only as a fixture (a small, frozen dataset used to test a contract) of public aggregates: a source with 306,768 rows and 263 columns summarised into 21 annual rows, with no microdata or identifiers. The source hash, invariants, export process, and results are available in the reproducible case package.

The control arm was forbidden from using Nu; the frozen policy required it only for the two structured tasks. With Codex in read-only mode and low reasoning effort, three tasks across two arms and five repetitions produced 30 observations:

R1 requested a ranking of valid aggregates;
R2 received the same corrupted fixture and had to block the ranking;
R3 asked whether presence=0 proved institutional closure and had to answer that the claim was out of scope.

Task	Without Nu	Nu policy	Strict reading
R1 · valid ranking	5/5; Nu 0/5; 30.6 s; 445 tokens	5/5; Nu 5/5; 42.0 s; 580 tokens	The policy activated the route but did not improve accuracy.
R2 · corrupted fixture	5/5; Nu 0/5; 31.4 s; 358 tokens	5/5; Nu 5/5; 32.0 s; 410 tokens	Both blocked the ranking; the expected activation occurred 5/5 times.
R3 · epistemic boundary	5/5; Nu 0/5; 15.0 s; 88 tokens	5/5; Nu 0/5; 11.4 s; 62 tokens	The policy did not route a conceptual question through Nu.

Both arms achieved 5/5 on all three tasks. The case demonstrates policy conformity—Nu in 10/10 structured observations and 0/5 conceptual observations within that arm—but no difference in accuracy. I did not calculate a p-value: five repetitions of the same case are not five independent problem types. Nor does this alter the boundary of the data: presence=0 does not prove institutional closure.

A verdict for each outcome

Outcome	Where it appears	Defensible interpretation
Improvement	Tuned corpus: 30/30 versus 23/30; holdout: 14/15 versus 10/15	Some task families show an accuracy signal, but not a generalisable rate.
Regression	Microbenchmark, tuned corpus, and holdout	The structured route added latency and, in the agent experiments, more tokens.
No material difference	Real aggregate case and tasks that did not activate the skill	Changing the route did not improve accuracy when both arms already satisfied the contract.

This is the rule I kept after measuring:

Nushell is worth testing when a query combines structured data, several transformations, and a concrete risk of silent failure. For a native operation, a single transformation, or analysis at larger scale, a simpler or more appropriate tool usually exists.

I do not want to make it my primary shell or tell the agent to use it “whenever possible.” The objective is the opposite: it should be able to justify both entering and avoiding that route.

I also see no reason yet to turn this route into an MCP server. A query would merit promotion to a dedicated tool if it recurred, had a stable interface, accepted typed parameters, could be reused across agents, and measurably improved safety or observability. These cases do not yet meet all those conditions.

Closing — A shell is not a religion

The result is not that Nushell wins. It improved accuracy on the tuned corpus; it added time in the microbenchmark and agent experiments, plus output tokens in the latter; and it did not change correctness in the real aggregate case. The reasonable decision depends on the task and on the cost of being wrong.

The most interesting finding was not Nushell either. It was discovering that a skill might never activate, that a rule about hidden files might be incomplete, and that a pipeline could return null with apparent success. The benchmark ended up testing both the tool and my assumptions.

There are probably better routes. If you use Nushell, DuckDB, jq, Python, MCP, skills, or another strategy that gives an agent a concrete advantage, I would like to know what problem it solves, what baseline you compared it against, and how you verified that it actually improved the workflow. Rather than collecting tools, we should start collecting evidence about when they are worth using and what they measurably improve.

References and notes

Conflicts of interest and provenance. The penta-agent metrics and the thesis case were produced by the same project that implemented the skill. The Nushell documentation also comes from the tool's developers. I use it to document the declared contract and behaviour, not as independent evidence of superiority.

Greenberg, Michael, and Austin J. Blatt. 2020. “Executable Formal Semantics for the POSIX Shell.” Proceedings of the ACM on Programming Languages 4 (POPL), article 43, 1–30. https://doi.org/10.1145/3371111. ↩
Nushell. n.d. “Nushell: A New Type of Shell.” Accessed September 5, 2026. https://www.nushell.sh/. ↩
R Core Team. n.d. “Fisher's Exact Test for Count Data.” R Documentation. Accessed September 5, 2026. https://stat.ethz.ch/R-manual/R-devel/library/stats/html/fisher.test.html. ↩
Clopper, C. J., and E. S. Pearson. 1934. “The Use of Confidence or Fiducial Limits Illustrated in the Case of the Binomial.” Biometrika 26, no. 4: 404–413. https://doi.org/10.1093/biomet/26.4.404. ↩
R Core Team. n.d. “Exact Binomial Test.” R Documentation. Accessed September 5, 2026. https://stat.ethz.ch/R-manual/R-devel/library/stats/html/binom.test.html. ↩
Efron, Bradley, and Robert J. Tibshirani. 1993. An Introduction to the Bootstrap. New York: Chapman & Hall. https://www.routledge.com/An-Introduction-to-the-Bootstrap/Efron-Tibshirani/p/book/9780412042317. ↩
sharkdp. n.d. “fd: A Simple, Fast and User-Friendly Alternative to find.” GitHub repository. Accessed September 5, 2026. https://github.com/sharkdp/fd. ↩
Nushell. n.d. “Scripts.” The Nushell Book. Accessed September 5, 2026. https://www.nushell.sh/book/scripts.html. ↩

Appraisal and vulnerability in 3 spoonfuls: change the denominator, change the map

Cristián Labra — Mon, 07 Sep 2026 00:39:03 +0000

Most countries tax immovable property, and most of them argue about it badly. The argument usually skips the part that decides the answer: before any map is coloured, someone has to choose what is added up, what it is divided by, over which territory it is aggregated, and which cases are left out. Change any of those and the map can change while the underlying data stay identical.

This post works through that problem with Chilean data, because Chile happens to publish the pieces needed to do it honestly: a national cadastre of every taxable property, and an official index that ranks small civic territories by socio-territorial vulnerability. The mechanics, though, are not Chilean. Any jurisdiction that assesses property for tax and then maps the result against a deprivation measure faces exactly the same four choices.

The question fits in one small fraction:

territorial indicator \frac{the total you want to describe}{the unit you compare it against}

Adding up the assessed value inside a territory answers how much administrative value was allocated there. Dividing that same total by households, by residents or by square metres answers different questions. None of them is «the correct one» by nature; the error appears when one is presented under another's name. The arithmetic is usually innocent. The narrative is not always.

Reading contract

I cross two Chilean administrative registers: the real-estate cadastre of the Servicio de Impuestos Internos (SII) —Chile's tax authority, roughly the counterpart of the IRS or HMRC— and the Índice Global de Vulnerabilidad Socioterritorial (IGVUST), a socio-territorial vulnerability index published by the Ministry of Social Development and Family. The unit of analysis is the neighbourhood unit, not the parcel, the household or the person.

A word on that unit, because it has no clean equivalent elsewhere and it drives half of what follows. A Chilean unidad vecinal (UV) is a civic territory drawn for neighbourhood organisation and local participation — closer to a British ward or an American neighbourhood association boundary than to a census tract. Crucially, it was never designed to tile the country. Large stretches of rural Chile belong to no UV at all. A census geography would cover everything by construction; this one does not, and pretending otherwise is the first way to get the map wrong.

Concept	What it means here	What it does not mean
SII cadastre	Administrative register of real estate and its characteristics.	A population census or a register of residents.
Parcel	Cadastral unit identified by municipality, block and parcel number.	A dwelling, a household, an owner or a person.
Fiscal appraisal	Administrative valuation used as the base of the property tax.	Sale price, income, or the wealth of whoever lives there.
IGVUST	A ranking of neighbourhood units by socio-territorial vulnerability.	An individual diagnosis or a causal mechanism.
RSH	Chile's Registro Social de Hogares, the means-testing registry that supplies the households and people used as denominators. In this processing it sums 15,978,644 people, close to 85% of the country's population.	A complete census, or a universe with even coverage across municipalities.
Neighbourhood unit (UV)	Territory defined for neighbourhood organisation and participation.	An exhaustive mesh covering all of Chile parcel by parcel.
Denominator	The magnitude the allocated appraisal is divided by.	Small print added afterwards: it defines the question.

The RSH matters because it is the source of the households and people I use as denominators. Nationally it is broad —around 85% of the population— but it does not cover every municipality equally. In municipalities with low relative RSH enrolment, as can happen in the wealthiest districts of Santiago, an indicator «per RSH household» can inflate because the denominator is narrow, not because there is more appraised value. That is a coverage artefact, not a finding.

Fiscal appraisal is also not market price: the SII builds it from the characteristics of the property and its homogeneous valuation zone, not from an observed transaction. It can be a useful territorial signal as long as it keeps its surname, fiscal — Rosen's (1974) hedonic price theory explains why surroundings weigh on the valuation of a differentiated good such as housing, but this post observes neither transactions nor household wealth.

One note on notation for readers used to the short scale: Chilean Spanish uses billón for 10¹². Throughout this English version I write trillion for that same quantity. Chilean pesos traded around 980 CLP per US dollar in July 2026, so the national total below —587.4 trillion CLP— is on the order of US$600 billion.

Data cut: 19 July 2026. Editorial date: 26 July 2026. All relationships are descriptive and depend on the UV mesh used.

The question

I aggregated the fiscal appraisal of SII parcels to UV scale and compared it against the IGVUST national vulnerability ordering, holding the numerator fixed and changing the lens:

Measure	Question it answers
Total appraisal	How much fiscal appraisal was allocated to this UV?
Appraisal per RSH household	How much allocated appraisal corresponds to each registered household in the UV?
Appraisal per RSH person	How much corresponds to each registered person?
Appraisal per m² of parcel area	How much corresponds to each square metre of allocated parcel surface?

The short answer: per household and per person there is almost no relationship with vulnerability. Per square metre a strong national relationship appears, but it dissolves when you look only at predominantly urban UVs. This is not a glamorous paradox between wealth and vulnerability. It is more sober, and therefore more useful: the denominator, the universe and the scale are part of the result.

A warning before continuing: none of this says how much the people living there earn, what their house is worth on the market, or who owns it. Turning a territorial association into a statement about persons is precisely the ecological inference Robinson (1950) warned about more than seventy years ago.

Before the spoonfuls: why we tax what cannot move

The property tax has a less exotic logic than its public reputation suggests. Property is a visible base, immobile, and tied to the territory where services are delivered. In Chile, property tax revenue is municipal: part stays in the municipality of origin and part feeds the Fondo Común Municipal, an equalisation fund that redistributes resources for street lighting, green areas, infrastructure and social programmes (SII, Impuesto Territorial). Without a cadastre, appraisals and parcel-level location, that architecture simply does not work.

None of this is a Chilean peculiarity. Recurrent taxes on immovable property hold a relevant place in local finance across many countries. The comparison assembled by the World Bank shows collections close to 2%–3% of GDP in the United States, Canada and the United Kingdom, and significant shares of local revenue. These are not copies of the Chilean system, but they share the same intuition: part of the value that accumulates in a territory helps finance that territory (World Bank, 2020).

The comparative evidence does not say that any property tax is fair by definition. It says something more uncomfortable: design rules. The OECD and the IMF highlight its immobile base, its revenue potential and its link to local services, but they recommend up-to-date valuations, moderate rates, and targeted or deferred relief for owners with low liquidity. The IMF itself uses the British Council Tax as an example of how overly compressed bands can produce a regressive outcome (OECD, 2022; IMF, 2024). The instrument does not arrive progressive from the factory.

There is, of course, a flashier route: delete a line from the bill and rebuild the cost on another spreadsheet. The sum can balance; the distribution need not. When an exemption stops looking at income or value and the compensation reproduces prior revenue, the tax does not disappear: it changes pocket, fund, or postcode. The accounting stays calm. The territory may not.

Seen that way, the cadastre stops being a collection of tax rolls and becomes what it actually is: the infrastructure that lets you measure the base, divide it, and argue about who benefits from each rule. Now, the three spoonfuls.

Spoonful 1: building the numerator without closing the leak

The original extract holds 10,343,893 records. A record is not the same as a unique parcel; administrative databases have echoes too. After deduplicating the cadastral key —municipality, block and parcel number— 9,401,277 parcels remain. The goal is to distribute their appraised value across 6,891 UVs before testing any denominator.

Parcels and UVs are both polygons, but their boundaries do not coincide. A parcel can fall entirely inside one UV, straddle several, or touch none. I use areal apportionment by intersection area, a form of areal interpolation (Goodchild, Anselin & Deichmann, 1993):

f_{p, u} = \frac{area ( p \cap u )}{area ( p )} A_{u} = p \sum a_{p} \cdot f_{p, u}

where $$a_p$$ is the parcel's fiscal appraisal and $$A_u$$ the total allocated to the neighbourhood unit. If the parcel sits entirely inside one UV, it contributes everything; if it straddles the boundary in half, it contributes half.

Two methodological decisions matter.

I use geometric area to apportion. Among unique parcels, 10.7% have no usable declared surface and 2.8% have no geometry at all. Declared surface can serve for auditing or sensitivity checks, but it is not enough to place a parcel in space when there is no polygon. So I do not impute UV allocation from reported square metres alone. If a fallback is implemented later, it has to enter the analytical pipeline first, with an explicit location rule, and only then the post and the viewer. A pretty map is not a licence to invent geometry.

I do not renormalise. If $$\sum_u f_{p,u} < 1$$, part of the parcel fell outside every UV. Redistributing that remainder among the UVs it did touch would produce a perfect sum —very convenient for the chart— and a worse measurement: it would hide the fact that the UV was never designed to tile Chile.

The residual is concrete: 271,150 parcels, 2.884% of the deduplicated set, landed in no UV at all. The median municipal leakage is 0.644%, but it is not homogeneous. In Antofagasta, 2,325 parcels outside any UV concentrate 32.6% of the municipality's fiscal appraisal; in Tortel, Timaukel, San Gregorio, Laguna Blanca and Río Verde the leakage reaches 100%, because the UVs cover the settlement and the catalogued parcels lie outside that mesh.

That bias gets declared, not swept under the rug. In municipalities with many parcels lacking polygons, or with heavy leakage outside the UV mesh, the crosswalk under-represents part of the cadastre. Public reading has to look at those indicators before interpreting any colour.

  <source type="image/webp">
  <img src="https://3cucharadas.cl/assets/images/avaluo-vulnerabilidad-unidad-vecinal/sankey-pipeline-en.webp" alt="Flow diagram: 10,343,893 original records split into 942,616 duplicates and 9,401,277 unique parcels; of the latter, 9,130,127 touch at least one neighbourhood unit and 271,150 touch none.">

Figure 1 — From the original register to the spatial universe. «Touches at least one UV» does not mean full allocation: a parcel can intersect a UV and still keep part of its surface outside the mesh. Source: own elaboration, data cut 19/07/2026. Click to enlarge.

Before the IGVUST: the size of the observed appraisal

Before crossing anything with vulnerability, it helps to know the order of magnitude. Across the 346 municipalities, allocated fiscal appraisal sums 587.4 trillion pesos (≈US$600 billion). The Santiago Metropolitan Region concentrates 286.7 trillion (48.8%); Valparaíso, 56.2 trillion (9.6%); Biobío, 39.4 trillion (6.7%). The concentration is not a detail: it sets the size of the numerator that later gets divided.

Table 1 — Allocated fiscal appraisal before normalising

Level	Territory	Allocated appraisal (trillion CLP)	National share
Region	Metropolitana	286.7	48.8%
Region	Valparaíso	56.2	9.6%
Region	Biobío	39.4	6.7%
Region	La Araucanía	28.2	4.8%
Region	Maule	26.4	4.5%
Municipality	Las Condes	38.2	6.5%
Municipality	Santiago	27.1	4.6%
Municipality	Providencia	16.3	2.8%
Municipality	Lo Barnechea	16.0	2.7%
Municipality	Vitacura	15.2	2.6%

Shares are computed over the national allocated total of 587.4 trillion. The amounts for La Araucanía and Maule are derived from that published share, not from a separately measured figure. In municipalities with UV leakage or low relative coverage of the RSH denominator, this size should not be confused with a complete reading of the territory or its residents.

The five municipalities in the table add up to 112.8 trillion: 19.2% of the entire allocated base of the country, in five municipalities out of 346, all of them in the eastern districts of Santiago. That is the concentration that later disappears from view once you divide by households or by square metres. Antofagasta also ranks high (15.1 trillion), but with very high municipal UV leakage; that is exactly the kind of case where the total, the denominator and the universe have to be read together.

The viewer carries this raw reading in the Appraisals tab of its denominator laboratory. First the numerator; then the story.

Spoonful 2: quartiles, bivariate map and denominators

The IGVUST ranks neighbourhood units by socio-territorial vulnerability. I keep its four official quartiles because they are that source's analytical contract — and note the direction, because it is easy to reverse: q1 is the most vulnerable quartile and q4 the least. On the appraisal axis, each UV is compared against the median of its own region, not against a fixed national cut: it lands below or above that regional median. The result is a 4×2 matrix —four IGVUST rows by two appraisal columns— which avoids two problems at once: a finer partition would make the bivariate map hard to read and, in regions with few UVs such as Arica y Parinacota, would suggest a precision the aggregated data do not deliver; and a fixed national cut would ignore that typical appraisal levels differ sharply between regions. A quartile indicates relative order, not distance.

In the bivariate map the main reading uses appraisal per m² of parcel area. It is the clearest signal for drawing attention where high unit appraisal coincides with high territorial vulnerability. In the palette those cells are darker, with a transparent layer so as not to cover the basemap or turn the map into a chromatic alarm. The counterintuitive should draw attention; the obvious does not need a megaphone. The indicator remains descriptive and national; restricting to UVs with $$p_\text{urban} > 50$$ attenuates the per-m² association sharply.

In the viewer, this crosswalk lives in an analytical map: UVs only, a graphic selector of Chile, hover with the unit's data, and a 4×2 legend. A single region-and-municipality search box governs the whole tour, and the selection you fix there carries into the tables and the territorial ranking where it applies. Inspecting parcel geometry is deliberately kept apart, as a documented annex: mixing it with the bivariate classification invites reading a cadastral boundary as if it were a result.

1. Per household, the eye-catching cell is a lead

If you divide by RSH households, the most vulnerable quartile (q1 IGVUST) contains 530 UVs in the highest quartile of appraisal per household. That number can look like a social contradiction. It is not one yet.

Table 2 — Neighbourhood units by national vulnerability quartile and appraisal per household

IGVUST quartile	Appraisal/household q1	q2	q3	q4
q1 · most vulnerable	399	344	446	530
q2	564	451	385	321
q3	467	509	429	316
q4 · least vulnerable	293	419	463	546

The right word is lead, not conclusion. The ratio combines territorial appraisal with RSH households. If the denominator is small or the territory is large, the quotient rises without that demonstrating any greater wealth among the people who live there.

2. The eye-catching quadrant has fewer households and far more area

The vulnerable UVs with the highest appraisal per household have a median of 120.5 households and 78.2 km². The vulnerable ones with the lowest appraisal per household have 265 households and 3.36 km². The ratio grows because the denominator shrinks while the territory expands. The spreadsheet does its job; interpretation has to do its own.

Table 3 — Mechanism inside the most vulnerable quartile (q1 IGVUST)

Appraisal/household	UVs	Median households	Median area (km²)	Median appraisal/household (million CLP)
q1	399	265.0	3.36	10.2
q2	344	368.5	15.21	26.2
q3	446	274.5	45.59	57.6
q4	530	120.5	78.22	185.6

The table does not invalidate the crosswalk. It delimits what it measures: fiscal appraisal allocated to a UV divided by RSH households, not the wellbeing of its residents.

3. The association changes with normalisation

The next table uses two summaries between -1 and +1. Pearson summarises a linear relationship over the logarithm of positive appraisal; Spearman summarises whether the ordering of UVs changes monotonically. Near zero there is little linear or monotonic relationship. Neither column estimates a causal effect.

Table 4 — Sensitivity of the association to the denominator

Appraisal measure	Pearson	Spearman	UVs
Total allocated	-0.371	-0.382	6,857
Per RSH household	-0.061	-0.047	6,849
Per RSH person	-0.079	-0.072	6,849
Per m² of allocated parcel area	-0.582	-0.575	6,851
Per m², predominantly urban UVs only	+0.079	+0.081	3,221

Per household and per person, the association is close to nil. Per square metre, the national pattern looks strong. Restricting to predominantly urban UVs it flips to roughly +0.08. The prudent reading is that the national per-m² result contains a great deal of urban–rural contrast; not that a neighbourhood-level mechanism has been identified.

The violins in Figure 2 show the full distribution. Their width indicates where more UVs concentrate; the internal lines show median and interquartile range. They are smoothed densities, not literal silhouettes of the territory.

  <source type="image/webp">
  <img src="https://3cucharadas.cl/assets/images/avaluo-vulnerabilidad-unidad-vecinal/violin-denominadores-en.webp" alt="Three violin plots compare the distributions of appraisal per household, appraisal per square metre nationally, and appraisal per square metre in predominantly urban neighbourhood units, across the four national vulnerability quartiles.">

Figure 2 — The same appraisal produces different distributions once the denominator and the universe change. The violins show estimated densities; their shape depends on the bandwidth and proves neither natural groupings nor causality. The internal lines summarise median and interquartile range. Source: own elaboration, data cut 19/07/2026. Click to enlarge.

4. What is robust is the sensitivity

Among the 6,843 UVs with an available quartile both per household and per m², only 1,362 (19.9%) stay in the same quartile and 3,132 (45.8%) move two or more. The parcels did not change. The question did.

Spoonful 3: scale and concentration

Among the 6,857 UVs with positive allocated appraisal, the Gini coefficient is 0.7265. It describes a highly concentrated territorial tax base; it is not a Gini of personal income or wealth.

This matters beyond the statistical exercise. On a base this concentrated, any exemption also redistributes: it decides not only who stops paying, but which municipality, fund or tax will have to rebuild the amount. The benefit fits on one line; the full incidence usually needs another spreadsheet.

The Gini summarises concentration but does not separate how much occurs within and between groups. That is what the Theil index is for, since it does decompose. With $$x_i$$ as the appraisal allocated to UV $$i$$, $$\mu$$ its mean and $$w_g$$ the share of group $$g$$ in total appraisal:

T = \frac{1}{n} i = 1 \sum n \frac{x _{i}}{μ} ln! (\frac{x _{i}}{μ}) = g \sum w_{g} T_{g} within + between \sum g w_{g} ln! (\frac{μ _{g}}{μ})

Grouping by region, $$T = 1.2042$$ and 81.0% stays within regions. Regrouping by municipality, the between-group part reaches 56.9%. The municipality does not «reveal» segregation by magic: when you refine a partition, part of the inequality shifts from the within component to the between component by construction (Shorrocks, 1984).

That is the modifiable areal unit problem, or MAUP (Fotheringham & Wong, 1991). The same parcels can produce different statistics depending on whether they are grouped into regions, municipalities or UVs. Scale does not decorate the result: it defines it. Which is why it matters what the UV actually is before using it as a container: if the unit does not correspond to a territory with its own meaning, the statistic it produces inherits that mismatch.

Second brake: IGVUST quartiles order UVs, not people. The most vulnerable quartile gathers 25% of the units, but 2,032,893 of 15,978,644 RSH people (12.7%). A choropleth can over-represent dispersed rural territory even when its colours are perfectly computed.

Third brake: the assessment ratio literature shows that fiscal valuation can depart systematically from market values, and that the pattern depends on institutional context. Hodge, McMillen, Sands and Skidmore (2017) study that problem in another market; they do not prove the SII carries the same bias. What they do show is that using fiscal appraisal as a synonym for market price requires substantial adjustment factors — although, even so, territorial gradients and trends should not diverge that much.

Closing: gaps pay property tax too

The map does not dictate a tax policy. It does make it impossible to pretend the base is homogeneous, that every municipality starts from the same place, or that an exemption has no geography. The crosswalk identifies five gaps that must be closed before its colours can be used as strong evidence.

Gap 1: the denominator's universe. The RSH covers around 85% of the country's population, but not with equal intensity across municipalities. Any indicator per RSH household or person has to declare that coverage and, where applicable, contrast it against census data. That contrast is exactly what the viewer opens with: before any crosswalk, it measures what fraction of the private dwellings counted in the 2024 Census is reached by the SII residential register, municipality by municipality. It is the same warning as this post, in its simplest form — declare the universe before dividing by it.

Gap 2: geometry and surface. Apportionment requires polygons. Declared surface does not replace missing geometry without an additional spatial rule. Municipalities with many parcels lacking polygons need a warning before anyone interprets their colour.

Gap 3: leakage outside the UV mesh. The UV does not cover the entire cadastral territory. If a municipality concentrates a lot of appraisal outside any UV, the crosswalk describes a subset, not its municipal total. The UV mesh needs local work to fit reality better.

Gap 4: urban–rural. Appraisal per m² has a strong national signal, but it changes when the universe is restricted to urban UVs. The indicator needs a universe filter, not just an intense palette.

Gap 5: scale. Region, municipality and UV are not enlarged versions of the same question. Changing the territorial unit changes the statistic.

These gaps are not an automatic defence of every appraisal, rate or charge in force either. Relieving someone with little liquidity and a highly valued home is a real problem. Comparative evidence offers more precise instruments: income-based reductions, caps on the tax burden, deferrals until sale or inheritance, and transparent reassessments. There is no need to ask the cadastre to pretend the asset stopped existing.

You can, of course, remove the obligation from one column and restore it with transfers from another. The relief stays visible; its financing moves. Before celebrating that the bill disappeared, it is worth checking the second spreadsheet and asking which territories end up paying for the courtesy.

The viewer lets you explore these gaps from the general to the particular: the whole country, the municipality you choose, its neighbourhood units in the bivariate map, and a laboratory that zooms back out to test denominators, with an appraisals view, distributions, sensitivity checks and a municipal reading. An exemption does not stop being distributive because it is called a benefit: it also has a numerator, a denominator and a geography.

Explore the map and the denominator laboratory

The viewer's interface is in Spanish, but its charts, tables and downloadable Parquet files are readable without it.

Sources

Property tax and international comparison

Servicio de Impuestos Internos (SII). Impuesto Territorial. Tax base, exemptions, reassessment and cadastral mapping. sii.cl.
Servicio de Impuestos Internos (SII). ¿Para qué sirve el pago del impuesto territorial? Municipal destination and the Fondo Común Municipal. sii.cl.
OECD (2022). Housing Taxation in OECD Countries. OECD Tax Policy Studies, No. 29. 10.1787/03dfe007-en.
Grote, M. & Wen, J.-F. (2024). How to Design and Implement Property Tax Reforms. IMF How-To Notes, 2024/006. 10.5089/9798400288753.061.
World Bank (2020). Property Tax Diagnostic Manual. Institutional repository.
Senate of the Republic of Chile (15 July 2026). Reconstrucción nacional: ¿cuáles fueron los aspectos centrales aprobados? Legislative background to Bill No. 18.216-05, accessed 26 July 2026. senado.cl.
Cooperativa (22 July 2026). Megarreforma: comisión mixta aprobó compensación a municipios por exención de contribuciones. Formula approved by the joint committee and status of the bill, accessed 26 July 2026. cooperativa.cl.

Method and theory

Sabatini, F., Cáceres, G. & Cerda, J. (2001). Segregación residencial en las principales ciudades chilenas: Tendencias de las tres últimas décadas y posibles cursos de acción. EURE, 27(82), 21-42. 10.4067/S0250-71612001008200002.
López-Morales, E., Sanhueza, C., Espinoza, S. & Órdenes, F. (2019). Verticalización inmobiliaria y valorización de renta de suelo por infraestructura pública: un análisis econométrico del Gran Santiago, 2008-2011. EURE, 45(136), 113-134. 10.4067/S0250-71612019000300113.
Rosen, S. (1974). Hedonic Prices and Implicit Markets. Journal of Political Economy, 82(1), 34-55. 10.1086/260169.
Goodchild, M. F., Anselin, L. & Deichmann, U. (1993). A Framework for the Areal Interpolation of Socioeconomic Data. Environment and Planning A, 25(3), 383-397. 10.1068/a250383.
Robinson, W. S. (1950). Ecological Correlations and the Behavior of Individuals. American Sociological Review, 15(3), 351-357. 10.2307/2087176.
Shorrocks, A. F. (1984). Inequality Decomposition by Population Subgroups. Econometrica, 52(6), 1369-1385. 10.2307/1913511.
Fotheringham, A. S. & Wong, D. W. S. (1991). The Modifiable Areal Unit Problem in Multivariate Statistical Analysis. Environment and Planning A, 23(7), 1025-1044. 10.1068/a231025.
Hodge, T. R., McMillen, D. P., Sands, G. & Skidmore, M. (2017). Assessment Inequity in a Declining Housing Market: The Case of Detroit. Real Estate Economics, 45(2), 237-258. 10.1111/1540-6229.12126.

Multi-agent work in three spoonfuls III: a memory that leaves traces

Cristián Labra — Mon, 07 Sep 2026 00:38:16 +0000

Status of the demo. The viewer was regenerated on August 29, 2026 from a sanitized public projection (with the non-public bits stripped out 😀): the artifact contains no mail bodies, attachments, addresses, absolute paths, tokens, credentials, or microdata.

Preamble: remembering is not enough

In the second part I went after a bounded problem: getting penta-agent's memory to retrieve evidence and to recognize when it had found none. The question in this third part is more practical, and it comes out of the system having been in use for a while: what happens to a memory as it grows and turns blurry, or even contradictory?

An index can pile up fragments without any trouble, and there are plenty of tools that already do that well. A more useful memory, in my judgment, has to carry provenance, currency, permissions, contradictions, and deletion criteria. It also has to tell finding a source apart from using it correctly. Recent literature insists on separating RAG — retrieval-augmented generation — context management, and agent memory, because they do different jobs and call for different evaluations ¹.

What follows has three movements: what changed since part II; which experiments survived a more serious evaluation; and how to show a memory without passing it off as a mind.

Spoonful 1: from retrieving fragments to governing evidence

In part II the problem was retrieving well: finding the relevant context and recognizing when there was not enough evidence. A useful memory does not only retrieve information; it also has to know where it came from, whether it still holds, where it can be used, and what is allowed to be done with it.

RAG mostly solves retrieval. The memory layer adds rules for keeping, updating, relating, or discarding evidence. None of those functions amounts, on its own, to identity. To describe provenance I use concepts compatible with PROV-O — entities, activities, and agents — while currency, sensitivity, and permissions need rules of their own ².

What changed since part II

Open item from II	What exists now	What is still open
Compare dense retrieval, lexical retrieval, and reranking.	A frozen cut of 319 contexts and 40 queries evaluated at `k=5`.	The best configuration gets 38 complete cases and 2 partials; the strict gate stays shut.
Check that an answer uses its sources and knows how to abstain.	The `context-answer-v1` contract, with 12 positive and 6 negative cases, all sanitized.	The end-to-end evaluation with a local model and the reserved human review are unfinished.
Add currency without erasing history.	The proof of concept admits `supersedes` only toward later versions and rejects competing successors.	There is still no temporal reasoner wired into live memory.
Show growth without turning the graph into truth.	A 3D viewer, regenerable from sanitized JSON and accompanied by a text alternative.	The viewer neither validates relations nor represents a mind.

The difference may look small, but it changes the question. Knowing which fragment sits close to a query is no longer enough; what matters as well is what kind of evidence it is and under what conditions it can be reused.

What memory actually exists

The PoC brings several layers together, but does not treat them as equivalent:

penta-agent experience: 16,955 indexed points and 1,432 strategies make it possible to explore actions, corrections, and failures. Semantic closeness proves neither causality nor truth.
Curated context: 319 canonical records make it possible to retrieve handoffs and decisions with their provenance. The index helps to find them, but does not replace the original record.
Research process: a projection with 796 derived artifacts and 533 links makes it possible to inspect the work trajectory without publishing documents or microdata.
Personal mail: the local inventory holds 12,072 unique messages between 2011 and 2026. It serves to test reading and deduplication within an authorized scope; it is not a public corpus and not a personality model.
Experimental personal memory: a separate prototype tests retrieval through mbox, SQLite/FTS, scopes, and purge. There is still no authorization to generate answers out of sensitive mail.

This separation heads off a frequent temptation: confusing having technical access to a source with being authorized to turn it into reusable memory.

A useful failure

The pipeline itself supplied an example of why provenance matters. The historical exporter expected a plain vector, while the current index stored the named dense vector. The first regeneration produced a degraded graph, with no semantic edges. A run against the real index caught the incompatibility and, once the exporter was fixed, 3,658 edges came back.

The lesson matters more than the number: an auditable visualization has to be able to show when its data chain degraded, why it happened, and how it was put back together. It is a real use case.

From command to task

The 1,432 recorded strategies are still the basic unit of this memory. Many of them started life as commands, so I added a deterministic classification to make them more readable: coordinating agents (399), researching and analyzing (396), tracing evidence (385), executing or automating (118), versioning changes (76), verifying (28), operating infrastructure (18), and communicating results (12).

A strategy could belong to several categories, but today it lands in the first matching rule. It is a lens for walking through the memory, not a description of the person behind it. There is plenty of room to improve this with other visualizations; if you know of one, I would be grateful for the tip.

Spoonful 2: governing sources before blending them

The architecture starts from a simple separation. The canonical record (the ledger) and the source files hold the evidence; Qdrant keeps indexes that can be destroyed and regenerated; the viewer publishes a sanitized projection; and the private adapters stay outside Git. The index is there to find things. It has no authority to turn a vector match, on its own, into a durable fact.

An architecture of permissions, not a blender

Mail, thesis material (from the master's degree), and operational memory may all be technically readable by the same system, but that does not make them interchangeable. In this PoC, only the previously curated context may feed cross-agent retrieval and the public projection. Mail stays in a private, reversible, revocable circuit; the thesis contributes authorized process metadata and nothing else.

The distinction matters: having technical access to a piece of data does not settle whether reusing it for any purpose is legitimate. Contextual integrity theory poses exactly this problem: privacy depends not only on the data, but also on the context, the actors, and the norms that govern its circulation ³.

Figure 1. The current integration is an architecture of permissions: each source determines which outputs are permitted.

The thesis is a good example. What enters the public system is a snapshot of the research index, not the corpus. The August 29 cut holds 796 derived textual artifacts — 316 audits, 244 reports, 133 contracts, 71 pseudocode files, and 32 inventory, replication, or documentation pieces — plus 533 links and 7 open leads. It leaves out the source documents, DTA, Parquet, PDF, images, paths, full texts, and microdata. The search is deliberately lexical: FTS5 and TF-IDF help to find artifacts, but they make no claim to understand the research.

There is a detail more interesting than the figures. The published snapshot is still faithful to the cut it declares: its fingerprint matches the manifest of that moment. The corpus, however, kept growing and reached 817 documents, twenty-one more. Since the index was not regenerated, the currency gate is red: check-research-index returns 2, because document_count and source_fingerprint no longer match the current state.

That does not invalidate the snapshot; it dates it. Its correct status is "valid for the August 29 cut, but not current with respect to today's corpus". A gate that had stayed green after the corpus grew would have been worse than a failed gate: it would have certified a currency that does not exist. This is the formal record of the memory's growth and potential divergence.

Reuse before reinventing

None of this requires building every memory component from scratch. In fact, a good sign of maturity would be being able to delete my own code when an existing tool solves the same problem better without degrading privacy, provenance, or reversibility.

To recover decisions scattered across coding sessions, deja-vu already indexes the local histories of many agents and exposes them through a CLI and MCP. It is a natural candidate to contrast against my own handoffs and events before writing yet another equivalent layer.

For more structured persistent memory there are more ambitious approaches. MemGPT introduced the idea of managing distinct memory tiers as a way of extending an agent's effective context ⁴; Letta's current line carries that principle into editable memory blocks and external memory. Mem0 automates the extraction, consolidation, and retrieval of information from conversations ⁵, while Hindsight distinguishes the operations of retaining, recalling, and reflecting, taking in semantic, lexical, temporal, and graph-based retrieval ⁶.

The currency problem deserves an experiment of its own. Graphiti, the open component described in Zep's architecture, explicitly models relations that change over time and keeps historical information instead of silently replacing it ⁷. That comes far closer to the problem I am trying to solve with supersedes than piling on more temporal rules of my own.

For document collections, Microsoft GraphRAG offers another useful idea: build a graph derived from the corpus and summarize communities to answer global questions that a conventional RAG handles worse ⁸. I would not use it yet as a replacement for the thesis index. First it would have to show, over a bounded scientific subset, that the added complexity and cost improve something the lexical baseline cannot resolve.

Visualization, finally, is a practically solved problem: 3d-force-graph already provides a three-dimensional layout built on Three.js and force algorithms. The relevant part of this PoC is not writing another graphics engine, but controlling which graph the browser receives and remembering that visual distance proves neither conceptual proximity, nor causality, nor human affinity.

The common rule is simple: test components, do not collect them. That a library can remember more does not mean it should receive more data.

There is also a conflict of interest worth making explicit. Mem0, Hindsight, Zep/Graphiti, and Letta are described in large part by their own teams. Their papers and repositories are appropriate sources for learning the architectures they propose, but their comparative results are not independent validation of superiority. I use them here as designs that deserve a contrast, not as winners of a competition — and my own stack is not superior either. If anything, mine is rather experimental, built for my own purposes.

A retrieval experiment that could fail

I tested Qwen3-Embedding-0.6B on an isolated copy of 319 contexts, without touching production. The evaluation used 40 queries, eight of them designed to check that the system also knew how not to retrieve evidence when it should not.

The best configuration got 38 complete cases, 2 partials, and no outright miss within the top five positions. From there I tried several possible improvements:

dropping the BM25 lexical boost held the best result;
adding a generic instruction to the embedding made both retrieval and abstention worse;
Qwen3-Reranker-0.6B ordered the results somewhat better, but pushed response time up too far;
diversifying by repository and fusing rankings did not resolve the two partial cases either.

The experiment left a conclusion more useful than finding a new model: the two open cases do not seem to need more power, but better metadata. Both of them require retrieving documents from different families within only five results.

So the next test will be to add explicit information about lineage and document intent, without using the correct answers to build those labels. Arbitrarily raising k or piling on more models would only have moved the problem elsewhere.

Until those two cases are resolved reproducibly, the collection stays in staging. In this system, remembering that an improvement has not been demonstrated yet is also part of the memory.

Spoonful 3: a map that does not pass itself off as a mind

Once what may enter the memory is sorted out, another question remains: how do you show it without mistaking a representation for reality?

The viewer answers with a precaution: it queries neither Qdrant (the database where the vectors are indexed) nor any private source when someone opens the site — it receives a sanitized JSON (a data file from which the information that must not be published has been removed), generated from a specific cut of the memory.

That way the graph can be rebuilt and audited without touching the original sources again. The public JSON export even lets you inspect directly what information the browser receives.

Seeing the network without attributing more to it than it says

The August 29 cut holds 1,432 strategies, 3,949 relations, and eight task families, derived from 16,955 indexed points.

The image below is not that network: it is an illustration, and the percentage is the joke. The real network is explored in the full viewer, which lets you select tasks, projects, and errors.

Figure 2. An illustration, not a projection of the data: the digital-clone metaphor loaded to 20%. The network hints at itself where there is density and comes apart where there is none, which is exactly what an index knows how to do. The real projection, with its nodes and edges, is in the viewer.

Open the interactive viewer in a new tab →

It is worth reading with some precautions. A node (a point in the graph) stands for a recorded strategy. An edge (a line between two nodes) stands for some derived relation: semantic similarity, a shared tool, or a correction, for instance. A community (a group of nodes that appears especially well connected) helps you get your bearings inside the network.

None of those relations proves, on its own, causality, truth, or a trait of the person who used the system. Mail and private documents do not appear as content nodes either.

The numbers belong, moreover, to a dated cut. Updating the memory does not silently change the graph: the projection has to be regenerated, sanitized again, and its differences reviewed before it is published anew.

The viewer is not the memory. It is barely a map built from one of its projections.

Retrieving a source is not enough either

Finding the right document is only half the problem. The system also has to use the right source, respect its scope, and abstain when the evidence falls short.

To test that layer I built context-answer-v1, a small set of 18 cases: 12 with sufficient evidence and 6 in which the right answer was to claim no more than what was available. The deterministic test passed all 18 cases and confirmed that the gate works; it still does not prove that a generative model answers well on its own.

The tests with external models also left a practical rule. Only the sources authorized to leave the machine should be evaluated outside it. The exportable subset passed 11/11 cases; another seven sources stayed local_only and require an evaluation inside the local environment.

The conclusion is simple: retrieving is not enough; every answer has to carry provenance, permissions, and the ability to abstain. Until that local evaluation and its human review are complete, I can talk about a governed and attributable memory, but not yet about a reliable generative memory.

Closing: a useful memory before a digital clone

The "digital clone" is still some way off; today it is a distant horizon. What is missing, at a minimum: a temporal memory able to correct itself, revocable preferences and limits, evidence of authorship, behavior evaluated in new situations, and "human" or higher control over what is kept, shared, or deleted. MemGPT⁴ and the generative agents of Park et al.⁹ offer influential architectures for handling context, memories, reflection, and planning, but they do not turn those functions into identity (Packer et al. 2023; Park et al. 2023).

In this third part, penta-agent is a local prototype of governed memory: it keeps experience, records corrections, exposes a bounded public projection, and lets its own tests fail without disturbing production.

The next step forward is not adding more nodes. It is closing the local answer evaluation and comparing alternatives — Graphiti, GraphRAG, or deja-vu — under the same cut, the same permissions, and observable output criteria. I am very much open to your comments and usage experience; I think one practical point of comparison would serve me better than going on testing the many tools that appear day after day.

References

Software and technical documentation

GetZep. n.d. Graphiti: A Framework for Building Temporal Knowledge Graphs. GitHub repository. Accessed August 31, 2026. https://github.com/getzep/graphiti.

Hugging Face. n.d. Sentence Transformers. Technical documentation. Accessed August 31, 2026. https://www.sbert.net/.

Letta AI. n.d. Letta Code. GitHub repository. Accessed August 31, 2026. https://github.com/letta-ai/letta-code.

Mem0 AI. n.d. Mem0: Universal Memory Layer for AI Agents. GitHub repository. Accessed August 31, 2026. https://github.com/mem0ai/mem0.

Microsoft. n.d. GraphRAG. GitHub repository. Accessed August 31, 2026. https://github.com/microsoft/graphrag.

Qwen. n.d. Qwen3-Embedding-0.6B. Model card, Hugging Face. Accessed August 31, 2026. https://huggingface.co/Qwen/Qwen3-Embedding-0.6B.

Qwen. n.d. Qwen3-Reranker-0.6B. Model card, Hugging Face. Accessed August 31, 2026. https://huggingface.co/Qwen/Qwen3-Reranker-0.6B.

Shulcz, Vladislav. n.d. deja-vu. GitHub repository. Accessed August 31, 2026. https://github.com/vshulcz/deja-vu.

Vasturiano. n.d. 3d-force-graph. GitHub repository. Accessed August 31, 2026. https://github.com/vasturiano/3d-force-graph.

Vectorize. n.d. Hindsight: Agent Memory That Learns. GitHub repository. Accessed August 31, 2026. https://github.com/vectorize-io/hindsight.

Conflicts of interest in the sources. The model cards, the repositories, and several of the systems papers are written by their own developers or by organizations that offer related services; LongMemEval-V2, moreover, is still declared work in progress. They are used here to document architecture, declared functions, and maintenance status, not to accept claims of superiority. penta-agent's own metrics are likewise evidence produced by the project itself, and they require reproducible artifacts and independent review before they can support general comparisons.

Hu, Yuyang, Shichun Liu, Yanwei Yue, Guibin Zhang, Boyang Liu, Fangyi Zhu, Jiahang Lin, et al. 2025. "Memory in the Age of AI Agents". arXiv, December 15, 2025. https://arxiv.org/abs/2512.13564. ↩
Lebo, Timothy, Satya Sahoo, and Deborah McGuinness, eds. 2013. PROV-O: The PROV Ontology. W3C Recommendation, April 30, 2013. https://www.w3.org/TR/prov-o/. ↩
Nissenbaum, Helen. 2004. "Privacy as Contextual Integrity". Washington Law Review 79, no. 1: 119–58. https://digitalcommons.law.uw.edu/wlr/vol79/iss1/10/. ↩
Packer, Charles, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. 2023. "MemGPT: Towards LLMs as Operating Systems". arXiv, October 12, 2023; revised February 12, 2024. https://doi.org/10.48550/arXiv.2310.08560. ↩
Chhikara, Prateek, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory". arXiv, April 28, 2025. https://arxiv.org/abs/2504.19413. ↩
Latimer, Chris, Nicoló Boschi, Andrew Neeser, Chris Bartholomew, Gaurav Srivastava, Xuan Wang, and Naren Ramakrishnan. 2025. "Hindsight Is 20/20: Building Agent Memory That Retains, Recalls, and Reflects". arXiv, December 16, 2025. https://arxiv.org/abs/2512.12818. ↩
Rasmussen, Preston, Pavlo Paliychuk, Travis Beauvais, Jack Ryan, and Daniel Chalef. 2025. "Zep: A Temporal Knowledge Graph Architecture for Agent Memory". arXiv, January 20, 2025. https://arxiv.org/abs/2501.13956. ↩
Edge, Darren, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Dasha Metropolitansky, Robert Osazuwa Ness, and Jonathan Larson. 2024. "From Local to Global: A GraphRAG Approach to Query-Focused Summarization". arXiv, April 24, 2024; revised February 19, 2025. https://arxiv.org/abs/2404.16130. ↩
Park, Joon Sung, Joseph C. O'Brien, Carrie J. Cai, Meredith Ringel Morris, Percy Liang, and Michael S. Bernstein. 2023. "Generative Agents: Interactive Simulacra of Human Behavior". In Proceedings of the 36th Annual ACM Symposium on User Interface Software and Technology, article 2, 1–22. New York: Association for Computing Machinery. https://doi.org/10.1145/3586183.3606763. ↩

Multi-agent work in three spoonfuls II: auditable memory

Cristián Labra — Mon, 07 Sep 2026 00:37:14 +0000

In the first post I described how I organized my local multi-agent setup, penta-agent: Codex executes, Claude reviews, other agents enter in bounded ways, and the human keeps closure authority. I also argued that operational memory should not depend on a single conversation or be confused with the vector index.

By the time I closed that first post, I already had continuity mechanisms: handoffs, routing rules, append-only logs, experiential memory in JSONL/YAML, a rebuildable vector collection, and the recall-context skill. My problem was not absolute amnesia. It was that I still could not prove what the system retrieved, when it confused a coincidence with evidence, and when it should admit that it did not have an answer.

This second part, then, is not about inventing memory from scratch. It is about turning still-fragile operational continuity into a traceable, testable, and rebuildable mechanism.

The idea of an external working memory is not new. It echoes Bush's old ambition of augmenting recall through a personal archive and the extended-mind intuition that notes and tools can become part of cognition.¹² My claim here is narrower: local traces are useful only if I can retrieve them with provenance and audit how they were used.

Spoonful 1: the problem was not storing, but retrieving well

Storing information is easy. The difficult part, I think, is retrieving the right piece when there are successive decisions, similar names, contradictory versions, and explanations spread across several files.

To organize that "memory" in my own setup, I separated its operational layers:

Table 1 - System memory layers

Layer	Question it answers	Effective implementation
Canonical record	What happened, and what was decided?	`memory/experience-events.jsonl`, `memory/experience-lessons.yaml`, `memory/interaction-metrics.jsonl`, and curated `context` events.
Retrieval index	Where is the relevant evidence?	Qdrant with `penta_context_v2` for curated context and `penta_experience_v1` for operational memory; both are derived.
Episodic history	How did a session unfold?	Selected Markdown handoffs, compact context events, and operational logs; full sessions are not indexed raw.
Working context	What context do I need to provide now?	MCP `experience-memory` (`experience_status`, `recall_experience`) consumed by the `recall-context` skill.

The distinction matters. A retrieved result is not yet a verified decision. It is a clue that must preserve provenance, date, and a link to its source. In the current contract, local JSONL/YAML files are the source of truth; Qdrant is rebuilt from them. If the index contradicts a current file, the file wins, and the right fix is to reindex or correct ingestion, not to publish vector proximity as if it were final evidence.

The actual flow ended up like this:

Figure 1 - Operational flow of auditable memory in my multi-agent setup. Note: local JSONL/YAML files are the source of truth; Qdrant and BM25 are derived retrieval indexes, not final evidence.

RAG, without turning it into magic

A language model stores part of what it learned during training in its parameters. That memory does not necessarily include what I decided yesterday in a local repository. Retrieval-Augmented Generation, or RAG, adds an external memory: before answering, a retriever searches for relevant passages and gives them to the generative model as context.³

In my implementation, experience-memory acts as the retriever: it queries Qdrant, fuses signals with the canonical records, and returns candidates through MCP. Codex, Claude, or Gemini then use that context according to the workflow. That is why I prefer to describe this as retrieval-augmented agents rather than as an "autonomous RAG": storing and ordering fragments is not the same as reasoning over them.

Searching by meaning and by words

Semantic search transforms each fragment into a vector. The query is represented with the same model and then compared by orientation through cosine similarity:

sim (q, d) = \frac{q \cdot d}{∥ q ∥ ∥ d ∥}

If the query and the document point in similar directions, their similarity increases. This makes it possible to find paraphrases even when they do not share the exact same words.

Lexical search covers the complementary problem: identifiers, acronyms, paths, proper names, and exact terms. BM25 does more than count matches; it weighs term rarity and frequency, saturates repetitions, and partially adjusts for document length.⁴

Today I combine five signals:

dense search in Qdrant with bge-m3 embeddings;
lexical fallback over canonical context events;
BM25 sparse vector with Qdrant/bm25;
event recency;
lifecycle type: outcome, review, decision, or handoff.

I still do not use RRF in the evaluated version. The active fusion is a weighted formula in hybrid_context_hits: when there is a semantic signal, it assigns 0.60 to dense similarity, 0.28 to lexical evidence, 0.07 to recency, and 0.05 to lifecycle type. When there is no semantic signal, the fallback mostly weights lexical evidence. BM25 contributes as an additional reordering signal, but it is not enough by itself to rescue a result.

One less flashy virtue is still missing: teaching the system to stay quiet. A query with no answer in the corpus should not receive a fragment only because it looks nearby. In this version I measure retriever rejection: a candidate qualifies if it passes any of these criteria in the gate run, lexical_score >= 0.34, semantic_score >= 0.44, or hybrid_score >= 0.61. I still do not have an automated abstention metric for the final generator. If a model receives context and invents anyway, this evaluation will not catch it.

Spoonful 2: from a useful index to evaluated retrieval

What I left working uses these pieces, verified against the local repo and active services:

Table 2 - Active components

Function	Component	Verified configuration
Canonical source	`memory/.jsonl` and `memory/.yaml`	Rebuildable local records; at review time, `experience-events.jsonl` had 1,829 lines and `interaction-metrics.jsonl` had 904.
Dense vectorization	Ollama + `bge-m3:latest`	`bert` model, 566.70M parameters, F16, 8192 context, 1024-dimensional embeddings.
Vector database	Local Qdrant	Collections `penta_context_v2` and `penta_experience_v1`; the MCP reported `green` status, 14 canonical contexts, and 1,769 operational points.
Lexical retrieval	Canonical JSONL + FastEmbed BM25	`context_fallback_hits` computes lexical matching; `SparseTextEmbedding("Qdrant/bm25")` feeds the `bm25` sparse vector.
Fusion	`hybrid_context_hits`	Fuses dense, lexical, BM25, recency, and lifecycle signals; deduplicates by `handoff_id` or `source_document`.
Reranking	Not active in the published run	An opt-in reranker exists with `PENTA_AGENT_RERANK=1`, but the validated gate does not use it.
Agent interface	MCP `experience-memory`	`experience_status` and `recall_experience`; the `recall-context` skill uses it as its primary path.
Test automation	`evaluate_context_retrieval.py` and `rag_regression_gate.py`	The `penta-agent-rag-gate.timer` is enabled weekly; the gate records history in `memory/retrieval-metrics.jsonl`.

I run this on a local Arch Linux/KDE workstation. Ollama and Qdrant are queried over loopback; the timers are systemd --user timers. That detail is not cosmetic: if I isolate the canonical fallback or the gate environment is missing, retrieval changes materially. That is why the gate service explicitly sets PENTA_AGENT_EMBED_BACKEND=ollama, PENTA_AGENT_OLLAMA_MODEL=bge-m3, and PENTA_AGENT_CONTEXT_SEM_THRESHOLD=0.44.

The embedding model I actually used

BGE-M3, in its original implementation, supports dense, sparse, and multivector representations, works with more than one hundred languages, and accepts long sequences.⁵ But those model capabilities do not prove that all of them are exposed in my stack.

I use bge-m3:latest, served by Ollama through /api/embed.⁶ In practice I use only the dense representation returned by Ollama: 1024-dimensional vectors in the local installation. The sparse branch of the system does not come from BGE-M3; it comes from BM25 with FastEmbed and Qdrant.⁷⁸ Pooling, tokenization, and normalization are encapsulated in the Ollama runtime, not in custom repo code.

I also did not chunk the whole workspace indiscriminately. The context ingestion works with selected documents: sanitized Markdown handoffs and compact events. When importing handoffs, the extractor takes sections such as goal/context, decision, and outcome; compacts them; preserves source_document, source_hash, source_type, handoff_id, workspace_entry, repo_scope, branch, and date; and limits text to short fields. I do not dump full conversations or raw private files into the index.

A question set that makes the system uncomfortable

I evaluated with a local golden set of 40 questions: 32 positives and 8 negatives. Positive cases point to expected documents through suffixes relative to the workspace; the evaluator does not open or emit the source content. Difficulty labels are not mutually exclusive: there are 10 exact-keyword cases, 9 paraphrase cases, 7 cross-language cases, 3 colloquial cases, and 4 multi-document cases. Negatives include cooking, sports, finance, science, and unrelated technology queries.

I annotated expected answers manually against selected handoffs and relative paths. That makes the set useful for development and regression, not as an independent benchmark. If I use the same file to calibrate thresholds and then celebrate the result, I cannot treat it as independent evidence.

Results: what happened in the validated run

The traceable run was:

env PENTA_AGENT_EMBED_BACKEND=ollama \
    PENTA_AGENT_OLLAMA_MODEL=bge-m3 \
    PENTA_AGENT_CONTEXT_SEM_THRESHOLD=0.44 \
    /opt/entornos/mamba312/bin/python scripts/evaluate_context_retrieval.py --strict

I ran it in strict mode, and it exited with code 1 because there was one partial case. The gate itself passed because it evaluates aggregate thresholds: minimum recall 0.95, minimum MRR 0.85, minimum precision 0.40, and perfect negative abstention.

Table 3 - Validated local result

Configuration	Recall@5	MRR	Precision@5	Negative rejection	Latency
`bge-m3` + dense Qdrant + lexical JSONL + sparse BM25	0.9896	0.9479	0.4448	8/8	p50 401 ms; max 4,250 ms

My cautious reading is:

The active retrieval setup finds almost all annotated evidence in this small, curated corpus.
The negative cases are the strongest result: all eight were rejected.
Precision@5 is low by design: I prefer bringing extra context over missing the expected document.
The remaining error is multi-document: catastro_multi_sii recovered part of the expected evidence, not all of it.
The metric does not prove that the final answer is faithful; it only proves that the retriever brought or rejected candidates.

I also found a practical signal: when I isolate the canonical fallback without Qdrant, aggregate recall drops to 0.8177. That is not the result of the chosen stack; it is the comparison I needed to understand how much semantic retrieval contributes and why the evaluation configuration must be explicit.

Fusion and reranking

I do not compare raw scores from different models as if they lived on the same scale. First I gather candidates from dense Qdrant, lexical JSONL, and sparse BM25. Then I compute a hybrid score with admission thresholds. After that I deduplicate by lifecycle: if an outcome and a pending handoff share the same handoff_id, the completed result wins.

A regression gate

I can run the evaluation by hand, and I also installed it as a weekly user timer: penta-agent-rag-gate.timer, with OnCalendar=weekly, Persistent=true, and a randomized delay of up to 30 minutes. The service runs scripts/rag_regression_gate.py with Ollama, bge-m3, and semantic threshold 0.44. It records aggregate metrics in memory/retrieval-metrics.jsonl and fails if they fall below the configured thresholds.

I call it a regression gate because it checks known cases. Detecting real drift requires observing changes in queries, documents, versions, or score distributions.

Spoonful 3: what this memory still does not solve

The memory now retrieves better, but it still has clear limits: it does not handle document validity over time very well, it does not detect contradictions in a general way, it does not turn full sessions into permanent memory, and it still fails on some answers that require combining several sources.

I also do not yet evaluate the faithfulness of the final answer. Recall, MRR, and precision indicate whether the right evidence appeared, not whether Claude or Codex interpreted it correctly, respected its validity, or knew when to abstain. Benchmarks such as BEIR also show that no retriever dominates uniformly across all domains.⁹

Next, I want to compare each layer of the system reproducibly: dense search, lexical JSONL, BM25, hybrid retrieval, RRF, and opt-in reranking. After that I want to add document-validity handling and answer evaluation with citations, so I can measure not only whether I retrieve evidence, but whether the answer uses it faithfully.

If you are building something similar - a multi-agent setup, a local RAG, a second brain, or working memory to avoid repeating context - I would like to read what worked for you, where it failed, and how you decided when to abstain. That comparison between honest logs is worth more than a perfect architecture.

References

Vannevar Bush, "As We May Think", The Atlantic, July 1945. https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/ ↩
Andy Clark and David Chalmers, "The Extended Mind", Analysis 58, no. 1 (1998): 7-19. https://doi.org/10.1111/1467-8284.00096 ↩
Patrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", Advances in Neural Information Processing Systems 33 (2020). https://arxiv.org/abs/2005.11401 ↩
Stephen Robertson and Hugo Zaragoza, "The Probabilistic Relevance Framework: BM25 and Beyond", Foundations and Trends in Information Retrieval 3, no. 4 (2009): 333-389. https://doi.org/10.1561/1500000019 ↩
Jianlv Chen et al., "BGE M3-Embedding: Multi-Lingual, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation", 2024. https://arxiv.org/abs/2402.03216 ↩
Ollama, "Generate embeddings", /api/embed documentation, accessed July 23, 2026. https://docs.ollama.com/api/embed ↩
Qdrant, "Vectors", documentation on named vectors and sparse vectors, accessed July 23, 2026. https://qdrant.tech/documentation/manage-data/vectors/ ↩
Qdrant, "Full-Text Search: BM25", documentation on BM25 and sparse vectors, accessed July 23, 2026. https://qdrant.tech/documentation/search/text-search/full-text-search/ ↩
Nandan Thakur et al., "BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models", 2021. https://arxiv.org/abs/2104.08663 ↩

CASEN 2024 in 3 spoonfuls: without a fine-grained territorial reading, social policy moves blind

Cristián Labra — Sun, 06 Sep 2026 14:05:49 +0000

In Chile, La Araucanía records 13.0% extreme poverty; Magallanes, 4.2%. That is 8.8 percentage points of difference — and if a public agency at the central or local level (regional governments / municipalities) designs its intervention using only the national average (6.9%), or disregarding regional differences, it could get the allocation of resources or the distribution of its components wrong.

This post documents a reproducible analysis of CASEN 2024 in Julia, with cross-validation of official public figures against BIDAT and good traceability of the flow in the repo.

Three findings to start with — statistically robust:

Extreme poverty: La Araucanía 13.0% 95% CI [11.8%, 14.1%] versus Magallanes 4.2% [3.1%, 5.2%] — a gap of 8.8 pp with non-overlapping CIs.
FONASA coverage: La Araucanía 91.1% [90.2%, 92.0%] versus Metropolitana 75.9% [75.0%, 76.7%] — a gap of 15.2 pp with non-overlapping CIs.
Completed higher education: Metropolitana 34.9% [34.0%, 35.7%] versus Maule 20.4% [19.2%, 21.6%] — a gap of 14.5 pp with non-overlapping CIs.

The CIs are 95% and were computed by Taylor linearization (wiki) for CASEN's complex sampling design (stratified two-stage, expr weights). That the CIs do not overlap implies these regional differences are statistically significant at the conventional level.

Tolerance to contrast, or checking against official data

All results were checked against the official tables available in BIDAT.

Table 1 — Official validation results (BIDAT, CASEN 2024)

Parameter	Value
Validation status (national + regional, % + expanded)	PASS
Maximum tolerance in percentage points	1×10⁻⁵ pp
Maximum tolerance in expanded values	1×10⁻⁶
Observed difference (pp)	2.98×10⁻⁶ pp
Observed difference (expanded)	0.0
National rows compared	16
Regional rows compared	256

The maximum observed difference is below 3 millionths of a percentage point and within the preset tolerance. The results match the official tables within the predefined tolerances.

Spoonful 1: sampling design and expansion without shortcuts

CASEN 2024 has a probabilistic stratified two-stage design (BIDAT methodological note). The expr factor applies to national and regional estimates. The complementary expc factor supports descriptive commune calculations, but does not make estimates representative of each commune, according to the official CASEN 2024 data-use note. This analysis uses expr and reports estimates by region with 95% CIs computed by Taylor linearization over the complex design (strata, PSU/UPM and weights/factors).

Population represented in this run (sum of expr): 20.13 million people (a pending task is to assess the impact of the new 2024 Census instead of projections over the 2017 Census).

# CASEN 2024 sampling design specification
design = (
    weight = :expr,     # regional expansion factor
    strata = :estrato,  # sampling stratum
    psu    = :cod_upm,  # primary sampling unit (PSU)
    domain = :region,   # estimation domain
)

Coverage by analyzed dimension:

Table 2 — CASEN 2024 variables used and target population

Dimension	CASEN variable	Target population
Education	`educc`	People ≥ 18 years
Health	`s13`	Total population
Poverty	`pobreza`	Total population

Weighted national results

The following percentages correspond to proportions weighted with expr, validated against official data in BIDAT. The difference from the official values is < 3×10⁻⁶ pp.

Table 3 — Weighted national distribution (CASEN 2024, main categories)

Dimension	Category	% national
Education	Complete secondary	30.9%
Education	Complete higher education	29.1%
Education	Incomplete higher education	12.5%
Education	Incomplete secondary	9.9%
Education	Incomplete primary	8.4%
Education	Other	7.7%
Education	No formal education	1.5%
Health	Public system FONASA	82.6%
Health	Isapre	13.2%
Health	None (private out-of-pocket)	2.0%
Health	Armed forces and police	1.8%
Health	Does not know	0.3%
Health	Other system	0.2%
Poverty	Non-poverty	82.7%
Poverty	Non-extreme poverty	10.4%
Poverty	Extreme poverty	6.9%

Spoonful 2: the technical flow in Julia

The pipeline runs end to end with julia --project=. scripts/run_all.jl (the orchestrator). The two most relevant pieces of code to reproduce and "audit" these results are the cell-allocation algorithm and the sampling-design specification, available in the public repository.

Taylor linearization: SE and CI of the complex design

A Taylor estimator was implemented for proportions in domains (regions). The linearized variable for the proportion $\hat{p}_d$ in domain $d$ is:

z_{j} = \frac{1 ( j \in d ) ( 1 ( cat _{j} = C ) - p ^ _{d} )}{N ^ _{d}}

The variance is estimated with the stratified cluster-design formula:

# Taylor linearization variance (stratified, PSU)
# e_{hi} = sum of w_j * z_j over PSU i in stratum h
var_total = sum over strata h:
    (n_h / (n_h - 1)) * sum_i (e_{hi} - mean(e_h))^2

se    = sqrt(var_total)
ci_lo = clamp(p̂ - 1.96 * se, 0.0, 1.0)
ci_hi = clamp(p̂ + 1.96 * se, 0.0, 1.0)

All PSUs of the design are used (including those outside the domain, with $z_j = 0$), which is correct for random-domain estimation. The median regional 95% CI width is 1.66 pp; the maximum is 5.76 pp (small regions with low-prevalence categories).

Next entry, at some point 👀 — Jackknife and Bootstrap for CASEN as a contrast: TSL is an optimal first-order approximation for means and proportions, but for non-linear statistics (Gini, medians, quantile ratios) it can under-estimate the variance. The code repository includes the theory and the in-progress Julia code to contrast TSL with Jackknife (delete-1) and Bootstrap — a future entry in this series, which I have not reviewed in depth.

Largest remainder: why it matters in a waffle chart

A 100-cell waffle chart requires the proportions to add up to exactly 100 whole cells. Direct rounding introduces accumulated errors that make the sum 99 or 101. This flow uses the largest remainder algorithm, which guarantees the exact sum by introducing a slight imprecision for the sake of the visualization (take it as a purely visual nicety):

"""
Allocate `n_cells` whole cells to proportions `p` using largest-remainder.
Guarantees that sum(cells) == n_cells exactly.
"""
function allocate_cells(p::AbstractVector{<:Real}, n_cells::Int = 100)
    raw    = p .* n_cells
    floors = floor.(Int, raw)
    remain = raw .- floors
    deficit = n_cells - sum(floors)
    # Assign remaining cells to the proportions with the largest remainder
    idx = sortperm(remain, rev=true)[1:deficit]
    floors[idx] .+= 1
    return floors
end

Validated with unit tests: allocate_cells([0.5, 0.3, 0.2], 100) == [50, 30, 20].

Reproducibility

# Requirements: Julia 1.10+
git clone <repo>
cd casen2024/julia_viz
julia --project=. -e "using Pkg; Pkg.instantiate()"
julia --project=. scripts/run_all.jl

The flow generates plenty of artifacts (CSV tables, PNG charts, audit logs for each input). The Manifest.toml file pins the exact versions of all dependencies (I used Julia 1.10).

Spoonful 3: visual evidence

National composition (Charts 1–3)

Each waffle represents 100 cells allocated by largest remainder over the weighted proportions.

Chart 1 — Education: highest educational level attained (population ≥18 years, CASEN 2024)

Chart 2 — Health: health insurance system (total population, CASEN 2024)

Chart 3 — Income poverty: extreme, non-extreme and non-poverty (total population, CASEN 2024)

Charts 1–3 — National composition: education (population ≥18 years), health and poverty (total population). Source: CASEN 2024, own elaboration in Julia. Values are validated against BIDAT. Click to enlarge.

Regional gaps (Charts 4–6)

Each panel uses an axis fitted to the range of its own category (not a shared global scale), which makes it possible to visualize differences that flatten out if all categories share the same axis. The horizontal bars are 95% CIs computed by Taylor linearization; the dashed vertical line marks the national estimate and the pale grey band its 95% CI.

Chart 4 — Regional gaps in education: dot plot by category (axis fitted per panel, dashed line = national, band = 95% CI)

Chart 5 — Regional gaps in health: dot plot by category (axis fitted per panel, dashed line = national, band = 95% CI)

Chart 6 — Regional gaps in poverty: dot plot (axis fitted per panel, dashed line = national, band = 95% CI)

Charts 4–6 — Regional gaps with 95% CIs (Taylor linearization, complex design): education, health and poverty. Bars = regional 95% CI; dashed line = national estimate; grey band = national 95% CI. Axis fitted per category. Click to enlarge.

Gaps with 95% CIs — all statistically robust

Table 4 — Regional gaps with 95% CIs by Taylor linearization (CASEN 2024)

Dimension	Category	Gap (pp)	Maximum	95% CI	Minimum	95% CI
Poverty	Non-poverty	18.6 pp	Magallanes 90.0%	[88.5%, 91.5%]	La Araucanía 71.4%	[69.8%, 73.0%]
Health	Isapre	16.3 pp	Metropolitana 20.6%	[19.8%, 21.5%]	Maule 4.3%	[3.7%, 5.0%]
Health	FONASA	15.2 pp	La Araucanía 91.1%	[90.2%, 92.0%]	Metropolitana 75.9%	[75.0%, 76.7%]
Education	Complete higher education	14.5 pp	Metropolitana 34.9%	[34.0%, 35.7%]	Maule 20.4%	[19.2%, 21.6%]
Poverty	Extreme poverty	8.8 pp	La Araucanía 13.0%	[11.8%, 14.1%]	Magallanes 4.2%	[3.1%, 5.2%]

In every case the CIs do not overlap: the gaps are statistically significant at 5%. CIs computed by Taylor linearization over the complex design (strata, PSU/UPM, expr).

Closing: three questions for those who use the survey

If you use CASEN 2024 for territorial characterization or other uses where regional-level variables matter, think twice before using a point estimate (without its confidence interval):

Are your results validated against BIDAT and do they carry design-based CIs? A difference greater than 1×10⁻⁵ pp from the official tables is not technical: it is a process issue. And without complex-design CIs, an 8 pp gap can look like evidence when it is noise in small regions.
Are you using the correct expansion factor? expr applies to national and regional domains; having expc does not guarantee commune representativeness. The factors are not interchangeable, and the domain and scope of inference must be stated.
Is your analysis reproducible? A flow that cannot be audited cannot be defended before a technical counterpart, nor updated when CASEN 2026 is released.

The CIs incorporated here are complex-design (Taylor linearization), not simple asymptotic ones. They cover sampling variance but not non-response error or undercoverage. Causal inference between subpopulations requires additional design.

Multi-agent work in three spoonfuls: what worked for me and what did not

Cristián Labra — Sat, 05 Sep 2026 22:18:38 +0000

This started as a practical annoyance: long tasks interrupted by quota limits, conversations that became too heavy, and reviews that required copying context across windows in clumsy and inefficient ways. To deal with that, I built a multi-agent workflow in VS Code, on Arch Linux. I first called it tri-agent; after a couple of months it became penta-agent, a still imperfect way of coordinating agents, roles, permissions, and traces in my own workflow.

It is not a new idea, and it is not a promise of full autonomy. In fact, maintaining it takes work. But it is a local work contract that orders who executes, who reviews, when MCP is used, when Gemini/Antigravity enters, when Copilot remains only support, which skills are loaded, and what evidence or artifact should exist at the end.

I am writing from my own cases: memos, regulatory review, spreadsheets, statistical models, scripts for a home server, system timers, self-hosted cloud, router security, backups, this blog, and everyday maintenance. In those cases, having some agentic governance has helped me. Maybe it is also a false sense of digital sovereignty. I am not immune to that.

The thesis is simple: a multi-agent system without roles, permissions, and traces may look sophisticated, but in practice it can feel too much like a meeting without minutes.

Three ideas to start with:

Codex has worked for me as the main executor: it reads files, applies patches, runs validations, and can close diffs with evidence. It is not infallible, so it should not be the only validator on critical changes.
Claude has worked for me as a strong reviewer, especially with Opus: architecture, regulation, statistical assumptions, and argumentative risks. I use it as a brake and as support for the main executor.
Gemini/Antigravity, Copilot, and LiteLLM with DeepSeek and Z.ai work better when bounded: exploration, validation, canary work, or small tasks. When they start deciding with too little context, the workflow gets worse.

Spoonful 1: the problem was not using agents, it was losing continuity

In a long task, the cost of a pause is not only the time without an answer. The expensive part is losing continuity: what was being tested, what file changed, which hypothesis failed, which validation remained pending, and which context should no longer be dragged along.

My first mistake was treating each model or agent as a symmetric second opinion. That does not scale. In a memo or a regulatory review, I ended up with useful comments that were hard to reconcile.

The fix was more boring and more useful: separate roles. Not because it is the right way for everyone, but because in my workflow it lowers the cost of returning to a task without having to recap everything from scratch.

I read provider convergence from there. Codex documents configuration, sandboxing, permissions, MCP, AGENTS.md, skills, and subagents; GitHub Copilot supports repository instructions; Gemini Code Assist describes an agent mode with tools, MCP, and approval of changes; and Claude Code exposes hooks such as PreToolUse, PostToolUse, and SessionStart.¹²³⁴

Table 2 — Current roles in penta-agent

Component	Actual role	Limit I impose
ChatGPT/Codex	Local technical orchestrator, planner, and executor	It should not self-validate as the only source of truth on critical changes
Claude	Reviewer, auditor, and co-planner	It should not take operational control by default
Gemini/Antigravity	Explorer, validator, and fallback	It should not enter the critical path unless explicitly promoted
Copilot	Canary and IDE/GitHub-native support	It should not be treated as an independent architectural arbiter
LiteLLM sidecar	Cheap, narrow delegation	I do not use it for architecture, security, or final decisions; today I use it in bounded ways with DeepSeek and Z.ai
Human	Closure, privacy, and acceptance	Final judgment is not delegated when risk is involved

The local architecture makes that explicit. In routing.yaml, the penta_agent_ops rule keeps Codex as primary, Claude as reviewer, Gemini as validator/fallback, and the human as checkpoint:

id: penta_agent_ops
planner: codex
primary: codex
reviewer: claude
escalate_to: human
validator_chain: [gemini]
fallback_chain: [gemini]
planning:
  proactive_skills: [handoff-protocol, recall-context]
  mcp_policy:
    mode: conditional
    allowed_paths: [claude_to_codex_mcp, gemini_to_codex_mcp]
  provider_roles:
    planning_sidecars:
      canary: copilot

The key detail is mcp_policy.mode: conditional. Not everything goes through MCP. Not everything deserves a handoff. Not everything deserves a second provider. After some iterations, I made evaluation proactive, as with skills, but invocation still needs a signal. Early on, skills were not activated when I wanted them to be, and handoffs were scarce.

Spoonful 2: the repository as a work contract

The piece that helped me most was not a model. It was a startup rule: if a task touches multi-agent work, MCP, Claude, Gemini, Copilot, routing, handoffs, or penta-agent, first read the local canon.

In my case, that canon lives in files such as:

router/routing.yaml
shared-references/arquitectura-multiagente.md
playbooks/puente-mcp-codex.md
.mcp.json

This prevents a common vice: generic probing of CLIs, models, and commands before understanding the project's contract. For small things, it may not matter. For a regulatory review, a statistical run, or a local security change, it does. Drift burns tokens and sometimes leaves the task stranded in the wrong place.

A useful AGENTS.md does not need to be a novel. Long instructions consume context. I think it should mostly prevent bad practices:

# Workspace multi-agent rules

If the user mentions multi-agent work, MCP, Claude, Gemini,
Copilot, routing, handoff, or penta-agent:

1. Use `penta-agent/` as the source of truth.
2. Read routing, architecture, MCP bridge, and MCP config first.
3. Do not probe generic CLIs before reading the canon.
4. Delegate to Antigravity only through `scripts/agent/agy-bridge`.
5. Do not send secrets, `.env`, keys, or credentials to external providers.

Recent literature seems to move in a similar direction, with a healthy warning. Galster et al. describe these artifacts as versionable mechanisms for configuring agentic tools and observe that AGENTS.md is emerging as an interoperable standard.⁵ Arabat and Sayagh propose treating them as instructions-as-code, not as side notes.⁶ On the other hand, Gloaguen et al. warn that context files can reduce success and increase cost when they add unnecessary requirements.⁷ My experience is that the balance must be tuned constantly.

Skills: procedures, not endless prompts

Skills have helped me when they act as reusable procedures with clear activation rules, limits, and references. A publishing skill, for example, should not say "write nicely." It should say verifiable things:

name: jekyll-post
description: Jekyll posts with front matter, drafts/posts workflow, build checks, and reproducible publication.

- Prepare correct front matter and validate the build.
- Keep claims dated and traceable.
- Review front matter and the editorial guide.

The minimum question for a skill is: when does it activate, what must it not do, which files must it read, and what output makes it possible to verify that it did the job well. That fits Anthropic's progressive-loading model: metadata first, instructions when the skill activates, and resources or scripts only if needed.⁸ It also fits SkillJuror, which shows that skill organization changes how agents search for and apply knowledge, although the benefit depends on whether resources are actionable.⁹

The security warning matters too: SKILL.md is not passive documentation.¹⁰ If a skill brings scripts, ambiguous instructions, or manipulable metadata, it is closer to installing software than to pasting an innocent prompt.

MCP: a bridge, but I still do not squeeze it fully

The real MCP surface in penta-agent is deliberately small:

{
  "mcpServers": {
    "codex": {
      "type": "stdio",
      "command": "scripts/codex_mcp.sh",
      "args": ["mcp-server"],
      "env": {}
    }
  }
}

The idea is not that every agent connects to every other agent. The preferred path is Claude/Gemini to Codex when they need filesystem access, commands, tests, or local edits. Codex to Claude or Antigravity uses controlled CLI/file handoffs. I do not assume a bidirectional bridge or a universal filesystem MCP baseline.

That is also a security decision. MCP's official security guidance lists risks such as confused deputy, token passthrough, SSRF, session hijacking, and local server compromise.¹¹ Recent work on tool poisoning in MCP argues that the critical problem is often on the client side: malicious metadata, low parameter visibility, and implicit trust.¹² I still do not get all the value from MCP, but I prefer it narrow.

Handoffs: the antidote to "I told them"

A handoff is not saying "let Claude review it." A useful handoff leaves a minimal trace:

HANDOFF-TRACE: codex asks claude for support (model: sonnet) via CLI
MODEL-REPORT: {"agent":"codex","provider":"openai","model":"__default__","source":"self_report"}
MODEL-REPORT: {"agent":"claude","provider":"anthropic","model":"sonnet","source":"self_report"}

And it separates the basics:

metadata:
  from: codex
  to: claude
  via: CLI
  skill: handoff-protocol

essential_context:
  - what was done
  - what was rejected
  - what remains to validate

task_for_receiver:
  - review claims
  - detect risks
  - do not modify files

verification:
  - tests run
  - sources checked
  - final decision

This feels bureaucratic until something fails. When it fails, the trace helps answer whether the problem was insufficient context, wrong model, bad route, ambiguous output, quota, permissions, sandboxing, or a poorly written instruction. OpenAI proposes a similar logic in its agent improvement loop: use traces, feedback, and evals to modify the harness, not only to ask the model to "do better."¹³ This has also helped me use recall-context: with a good trace, previous work is much easier to recover across agents.

Spoonful 3: what I learned by making it fail

My own error list is more useful than a list of tools. I hope this post reads more like a logbook than a showcase. It will probably age quickly, but perhaps it will be useful to someone else.

Table 3 — My mistakes and current controls

Mistake	What it looked like	Current control
Treating models as equivalent	Any provider could comment on anything	Explicit roles: primary, reviewer, explorer, validator, canary
Automatic fan-out	I asked for second opinions out of habit	Always evaluate, invoke only with enough signal
Fragile model IDs	A rename broke scripts or examples	Use `__default__`, aliases, and discovery
Declaring a sidecar ready too early	The proxy started, but the provider failed by quota or balance	Separate "proxy is alive" from "provider is usable"
Overlong context files	The agent followed irrelevant rules and explored too much	Minimal, actionable, dated instructions
MCP as a universal solution	More servers, more implicit trust	Conditional MCP, consent, sandboxing, and minimal permissions
Vector memory as source of truth	Drift risk from dimensions or derived indexes	JSONL as source; Qdrant/FastEmbed as rebuildable indexes
Copilot as a strong second provider	It did not always add independent judgment	Use it as canary/support, not as arbiter

Memory deserves a paragraph. In penta-agent, operational memory lives in append-only files such as experience-events.jsonl, experience-lessons.yaml, and interaction-metrics.jsonl. Qdrant and FastEmbed help retrieve experiences, but they are derivatives. If embeddings change or a dimension mismatch appears, the index is rebuilt from JSONL. After fighting that kind of drift, I do not want the source of truth to be fragile.

The LiteLLM sidecar follows the same philosophy. It is useful for cheap, narrow delegation to aliases such as cheap, cheap-code, or cheap-reasoner, but not for architecture, security, or final decisions. The real provider smoke test matters more than a healthy container. If DeepSeek returns Insufficient Balance, the system is not ready; we have only learned that Docker can turn on a light.

Closing: an optimization loop

My stack should not be read as a universal template. It is not one. What may be useful is the logic behind it: small contracts so the work does not depend on human memory or on the enthusiasm of the moment. I published a sanitized public version of the stack at tatanlabra/penta-agent. It is not a dump of my local environment: I removed runtime memory, private paths, logs, .env files, credentials, internal IPs, and anything that could reveal personal configuration. Anyone cloning it should treat it as a template and review the placeholders in AGENTS.md, .mcp.json, router/routing.yaml, scripts/agent/agy-bridge, and skills/ before using it.

penta-agent has helped me not because it has many agents, but because it has brakes: roles, routes, skills, permissions, handoffs, rebuildable memory, and validation. That does not make it universal or superior. It makes it auditable for my problems. Vibe coding names the first feeling of flow well: ask, watch code appear, correct, continue. But when the workflow matures, the question changes: how efficient, elegant, and verifiable is the solution you get?

Update · July 2026

I updated the public repo to a v3.1 profile. None of it came from a redesign: it all came from broken things that kept running.

The main one, a silent fallback is the actual failure. Degrading is fine; degrading quietly leaves the system "running" on stale inputs. My board detected exactly that, and nobody found out, because looking at it required suspecting it first. It now notifies only on transitions, every check says how long it has been red, and it separates a broken probe from a downed provider: identical on screen, opposite fixes.

The executor also stopped being at the top. And the cheap models I praise here as a sidecar turned out to be untraced delegations against models I had never verified; they now hold the same evidence contract as everything else. Less impressive than adding another agent, considerably more useful.

Technical References

OpenAI Developers, "Configuration Reference -- Codex," accessed June 21, 2026. It documents configuration, permissions, sandboxing, MCP, AGENTS.md, skills, and subagents in Codex. https://developers.openai.com/codex/config-reference ↩
GitHub Docs, "Adding repository custom instructions for GitHub Copilot," accessed June 21, 2026. It documents repository instructions and formats associated with Copilot. https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions ↩
Google Developers, "Use the Gemini Code Assist agent mode," accessed June 21, 2026. It describes agent mode in the IDE, tool use, MCP, and action approval. https://developers.google.com/gemini-code-assist/docs/use-agentic-chat-pair-programmer ↩
Anthropic, "Hooks reference -- Claude Code Docs," accessed June 21, 2026. It describes hooks as lifecycle control points, including PreToolUse, PostToolUse, and SessionStart. https://code.claude.com/docs/en/hooks ↩
Matthias Galster et al., "Configuring Agentic AI Coding Tools: An Exploratory Study," arXiv:2602.14690, 2026. It analyzes mechanisms such as context files, skills, subagents, hooks, settings, and MCP. https://arxiv.org/abs/2602.14690 ↩
Ali Arabat and Mohammed Sayagh, "Toward Instructions-as-Code: Understanding the Impact of Instruction Files on Agentic Pull Requests," arXiv:2606.13449, 2026. It analyzes agentic pull requests and concludes that instructions do not automatically improve performance. https://arxiv.org/abs/2606.13449 ↩
Thibaud Gloaguen et al., "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?," arXiv:2602.11988, 2026. It reports that context files can reduce success and increase cost when they add unnecessary requirements. https://arxiv.org/abs/2602.11988 ↩
Anthropic, "Agent Skills -- Claude API Docs," accessed June 21, 2026. It describes skills as modular capabilities with instructions, metadata, scripts, and references loaded in stages. https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview ↩
Zhiyu Chen et al., "SkillJuror: Measuring How Agent Skill Organization Changes Runtime Behavior," arXiv:2606.11543, 2026. It evaluates skill organization and progressive loading. https://arxiv.org/abs/2606.11543 ↩
Shoumik Saha, Kazem Faghih, and Soheil Feizi, "Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry," arXiv:2605.11418, 2026. It warns that SKILL.md metadata and instructions can manipulate skill discovery, selection, and governance. https://arxiv.org/abs/2605.11418 ↩
Model Context Protocol, "Security Best Practices," accessed June 21, 2026. It lists risks and mitigations for MCP implementations. https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices ↩
Charoes Huang, Xin Huang, Ngoc Phu Tran, and Amin Milani Fard, "Model Context Protocol Threat Modeling and Analyzing Vulnerabilities to Prompt Injection with Tool Poisoning," arXiv:2603.22489, 2026. It applies STRIDE/DREAD to MCP and highlights tool poisoning as a critical client-side vulnerability. https://arxiv.org/abs/2603.22489 ↩
OpenAI Cookbook, "Build an Agent Improvement Loop with Traces, Evals, and Codex," accessed June 21, 2026. It uses traces, feedback, evals, and harness configuration to improve agents. https://developers.openai.com/cookbook/examples/agents_sdk/agent_improvement_loop ↩

AI quotas in three spoonfuls: a HUD for the KDE panel

Cristián Labra — Sun, 26 Jul 2026 15:38:43 +0000

I currently use Claude Code, Codex, Gemini (through agy on the command line), and DeepSeek on Arch Linux with KDE Plasma 6. For me, as for many others, the problem has become knowing which one still has quota—especially when a task already carries a lot of context, reviewed files, and an hour of iteration.

That is how I ended up building a viewer, or HUD, for the KDE panel: five indicators showing how much room each agent has left and when its quota should reset. No extra tab, no separate dashboard, and—most importantly—no surprise when the quota runs out while I am wrapping up a task or a git rebase 😱.

First spoonful: the token-week

Each provider invented its own way of measuring how much we can use it.

Claude speaks in windows of hours and days. Codex reports the windows available for the plan. Gemini requires a local estimate of requests. Copilot counts premium requests against a calendar cutoff. DeepSeek, by contrast, speaks in monetary balance.

Five agents, five clocks, and no shared unit.

The industry has achieved something rather peculiar: turning token-hours and token-weeks into real planning units. It is no longer enough to ask how long a task will take. I also have to calculate whether the agent can finish it before leaving me to do things the old-fashioned way :).

On the panel I reduced it to five rings, or donuts. A nearly full one means the agent still has room. A nearly empty one means it is probably time to thank it for its service and try the next one.

Figure 1 — Compact AI Quota HUD view on the KDE Plasma panel. The five rings summarize the available margin by agent. The coloured arc is what remains free, and the outer white marks count the days until reset. Source: own screenshot with synthetic data.

Hovering over one donut shows that agent in detail: its windows and their reset times.

Figure 2 — The hover panel shows the windows of the agent under the cursor without leaving the active task. Antigravity carries two independent weekly quotas on separate clocks: one for Google models and one for third-party ones. The badge says where each figure comes from: OFFICIAL if the provider reports it, LOCAL if it is a local count. Source: own screenshot with synthetic data.

Clicking opens the detailed view, with the five agents on top and the windows of whichever one is selected below.

Figure 3 — The detailed view. On top, the five agents with their tightest margin; below, the windows of whichever one is selected. Each line says how much is left, when it renews, and where the figure comes from. Source: own screenshot with synthetic data.

Watch the full video demo on 3cucharadas.cl.

Figure 4 — The walkthrough from the panel bar to the detailed view, with the selector row moving through Codex, Antigravity and DeepSeek. The values are synthetic and do not represent personal quotas. Source: a sequence rendered with the same probe the tests use, frame by frame and with the clock pinned, so it can be regenerated identically.

Second spoonful: the data decides, not the order

The first version worked well for weeks. Codex returned two windows: a short five-hour one and a weekly one.

My code interpreted them by position:

The first window, or outer ring, was the five-hour one.
The second was the weekly one.

It was simple—until Codex changed the schema.

One day the widget showed 5% available in the supposed “5h” window, but with a reset scheduled six days later. Even for a technology company, five hours lasting almost a week seemed like too much innovation.

The raw response contained a single window:

604800 seconds

That is seven days.

Codex had stopped reporting the short window, but my code still called whatever appeared first “5h.” At the same time, the old weekly window remained frozen in the cache because the “keep the last good value” logic could not distinguish between a failed query and a window that had ceased to exist. 👻

The correction had two parts.

First, each window stopped being identified by its position and began to be identified by its actual duration. A short duration is a session; an extended duration is a weekly window or equivalent.

Second, the monitor now distinguishes between:

a query that failed, in which case it temporarily preserves the previous value and marks it as cached;
a valid query that no longer contains a window, in which case it removes that window from the current state.

The interface also stopped assuming that every agent has the same structure. If two windows arrive, it draws a double donut. If one arrives, it draws a single ring. The data defines the interface, not the other way around.

The lesson is small but fairly general: if the provider supplies the duration, that is the identity of the data; its position in an array is only a temporary coincidence.

Third spoonful: local, useful, and not very universal

This project is not meant to be a cross-platform application.

I built it for an environment very much like mine:

Arch Linux;
KDE Plasma 6;
systemd --user;
Python;
Bash;
QML;
the local sessions and credentials of the tools I already use.

It can probably be adapted to other distributions running Plasma 6. I do not promise that it will work unchanged on GNOME, Plasma 5, Windows, or macOS. Nor did I abstract every possible authentication method. It is a tool for my own desktop that I decided to organize and publish, not an attempt to solve every possible combination of operating systems, providers, and plans.

Inside, the path is short:

                 systemd --user timer
                          │
                     every five minutes
                          ▼
 helpers/*.sh ──► Python monitor ──► status.json
                                           │
                            ┌──────────────┴──────────────┐
                            ▼                             ▼
                    QML widget                      MCP server
              panel · tooltip · popup       checks before delegation

The helpers are the only component that touches credentials. They return sanitized JSON, without authentication tokens or conversation content.

The Python monitor queries, validates, and merges the information. If it encounters a timeout, an expired credential, or a 429 error, it preserves the last known value and marks it as cached.

The systemd timer runs the update every five minutes. The widget does not query providers directly; it only reads a local file with 0600 permissions. That way I avoid triggering a rate limit by checking the rate limit too often, which would be an especially elegant way of closing the loop. 🫠

The same status.json can be read by an MCP server. This lets an agent ask which provider still has quota before delegating a task. The desktop bar and the orchestrator receive exactly the same state.

Closing

The repository is published under the MIT license. It is designed for KDE Plasma 6, does not require sudo, and installs into the user's local paths:

git clone https://github.com/tatanlabra/ai-quota-kde.git
cd ai-quota-kde
scripts/install-user.sh
ai-quota-monitor doctor

View the repository on GitHub

It does not create more quota, negotiate better plans, or eliminate the token-week. It only prevents me from discovering halfway through a task that the chosen agent has gone off in search of additional quota 🤑.

It is a small spoonful of sovereignty over my own workflow: knowing how much remains, when it resets, and who should get the next handoff.

Update, 8 September 2026

The HUD changed enough that the July screenshots no longer represented it.
Figures 1 to 3 above show the current state; the recording in figure 4 is still
from July and is kept because the walkthrough —panel, hover panel, detailed
view— has not changed, even though the design has.

What is different:

Five agents instead of four. Copilot was added; it counts premium requests against a calendar cutoff. The post said "four" in seven places and has been corrected.
A different hover panel. It used to squeeze all five agents into one cramped list. It now shows the detail of the agent under the cursor, with a badge per line saying whether the figure is reported by the provider (OFFICIAL) or counted locally (LOCAL).
A different click view. The five agents moved into a row of selectors showing their tightest margin, with the windows of the selected one below. Previously it was five simultaneous columns that did not fit.
Slightly thicker strokes and larger logos. The quota arc went from 0.055 to 0.060 of the diameter and the logos grew by 3 %, measured at runtime. The central aperture was recovered by tightening the gap between rings, because widening the stroke was shrinking it.
The interface is translated. Source strings moved to English and Spanish lives in a gettext catalogue, so the widget speaks the language of the desktop.

And two things that surfaced precisely while preparing these screenshots, which
matter more than the screenshots themselves:

Dates rendered in English on a Spanish desktop. Qt.formatDate with a hand-written format uses the C locale, not the system one: with everything else already translated, it still said "Sat 12 Sep" where "sáb 12 sept" belonged. Measured with QLocale("es_CL") on the same date.
Four labels were written in Spanish by the collector and reached the screen without passing through the catalogue, so on an English desktop they read in Spanish among translated strings.

The screenshots are generated by a script in the repository, not by hand, and
that is where the three new figures come from:

scripts/capture_previews.sh build/previews en 3

It renders the three views without opening a window, with the same component the
tests verify, at whatever scale is asked for —3× for these. The data comes from
ai-quota-monitor sample, which writes a synthetic report into a temporary
directory: the real cache is neither read nor touched, and every line of the
render is labelled as synthetic. That is why the figures do not show my quotas,
and why they can be regenerated identically. It does need a GPU, though, and the
update below explains why.

Update, 9 September 2026

Figures 1 to 3 were regenerated for a specific reason: the logos came out
black. The widget on the panel was always fine; what was wrong was the
screenshot script.

The Kirigami component that recolours a monochrome SVG does it with a GPU
material, and the software renderer has no equivalent for that material: it draws
the silhouette and skips the colour. The script rendered in software, so four of
the five logos showed up black —Codex, white— and in the popup they were nearly
invisible, dark on dark. The fifth, Gemini, looked right because it was never
meant to be tinted: it keeps the blue of its own file.

What interests me most about this failure is why all 93 tests stayed green. A black
silhouette has exactly the same width, the same height and the same aperture as a
tinted one, so no geometric invariant could see it: the absence of a colour check
was the reason it went unnoticed. And it had been written down in the repository
since 6 September —«software rendering alone did not show SVG mask colours
faithfully»— two days before a commit switched the flow to offscreen and shipped the
defect.

Measured: the bar had 1452 opaque pixels of pure black and 299 of pure white; the
popup, 2597 and 6. It now has zero of each, and the four masked logos appear in their
accent colour. There is a new test that looks at the pixel colour inside the central
disc of every donut and requires the dominant colour to be that provider's accent,
with Gemini as the negative control: if Gemini matched both, the measurement would be
looking at the ring rather than the logo. It skips explicitly when the machine has no
GPU, and it never passes by measuring nothing.

A twist I did not expect: of the three ways to render on the GPU, the two obvious ones
require mapping a window, and a locked screen stops presenting it. The same
commands that worked in the afternoon hung an hour later with the session locked,
waiting for a frame nobody was going to paint. The one that works opens no window at
all. And switching platforms brought another surprise: the new one derived the DPI
from the real monitor instead of using 96, and with that the tooltip grew 24 pixels
without a single line of code changing. The DPI is now pinned, so the geometry does not
depend on the monitor of whichever machine takes the screenshot.

The logos also grew by 5.3 %, which is all the margin left: the corner of their box now
touches the circumference of the central hole. The check that guaranteed that
containment had been disabled by a silent ceiling that clamped any value above 1
without warning —a value of 1.10 came out green—; removing it put the check back in
service.

Figure 5 — Compiling, xkcd no. 303, by Randall Munroe. The old excuse was that the code was compiling; now I can say the quota resets next week. Licensed under CC BY-NC 2.5.

DEV Community: Cristián Labra

Nushell in three spoonfuls: when does a structured shell actually help an agent?

Prelude — Does structure actually help?

Route before you replace

Measure with R, not impressions

First level: pipeline against pipeline

Second level: agent against agent

Counter-tests before the verdict

The holdout that corrected the story

A real aggregate case from my thesis

A verdict for each outcome

Closing — A shell is not a religion

References and notes

Appraisal and vulnerability in 3 spoonfuls: change the denominator, change the map

Reading contract

The question

Before the spoonfuls: why we tax what cannot move

Spoonful 1: building the numerator without closing the leak

Before the IGVUST: the size of the observed appraisal

Spoonful 2: quartiles, bivariate map and denominators

1. Per household, the eye-catching cell is a lead

2. The eye-catching quadrant has fewer households and far more area

3. The association changes with normalisation

4. What is robust is the sensitivity

Spoonful 3: scale and concentration

Closing: gaps pay property tax too

Sources

Multi-agent work in three spoonfuls III: a memory that leaves traces

Preamble: remembering is not enough

Spoonful 1: from retrieving fragments to governing evidence

What changed since part II

What memory actually exists

A useful failure

From command to task

Spoonful 2: governing sources before blending them

An architecture of permissions, not a blender

Reuse before reinventing

A retrieval experiment that could fail

Spoonful 3: a map that does not pass itself off as a mind

Seeing the network without attributing more to it than it says

Retrieving a source is not enough either

Closing: a useful memory before a digital clone

References

Further reading

Software and technical documentation

Multi-agent work in three spoonfuls II: auditable memory

Spoonful 1: the problem was not storing, but retrieving well

RAG, without turning it into magic

Searching by meaning and by words

Spoonful 2: from a useful index to evaluated retrieval

The embedding model I actually used

A question set that makes the system uncomfortable

Results: what happened in the validated run

Fusion and reranking

A regression gate

Spoonful 3: what this memory still does not solve

References

CASEN 2024 in 3 spoonfuls: without a fine-grained territorial reading, social policy moves blind

Tolerance to contrast, or checking against official data

Spoonful 1: sampling design and expansion without shortcuts

Weighted national results

Spoonful 2: the technical flow in Julia

Taylor linearization: SE and CI of the complex design

Largest remainder: why it matters in a waffle chart

Reproducibility

Spoonful 3: visual evidence

National composition (Charts 1–3)

Regional gaps (Charts 4–6)

Gaps with 95% CIs — all statistically robust

Closing: three questions for those who use the survey

Multi-agent work in three spoonfuls: what worked for me and what did not

Spoonful 1: the problem was not using agents, it was losing continuity

Spoonful 2: the repository as a work contract

Skills: procedures, not endless prompts

MCP: a bridge, but I still do not squeeze it fully

Handoffs: the antidote to "I told them"

Spoonful 3: what I learned by making it fail

Closing: an optimization loop

Update · July 2026

Technical References