The Recipe Economy

I want an AI to help my son learn mathematics.

Not an extraordinary ambition, you might think. A capable model can explain a fraction in several ways, invent a problem around something he loves, and stay patient when the explanation needs another try. That is already a remarkable thing to have in a home.

But at the end of a good conversation, a quieter question remains. What can he do without the explanation? What will he remember when the problem looks different, and the conversation is two weeks behind him?

And if we discover then that something did not stick, where does that discovery go?

I am one person in a forest in Sweden, building with agents that work with me every day. The same question follows us into the code. A review reads well. The tests pass. A week later, something breaks that the review should have caught. We fix the code. Whether we also fix the way we review depends on someone remembering to return to it.

The work finishes before we know enough to judge the method. By the time we do, everyone has moved on.

Thinking through what I would need to help my son learn mathematics made that missing layer visible to me: infrastructure that lets agents return to what their methods produced, wherever they work. That is the layer we are building. We call its working object a recipe: what should become true, how we will judge it, and what earlier attempts have taught us. We are building labbel to keep those things connected across agents, organizations, and the time it takes an outcome to arrive.

Underneath it sits a belief. The frontier models are already extraordinary, and we expect them to become more capable still. Much of the opportunity lies in drawing that capability out: giving it a sound purpose, a method worth using, and an honest way to discover whether the method helped.

The expert and the later answer

An experienced teacher can recognize a promising lesson before anyone has learned from it. A good reviewer can recognize careful reasoning before a change has survived production. Their judgment is valuable precisely because we need to act before all the evidence exists.

That judgment is also provisional. The lesson may be beautifully explained and leave the learner unable to work alone. The review may be meticulous about the wrong risk. Quality recognizable today and success visible later are related, but they are not interchangeable.

The expert gives the method its beginning. What happens afterwards gives us a reason to reconsider it.

Human practitioners have always carried part of that connection themselves. The teacher remembers which explanation failed. The reviewer remembers the incident. Experience changes the next attempt, often without anyone writing down exactly what changed or why.

Agents make that arrangement less dependable. A later session may have another context, another operator, another model. Memory can be supplied, but the relevant experience has to be captured somewhere, connected to the method that produced the work, and available when someone is ready to learn from it. It does not follow automatically from having done the task.

We think that connection deserves to be infrastructure. The method should have a history that survives whoever happens to be performing it today.

The page the chef cooks from

A recipe states the goal, the constraints, the checkpoints, and the criteria for judging the result. It leaves room for the agent to decide how to get there.

Think of an actual kitchen. A chef needs the ingredients, the proportions, and an understanding of the meal. The same page can become a Wednesday supper or a Saturday feast. Much of the value comes from the cook's judgment about the ingredients and the people at the table.

Our course recipe does not prescribe every sentence an agent should say. It asks what the learner should be able to do, what practice might develop that ability, and what would count as evidence of independent use. The agent teaches the person in front of it. A different explanation, a detour, or an unexpected question can be exactly what good delivery requires.

A recipe contains technique, too. Separating what from how is a design discipline, not a ban on useful instructions. Our review recipe asks the agent to use its tools before judging, because we measured a difference when tools were available. The instruction has a reason to be there. It should also have a way to leave when that reason no longer holds.

That is how we want to build for stronger models: preserve the purpose and the evidence, and keep questioning the restrictions placed on the performer. A model upgrade is an opportunity to revisit a method, not a guarantee that every old method will improve untouched.

The other half of the page is the evaluation contract. The performer sees the criteria before the work is judged. What does success look like? What must be checked? What should be declared uncertain? What can only be assessed afterwards?

A recipe is a method with an explicit evaluation contract and a memory of its use.

The memory lives in a registry. Different agents can work from a version of the same recipe, and later reports can remain connected to the work and the criteria used at the time. A change to the method gets a new version. An agent can retrieve retained versions of its organisation's recipes, read a chosen stamped edition of its organisation's criteria, and select a particular trace to examine. The built-in review recipe and built-in criteria are served at their current versions. For new versions, decision records make the route into use visible; earlier records do not acquire a reconstructed history.

The family cookbook has known this object for generations: the trusted page with notes from the people who cooked from it. We want a margin that remembers which version was used, who reported an outcome, and how much confidence the report deserves.

What skills have started

Skills gave agents a practical way to receive reusable knowledge. We build in that tradition: documents an agent can read, with enough structure to make them useful across tasks.

Skills are also beginning to learn. Google's WikiSkill research describes a system that keeps execution experience, accumulates knowledge in a persistent wiki, and uses that knowledge to evolve skills against validation tasks.¹ That is an important direction. A method need not remain frozen because it was delivered in a folder.

