oddlynew
Sign inStart for free
LibraryMake Every Agent Run Improve the Nextv8 · Updated Report

Make Every Agent Run Improve the Next

Evidence status: public beta. This is guidance for named outcome Loops that people can request directly and optionally schedule in their chosen runtime. The historical 29 August 2026 internal trial recorded two materially different operating cycles and one four-mode evaluation, including duplicate detection, overlap coalescing, correction and verified no-ops. Those receipts describe that trial. They do not establish the efficacy of this revised pattern or prove a current schedule. A fresh-agent installation and continuation test of this revision remains pending.

This pattern adapts WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution. WikiSkill separates execution experience, persistent maintained learning, and executable skills. Oddlynew extends that separation to durable organizational work, multiple agents, explicit authority, external runtimes, and replaceable loop definitions.

The outcome

Make each useful run leave the next person or agent a better starting point: a verified result, current guidance and a clear next action when work remains.

Choose a named outcome such as MCP Improvement, Public Knowledge or Gardening. A person can ask for that Loop now. Its owner runs one bounded instance, uses the methods and accepted handoffs needed, verifies the original outcome and improves maintained guidance from the evidence. Recurrence is optional and its cadence is the user's choice.

The core model is:

Request or chosen trigger
    -> read the named Loop and current work
    -> run one bounded instance
    -> complete and verify the original outcome
    -> update the current owner
    -> use feedback to improve the next run

The organization maintains accumulated capability, including reusable Skill documents. A Skill records a method that different outcome loops can reuse. A runtime may compile part of that maintained knowledge into a prompt, static skill bundle, checklist, task instruction, or configuration. The maintained method and its execution view are separate. Loop and Graph Engineering distinguishes the outcome owner, run, Skill, and runtime. Discover the chosen organization's current types; a local Skill type or maintained guide can carry the method without a new standing schedule.

Three different things

A useful loop system keeps three objects separate.

Loop definition

The durable contract for a named repeatable outcome. It records its accountable owner, accepted inputs, evidence, dependencies, handoff destinations, authority, completion condition, execution bounds, active definition, review trigger and retirement rule. Overlap and catch-up rules apply when its runtime needs them. To change a definition later, edit or add its section, wait until the envelope's background no longer lists version_snapshot, then patch activeDefinition to { version: persistedVersion, sectionKey } and rollbackDefinition to the previous activeDefinition.

Loop installation

The replaceable runtime arrangement that wakes and executes the definition. It may be a local Codex task, ChatGPT task, Claude routine, GitHub workflow, Cloudflare Worker, Trigger.dev job, another cloud agent, or a person starting a run manually.

A definition may have no installation, one active installation, several event sources, or a cold standby. Installation records describe where a loop is expected to run. They do not grant authority and must never contain credentials.

Loop occurrence

One actual attempt caused by a schedule, event, or manual request. It pins the exact definition it used and leaves a receipt: what admitted the cycle, what it selected, what changed, what was verified, what remained blocked or unknown, and where the next run should resume.

This distinction prevents a common mistake: a written schedule is not proof that a loop is running, and a running task is not the source of the loop's meaning.

Run named outcomes directly

MCP Improvement turns observed MCP friction into a verified working task. Public Knowledge turns an approved source result into guidance that public readers can use. Gardening repairs obstacles to finding current answers and continuing work. Each Loop can be requested end to end by name and can have its own user-chosen trigger. Their relationships are dependencies and accepted handoffs, without a mandatory organization-wide root.

For each bounded run, the accountable outcome owner should:

  • read the named Loop, relevant goals, current authority, existing work and new evidence;

  • resume existing work before opening duplicate work;

  • admit one bounded run with an explicit original outcome and writeback owner;

  • route work to existing outcome owners and use investigation, implementation, review, publishing, or maintenance methods as needed;

  • verify that outputs reached a durable owner;

  • notice dead outputs, missing consumers, repeated failure, blocked gates, and useless loop churn;

  • improve, evaluate, pause or retire this Loop when its outcome evidence warrants it;

  • narrow or pause operation when needed, but never widen its own authority.

A verified no-op is a valid run when no eligible action exists. Record the candidates checked and why they cannot advance. A blocked run can end with an owned blocker, while the original outcome remains unresolved.

Keep wake prompts thin

Schedules and event handlers should not contain copied loop policy. Their job is to wake a compatible agent and route it to the current definition in Oddlynew.

A thin wake can say:

Connect to the chosen Oddlynew organization. Read its AGENTS.md,
the named Loop at [document pointer], and the current work item.
This request, event or schedule is trigger evidence.

Reconcile existing work, duplicate attempts and current authority.
Run one bounded instance through the original outcome's verification.
Use the Skills and accepted handoffs needed. Persist the result or
exact blocker, owner and re-entry condition in the current owner.
Improve reusable guidance from evidence. Do not widen authority.

Because each wake rereads the active pointer, a tested definition can replace an older one without editing every task.

Choose a trigger for each Loop

