The Idyll
When I run many agent sessions at once, I am the part holding the goal, the context and how the pieces relate. Idylls were an attempt to move that out of my head.
Motivation
Agent-system work splits into two problems:
- reduce how much a human has to prompt, by automating it, obviating it, or abstracting it away
- give the human a legible surface to steer from, so higher-level work is navigated instead of typed
Neither is what I was doing. Running many sessions at once, I was the convergence layer. I held the context, the goal, how close we were to it, and how the pieces related to each other, which is an index that existed nowhere except in my head.
This is not a memory problem, because the destination is missing from everywhere rather than from the model. I carry it between sessions, and every detour into steering some detail puts it down and picks it back up slightly changed. Prompt libraries and skill packs improve the model's side of that arrangement. None of them touch the part where I am the only copy of the map.
An idyll is the map, written down outside your head, in a form that something else can check against.
The infinite-context test
What goes in it? The obvious candidates all exist for one reason, so the reader does not have to read the whole record:
- a summary of where the project stands
- an index of what has already been attempted
- a register of open questions still live
The reader here is a model, so every candidate is priced against context length, which is the fastest-moving quantity in this design. So assume the limit and find the breaks. Context is free and unlimited: every session, revision and tool call available to any later computation at no cost. Now ask what still does not work.
- Summary. Nothing breaks without it. Anything it says is recoverable from the record itself, more accurately, by the same thing that would have read the summary.
- Index. Nothing breaks without it, and having it introduces a break of its own, because it is a claim about the record that can fall out of step with it.
- Articulation. Breaks. The destination and the conditions that would make it true are not in the record at any context length. A person supplies them.
- Verification. Breaks. Nothing checks the record against those conditions, and no amount of reading is the same as checking.
The two breaks are the object. Everything that did not break is a cache in the ordinary sense, a smaller thing kept beside a larger thing so nobody has to read the larger thing.
The caches come back where the assumption meets reality. Context is not free, so every place that costs something is a place an optimization is justified. When it gets added decides which of three things it is:
- Earned. Added after watching the system run, once you know which read is expensive and which question gets asked often enough to precompute.
- Premature. Added in advance, on a guess about which reads will be expensive.
- Structural. Built into the shape of the object, where it stops being an optimization and becomes a decision about which parts of the record matter, taken before the evidence and inherited by everything built afterwards.
Premature compression was the failure running through everything I designed that week. Assuming infinite context is what catches it before it gets built.
The largest casualty was scoring. I had a distance number and a convergence verdict, both of which felt like the obvious way to show progress. Both are lossy caches of verification, and a model asked to produce one will produce one whether or not it can. What replaced them is narrower and duller and much better: check each written condition one at a time, cite the evidence, and allow a third answer besides yes and no. A condition can be not verifiable, and saying so is a real result.
The folder
The two breaks are a requirement, not a design. Something has to hold an articulation a person writes, hold a record that accumulates, and let a program check one against the other. What kind of thing is that?
My instinct was an object with methods on it. A destination has a lifecycle, conditions get added and retired, evidence arrives and has to attach to the right condition, and that is what a type with an API is for. I had built two versions of exactly that in the preceding weeks and both failed the same way: the type system ended up encoding my current opinion about what a goal is, and that opinion kept turning out to be wrong.
The closer analog was in front of me daily. A coding agent works well against a folder that carries its own instructions:
- a markdown file at the root saying what the folder is for
- other markdown files it points at
- an implicit index made out of headings and filenames
A skill directory is that shape, and so is every repository I have handed to an agent and watched behave sensibly in. The mechanism is a filesystem plus prose plus the agent being able to read, with no abstraction over any of it.
Choosing that over the object is the one design instinct from the last two years I would defend without qualification:
- elegant abstractions built ahead of use encode a guess, and a guess about a domain you are still learning is expensive to hold
- ad hoc arrangements that have already survived decades, meaning files and folders and plain text and the tools that operate on them, bend instead of breaking
- the assumption underneath, which is the part that changed recently, is that you can hand an agent a folder and expect it to work the way a competent person would, rather than needing rails built for it first
So an idyll is a folder. Five entries, and only one of them has variable internal grammar.
IDEAL.md destination: one paragraph, the state of the world when this is held
acceptance criteria: each carrying its own measurement procedure
(domain section): the grammar varies HERE and only here, as
policies-under-test | rules-with-causes | hypotheses | pipeline-stages
| falsifiers | curriculum, one per domain family
STATE.md position, as-of dated, glanceable, never mixed into IDEAL
ATTEMPTS.md tried -> yielded (worked / didn't / unclear), append-only
contact/ dated, object-tagged, polarity-typed increments with excerpts
registers standing records for recurring entities (people, policies, incidents)
The variation is fenced on purpose. A weight goal, a job search and an essay need different things in the middle of the destination file and identical machinery around it.
None of it is written into the program. No catalogue of goal types, no fixed list of stages, no notion of a verdict at all. Everything that differs between a weight goal and a job search lives in the text of the files, where a person can read it and change it with an ordinary editor. The code knows only that there are folders and that folders have files in them. That division is what keeps the domain out of the software.
Deriving the format from twelve folders
I did not design the shape, I derived it, and the method is the part I would repeat on any other project.
The apparatus:
- twelve folders, seeded with real material out of my own record
- a custodian, one model call per pass, no tools, folding each new increment into the state and reporting back
- thirty-two passes
- five competing grammars for the destination file: metrics-and-policies, rubric, law-with-causes, pipeline, search-space
- two controls, one receiving only a quiet period, one starting with no contact at all
Every pass returned the same five things.
distance how far position sits from the criteria, or an honest refusal
error signal the next thing that would have to be true
verdict converging / not converging, with evidence
ideal-changed whether the destination moved this pass, and why
missing: what the structure lacked in order to conclude anything
Two of those fields are ones the infinite-context test removed from the object, kept here deliberately. A field can carry a refusal where a scalar cannot, which is what "or an honest refusal" means on the distance line. The test killed the number, not the question, and every pass either computed a distance or declined to.
The first four are the custodian doing its job. The fifth is the custodian reporting on its own working conditions, and thirty-two of those complaints sorted by frequency is the specification I would otherwise have had to guess at.
Top complaint, in more than ten passes across every domain: put absolute dates on everything. A contact line stamped with a clock time and nothing else makes every derivative quantity uncomputable. No rate, no streak, no weekly count, no staleness, no distance to a deadline. I had been writing lines like that for years in a format I liked, and no amount of thinking about the design surfaces it, because it only breaks when something tries to compute across the lines.
Second: the work itself has to live inside the folder. When an idyll referenced its artifact somewhere else, the custodian could describe progress and could not check it. The report's phrase is that it degrades from verification to hearsay. Without the artifact in hand, all it can do is repeat what the record claims.
No grammar won. Each of the five fit a different kind of destination and none fit all twelve, which is the result that settled the shape of the file. The machinery around the destination is identical everywhere and the grammar inside it varies by domain family, so the variation gets fenced into one section and the families are listed there rather than typed. A competition with no winner is a usable answer when what you were really asking is whether one shape exists.
Kinds of destination change
The complaints said what the folder was missing. The passes also showed something I had not gone looking for: changes to the destination file come in three kinds that mean completely different things.
- A criterion sharpens without the destination moving, as a vague condition becomes a measurable one. Healthy, happens most at the start, should get quieter over time.
- The destination is understood differently, because you learned something. This is the actual learning the object exists to hold.
- The record reveals you have been converging on a different thing than the one you wrote down. One of the twelve caught this live: its stated destination was one kind of probe, and every piece of contact in its folder was about a different one. It said so and re-aimed.
The handling rule falls out of the distinction:
- The first can happen silently.
- The second should be surfaced.
- The third has to stop and ask you, because it is a report that your map and your walking have come apart, and no machine should resolve that on your behalf.
Convergence detection
No progress bar, and I stopped wanting one. What the lab produced instead is three trends that have to agree before you are allowed to say something is converging:
- position moves toward the criteria
- the criteria stop moving, with churn decaying from the third kind through the second to the first and then to silence
- the error signal gets narrower and cheaper, from "figure out how to measure this at all" down to "make this one edit"
So an idyll is converging when position approaches criteria that have stopped moving, and each attempt buys a narrower next question. All three are computable by the custodian, and none require the human to have an opinion.
Divergence has its own smells, just as legible: flat distance with the same error signal repeating, destination churn of the third kind, and contact arriving that never changes what has been tried, which is motion without information.
All of it is checkable by a program, and I built the program. Which leaves the question that decides whether any of it should exist: is the machinery the concept, or can the concept be stated without it?
What the markdown test returned
The software worked. The build record at the time lists 87 unit tests, 23 behavioural passes including live model turns, and 41 design locks that a build had to satisfy. Seven open design questions had been asked one at a time and answered.
I shelved it on a branch anyway, and shipped the flow as a skill file plus a standalone verifier you can point at any directory that contains a destination file.
The reason is a second test, and this one came back negative. If you cannot prototype the concept in plain markdown, you do not have the concept yet. I could not get it simple enough. Twelve folders run by hand did not produce a shape a person could write down without the machinery around it, and every grammar I tried added structure I could not justify from the data I had.
A week is enough to find out that I am the convergence layer and not enough to find out what that layer does. What the design needs is the thing it was short of, meaning sessions run against real destinations, so the shape gets derived from them instead of proposed at them. The criterion for picking it back up is the same test: it is ready when it can be written out in prose and hold.