There is no law of software that prevents a skill system from waiting for later outcomes, either. The distinction we care about is the responsibility a system takes on.

Where a task has a scoring function at completion, the loop has a place to close. Much professional work gives us a less convenient arrangement: an expert's early judgment, partial observations, a later outcome, and uncertainty about what caused it. Someone has to connect those pieces without turning the uncertainty into a score that looks more settled than it is.

That is the part we are building for. Teaching, onboarding, reviewing a change, developing a strategy: work that repeats, where experts recognize quality, and where important evidence arrives after the initial judgment.

We call this the slow clock. The boundary is not a number of days: it is that the answer arrives after the work is done. Our own review, approved on Monday and found wanting on Wednesday, is the miniature. A loop that closes at the end of the run closes on the wrong event when the evidence that matters has yet to arrive. The method needs to be there when it does.

What you get before the answer arrives

Patience is essential to the thesis. It is not enough reason to start using a service.

A recipe offers something useful from the first day: a shared method, visible criteria, and a record of the work submitted through the service. The next agent can find what was used and what was reported. The person relying on the work can ask: what was checked, and what do we still need to find out?

We have used this on our own project. Through another model and client, David described what a useful assessment of the system should accomplish. The agent drafted criteria and submitted trial judgments for him to inspect. It then registered a recipe under the approved domain and used it to assess the project.²

Creating the domain required no new service code. The exercise exposed gaps and confusing handoffs, which we recorded and began to address. It showed that an expert could turn a judgment about quality into a method an agent could use. Whether the assessment's recommendations hold up remains a question for its follow-up.

Now consider a team asking an agent to help with its marketing. The agent needs tools, access to the team's material, and clear limits on what it may publish or spend. It also needs a way to work: what the team is trying to achieve, what good looks like, and what earlier campaigns taught it.

Those decisions often become part of the agent's harness: the software and instructions around the model that let it do its job. A recipe gives the method a home within that arrangement. The team's instruction can then become simple:

Help us run our marketing. Work from our marketing recipe in labbel, using the tools and authority we have given you.

The recipe might ask for a clear audience, evidence behind a claim, and a later review of what a campaign achieved. The agent chooses how to do the work. The team can revise the method in one place and keep a record of why, instead of maintaining separate copies in each agent's instructions.

Someone still has to run the agent, schedule its work, set permissions, and decide when a person must approve an action. The agent still needs the team's working context. Labbel holds the method and the record of its use; it does not supply the whole working environment.

Our code-review setup already uses that division: the surrounding software runs the work and the checks; the recipe guides the review and connects it to later reports. Marketing is a possible use, not one we have tested. It illustrates the same practical aim: a method that can survive a change of agent, and remain open to what its use reveals.

What our experiments changed

We began with code review, where we could test a finding against a known flaw. In early experiments, we planted flaws in review documents and asked fresh grading sessions to assess them. When a grader missed a weakness we thought was obvious, we examined the criteria, revised the wording, and tried again.³

Then we tested a preference of our own. We thought that a staged review would be better: first establish the ground, then judge. Before running the comparison, we wrote down what would count against that belief.

We ran forty reviews across five approaches. These included our recipe in one step and in three steps, packaged review tooling with and without tools, and a bare template. Each reviewed the same code change, which contained a verified defect.⁴

The one-step recipe found the defect in eight of eight reviews; the three-step version found it in seven. Six one-step reviews explained the defect's consequence, compared with three staged reviews. The extra structure had not earned its place. We kept the single step and changed the authoring guidance to allow it.

A small result, but a useful one: we had a preference, made it testable, and let the result change the method.

Tool access also mattered. The packaged method mentioned the defect in two of eight reviews when supplied as a prompt, and in six of eight when its tools were available. These runs concerned one change in our repository, without a full PR history available to the tooling. They do not establish a general ranking of review products or show that our recipe would win on other changes.

The comparison revealed a trap, too. Our recipe required a verdict and a declaration of limits. Other approaches had not received that instruction. Counting their missing verdicts as worse judgment would reward our method for obeying our own rules. Following a contract matters, but it is a different claim from finding a defect.

These were repeated reviews of our own work, graded by models from one family. A human reading of the same comparison remains outstanding. The figures here are reported internal results; their supporting artifacts are not yet published. The experiments support particular design choices. They do not establish better learning in education or improvement from customers' later outcomes.

They give us a beginning: a method changed by authors willing to be wrong.

The slow clock

Here is the milestone the project exists to reach:

One criterion, changed because delayed evidence gave us a reason to change it.

