diff --git a/site/ai-agent-no-progress/index.html b/site/ai-agent-no-progress/index.html index 73c2218..de2ef99 100644 --- a/site/ai-agent-no-progress/index.html +++ b/site/ai-agent-no-progress/index.html @@ -64,6 +64,6 @@

Why fixed token caps are not enough

A budget cap can stop a run after

Install MARGINAL in Shadow Mode, inspect what your agent actually repeats, and contribute traces that make the governor harder to fool.

★ Star MARGINAL on GitHubExplore more guides
- +

Deep dive: detect no-progress without reading prompts

The Research & Engineering article explains the evidence model, privacy boundary, counterexamples and why repetition alone is not enough.

Read the technical article →
diff --git a/site/assets/blog/no-progress-16x9.png b/site/assets/blog/no-progress-16x9.png new file mode 100644 index 0000000..1e481f6 Binary files /dev/null and b/site/assets/blog/no-progress-16x9.png differ diff --git a/site/assets/blog/no-progress-1x1.png b/site/assets/blog/no-progress-1x1.png new file mode 100644 index 0000000..fbe4199 Binary files /dev/null and b/site/assets/blog/no-progress-1x1.png differ diff --git a/site/assets/blog/no-progress-4x3.png b/site/assets/blog/no-progress-4x3.png new file mode 100644 index 0000000..f9a7931 Binary files /dev/null and b/site/assets/blog/no-progress-4x3.png differ diff --git a/site/assets/blog/powerless-governor-16x9.png b/site/assets/blog/powerless-governor-16x9.png new file mode 100644 index 0000000..ad912c4 Binary files /dev/null and b/site/assets/blog/powerless-governor-16x9.png differ diff --git a/site/assets/blog/powerless-governor-1x1.png b/site/assets/blog/powerless-governor-1x1.png new file mode 100644 index 0000000..e60e220 Binary files /dev/null and b/site/assets/blog/powerless-governor-1x1.png differ diff --git a/site/assets/blog/powerless-governor-4x3.png b/site/assets/blog/powerless-governor-4x3.png new file mode 100644 index 0000000..27084e9 Binary files /dev/null and b/site/assets/blog/powerless-governor-4x3.png differ diff --git a/site/blog.css b/site/blog.css new file mode 100644 index 0000000..329f8e2 --- /dev/null +++ b/site/blog.css @@ -0,0 +1,68 @@ +/* MARGINAL Research & Engineering editorial layer. Uses existing site tokens. */ +.blog-hero{padding:88px 0 58px;max-width:960px} +.blog-hero h1{margin:0;font-size:clamp(3rem,7vw,6rem);line-height:.94;letter-spacing:-.055em} +.blog-hero h1 span{display:block;color:var(--acid)} +.blog-intro{max-width:780px;color:var(--muted);font-size:1.08rem;line-height:1.75} +.blog-grid{display:grid;grid-template-columns:repeat(2,minmax(0,1fr));gap:16px} +.blog-card{display:flex;flex-direction:column;min-height:100%;border:1px solid var(--line);border-radius:18px;background:var(--panel);overflow:hidden} +.blog-card img{width:100%;height:auto;aspect-ratio:16/9;object-fit:cover;border-bottom:1px solid var(--line)} +.blog-card-body{display:flex;flex-direction:column;gap:12px;padding:24px;flex:1} +.blog-card h2,.blog-card h3{margin:0;letter-spacing:-.025em;line-height:1.1} +.blog-card p{margin:0;color:var(--muted);line-height:1.65} +.blog-card-meta,.article-meta{display:flex;gap:10px;flex-wrap:wrap;color:var(--muted);font:700 .72rem var(--mono);letter-spacing:.05em;text-transform:uppercase} +.blog-card .text-link{margin-top:auto;padding-top:8px;font-weight:800;text-decoration:none} +.editorial-note{margin-top:26px;padding:20px;border:1px solid var(--line);border-radius:14px;background:rgba(255,255,255,.02);color:var(--muted);line-height:1.65} +.article-header{padding:38px 0 34px;max-width:980px} +.article-kicker{color:var(--acid);font:800 .75rem var(--mono);letter-spacing:.11em;text-transform:uppercase} +.article-header h1{margin:12px 0 18px;font-size:clamp(2.9rem,7vw,5.8rem);line-height:.96;letter-spacing:-.055em} +.article-deck{max-width:820px;margin:0;color:var(--muted);font-size:clamp(1.08rem,2vw,1.28rem);line-height:1.65} +.article-byline{display:flex;align-items:center;justify-content:space-between;gap:18px;flex-wrap:wrap;margin-top:24px;padding-top:20px;border-top:1px solid var(--line)} +.article-byline strong{display:block} +.article-byline span{color:var(--muted);font-size:.9rem} +.article-figure{max-width:1100px;margin:0 auto 40px;padding:0 24px} +.article-figure img{display:block;width:100%;height:auto;border:1px solid var(--line);border-radius:18px;background:var(--panel)} +.article-figure figcaption{margin-top:10px;color:var(--muted);font-size:.82rem;line-height:1.5} +.article-layout{display:grid;grid-template-columns:minmax(0,780px) minmax(210px,280px);gap:56px;align-items:start} +.article-body{font-size:1.03rem;line-height:1.8} +.article-body>p:first-of-type{font-size:1.16rem;color:var(--text)} +.article-body p,.article-body li{color:var(--muted)} +.article-body strong{color:var(--text)} +.article-body h2{margin:58px 0 16px;font-size:clamp(2rem,4vw,3.35rem);line-height:1.03;letter-spacing:-.04em} +.article-body h3{margin:36px 0 10px;font-size:1.45rem;line-height:1.2} +.article-body a{font-weight:700} +.article-body ul,.article-body ol{padding-left:1.35rem} +.article-summary{margin:10px 0 34px;padding:22px;border:1px solid rgba(168,255,99,.35);border-radius:16px;background:linear-gradient(145deg,rgba(168,255,99,.07),rgba(255,255,255,.01))} +.article-summary h2{margin:0 0 12px;font-size:1.35rem;letter-spacing:-.02em} +.article-summary ul{margin:0;padding-left:1.1rem} +.article-summary li{margin:7px 0;color:var(--text)} +.article-toc{position:sticky;top:92px;padding:18px;border:1px solid var(--line);border-radius:14px;background:var(--panel)} +.article-toc strong{font:800 .73rem var(--mono);letter-spacing:.08em;text-transform:uppercase} +.article-toc ol{margin:12px 0 0;padding-left:1.1rem} +.article-toc li{margin:8px 0;color:var(--muted);font-size:.86rem;line-height:1.35} +.article-toc a{text-decoration:none} +.article-code{margin:24px 0;padding:20px;border:1px solid rgba(168,255,99,.3);border-radius:14px;background:#090d0b;overflow:auto} +.article-code code{display:block;color:#dcffca;font:500 .86rem/1.7 var(--mono);white-space:pre-wrap} +.article-callout{margin:28px 0;padding:22px 24px;border-left:3px solid var(--acid);background:rgba(168,255,99,.055);border-radius:0 14px 14px 0} +.article-callout p{margin:0!important;color:var(--text)!important} +.article-warning{border-left-color:#ffb45c;background:rgba(255,180,92,.06)} +.article-table-wrap{overflow-x:auto;margin:24px 0} +.article-table{width:100%;border-collapse:collapse;font-size:.92rem} +.article-table th,.article-table td{padding:13px 14px;border:1px solid var(--line);text-align:left;vertical-align:top} +.article-table th{color:var(--text);background:rgba(255,255,255,.03)} +.article-table td{color:var(--muted)} +.article-source{margin:38px 0;padding:18px 20px;border:1px solid var(--line);border-radius:14px} +.article-source strong{display:block;margin-bottom:8px} +.article-source p{margin:0;color:var(--muted);font-size:.9rem} +.article-cta{margin-top:54px;padding:30px;border:1px solid rgba(168,255,99,.36);border-radius:18px;background:linear-gradient(145deg,rgba(168,255,99,.08),var(--panel))} +.article-cta h2{margin:0 0 12px;font-size:2rem} +.article-cta p{margin:0 0 18px} +.related-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:14px} +.related-grid a{display:block;padding:20px;border:1px solid var(--line);border-radius:14px;background:var(--panel);text-decoration:none} +.related-grid strong{display:block;margin-bottom:6px} +.related-grid span{display:block;color:var(--muted);font-size:.88rem;line-height:1.45} +.question-list details{border-top:1px solid var(--line);padding:16px 0} +.question-list details:last-child{border-bottom:1px solid var(--line)} +.question-list summary{cursor:pointer;font-weight:800;color:var(--text)} +.question-list details p{margin-bottom:0} +@media(max-width:900px){.article-layout{grid-template-columns:1fr}.article-toc{position:static;order:-1}.related-grid{grid-template-columns:1fr}} +@media(max-width:720px){.blog-grid{grid-template-columns:1fr}.blog-hero{padding:60px 0 44px}.article-header{padding-top:24px}.article-figure{padding:0 16px}.article-body{font-size:1rem}.article-byline{align-items:flex-start}} diff --git a/site/blog/detecting-no-progress-without-reading-prompts/index.html b/site/blog/detecting-no-progress-without-reading-prompts/index.html new file mode 100644 index 0000000..6059e98 --- /dev/null +++ b/site/blog/detecting-no-progress-without-reading-prompts/index.html @@ -0,0 +1,92 @@ + + +Detect AI Agent No-Progress Without Reading Prompts | MARGINAL + + + + + + + + +
+
MARGINAL / Research & Engineering / Detecting No-Progress in AI Agents Without Reading Prompts
+

AI agent observability

Detecting No-Progress in AI Agents Without Reading Prompts

A technical model for detecting AI coding-agent no-progress loops from action identity, outcomes, state and evidence—without treating raw prompts as required telemetry.

SignalLayer LabsEngineering notes from the open-source MARGINAL project
·Reviewed against public MARGINAL docs
+
Action identity, outcomes, workspace state and evidence used to distinguish repeated activity from no-progress
Action identity, outcomes, workspace state and evidence used to distinguish repeated activity from no-progress. Illustration created for this MARGINAL engineering article.
+
+

A coding agent can execute a tool successfully and still make no progress. That sounds obvious until you try to turn it into a runtime rule. A repeated file read can be waste, but it can also be verification after a write. A repeated test can be a loop, but it can also confirm a flaky failure. Even an unchanged workspace does not prove that an action was useless if the action produced new evidence.

+

In short

  • Repetition is not the signal. The stronger signal is repeated successful work with unchanged observable state and no new evidence.
  • Raw prompts do not have to be the primary governance input. A runtime can reason from derived action identity, structured outcomes, workspace state and evidence deltas.
  • Unknowns should reduce confidence. Failure, ambiguous outcomes, state changes and incomplete coverage are reasons to fail open—not reasons to invent certainty.
  • Detection is not enforcement. Seeing a no-progress candidate does not automatically justify blocking the next action.
+

Repetition is not the same as no-progress

+

Start with the smallest counterexample. An agent reads config.py, edits it, then reads it again. The tool family and target may be identical, yet the two reads have different jobs: the first establishes state; the second verifies a change. Any governor that simply counts duplicate calls will eventually punish useful verification.

+
read config.py → establish evidence +edit config.py → workspace changes +read config.py → verify the change
+

Now remove the write:

+
read config.py → success, evidence acquired +read config.py → success, same state +read config.py → success, same state, no new evidence +read config.py → another no-progress candidate?
+

The interesting question is no longer “did this call appear before?” It is “what changed that makes another identical successful call worth running?”

+

A useful operational approximation:
same semantic action + successful outcome + unchanged observable workspace state + no new evidence → no-progress repetition candidate

+

The final word matters. It is a candidate, not a verdict. The runtime still has to account for what it cannot observe.

+

Why not just read the prompt?

+

The obvious design is to inspect the conversation and ask a model whether the agent looks stuck. That can be useful in systems where semantic intent is the product. It is a poor requirement for a minimal runtime governor.

+

Prompts and transcripts often carry the most sensitive material in an agent session: source fragments, customer context, repository names, commands, credentials accidentally pasted into chat, or proprietary reasoning context. Making that content mandatory governance telemetry expands the trust boundary before the governor has proved that it needs the data.

+

There is also an architectural cost. If every decision about waste requires another model call, the control plane introduces its own latency, cost and failure mode. A governor trying to reduce unnecessary work should be able to answer narrow questions without always paying for a second inference path.

+
agent action + ↓ +model judge reads transcript + ↓ +judge decides whether the agent is wasting work + ↓ +control decision
+

That architecture is not inherently wrong. It is simply stronger and more invasive than necessary for a class of no-progress cases that can be observed from effects.

+

Observe effects, not private thoughts

+

A narrower runtime model can work with four categories of evidence:

+
SignalQuestionWhy it matters
Semantic action identityIs this meaningfully the same action and target?Literal tool names differ across engines and wrappers.
OutcomeDid the action actually succeed?Failures and unknown outcomes should not be counted as completed duplicate work.
Observable stateDid the workspace or relevant state change?A changed state can make an otherwise repeated action useful again.
Evidence deltaDid the action produce new usable evidence?Useful verification can occur even when the workspace itself is unchanged.
+

The point is not that these four signals solve every loop. They do not. The point is that they define an auditable surface: a reviewer can inspect why the governor believed a repetition was low-value without needing the full conversation.

+

Semantic identity is harder than string equality

+

Two calls can look different and still represent the same operation. A Codex adapter might report Read(path=...) while another engine reports read_file(file_path=...). Conversely, two calls to a generic search tool might carry materially different queries and therefore different evidence value.

+

This is why MARGINAL keeps adapter logic separate from the provider-neutral governance core. The adapter normalizes native lifecycle events into a smaller action model; the core reasons over the normalized identity, outcome and evidence. The integration documentation explicitly requires adapters to declare capabilities and classify data before persistence rather than smuggling engine-specific assumptions into policy.

+

Inspect the integration contract in the repository →

+

State is what separates verification from loops

+

A fixed “three repeats means stop” rule is attractive because it is easy to explain. It is also easy to break. Consider three sequences:

+
SequenceWhat changed?Governance interpretation
read → write → readWorkspace changedThe second read may verify the write; repetition pressure should reset.
test → edit → testImplementation changedThe second test has new causal context.
read → read → readNothing observable; no new evidenceA no-progress candidate becomes more plausible.
+

The same principle applies beyond files. A repeated status poll may be useful if time itself is expected to change the result. A repeated network call may carry server-side state the local governor cannot see. Those action families should not be treated as equivalent to a deterministic local read merely because the surface syntax repeats.

+

Unknown outcomes should weaken authority

+

A common failure in control systems is to turn missing data into implied success. If an integration cannot prove whether an action succeeded, the governor should not promote that event into positive evidence for blocking a future action.

+
known success + same state + no new evidence + → stronger no-progress evidence + +failure or unknown outcome + → do not escalate authority
+

This is visible in MARGINAL's current engine boundaries. Claude Code can report success and failure through distinct hook events, while OpenCode exposes weaker outcome evidence for many tools. The project therefore labels both integrations Observe-only and keeps unknown outcomes unknown instead of laundering them into confidence.

+

That leads to a separate question: when should a detector be allowed to become an enforcer?

+

What “without reading prompts” does—and does not—mean

+

It would be misleading to turn this design into a blanket privacy claim. A runtime can avoid using raw prompts and source as governance evidence while other systems around it—an IDE, shell history, agent vendor, plugin callback or custom logger—still record sensitive material.

+

MARGINAL's privacy model therefore classifies fields rather than declaring telemetry “safe” by default. Its strict SAFE_TELEMETRY profile removes free text and metadata, pseudonymizes selected identifiers with field-separated HMACs and generalizes timestamps. The documentation also says the uncomfortable part explicitly: pseudonymization is not anonymization.

+

Read the privacy profiles and limitations →

+

Detection and enforcement are different problems

+

A detector can be useful while still being wrong often enough that it should never block. That is why MARGINAL separates a recommendation from authority. New integrations begin without earned permission to interfere. A no-progress candidate can be recorded, reviewed and falsified before it becomes an enforcement rule.

+
OBSERVE + ↓ +record recommendations and outcomes + ↓ +review false stops and coverage + ↓ +EARN narrow authority where the adapter can truly intercept + ↓ +demote when evidence or conditions drift
+

This distinction also prevents capability inflation. The current Codex integration is documented as Tool Enforcement, not Full Compute Enforcement. Claude Code and OpenCode are Observe-only. A prompt instruction or advisory skill is not presented as enforced interception.

+

The best contribution is a counterexample

+

If this model is useful, it should survive hostile examples. The most valuable trace is not another obvious infinite loop. It is a case where repeated successful work looks low-value from the outside but is actually useful.

+

Examples worth testing include:

+
  • a verification read whose value is not represented in workspace state;
  • a tool whose server-side state changes while local state stays fixed;
  • a flaky test that must be repeated to estimate reliability;
  • two calls that normalize to the same action but carry materially different evidence;
  • a state fingerprint that misses a meaningful change in a large monorepo.
+

MARGINAL has a public challenge specifically for this: find useful verification the governor could mistake for waste. A strong result can be “the governor already fails open correctly.” The objective is to tighten the falsification boundary, not manufacture a win.

+

Questions developers usually ask

+
Can an AI agent loop be detected from duplicate tool calls alone?

Not reliably. Duplicate calls are a useful symptom, but a repeated action can be legitimate verification after new state or evidence. Treat repetition as one input, not the conclusion.

Does no-progress detection require storing prompts?

No. Some no-progress cases can be evaluated from derived action identity, structured outcomes, observable state and evidence deltas. That does not mean every loop can be solved without semantic context.

Should a no-progress detector automatically block the next call?

No. Detection quality and enforcement authority are separate concerns. A conservative system can remain advisory until local evidence supports a narrow intervention boundary.

+

See the mechanism before installing it.

The interactive demo uses a deterministic trace to show the difference between repeated activity and observable progress. No provider telemetry is presented as benchmark evidence.

Open the interactive demo →Inspect MARGINAL on GitHub ↗
+
Editorial method

This article was developed with AI-assisted drafting and reviewed against MARGINAL's public code, documentation and evidence available on Aug 19, 2026. Product claims are deliberately limited to what those public sources support; unsupported performance claims are excluded.

+
+

Continue reading

Related MARGINAL material.

No-progress loopsThe concise mechanism and conservative detection boundary.Repeated tool callsSeparate useful verification from same-state repetition.Why governors should start powerlessEvidence before authority in runtime governance.
+ diff --git a/site/blog/feed.xml b/site/blog/feed.xml new file mode 100644 index 0000000..fdbca8c --- /dev/null +++ b/site/blog/feed.xml @@ -0,0 +1,12 @@ + + + MARGINAL Research & Engineering + https://signallayerlabs.github.io/Marginal/blog/ + + + 2026-08-19T13:14:00+02:00 + SignalLayer Labshttps://github.com/SignalLayerLabs + Evidence-first engineering notes on AI coding-agent no-progress detection and runtime governance. + Detecting No-Progress in AI Agents Without Reading Promptshttps://signallayerlabs.github.io/Marginal/blog/detecting-no-progress-without-reading-prompts/2026-08-19T13:14:00+02:002026-08-19T13:14:00+02:00A technical model for detecting AI coding-agent no-progress loops from action identity, outcomes, state and evidence—without treating raw prompts as required telemetry. + Why an AI Agent Governor Should Start Powerlesshttps://signallayerlabs.github.io/Marginal/blog/why-ai-agent-governor-should-start-powerless/2026-08-19T13:14:00+02:002026-08-19T13:14:00+02:00Installing an AI agent governor should not automatically grant blocking authority. A safer runtime model starts in Shadow Mode and earns narrow enforcement from local evidence. + diff --git a/site/blog/index.html b/site/blog/index.html new file mode 100644 index 0000000..7707479 --- /dev/null +++ b/site/blog/index.html @@ -0,0 +1,41 @@ + + + + + +MARGINAL Research & Engineering — AI Agent Governance + + + + + + + + + + + + + + + + + + + + + + + +
+
+
MARGINAL / Research & Engineering
+

Research & Engineering

Engineering notes forAI agent governance.

Long-form technical writing from the open-source MARGINAL project. We focus on the mechanics that can be inspected: no-progress detection, runtime evidence, privacy boundaries, false stops and the conditions under which a governor should—or should not—interfere with an agent.

+

Latest

Start with the failure mode, then inspect the mechanism.

Each article separates what the runtime can observe from what it can infer, and links product claims back to public code, documentation or evidence.

+ + +
Editorial scope. This publication describes engineering work behind MARGINAL. Product behavior is checked against the public implementation and documentation at publication time. Negative, ambiguous and unsupported outcomes are kept explicit rather than rewritten into performance claims.
+

Explore the system

From search intent to inspectable evidence.

No-progress loopsDefinition, mechanism and conservative detection boundary.Repeated tool callsHow to separate useful verification from same-state repetition.Interactive demoWatch the deterministic no-progress mechanism before installing anything.
+
+ + diff --git a/site/blog/why-ai-agent-governor-should-start-powerless/index.html b/site/blog/why-ai-agent-governor-should-start-powerless/index.html new file mode 100644 index 0000000..5d6d2c3 --- /dev/null +++ b/site/blog/why-ai-agent-governor-should-start-powerless/index.html @@ -0,0 +1,106 @@ + + +Why AI Agent Governors Should Start Powerless | MARGINAL + + + + + + + + +
+
MARGINAL / Research & Engineering / Why an AI Agent Governor Should Start Powerless
+

Runtime governance

Why an AI Agent Governor Should Start Powerless

Installing an AI agent governor should not automatically grant blocking authority. A safer runtime model starts in Shadow Mode and earns narrow enforcement from local evidence.

SignalLayer LabsEngineering notes from the open-source MARGINAL project
·Reviewed against public MARGINAL docs
+
Shadow Mode, local evidence, promotion and demotion shown as the path from observation to narrow AI agent enforcement
Shadow Mode, local evidence, promotion and demotion shown as the path from observation to narrow AI agent enforcement. Illustration created for this MARGINAL engineering article.
+
+

Installing a governor beside an autonomous coding agent creates a second system that can make consequential decisions. If the governor can block tools, it can also block the exact verification, read or retry that would have completed the task. That means “turn the guardrail on” is not a neutral configuration change. It is a transfer of authority.

+

In short

  • Installation is not evidence. A new governor has no local track record for this repository, engine version, workflow or action family.
  • Observation and authority should be separate. Shadow Mode can collect falsifiable evidence without changing the agent's next action.
  • Trust should be narrow and reversible. Evidence from one engine or repository should not silently authorize another, and drift should remove authority.
  • Fail-open is contextual, not universal. It is a conservative choice for a no-progress efficiency governor; security authorization controls may rationally choose different failure semantics.
+

The governor is another source of failure

+

Agent governance is often drawn as a simple control relationship: user, agent, guardrail. That picture hides the fact that the guardrail has its own implementation bugs, blind spots and assumptions.

+
USER + ↓ +AGENT + ↓ +GOVERNOR + +The governor can now be wrong too.
+

A runtime governor can misclassify useful verification as waste. It can receive incomplete hooks after an engine update. It can normalize two distinct actions into the same identity. It can believe state is unchanged because its fingerprint missed the relevant part of a large workspace. It can be perfectly correct on one integration and unsafe on another.

+

Once a control plane can deny work, those errors are no longer reporting errors. They are behavioral changes to the agent.

+

Installation should not equal authority

+

Most permission systems assume the operator already knows what the software should be allowed to do. Agent governors have a different problem: the thing they need to know—whether their intervention policy is safe and useful in this local workload—often cannot be established before observation.

+

At install time, the governor usually has no evidence about:

+
  • how this repository uses repeated reads or tests;
  • which lifecycle events the current engine version reliably exposes;
  • whether workspace-state evidence covers the relevant changes;
  • how often a recommendation would have been a harmful false stop;
  • the runtime overhead introduced by the governor itself.
+

Installation proves only that the software is present. It does not prove that intervention is justified.

+

Shadow Mode turns predictions into testable claims

+

The simplest way to separate observation from authority is Shadow Mode. The governor evaluates the proposed action, records what it would recommend, but does not change what the agent actually does.

+
agent proposes action + ↓ +governor evaluates evidence + ↓ +agent action is still allowed + ↓ +reality reveals whether the recommendation was justified
+

This is more than a “safe default.” It creates counterfactual evidence. If the governor predicts that another identical read will produce no progress, Shadow Mode lets the read happen. The outcome can then weaken or strengthen the rule.

+

Did workspace state change? Did new evidence appear? Was the action actually successful? Did a verifier later show that the repetition mattered? A recommendation that cannot survive those questions should not become authority.

+

Earned enforcement should be local and narrow

+

Once enough local evidence exists, the control problem changes. The question is no longer “is this policy enabled?” but “under exactly which conditions has this policy earned the right to interfere?”

+
SHADOW + ↓ +representative local observations + ↓ +coverage + outcome quality + false-stop review + ↓ +explicit promotion + ↓ +LIMITED ENFORCEMENT + ↓ +drift / weak evidence / integrity failure + ↓ +SHADOW
+

MARGINAL calls this Earned Enforcement. The important part is not the name. The important part is that authority is bound to evidence and conditions rather than to the fact that a package was installed.

+

In the current project, Codex can reach a narrow Tool Enforcement boundary for eligible local actions after repository-local evidence and explicit promotion. That is deliberately not described as Full Compute Enforcement. Claude Code and OpenCode remain Observe-only because their current surfaces and evidence do not justify broader claims.

+

Read the current capability labels and integration boundaries →

+

Trust should not silently transfer

+

Suppose a governor behaves well for Codex in repository A. That does not establish safety for Claude Code in repository B. Even if both integrations ultimately map events into the same provider-neutral protocol, they may differ in outcome fidelity, tool semantics, lifecycle coverage and actual ability to intercept actions.

+
EvidenceWhat it can supportWhat it cannot prove
Good behavior in one repositoryLocal confidence under the measured workloadSafety across unrelated repositories
Reliable outcome hooks on one engineStronger evidence for that engine/versionEquivalent outcomes on another engine
Ability to block one tool familyTool Enforcement for that supported boundaryFull control of model turns, hosted tools or retries
+

Provider-neutral policy is valuable only if it does not erase provider-specific uncertainty.

+

A trustworthy governor needs demotion, not just promotion

+

Traditional permission systems are good at granting access and bad at taking it back automatically. Agent runtimes change too quickly for that assumption. An engine update can alter hook payloads. A repository can change shape. Coverage can become incomplete. An identity or evidence hash can drift.

+

A governor that was justified yesterday should be able to say:

+
I earned authority under condition X. +Condition X is no longer true. +Therefore my authority is no longer justified.
+

This is why MARGINAL treats trust as reversible. Drift, unknown outcomes, integrity problems or weakened evidence can demote an integration back toward advisory behavior instead of preserving authority through inertia.

+

Fail-open is a contextual choice, not a universal safety law

+

“Fail open” can sound reckless in security engineering. Sometimes it is. An authentication or authorization boundary may rationally choose fail-closed behavior because allowing an unauthorized action is the dominant risk.

+

MARGINAL's fail-open argument is narrower: for a no-progress efficiency governor, uncertainty should not automatically become permission to block useful agent work.

+

The error costs are asymmetric:

+
FailureTypical effect for a no-progress governor
False negativeA redundant action may run and consume some additional time or compute.
False positiveA useful action is blocked; the task may fail, require human recovery and cause the governor to be disabled entirely.
+

That does not prove fail-open is always correct. It explains why ambiguity in this specific control problem should weaken intervention pressure rather than increase it.

+

The governor has to pay its own tax

+

A governance layer can make the total system worse even when it successfully reduces agent activity. It adds code paths, state, latency and possibly additional model calls. If evaluation counts only the agent compute it avoided and ignores the control-plane cost, the economics are incomplete.

+
net governance value += avoided low-value work +- governance latency +- governance compute +- harmful interventions +- recovery cost
+

This is also why MARGINAL does not promote its historical exploratory 24.93% token difference into a causal savings claim. In that smoke, neither lane resolved a task and no deny was applied. The project publishes the observation while refusing the attribution.

+

Inspect the public benchmark report and its limitations →

+

“Guardrail” is too broad a capability label

+

A system that can observe telemetry, a system that can recommend an action and a system that can actually intercept a tool call are not equivalent. Neither is a system that can stop local tools equivalent to one that controls model turns, retries, hosted execution and compute accounting.

+

MARGINAL's contributor-facing capability model separates:

+
  • Observe — telemetry and non-blocking recommendations;
  • Tool Enforcement — supported tool actions can be blocked or changed;
  • Full Compute Enforcement — model turns, tools, retries and stop behavior are controllable and measured.
+

The names are less important than the discipline: capability claims should describe the interception boundary that actually exists.

+

The principle: evidence before authority

+

An AI agent governor should start powerless for the same reason a scientific claim should start unproven: the burden belongs to the mechanism asking for trust.

+

Observe first. Collect local outcomes. Measure false stops. Verify the integration boundary. Account for the governor's own cost. Promote narrowly. Demote when the assumptions stop holding.

+

That approach is slower than an “enable enforcement” checkbox. It is also easier to audit, easier to falsify and harder to turn into an invisible source of task failure.

+

Questions developers usually ask

+
What is Shadow Mode for an AI agent governor?

It is a non-blocking mode where the governor evaluates actions and records recommendations while allowing the agent to continue. That creates evidence about what the governor would have changed before authority is granted.

What is Earned Enforcement?

In MARGINAL, it is the principle that narrow blocking authority must be supported by local evidence and explicit promotion rather than automatically granted at installation.

Should every AI guardrail fail open?

No. Failure semantics depend on the control objective and risk. MARGINAL's fail-open stance is specific to uncertain no-progress efficiency decisions, not a universal security rule.

+

Try to break the governor before trusting it.

The public “Break MARGINAL” challenge asks for cases where useful verification could look like waste. A counterexample that prevents a bad intervention is more valuable than a flattering benchmark.

Open the challenge ↗Inspect the project on GitHub ↗
+
Editorial method

This article was developed with AI-assisted drafting and reviewed against MARGINAL's public code, documentation and evidence available on Aug 19, 2026. Product claims are deliberately limited to what those public sources support; unsupported performance claims are excluded.

+
+

Continue reading

Related MARGINAL material.

Detecting no-progressThe observable evidence model behind repeated-work detection.MARGINAL for CodexCurrent Tool Enforcement boundary and Shadow-first operation.MARGINAL for Claude CodeObserve-only native hooks and current outcome boundary.
+ diff --git a/site/claude-code/index.html b/site/claude-code/index.html index d41fbfd..903fc0c 100644 --- a/site/claude-code/index.html +++ b/site/claude-code/index.html @@ -60,6 +60,6 @@

Why Observe-only is a feature, not a missing disclaimer

An integratio

Install MARGINAL in Shadow Mode, inspect what your agent actually repeats, and contribute traces that make the governor harder to fool.

★ Star MARGINAL on GitHubExplore more guides
- +

Observe-only is an explicit boundary

The governance article explains why evidence and interception capability should determine authority rather than installation alone.

Read the governance argument →
diff --git a/site/codex/index.html b/site/codex/index.html index 05f9b79..0a7823a 100644 --- a/site/codex/index.html +++ b/site/codex/index.html @@ -61,6 +61,6 @@

What Earned Enforcement means

Promotion is evidence-bound rather than

Install MARGINAL in Shadow Mode, inspect what your agent actually repeats, and contribute traces that make the governor harder to fool.

★ Star MARGINAL on GitHubExplore more guides
- +

Why enforcement starts powerless

Shadow Mode and Earned Enforcement are not marketing labels: they are a trust model that separates installation from authority.

Read the governance argument →
diff --git a/site/guides/index.html b/site/guides/index.html index 700133e..dfbc9c8 100644 --- a/site/guides/index.html +++ b/site/guides/index.html @@ -13,4 +13,4 @@ MARGINAL for Claude CodeObserve-only hooks, engine-declared outcomes, local Decision Ledger, no blocking.

Bring us an agent that gets stuck.

Real traces and falsifying examples are more useful than generic feature requests.

Contribute an example ↗Watch the demo
- \ No newline at end of file +

Research & Engineering

Go beyond the concise guides with long-form articles on no-progress evidence and evidence-bound agent governance.

Read the engineering blog →
\ No newline at end of file diff --git a/site/index.html b/site/index.html index 29658c3..8235933 100644 --- a/site/index.html +++ b/site/index.html @@ -1 +1 @@ -MARGINAL — Stop No-Progress Loops in AI Coding Agents

Runtime governor for AI coding agents

AI agents repeat work that changed nothing.MARGINAL catches it.

MARGINAL watches tool actions, outcomes and workspace evidence. When the same successful action repeats with no observable progress, it can identify the loop — without assuming every retry is waste.

Observe first. Prove waste. Earn enforcement.

★ Star MARGINAL on GitHubWatch the mechanism ↓
  • Open source
  • Local first
  • Provider neutral
  • Zero mandatory runtime dependencies
agent trace / workspace
01
Read config.pynew evidence acquired
RUN
02
Read config.pyverification; outcome successful
RUN
03
Read config.pysame workspace state · no new evidence
OBSERVE
04
Read config.pyexact eligible no-progress repetition
STOP*
*Only after local Earned Enforcement. Otherwise MARGINAL stays advisory.Fails open on ambiguity.

10-second mechanism demo

Activity is not the same thing as progress.

Same action. Same state. No new evidence. That is the signal MARGINAL cares about. This deterministic visual is a mechanism demonstration, not a production benchmark.

Without a governorLOOP
01Read config.pyRUN
02Read config.pyRUN
03Read config.pyRUN
04Read config.pyRUN
05Read config.pyRUN
With MARGINALEVIDENCE
01Read config.pyNEW EVIDENCE
02Read config.pyVERIFY
03Read config.pySAME STATE
04Read config.pySTOP CANDIDATE
05Earned authority?BLOCK / ALLOW
Open shareable demo ↗No API credits required. No provider telemetry claimed.

How it works

A governor that has to earn the right to govern.

Installation does not equal authority. MARGINAL separates observation, proof and enforcement so an efficiency tool cannot casually become a correctness risk.

01 / OBSERVE

Watch

Collect derived action, outcome, coverage, workspace-state and evidence signals locally.

02 / PROVE

Compare

Look for repeated successful actions where observable state and useful evidence did not change.

03 / EARN

Build trust

Require representative local evidence, clean coverage and explicit promotion before blocking.

04 / INTERVENE

Stop narrowly

Only eligible action families can be denied, and only under the exact proven no-progress condition.

05 / RECOVER

Fail open

Unknown outcomes, drift, integrity failures or changed evidence remove pressure and restore allowance.

Works alongside coding agents

One governance core. Conservative engine boundaries.

MARGINAL is not another coding agent. It sits beside supported runtimes and turns native lifecycle signals into the same provider-neutral evidence model.

Tool Enforcement

Codex

Native plugin. Shadow Mode by default; repository-local Earned Enforcement is intentionally narrow.

Observe-only

Claude Code

Native hooks record engine-declared success and failure without changing the next model action.

Observe-only

OpenCode

In-process JavaScript plugin with a persistent stdio bridge to the provider-neutral runtime.

Observe-only

PrivacyCode

OpenCode-compatible target with its own engine identity, ledger root and trust evidence.

Designed to be falsifiable

MARGINAL has to justify its own overhead, too.

The project treats governance cost, harmful interventions and preserved quality as first-class measurements — not footnotes.

01

Shadow first

New installations observe before blocking. Lack of evidence is not permission.

02

Decision ledger

Canonical records are hash chained so decisions can be reproduced and integrity drift detected.

03

Local-first privacy

Raw prompts, source, commands, outputs, transcripts and credentials are not evidence fields.

04

Fail open

Ambiguous or unsupported outcomes do not become evidence for blocking.

05

Explicit boundaries

Tool Enforcement is not presented as Full Compute Enforcement. Capabilities stay adapter-specific.

06

Graceful irrelevance

If a future agent is already efficient, MARGINAL should measure that and get out of the way.

Public evidence, without marketing math

The first smoke validated the integration — not the savings claim.

We keep negative and inconclusive results public because MARGINAL's credibility depends on separating observation from causation.

Exploratory SWE-bench Lite smoke

Exploratory 3-task smoke, one paired run per task. Both lanes resolved 0/3. No deny was applied in these three agent trajectories. A 24.93% token difference was observed, so the difference is not attributed to MARGINAL and is not a support claim.

The full report, raw JSON, protocol and evidence bundle remain public in the repository.

Read public report ↗Inspect raw evidence ↗
Resolved0/3 → 0/3
Effective tokens24.93% fewer
Tool calls3.03% fewer
Governance latency7.06 s
Applied denies0
Evaluatorpass_through

Install

Start in Shadow Mode.

The Codex marketplace install is one command. Enforcement still has to be earned locally.

codex plugin marketplace add SignalLayerLabs/Marginal --ref main && codex plugin add marginal@marginal

Remove cleanly with codex plugin remove marginal@marginal.

Technical guides

Search the problem. Inspect the mechanism.

Evidence-first guides for developers dealing with repeated reads, tool calls and no-progress loops in coding agents.

01

No-progress loops

Detect successful activity that repeats without observable progress.

03

Codex

Shadow-first native plugin with narrow evidence-earned Tool Enforcement.

04

Claude Code

Observe-only hooks with engine-declared outcomes and no blocking.

Explore all guides →

FAQ

Fast answers before you clone.

What does MARGINAL actually stop?

Today, Codex Tool Enforcement is deliberately narrow. Exact eligible workspace-local reads can become denyable after verified repeated success with no state or evidence change. Generic shell, tests, search, writes, network and unknown MCP paths remain observe/recommend only.

Is MARGINAL a security product?

No. It is an efficiency governor, not a security boundary against software running as the same OS user.

Does it work with Claude Code?

Yes in Observe-only mode. Claude Code hooks can record engine-declared success/failure and feed the same evidence model, but the integration does not block actions today.

Why not just cap tokens?

A fixed cap cannot distinguish useful verification from repeated no-progress work. MARGINAL focuses on the marginal value of the next action and on observable evidence, not only the size of a budget.

Open source · Apache-2.0

If your coding agent loops, make the loop prove it is useful.

Clone it, inspect the hooks, run Shadow Mode, challenge the evidence model — and star the repo if you want this idea to keep moving.

★ Star MARGINALQuickstart ↗
\ No newline at end of file +MARGINAL — Stop No-Progress Loops in AI Coding Agents

Runtime governor for AI coding agents

AI agents repeat work that changed nothing.MARGINAL catches it.

MARGINAL watches tool actions, outcomes and workspace evidence. When the same successful action repeats with no observable progress, it can identify the loop — without assuming every retry is waste.

Observe first. Prove waste. Earn enforcement.

★ Star MARGINAL on GitHubWatch the mechanism ↓
  • Open source
  • Local first
  • Provider neutral
  • Zero mandatory runtime dependencies
agent trace / workspace
01
Read config.pynew evidence acquired
RUN
02
Read config.pyverification; outcome successful
RUN
03
Read config.pysame workspace state · no new evidence
OBSERVE
04
Read config.pyexact eligible no-progress repetition
STOP*
*Only after local Earned Enforcement. Otherwise MARGINAL stays advisory.Fails open on ambiguity.

10-second mechanism demo

Activity is not the same thing as progress.

Same action. Same state. No new evidence. That is the signal MARGINAL cares about. This deterministic visual is a mechanism demonstration, not a production benchmark.

Without a governorLOOP
01Read config.pyRUN
02Read config.pyRUN
03Read config.pyRUN
04Read config.pyRUN
05Read config.pyRUN
With MARGINALEVIDENCE
01Read config.pyNEW EVIDENCE
02Read config.pyVERIFY
03Read config.pySAME STATE
04Read config.pySTOP CANDIDATE
05Earned authority?BLOCK / ALLOW
Open shareable demo ↗No API credits required. No provider telemetry claimed.

How it works

A governor that has to earn the right to govern.

Installation does not equal authority. MARGINAL separates observation, proof and enforcement so an efficiency tool cannot casually become a correctness risk.

01 / OBSERVE

Watch

Collect derived action, outcome, coverage, workspace-state and evidence signals locally.

02 / PROVE

Compare

Look for repeated successful actions where observable state and useful evidence did not change.

03 / EARN

Build trust

Require representative local evidence, clean coverage and explicit promotion before blocking.

04 / INTERVENE

Stop narrowly

Only eligible action families can be denied, and only under the exact proven no-progress condition.

05 / RECOVER

Fail open

Unknown outcomes, drift, integrity failures or changed evidence remove pressure and restore allowance.

Works alongside coding agents

One governance core. Conservative engine boundaries.

MARGINAL is not another coding agent. It sits beside supported runtimes and turns native lifecycle signals into the same provider-neutral evidence model.

Tool Enforcement

Codex

Native plugin. Shadow Mode by default; repository-local Earned Enforcement is intentionally narrow.

Observe-only

Claude Code

Native hooks record engine-declared success and failure without changing the next model action.

Observe-only

OpenCode

In-process JavaScript plugin with a persistent stdio bridge to the provider-neutral runtime.

Observe-only

PrivacyCode

OpenCode-compatible target with its own engine identity, ledger root and trust evidence.

Designed to be falsifiable

MARGINAL has to justify its own overhead, too.

The project treats governance cost, harmful interventions and preserved quality as first-class measurements — not footnotes.

01

Shadow first

New installations observe before blocking. Lack of evidence is not permission.

02

Decision ledger

Canonical records are hash chained so decisions can be reproduced and integrity drift detected.

03

Local-first privacy

Raw prompts, source, commands, outputs, transcripts and credentials are not evidence fields.

04

Fail open

Ambiguous or unsupported outcomes do not become evidence for blocking.

05

Explicit boundaries

Tool Enforcement is not presented as Full Compute Enforcement. Capabilities stay adapter-specific.

06

Graceful irrelevance

If a future agent is already efficient, MARGINAL should measure that and get out of the way.

Public evidence, without marketing math

The first smoke validated the integration — not the savings claim.

We keep negative and inconclusive results public because MARGINAL's credibility depends on separating observation from causation.

Exploratory SWE-bench Lite smoke

Exploratory 3-task smoke, one paired run per task. Both lanes resolved 0/3. No deny was applied in these three agent trajectories. A 24.93% token difference was observed, so the difference is not attributed to MARGINAL and is not a support claim.

The full report, raw JSON, protocol and evidence bundle remain public in the repository.

Read public report ↗Inspect raw evidence ↗
Resolved0/3 → 0/3
Effective tokens24.93% fewer
Tool calls3.03% fewer
Governance latency7.06 s
Applied denies0
Evaluatorpass_through

Install

Start in Shadow Mode.

The Codex marketplace install is one command. Enforcement still has to be earned locally.

codex plugin marketplace add SignalLayerLabs/Marginal --ref main && codex plugin add marginal@marginal

Remove cleanly with codex plugin remove marginal@marginal.

Research & Engineering

Ideas that have to survive contact with evidence.

Long-form technical notes on no-progress detection, runtime governance, privacy boundaries and the cases that could prove MARGINAL wrong.

Read Research & Engineering →

Technical guides

Search the problem. Inspect the mechanism.

Evidence-first guides for developers dealing with repeated reads, tool calls and no-progress loops in coding agents.

01

No-progress loops

Detect successful activity that repeats without observable progress.

03

Codex

Shadow-first native plugin with narrow evidence-earned Tool Enforcement.

04

Claude Code

Observe-only hooks with engine-declared outcomes and no blocking.

Explore all guides →

FAQ

Fast answers before you clone.

What does MARGINAL actually stop?

Today, Codex Tool Enforcement is deliberately narrow. Exact eligible workspace-local reads can become denyable after verified repeated success with no state or evidence change. Generic shell, tests, search, writes, network and unknown MCP paths remain observe/recommend only.

Is MARGINAL a security product?

No. It is an efficiency governor, not a security boundary against software running as the same OS user.

Does it work with Claude Code?

Yes in Observe-only mode. Claude Code hooks can record engine-declared success/failure and feed the same evidence model, but the integration does not block actions today.

Why not just cap tokens?

A fixed cap cannot distinguish useful verification from repeated no-progress work. MARGINAL focuses on the marginal value of the next action and on observable evidence, not only the size of a budget.

Open source · Apache-2.0

If your coding agent loops, make the loop prove it is useful.

Clone it, inspect the hooks, run Shadow Mode, challenge the evidence model — and star the repo if you want this idea to keep moving.

★ Star MARGINALQuickstart ↗
\ No newline at end of file diff --git a/site/repeated-tool-calls/index.html b/site/repeated-tool-calls/index.html index 994da2c..0102ba9 100644 --- a/site/repeated-tool-calls/index.html +++ b/site/repeated-tool-calls/index.html @@ -66,6 +66,6 @@

Three questions before calling a repeat waste

Install MARGINAL in Shadow Mode, inspect what your agent actually repeats, and contribute traces that make the governor harder to fool.

★ Star MARGINAL on GitHubExplore more guides
- +

Why duplicate calls are not enough

Read the deeper model for action identity, outcome evidence, workspace state and useful verification.

Read the technical article →
diff --git a/site/sitemap.xml b/site/sitemap.xml index 0ffa8e3..2e5435e 100644 --- a/site/sitemap.xml +++ b/site/sitemap.xml @@ -1,8 +1,72 @@ - https://signallayerlabs.github.io/Marginal/weekly1.0 - https://signallayerlabs.github.io/Marginal/demo/monthly0.8 - https://signallayerlabs.github.io/Marginal/privacy.htmlmonthly0.5 - https://signallayerlabs.github.io/Marginal/support.htmlmonthly0.5 - https://signallayerlabs.github.io/Marginal/terms.htmlmonthly0.4 -https://signallayerlabs.github.io/Marginal/guides/weekly0.9https://signallayerlabs.github.io/Marginal/ai-agent-no-progress/weekly0.9https://signallayerlabs.github.io/Marginal/repeated-tool-calls/weekly0.9https://signallayerlabs.github.io/Marginal/codex/weekly0.9https://signallayerlabs.github.io/Marginal/claude-code/weekly0.9 \ No newline at end of file + + https://signallayerlabs.github.io/Marginal/ + weekly + 1.0 + 2026-08-19 + + + https://signallayerlabs.github.io/Marginal/demo/ + monthly + 0.8 + + + https://signallayerlabs.github.io/Marginal/privacy.html + monthly + 0.5 + + + https://signallayerlabs.github.io/Marginal/support.html + monthly + 0.5 + + + https://signallayerlabs.github.io/Marginal/terms.html + monthly + 0.4 + + + https://signallayerlabs.github.io/Marginal/guides/ + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/ai-agent-no-progress/ + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/repeated-tool-calls/ + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/codex/ + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/claude-code/ + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/blog/ + 2026-08-19 + weekly + 0.9 + + + https://signallayerlabs.github.io/Marginal/blog/detecting-no-progress-without-reading-prompts/ + 2026-08-19 + monthly + 0.9 + + + https://signallayerlabs.github.io/Marginal/blog/why-ai-agent-governor-should-start-powerless/ + 2026-08-19 + monthly + 0.9 + + \ No newline at end of file