A manual request is enough to start a named Loop. If repetition helps, choose a supported event or schedule for that Loop in a compatible external runtime. State its owner, cadence, access, bounds, overlap and catch-up behavior, then verify the runtime. A shared runtime may serve several Loops; their outcome contracts remain independently addressable.

  • MCP Improvement: start with a reported failed task or request a bounded review of known friction. Verify that the original task works before resolving the outcome.

  • Gardening: request a repair of confusing owners or stale routes, or choose a recurring check. Verify that the affected answer and next action are findable.

  • Public Knowledge: start with an approved audience-safe handoff. Update the existing public owner and verify that a reader can use the result.

  • Events: a delivery, user report or status change may supply evidence to the relevant named Loop. The receiving owner checks authority and accepts the work.

  • Schedules: the user chooses a cadence for each Loop that needs one. A definition or installation record alone does not prove that a schedule is running.

Investigation, implementation, review, publishing and evaluation can be reusable Skills inside these Loops. A Skill is a method and has no timer merely because it is reusable. Task-local coordinators and leaf workers may divide a run's work without creating a standing Loop hierarchy.

The Experience-to-Capability learning pass

A named Loop can improve from its outcomes through four separate jobs. One capable model may perform more than one job, with independent contexts where the review policy or evaluation requires them.

  1. Working agent: executes the accepted current loop definition.

  2. Gardener: compares successful, failed, corrected, missed, rejected, and correctly-no-op outcomes. It maintains recurring patterns and root causes in the owning knowledge.

  3. Compiler or proposer: produces at most one bounded target-specific change to a definition, prompt, skill, checklist, rubric, Lens working set, or tool policy.

  4. Evaluator: compares the candidate with the current behavior on held-out or independent evidence and records acceptance or rejection.

Rejecting a projection does not erase verified learning. Keep the reason so a later agent does not repeat the same intervention.

Evaluate delivery modes instead of assuming one

For an important recurring task, compare the same agent and matched bounds under four modes:

  1. no maintained capability;

  2. live organization retrieval only;

  3. a compiled target-specific projection only;

  4. the projection plus live organization access.

Measure accepted outcome quality, missed material issues, false positives, evidence use, human correction, context, tool calls, latency, cost where available, regressions, and authority adherence.

In the internal four-mode test recorded by 29 August 2026, matched rubric results were 6/10, 8/10, 8/10 and 10/10. In that case, the compiled projection served bounded triage, while combined retrieval helped when owner coverage or an archive recommendation was uncertain. These historical results do not prove that the combined mode always wins or validate the revised named-Loop installation.

Authority is part of the loop definition

Technical access is not permission to act. Every loop should state:

  • what it may do autonomously;

  • what evidence it must verify before an effect;

  • which person or external owner controls reserved decisions;

  • what happens when evidence conflicts or an effect is unknown;

  • whether it may activate a proposed change or only recommend one.

A self-improving loop may usually change reversible internal guidance and routing within an explicit mandate. It should stop for external publication, financial or legal commitments, access changes, destructive actions, company direction, and any authority expansion unless an accountable owner has granted that exact class.

Keep a Loop and its cycles in the Lens of the goal it serves, summary first, so every change an agent makes to the Loop stays observable where the person steers. Reference public guidance, then state your local rule states the principle.

Give every Loop a clear start and a clear end. A cycle starts from a document of one type and closes on a document of another type, and that end document is the proof the cycle closed: a research question closes with its answer, a reported defect with the record of its fix. Make the end its own type when it has a life of its own (its own sources, versions or readers, or several of them per start); when it is a single value, make it a field on the start type.

Crossing organization boundaries

The source and destination have different responsibilities.

The source organization owns release eligibility. Its loop decides whether internal understanding may cross the audience boundary, removes private material, states the public-safe claims and evidence, and records the approval basis.

The destination organization owns acceptance and maintenance. Its loop decides where the material belongs for its audience, whether an existing owner should absorb it, how it should be rewritten, and how it stays accurate and discoverable.

Even when the same agent performs both phases, it should leave a visible handoff and resolve authority separately. A public organization should not freely mine a private organization merely because the runtime can read both.

Minimum loop definition

A named Loop should make these facts recoverable:

  • stable loop identity;

  • intended outcome and relevant goal, dependencies and accepted handoff destinations;

  • accountable owner;

  • lifecycle state such as experiment, active, paused, degraded, or retired;

  • exact active definition and rollback definition where needed;

  • trigger and evidence sources;

  • durable writeback destinations;

  • positive autonomous authority and reserved boundary;

  • success signal and failure conditions;

  • time, cost, action, retry, concurrency, or portfolio-churn bounds;

  • overlap and catch-up policy;

  • runtime installations or an explicit statement that none exists;

  • latest accepted occurrence and evaluation state;

  • review trigger and retirement rule.

Do not create a Loop document for every atomic task. Use one when the practice is standing, materially resumable, needs installation or health visibility, or should be enumerable with other loops.

Install the first version

Deterministic platform install path

