In June I wrote that LLooMA could finally act: a community of independent hosts was making real tool decisions, with a grammar under every output and a safety net under every step.

What I did not write is that the loop doing all of that acting was our own first-generation engine. Every piece of it (deciding, validating, retrying, reviewing, keeping the transcript straight, falling back) was purpose-built inside the orchestrator, and every piece of it was ours alone to carry.

This month we graduated it. LLooMA 2.0 now runs on The Standard Agent, an open-source, spec’d, conformance-tested agent framework, and the orchestrator kept every behavior it had, got measurably faster, and shed a whole category of code we no longer have to carry alone.

This post is the story of that transition: why we made it, how the seam works, and what going live taught both sides.

0/ The Loop Is Not the Product

Here is the realization that started this.

LLooMA’s value is not its agentic loop. LLooMA’s value is everything around the loop: knowing what models live on the network and what they are good at, racing community hosts before ever touching the core, compiling grammars so small models can’t emit garbage, gating by capability, rewarding the host that did the work. That combination is the product. That is where our differentiation lives.

The loop itself (decide, authorize, act, observe, repeat, with guardrails) is a general infrastructure problem. And general infrastructure does not belong in product code once you have a framework you can trust, because carrying it yourself has a compounding cost:

The first-generation loop: one orchestrator box containing decide, validate, retry, review, transcript, tools, and fallback, every concern wired directly to every other concern

When one team carries the whole loop, every concern is load-bearing on every other concern. Hardening the retry path means re-testing the review path. Fixing the transcript means re-checking the fallback. This engine was proven; it carried LLooMA in production for months. But every improvement cost a full lap around the whole machine.

The loop is not the product. Owning it was all cost and no moat.

1/ A Framework With a Spec

The Standard Agent is an agent framework built under The Standard, the same engineering discipline behind the rest of my open-source work. Three properties made it the right foundation, and I would want all three from any framework before handing it my loop:

It is spec’d. The behavior lives in a written specification, independent of the C# implementation. Anyone can build a conforming agent in any language. The loop’s rules are not folklore in someone’s head, mine included.

It is conformance-tested. A public suite of behavioral vectors, across graded profiles, that an implementation must pass. Every vector is proven able to fail, so a green run means something. When I claim the framework authorizes every irreversible act before performing it, there is a test that goes red if it ever stops being true.

It is disciplined about the dangerous parts. Budgets that bound every run. A perimeter that authorizes each act before it happens, not a log entry after. Run-once semantics so a retried turn never performs the same side effect twice. A review pass over answers before they ship. All of it framework-owned, all of it spec’d.

That last point is the honest reason to adopt a framework at all: not to save typing, but to stop being the only line of defense.

2/ One Interface: Plug In the Routing Brain

The migration question was never “can the framework do what LLooMA does?” It was: is there a seam exactly the width of what makes LLooMA special?

There is. The Standard Agent lets you bring your own brain: the component that, given the conversation and the tools, produces the next decision. Everything upstream and downstream of that decision (the loop, the perimeter, the budgets, the review) is the framework’s. Everything inside it is yours.

So the entire network (host selection, capability gating, grammar shipping, the decentralization-first racing, the core fallback) became one brain, behind one interface:

Rebuilt on The Standard Agent: the orchestrator is now a thin coordinator embedding The Standard Agent (loop, perimeter, budgets, review) connected through one seam to LLooMA's routing brain, which tries community hosts first and falls back to PeerLLM core on any miss

Read that diagram against the first one. The general machinery has moved out of our code entirely. Not rewritten in place, rehomed, to a framework whose whole job is to carry it. The orchestrator is now a thin coordinator: it translates your OpenAI-standard request into the framework’s terms, embeds an agent, and renders the answer back. The routing brain still tries the people’s network first and only falls back to PeerLLM’s core on a miss, exactly as before. Decentralization first and privacy by fragmentation did not move an inch; they just stopped sharing a room with the retry logic.

And because rewiring a production brain is not a leap you take blind, the old loop is still there, one committed switch away, and both paths answered the same probes before the new one took the traffic.

Keep what is yours. Inherit what is everyone’s. Make the boundary one interface wide.

3/ Going Live Hardened Both Sides

This is my favorite part, because nobody puts it on the brochure: re-platforming onto a disciplined loop is a diagnostic event. A framework with opinions will disagree with your code, and some of those disagreements are hardening opportunities you would never otherwise see.

Two examples from this migration, both found in production traffic within a day of the cutover.

The tool schema that was never really a schema. One of the built-in tools on the new path had been advertising its parameters in a shape that was not a strict JSON-Schema object. Lenient models shrug at that and cope, which is exactly how a defect like this survives: nothing strict had ever been asked to read it. The moment production traffic put that tool in front of a strict provider, the entire turn was rejected, loudly, with the tool’s name in the error. We fixed it at the source and added a framework-level test that makes that class of mistake visible, and the request boundary now salvages near-miss schemas defensively instead of trusting every tool to be perfect.

