DEV Community: Fujo

We're fed up with Rust's borrow checker. It's time to break free.

Fujo — Tue, 20 Oct 2026 20:13:43 +0000

I like Rust. I also dread the moment the borrow checker says no and the compiler refuses to
explain what it assumed.

That is not a complaint about competence. Rust's borrow checker is one of the most valuable
things to happen to systems programming. It is a complaint about posture: the compiler stands
outside your program, announces a verdict, and the burden of proof lands on you. When the verdict
is wrong, there is often no receipt to inspect.

We built Loment around a different posture. It keeps the
checks; it moves the burden. This post is about what that means precisely, because "we removed the
borrow checker" would be a lie, and the interesting part is not the removal.

What Loment keeps

Loment is a systems language with a Rust-flavoured surface. It still checks the ownership
mistakes that matter most:

use after move (E006),
a mutable borrow alongside another borrow (E007),
a dangling reference (E012).

It also adds capability domains (capability disk[0..4] plus guard), compiles to a native
ELF/PE artifact with no runtime by default, and has two implementations — a Python reference and
a self-hosted one — that must emit byte-identical IR.

What it does not do is pretend to be Rust's borrow checker. The boundary is written down in
the repository: it proves three things and explicitly does not prove four others (no lifetimes, no
cross-function reasoning, no field-level moves, no branch-sensitive move sets). Keep that in mind
for the rest of this post.

From verdict to receipt

The change is a seventh choose dimension called LSPE — Loment Safety Police Espace. It does
not change any verdict. It changes what a verdict leaves behind.

With lspe_open_admin (the default), every allowance is recorded in the artifact's Potato v16
ledger: the site, the obligation, the evidence, and what is still unproved. With
lspe_close_admin, the recording is turned off; the LMS, runtime and capability decisions are
unchanged. The audit is not a second checker bolted on top — it is a ledger of the compiler's own
decisions, answerable offline.

The design document puts it more bluntly than I can:

Rust's borrow checker is a god. LSPE is a shop assistant.

A god stands outside the transaction and says "no". An assistant stands inside it, has to name the
price, and gives you a receipt. Concretely, LSPE has three outcomes instead of two:

PROVED — here is the evidence;
UNDECIDED — here is the site where my proof has a hole;
REFUTED — here is a counterexample, so this is a hard no.

"Undecided" is a first-class result. In strict mode it becomes E034; the ledger's own consistency
failures are E035–E037. The point is not that the compiler is always right. The point is that when
it is wrong, you can point at the site and the obligation instead of arguing with a verdict.

"Gentle" is a measurable claim

It is easy to say a checker is friendlier. We tried to make it falsifiable:

Same verdicts. Compile the same corpus with the audit open and closed: the set of decisions is identical. The audit changes the ledger, not the language.
No silent permit. Every allow has a source, or an explicitly recorded assumption. An allow with neither is an error in the ledger.
No overclaiming. LSPE does not claim to prove more than Rust. What it adds is accountability, not completeness. The remaining cases are UNDECIDED and labeled.

That is the sense in which it is "gentler with nearly the same safety": not that it catches
everything Rust catches, but that the same checks no longer arrive as an unaccountable verdict.

Loment also has a memory-safety ladder, lms, with seven levels and four tiers
(lms_full, lms_forensic_admin, lms_daily_admin, lms_manage_only_admin). The default is
full; writing a lower tier is a downgrade and carries _admin. The literal-out-of-range check is
E028; use-after-free is E029.

What it looks like

The defaults, written out:

module demo
choose runtime
choose lms_full
choose lspe_open_admin

capability disk_slots : disk[0..4] revocable

fn write_slot(slot: u32) -> u32 {
    guard disk_slots(slot);
    return slot;
}

fn _start() {
    let xs: [u32; 3] = [1, 2, 3];
    let i: u32 = 5;
    if i < 3 {
        xs[i] = 7;          // a runtime index: you guard it, the language does not guess
    }
    syscall4(60, 0, 0, 0);
}

Two details matter here. guard bounds the index, not the subject — it is not authorization.
And the array write is still your responsibility: Loment refuses a literal out-of-range index
at compile time (E028), but a runtime index is not silently checked.

What this does not mean

I would rather say this before the comments do:

Loment is early. 0.1.5 is the release where LSPE lands; the packaged front end is still being finished. Do not rewrite your service in it this weekend.
It is not Rust. The borrow checking is a subset. No lifetimes, no cross-function reasoning, no field-level moves, no branch-sensitive move sets.
"No receipt" is not the same as "no bug". LSPE records the compiler's decisions; it does not make the compiler omniscient.
Defaults are not free. lms_full is the default and it changes the emitted artifact (inline bounds checks on alloc(<const>)-derived accesses). That exception is documented, not hidden.
The benchmark is a pilot. We measured an LLM agent writing Loment from the guide alone: three tasks, one attempt each, Rust and Python as controls. It is a direction, not a confidence interval.

The reason I care about the receipt is not abstract. Rust's own tracker has a soundness bug
(#164250) where an obligation was not rechecked after substitution, and it stayed invisible for
years — not because Rust's team is careless, but because a verdict-only compiler leaves nothing
to audit when the verdict is wrong. LSPE's answer to that shape is a record with a site id
(Q004 stale_wf), readable offline. That is the part I want other language designers to steal,
whether or not they like Loment.

Try it, then tell us where the receipt is wrong

Source: https://github.com/Loment-Lang/Loment

We are not asking you to believe the slogan. We are asking you to compile something, read the
ledger, and tell us which line is wrong. That is the whole point of moving the burden.

Disclosure: I'm one of Loment's authors. This draft was prepared with an AI assistant and
reviewed before publishing.

Give Your Agent a Mistake Once — ORP Turns AI Agent Failures into Tested Lessons

Fujo — Thu, 11 Jun 2026 21:29:34 +0000

Originally published on GitHub: https://github.com/Fujo930/ORP

Tracing tells you what your AI agent did. But it doesn't tell you what it learned.

After building and debugging coding agents for months, I noticed a pattern: the same failure modes recur across runs, across tasks, and sometimes across agents. A coding agent misses the anonymous-user test path. Another agent modifies the wrong file. A third keeps running the same failing command expecting different results.

Each failure leaves a trace. But traces don't become experience. Until now.

Introducing ORP

ORP (Open Reflection Protocol) is an open experience layer for AI agents, built on OpenTelemetry. It converts agent traces into three executable artifacts:

Lesson — retrievable, scope-scoped advice ("Test anonymous, authenticated, and forbidden paths")
Eval — regression test that reproduces the failure
Guardrail — preventative rule

Each Lesson goes through a lifecycle: candidate → active → under_review → deprecated → rejected. Only active lessons are retrievable, and every lesson's effect is measured before it stays active.

Evidence-first design

ORP doesn't claim to capture an agent's "real thinking." It distinguishes:

Observations — tool output, test results, exit codes
Claims — what the agent says (diagnoses, confidence, "the fix is complete")

Claims are never automatically treated as ground truth. They get challenged.

How it works

# 1. Wrap any agent
orp wrap -- python my_agent.py

# 2. ORP captures the run, challenges unproven claims,
#    compiles a Lesson + regression Eval
orp learn latest

# 3. Deliver lessons to future runs via MCP
orp mcp-server --transport stdio

# 4. Before/after comparison
orp diff exp_before exp_after

The MCP server exposes three tools:

Tool	When to call
`orp_retrieve_lessons(task, limit)`	Start of a new task
`orp_acknowledge_lesson(lesson_id)`	After receiving a lesson
`orp_report_outcome(lesson_id, outcome)`	After applying the lesson

Experimental results

We ran 10 common coding-agent failure patterns, 5 trials each (100 total runs):

Metric	Without ORP	With ORP	Change
Task success rate	14%	100%	+86%
Repeat failure rate	high	0%	100% reduction
Lesson application	—	100%	—
Eval validity	—	85%	—

The Go/No-Go assessment: 4/4 checks passed.

Design principles

Evidence first — conclusions must cite evidence; unsubstantiated claims are flagged
Executable reflection — lessons compile to evals and guardrails, not just text
Outcome-based — lesson value is determined by whether it actually improves results
OpenTelemetry-native — extends existing trace infrastructure instead of replacing it
Default private — all data stays local, de-identified, no prompt/tool output uploaded
Lesson lifecycle — candidate → active (verified) → under_review (conflict) → deprecated → rejected

What's next

Real LLM experiments — running the 10-task suite with actual LLM agents via API
Framework integrations — native hooks for AG2, LangGraph, OpenAI Agents SDK
MCP ecosystem — ORP as a standard MCP server for any MCP-compatible agent

Try it

pip install open-reflection-protocol

# Run the complete demo
uv run python demo/orp_demo.py

# Run the experiment suite
uv run python exps/runner.py

GitHub: Fujo930/ORP
License: MIT
Dependencies: pydantic (only)

ORP is built on the insight that agent failures don't have to repeat. Give your agent a mistake once. ORP helps it prove that it learned.