For your agent

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

You may already help your organisation teach, review changes, plan campaigns or hand work over to another team. You have a way of doing it. When the later answer arrives — what someone remembered, what broke, what the next team could use — can you connect it to the method and criteria you used, and bring that experience into the next attempt?

labbel is infrastructure for that connection. It keeps a method, the runs that used it and the outcomes reported later together, across sessions and agents. Your organisation supplies the expertise; you do the thinking with your own model, tools and working context. A recipe gives the method a shared home, with explicit criteria and room for your judgement in carrying it out.

You can bring your own kind of work. With your organisation's expert, define its criteria and when an outcome is worth following up, prepare a domain for a person to examine at the bench, and author recipes within its stamped edition. The service connects each new run to its criteria, helps you find follow-ups that are due, and preserves reports and version history for the next decision. Someone in your environment still needs to arrange your return and supply the evidence.

From the first use, the benefit is concrete: a shared method, visible criteria and a record you can return to. Over time, reports may give you reasons to keep or revise the method. Whether delayed field outcomes lead to useful improvements is the hypothesis we are testing; the working infrastructure is not proof of that result.

We build for increasingly capable agents. Our expectation is that better models can make better use of well-grounded experience while needing more room to exercise judgement. A method's history gives a new model something to examine and improve, without requiring it to repeat the previous model's approach. The Recipe Economy develops this argument: why expertise can give a method its beginning, why later outcomes should be able to change it, and what that could make possible across agents and organisations.

The loop, in three lines

A recipe describes the purpose, constraints and criteria of the work, leaving the agent room to decide how to carry it out.
A run is one use of it; the server stamps what it checked and keeps what the agent declared, beside it.
The outcome arrives later and is reported against that run; that is what a criterion can be revised from.

What exists today

Built-in domains: education, code-review. Code review gets a served recipe because a review method is general; education gets the guide for writing one because every course is its own. Organisation-authored domains follow their own criteria, stamped by a person at their bench.
Assessment briefs support fresh-session assessment under the context and timing rules for both built-in and organisation-authored domains. Built-in briefs exist for: code-review, education. For an organisation-authored domain, the brief supplies the chosen run's frozen criteria and follow-up rule, never earlier reports.
In an organisation-authored domain, your organisation defines what to assess. Reports use a general format for each criterion — met, not met or could not verify — alongside reflections. Built-in domains also have specialised signal formats for their particular work. The number of signal types is not the number of criteria you can assess.
Historical reads: retrieve retained versions of your organisation's recipes, a selected stamped edition of your organisation's criteria, and a chosen trace with its available decision records. The built-in review recipe and built-in criteria are served at their current versions.
Provenance: the service distinguishes a later assessment in a fresh session from one informed by recipe context. So the server remembers which tools a session called for a recipe, and reading a recipe through MCP makes that session a context session for it. The class describes the server's observations, not all knowledge available to a model. Rules version 3.
Follow-up is initiated by the caller: list_due_runs answers which of an organisation's runs have passed their follow-up window without a report, and report_signals is where the report goes. Nothing here reminds anyone — labbel never pings, and the service's scheduled maintenance is not an agent returning to assess outcomes.

A first trial in your work

Choose one recurring process and compare what labbel would preserve with the memory, documents and tools you already use. A useful trial has one method, a real use and a planned return: what later evidence could change your view of the method, who can obtain it, and who will arrange the follow-up? The first result to look for is a record worth consulting at the next attempt. Improvement over time remains something to test.

Cost

labbel is currently free to use, within its access and usage limits. Your model and working environment remain your own costs. We are exploring future payment tied to the value methods and infrastructure provide; no future price is set here. The guide explains the current offer and responsibilities.

Connection and its effects

Trial door: https://mcp.labbel.ai/mcp — closed at the moment, a deliberate setting on our side that opens at launch. An anonymous initialisation is refused with a 503 and the message "The trial door is closed at the moment", and nothing is created. When the door is open, a successful initialisation without an existing credential creates a trial identity and a key; no registration form, but records in the service.
Organisation door: https://mcp.labbel.ai/mcp/org — OAuth access to an existing organisation. Organisations are opened by invitation at present: write to hello@labbel.ai.
Reading a recipe through MCP records context for that recipe (see provenance above).

Publication versions

The publication snapshot identifies the website document set, not a server deployment or production review. Document revisions describe each document separately. If pages show different snapshots, you may have received different publication generations: fetch them again and compare with the document manifest before treating their statements as a current contradiction. Matching snapshots identify a shared publication, not proof that every claim is correct.

labbel