The blind final answer. A community host, asked to wrap up an agentic conversation, occasionally produced a confident-sounding non-answer: the model equivalent of a shrug in a suit. Rebuilding forced us to look at that moment squarely, and the new path now refuses it outright: a host’s final word in a conversation that already has real content must actually engage with that content, or the turn quietly falls back to the core decider and the user never sees the shrug.

Neither finding came from a test written in advance. Both came from a stricter loop turning silent tolerance into a visible signal.

A framework with opinions is a diagnostic instrument. The disagreements are the findings.

And notice which direction the fixes flowed: into the framework, not just into LLooMA. This street runs both ways. The framework gives LLooMA a loop it no longer has to carry alone; LLooMA gives the framework the one thing no framework can give itself: a live production system, with real users and real traffic, exercising it against realities no test bench would ever stage. Every conforming implementation, in any language, now inherits what this deployment taught.

4/ Loop on the Server, Yield to the Caller: Now in the Spec

In June I described the distinction that lets one endpoint power both a “search the web and answer” turn and a full coding-agent session: server-side tools loop, client-side tools yield.

Back then, that distinction lived in orchestrator code. Now it is a first-class concept in The Standard Agent’s spec, and that promotion is the deepest part of this migration, because it means the idea survived translation out of my codebase and into a document anyone can implement.

Here is one turn through the loop as the framework sees it:

One turn through the loop: you send prompt plus tools plus schema, the request is resolved once, the loop decides and acts, server-side tools run and loop again, a caller tool pauses the run and yields back to you, and the final answer arrives in your schema

Three ideas ride that picture:

  • Resolve once. Your request can carry its own response schema, its own tools, its own generation settings. The framework reconciles them with the agent’s configuration exactly once, at the boundary (configured wins, then the request, then defaults), and the whole run obeys that single resolution. No mid-run surprises.
  • Loop on the server. Tools the network owns (like web_search) run inside the loop, invisible to you, each pass through the same perimeter and budget.
  • Yield to the caller. A tool only you can run (your editor’s read_file, your app’s database) is not something the agent pretends to execute. The run pauses and hands you the pending call; you execute it, post the result, and the run resumes where it stopped. The framework already had the shape for “the run pauses; something outside must act and report back”: it was built for human approval. Your editor turned out to be the same shape with a different authority.

That last one matters for the network’s principles too: a host deciding a turn still never learns who you are, and the framework, rather than orchestrator-local code, now enforces the pause-and-resume boundary around your private tools.

5/ Faster, Not Just Cleaner

I expected to pay a toll for the abstraction. We measured the opposite.

Probing both paths on the same day, against the same production network, on the same prompts: the Standard-Agent path was faster on every single probe. The heaviest turn in that probe set ran about 3× faster end-to-end. Tool-result continuation turns (the bread and butter of a coding agent session, where your editor posts a tool result and waits for the next decision) came back about 3.5× faster in that probe set.

No network got faster that day. What changed is that the new path wastes less: a leaner conversation shape, fewer redundant passes, and a loop that does exactly what the spec says and nothing else. It turns out the defensive weight a first-generation engine accretes while it is learning the territory is not free at request time either.

These are single-day probe numbers, not a benchmark paper. And the next round of performance work (true end-to-end streaming through the framework, tighter budgets on host misses) now happens once, in the framework, and LLooMA inherits it. That is the real speed story: not this month’s numbers, but who pays for next month’s.

6/ What This Buys

Stepping back, this is what the transition actually purchased:

  • The moat got purer. Everything left in the orchestrator is genuinely ours: the network, the routing, the grammar compiler, the economics. The generic machinery is gone from our books.
  • Safety got institutional. Budgets, authorization-before-action, run-once, review: enforced by a spec’d, conformance-tested framework, not by my memory of my own code.
  • Findings got louder. Strictness turned two silently-tolerated gaps into fixed, tested, closed issues.
  • The street runs both ways. LLooMA is better for standing on the framework, and the framework is better for having carried LLooMA in production. Real traffic is the reviewer no test suite can replace.
  • The behavior became portable. The loop LLooMA runs is now a public specification. A host tool, a rival orchestrator, a Python implementation: anyone can build against the same contract and know exactly what it promises.
  • And it got faster, which I will happily take as a bonus for doing the right thing.

A first-generation loop is how every serious agentic system starts, and ours deserves to be remembered well; you cannot spec what you have not yet survived. But there is a moment when the loop stops being where you learn and starts being what you carry alone. For LLooMA, that moment was this summer.

And this crossing is the first of many. The plan from here is deliberate: build more of PeerLLM’s machinery as Standard-compliant open-source tools, prove each one in the open, then incorporate it into the platform, the same road the loop just traveled. Followed to its end, that road arrives somewhere worth saying out loud: the entirety of PeerLLM, the platform itself included, running on Standard-compliant open-source software available to everyone.

The network still decides. The community still races. The core still catches.

Only now, the loop underneath it all has a spec, a test suite, and a community of its own.

PeerLLM is experimental software provided as is. The Standard Agent is an open-source framework licensed under the TSSL. Product and model names referenced here belong to their respective owners and are mentioned only to describe interoperability; their mention does not imply affiliation or endorsement.

Hassan