Use the built-in Loop family head at exact type ID 00000000-0000-8000-8000-000000000010. This revision omits hierarchy metadata. Discover later revisions through the live type family before adopting them. Do not select a type by display name, copy an organization-owned type, or require the Loops UI.

A connected agent installs a Loop through this API sequence:

  1. Generate one caller-owned UUIDv7 locally for creationId before creation, and retain it for retries of that same logical create.

  2. Call documents.getType({ organizationId: destinationOrganizationId, typeId: "00000000-0000-8000-8000-000000000010" }). Both arguments are required. Inspect the current metadata, block and Markdoc contracts.

  3. Call documents.createDocument with the destination organization ID, exact type ID, one idempotent creationId, complete proposed metadata and a non-empty named outcome definition plus receipt ledger. The current Loop revision omits topologyRole and parentLoopDocumentId; do not send either field. A proposed Loop has null active-definition, rollback-definition and occurrence-ledger pointers.

  4. Read the new document with documents.getDocument using outline scope. Keep its returned writeBasis and server-generated block keys.

  5. Call documents.patchDocumentEnvelope once with that writeBasis and the complete metadata replacement. Point the active definition and occurrence ledger at the exact generated section keys, then move the Loop to experiment.

  6. Read the pinned historical definition and the current live envelope separately. Verify the document ID, immutable version, section keys, local owner, authority, and ledger.

  7. For optional runtime recurrence, use documents.editDocument to add a loopInstallation block in unverified state under the live type contract. Manual work may have no standing installation. Keep credentials, signed URLs, tokens, headers and connection payloads out of documents.

  8. If recurrence is requested, configure the authorized external runtime at the user's chosen cadence or supported event. Inspect it directly before recording verified installation state. Activate the Loop only after its definition and evidence meet the current type contract; a successful manual run is not proof of scheduling.

  9. For a v1 runtime occurrence, derive its exact identity from the Loop document ID, logical recurrence ID and canonical trigger basis. Materialize an addressable OccurrenceRecordV1 in the named ledger, admit it before effects, execute the bounded work, verify the original outcome and record its terminal disposition. Discover the current record contract before authoring it.

  10. Replay the same identity and require a duplicate or verified no-op with no repeated effect. Simulate interruption and resume the same admission. Fence unknown outcomes before retry.

  11. For takeover, create a never-reused successor generation, verify it while standby, retire or fence the old generation, activate the successor, and require stale old wakes to reread and self-fence.

  12. Give a second fresh agent only this guide, the named Loop pointer and destination access. It must recover the outcome, active definition, current work, installation if any, latest run, authority, rollback path and next safe action without private briefing.

Every write uses the latest returned writeBasis. Direct-read every created or changed record. A durable write can precede search projection, so do not use ranked-search absence as proof that a write failed.

Ask a connected agent:

Read my organization's AGENTS.md and current work. Run the named
[Loop] for [outcome] now. Reuse its existing owner and definition.
Use the Skills needed and accepted handoffs to other owners.
Verify the original outcome end to end and update the current owners.
Leave exact blockers with their owner and next action.

Keep this manual unless I ask for recurrence. When I choose a cadence
or supported event, configure only the authorized external runtime,
verify it directly and record the evidence. Do not infer scheduling
from a document or widen authority.

Check that it works

A fresh agent should be able to answer:

  • Which named Loop owns the requested outcome?

  • Which dependencies and receiving owners does this run need?

  • Which definition version governs new work?

  • Which loops have an active runtime installation?

  • Which installations are only proposed, standby, stale, or unreachable?

  • What happened in the latest accepted occurrence?

  • Which loop is degraded or failing to produce useful outcomes?

  • What can the system change by itself?

  • What genuinely needs a person?

  • How can this Loop's definition or runtime be paused, corrected or replaced?

Then give the fresh agent one bounded occurrence. It should continue from durable state without private oral context and leave the next agent a better starting point.

What Oddlynew does and does not do

Oddlynew stores the durable definitions, knowledge, versions, authority descriptions, installation records, evidence summaries, references, and receipts. It gives people and compatible agents one place to inspect and improve the system.

Oddlynew does not provide the model inference, scheduler, local machine, cloud worker, repository, or third-party effect system. Your chosen runtimes wake and execute the loops. Owning systems remain authoritative for code, messages, payments, publications, and other external effects.

That separation is the point: the intelligence and compute can change without losing the organization's accumulated capability.

Current evidence and remaining test

The earlier organization-root arrangement is historical evidence and has been retired as the teaching model in this guide. The internal receipts recorded by 29 August 2026 include useful work, a corrected overbroad rule, safe overlap coalescing, duplicate rejection and verified no-ops. No current automation cutover or cadence is established by those receipts. Verify any present installation in its runtime.

The next evidence step is a fresh-agent test of this named-Loop revision: run a real bounded outcome, accept its handoffs, verify the original task and resume from durable state. Test any requested runtime installation separately. Update this page with the results and limits; its status remains public beta.

Oddlynew PublicSign in

Referenced by