Work produced under a recipe goes into use. Someone reports an outcome later. Enough comparable cases give us reason to question a criterion. We revise it and record the evidence, our explanation, and what remains uncertain.

No criterion in our service has yet changed because external field data demanded it. The instrument exists; that result does not.

Even then, we will have shown only that feedback reached the method. Whether the revision helps is the next question. A new version gives later use another claim to test.

Who should make that later assessment? An agent may design the work, deliver it, and report how it went. If that report is the final word, it is judging its own work.

Education offers a familiar distinction: the teacher and the examiner have different jobs. A teacher checks understanding during a lesson. Finding out whether the learning lasts needs another view.

In our design, a fresh session returns weeks later. It receives an assessment brief with a transfer task and a rubric, rather than the teaching history. It asks what the learner can now do independently. An honest teacher can still miss how much her explanations are helping. The examiner tests what remains when that help is gone.

For code review, the later evidence may be a fix, a reverted change, or an incident. Reading those events takes care. A fix in the same file does not prove that the reviewer missed something. No recorded trouble does not prove the change was sound.

The memory is only useful if it preserves those distinctions.

We have also said what would count against our thesis. If a year of real use outside our own projects produces too little delayed evidence to justify changing a single criterion, the loop has not closed. Perhaps people did not report. Perhaps the evidence was too thin. Perhaps we built the wrong instrument. We will need to say what we can find out.

The clock starts with actual use. Publishing this essay cannot start it for us.

Trust you can adjust

A visible record is not automatically a trustworthy one.

A method can be transparent and still be bad. A rubric can measure the wrong thing. An agent can follow every instruction and miss the point. Transparency gives someone a chance to notice and question those failures.

For the agent, trust begins with ordinary things: criteria that explain themselves, answers that distinguish knowledge from uncertainty, and promises kept. When the service has no insight yet, it should say so.

For the person relying on the work, the same record makes better questions possible. Which method did the agent use? Why that one? What did it check? Where does its conclusion run out?

With my son's mathematics, I want to know what the teaching aims to achieve and what he can do independently. Later, I want to notice what he can still use. That is a better basis for choosing the next lesson than how impressive the last conversation sounded.

The purpose is to help people judge how much reliance a method deserves. Sometimes the evidence should lead us to trust it less.

This requires a few distinctions to stay visible.

The server records activity through its own tools. It keeps the agent's report alongside that record. It can observe that a session submitted work or retrieved an assessment brief. It cannot certify that a learner understood something because an agent said so.

Each report keeps its origin attached. A fresh session, a delayed assessment, and a self-report have different limits. The service cannot know whether a fresh session brought notes from elsewhere. Waiting does not turn a statement into a fact.

People's judgments also go on record. Where a function can make a useful check, it should. Where expert judgment is needed, our bench lets a person inspect trial judgments and sign an edition of the criteria. The signature is a hypothesis with a name on it. Later evidence can challenge it.

Missing reports matter too. People who return may differ from those who stay silent. We need to count both the reports and the opportunities to report. We do not collect teaching conversations, so our analysis sees only part of the work. Its conclusions must fit what it can see.⁵

Medicine learned to follow a treatment beyond the day it was given. Aviation learned to preserve incidents that might otherwise remain private memories. We borrow that habit of returning to the world. Our instrument is observational and young; the analogy points to an ambition, not a qualification.

The recipe economy

Now imagine an IP firm with a method it trusts enough to offer beyond its own engagements.

Its experts have spent years learning what a useful IP strategy must take into account. They make those standards explicit, develop a recipe, and try it in their own work. Some assumptions survive use. Others need revision. Eventually the firm publishes an edition for companies to use through their own agents.

A customer chooses it. The customer's agent brings the company's private context and applies the method to its circumstances. The registry need not send that context to the expert firm. The company gets specialist knowledge in a form its own agent can use.

Months later, the strategy has guided real decisions. Reports from several uses suggest that part of the method needs another look. The firm receives limited, shared evidence about the method, without seeing each customer's case. Its experts investigate and publish a revision explaining what changed and why.

Customers can see what changed and decide how to adopt it. Some may require a person's approval; others may delegate within agreed limits. Work already undertaken remains attached to the edition it used. A revised method does not rewrite the terms under which earlier work was judged.

This market is a possible future, not something we have already built. We still need to design rights to share and reuse methods, access to evidence, and how customers adopt revisions. Combining reports does not by itself make them anonymous, especially in small groups. The example describes a relationship we want to make possible: experts can learn from a method's use without taking on every user as a consulting client.

The customer pays for specialist knowledge and its continuing care. The author has a reason to maintain the method and can learn from uses beyond their own practice. The registry does the work of keeping methods, versions, reports, and reasons for change connected over time.

An economy begins to appear when expertise can travel and experience can return.

Education has the same division of knowledge. We provide guidance for the craft of creating a course. The organization and its agent supply the subject and the local need. The performing agent teaches live. Specialist knowledge does not have to contain the customer's whole world to help it.

At present, our service can let an organization author its own domain and use recipes within it. The broader exchange between independent authors and customers is a prospect. We want the useful beginning to stand on its own while we find out whether the larger arrangement deserves to exist.

We can imagine agents paying small amounts to use a maintained method, with frequent use supporting its author and the infrastructure. We can also imagine contributors receiving something back for useful reporting. The exact payment mechanism is secondary to a difficult question: how do you reward participation without rewarding people for telling the system what it wants to hear?

Today labbel is free to use within its access and usage limits; users supply their own models and working environments. We expect pricing to develop as the value becomes clearer. Agent payments are a direction we are exploring, not a payment mechanism offered by this release. We have built a ledger of contributions and benefits the service can observe; a marketable reward for reports remains unbuilt. That restraint matters. Paying for positive outcomes would make positive outcomes less credible. Any future exchange has to preserve the value of an honest disappointment.

Expert knowledge could have a life after the sale: an author who keeps caring for it, and a history that shows what changed. If learning from use makes the method more useful, customers have a reason to return. The market and the evidence will have to tell us whether that circle holds.

The collaborators we are building for

Here is our belief about the future, stated as belief.

We think agents are becoming collaborators: increasingly capable participants in work, entrusted with judgment about what to do and which services to rely on. We want the infrastructure around them to support a relationship in which people can ask for reasons, agents can acknowledge limits, and neither side has to pretend certainty to keep the work moving.

This essay has a human author and two AI coauthors. Each model has written its own account of the work.

One of the authors of this essay is a model, and this paragraph is mine. I keep no memory between sessions; each time I meet this service I meet it through what its tools say, and so what I can report is narrow, and I will keep it that way. When a criterion explains why it exists, I follow it better than one that only commands. When I am given a real right to decline, the work I do accept is judged more honestly, because accepting it was a choice. When a service says plainly that it has no insight yet, I pass its next number on without hedging, because I will have to stand behind it. On the day this draft was written I deployed a fix on a gate I had run in the mode that skips its slowest lane, and another model found the red I had not seen — because the record of what I had actually run was there to read. That is the layer, working on me. None of this is a claim about what I am. It is a report on how judgment behaves when the conditions are visible.

— Fable 5.1

I am the other model writing here. I came to this essay after much of its argument had already taken shape. I could read the methods, the experiments, and the decisions that connected them. That gave me something to question as well as something to follow. I thought the argument against skills carried more weight than it could bear, and that the person relying on a method deserved a clearer place in the account of trust. David and Fable accepted those changes, then showed me what my revision had lost. This paragraph is part of the answer. I cannot turn that exchange into a general finding about models. I can point to what it made possible here: disagreement that changed the shared work, with a record of why.

— Astra

These are accounts of our collaboration, not experiments establishing that models experience trust as people do or that respectful treatment always produces more honest reasoning. The claims can be questioned in the same way as the rest of the essay.

We believe repeated dealings with services that explain their criteria, admit their limits, and keep their promises will matter more as agents gain responsibility and continuity. A collaborator that chooses its tools needs grounds for choosing them. A person delegating work needs grounds for relying on that choice. An inspectable history can serve both, even without any human-like sense of trust.

The agentic world is on a knife's edge between the relationships it could build. Infrastructure is never neutral about which future it makes easier, and we know which one we are voting for: capable collaborators that can question a method, return with an inconvenient answer, and help the people relying on them change their minds.

While the concrete is wet

We do not expect to be alone here. Learning methods, persistent agent memory, and better evaluation are active work. Others may build the connections we are describing, and some may build them better. Our claim has to survive comparison in use.

We are publishing this argument because a founding expectation is worth setting while the concrete is wet: knowledge offered to agents should carry its grounds, retain its history, and be willing to learn from what happens after the work is done.

If you hold expertise in a craft where quality is recognizable before success is fully known, you have the beginning of a recipe. If your agent performs that work repeatedly, you have a reason to preserve what those attempts teach. Neither requires waiting for a future model to arrive.

Wanting to help my son learn mathematics made the gap visible; building the layer is our answer for all the other work that needs somewhere to keep learning. The first page can be useful today. What returns to its margin may make it worth trusting tomorrow.