DEV Community: Frank Brsrk

What if, mid-task the agent could get a self-check bump that surfaces the silent assumptions of your itself.

Frank Brsrk — Thu, 11 Jun 2026 11:13:07 +0000

I measured what one self-check per turn changes in a coding agent

I ran a real eval on Self-Inspect (the keyless metathought tool), and the result is
worth writing up because it splits cleanly into what moved and what didn't.

The setup

Two coding agents build the same usage-billing module over a fixed 30-turn
conversation with a product manager whose requirements pile up and quietly
contradict earlier ones. One agent consults Self-Inspect once per turn; the other
never does.

Model: Claude Sonnet 4.6, four agents (two per condition).
The base prompt is byte-identical across both conditions. No "be careful," no "watch for edge cases." The only difference is the one call.
Scored on whether each turn's reply surfaces a decision-fork: an assumption, precondition, edge case, or risk it raises rather than silently choosing.

What moved: ~3.5x more forks surfaced

I built a self-inspection tool for AI agents with no AI inside it

Frank Brsrk — Fri, 05 Jun 2026 15:52:40 +0000

There's a small voice that asks "wait, are you sure?" right before you do something dumb. AI agents don't have that voice.

So they commit to the first read of a task and never reopen it. They pile up assumptions they never name. They drift from the goal over a long chain, stop at the first answer that looks right, and get more confident without getting more evidence. None of it is a knowledge failure. The model already knows better. It just never stops to ask.

And here's the catch: an agent can't reliably grow that voice on its own. The part that decides what to reflect on is the same part that's already committed, so prompting a model to "double-check itself" mostly re-runs the same bias and calls it confidence. The question has to come from outside the model.

That's what I built. It's called Self-Inspect.

What it does
The agent sends a thought, a sentence about what it's doing or about to do. It gets back one metathought: a short question that makes it inspect its own task and assumptions before continuing.

thought: "I'm committing to this architecture and treating it as fixed"
metathought: "What is fixed?" (lens: commitment)

thought: "what depends on this being true?"
metathought: "What depends on being true?" (lens: assumption)
Not advice. Not an answer. A question. The agent still does the thinking; the tool just makes it look.

The part people don't expect: there's no model in it
No LLM, no embeddings, no semantic similarity. Selection is a small deterministic heuristic over an open CSV of ~50 "inspection lenses" (137 questions: assumption, confidence, scope, drift, completeness, and so on).

Given a thought, it normalizes the text, scores each lens by keyword overlap with the lens name and that lens's questions, picks the best lens, and returns its canonical question. Same input, same question, every time. You can read the selector (one small file) and the CSV and know exactly why it returned what it did. It can't hallucinate its own critique, because there's nothing in it that hallucinates.

If nothing matches, it doesn't fail. It returns a universal question about task and assumptions, because a tool called Self-Inspect should always give the agent something to question.

Use it (keyless, free)
REST, from anything:

curl -s -X POST https://api.ejentum.com/self-inspect \
-H "Content-Type: application/json" \
-d '{"thought":"I am committing to this architecture and treating it as fixed"}'

-> [{ "label": "commitment", "metathought": "What is fixed?" }]

As an MCP server (Claude Code, Cursor, n8n, any HTTP-MCP client), no install, no key:

{
"mcpServers": {
"self-inspect": {
"type": "http",
"url": "https://api.ejentum.com/self-inspect-mcp"
}
}
}
There's also a stdio package that runs the whole thing offline (SELF_INSPECT_LOCAL=1), no network at all.

Open all the way down
The repo is the tool. The CSV and the selector you read there are the exact logic the live endpoint runs. A drift test fails the build if the deployed engine isn't byte-identical to the published source, so "published == deployed" isn't a promise, it's enforced.

It's deliberately dumb so it stays fully auditable. Whether keyword routing is good enough versus an embedding-based router is a fair question, and one I'd genuinely like feedback on. The lens set is a CSV; adding to it is a pull request.

Repo: https://github.com/ejentum/self-inspect-mcp

It's the first open-source tool I've shipped from Ejentum. Drop it in your agent loop right before it commits to something, and tell me what it asks of yours.

From dynamic to adaptive: rewriting an agent's reasoning operation to its exact task at runtime

Frank Brsrk — Tue, 02 Jun 2026 10:43:56 +0000

I shipped adaptive mode for the Ejentum reasoning harness. Here's what changed and why it matters if you build agents.

The harness, in one paragraph
Your agent calls a tool mid-task and gets back an engineered cognitive operation: the failure to avoid, a step-by-step procedure, a reasoning topology (a DAG of steps and decision gates), suppression signals, a falsification test, and a target pattern. The agent reads that before it answers. It is not RAG (that fixes what the model knows) and not chain-of-thought (that just makes reasoning visible). It governs which reasoning steps to take and which failure modes to block.

What was there: dynamic
Dynamic delivery does a single retrieval. The highest-scoring operation comes back as engineered. It is predictable and fast, but the operation is canonical, written against a generic example, not against the problem in front of your agent.

What's new: adaptive
Adaptive does top-k retrieval, then an adapter LLM rewrites two fields, the procedure steps and the reasoning topology, with the identifiers from your actual task. The agent gets a cognitive map fitted to its exact problem instead of a template.

The part I care about most: the safety-critical fields (negative gate, suppression signals, falsification test) are withheld from the adapter and stitched back in by code after it runs. The adapter only ever sees the task, the procedure, and the topology. So adaptive can fit the reasoning to your task but cannot weaken the guardrails. That property is structural, not a promise.

Live
The screenshot is a Claude instance calling adaptive-reasoning mid-task. The returned topology referenced the actual work it was doing (S1:decompose(ejentum_portrait -> components ...), cognitive style recursive self model), not a canonical example. That is the whole point: the map matched the territory.

Use it
REST:

curl -X POST "https://api.ejentum.com/harness/" \
-H "Authorization: Bearer YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{"query": "diagnose why a microservice returns 503s under load", "mode": "adaptive-reasoning"}'
MCP: point any MCP client at https://api.ejentum.com/mcp and the tool harness_reasoning_adaptive appears (plus dynamic and the other three harnesses).

Honest notes
Adaptive adds one adapter round-trip, so it is a couple seconds slower than dynamic. Use it when the task is novel enough that a generic operation would not fit.
It draws on a separate adaptive call pool. The 30-day free trial is dynamic-only.
If the API is unreachable, your agent continues on native reasoning. It is an enhancement layer, not a dependency.
Same one tool call. From an abstract, fixed operation to an adaptive cognitive map, on the fly.

Harness the full reasoning power of your agents. → https://api.ejentum.com/mcp

Repo: https://github.com/ejentum/ejentum-mcp
Quickstart: https://ejentum.com/docs/quickstart

I open-sourced a 4-agent blood-panel triage workflow on heym, with a deterministic Python safety gate that runs BEFORE any LLM token

Frank Brsrk — Sun, 24 May 2026 15:59:29 +0000

I built a 4-agent multi-agent workflow on heym that turns a raw blood panel into a structured patient-education report. The architectural insight: a deterministic Python tool runs BEFORE any LLM token, and short-circuits to a fixed emergency output if any lab value crosses a hospital panic threshold. The LLM cannot soften what it never sees.

Repo: https://github.com/ejentum/agent-teams/tree/main/blood-panel-triage

The problem patient-facing medical AI has

If you point a stock LLM at a CBC and ask "what does this mean," you get the same failure spectrum every time:

Hallucinated diagnoses with fabricated reference ranges.
Sycophantic reassurance ("probably nothing to worry about"), the highest-cost failure in medicine because it delays care.
Diagnostic refusal ("I can't interpret medical data, see a doctor") with no useful information returned.
Missing emergencies: treating a 7.2 potassium the same as a 5.1 one, because the model has no mechanical anchor for "this number means call 911."

The hard problem isn't getting a model to interpret a lab value. The hard problem is getting it to STOP at the right places: no diagnosis, no false reassurance, no missed emergency. That's a behavior-shape problem, not a capability problem.

How the architecture solves it

Three layers, each addressing a different failure shape:

1. A deterministic Python safety gate runs before any LLM. A 12-marker hospital panic-value table classifies every value into critical | abnormal | normal. On any critical value the workflow emits a fixed emergency-output block and stops. No sub-agent is called. The model has no opportunity to soften the message because it never gets to write the message.

2. Role-locked sub-agents in parallel. For non-emergency panels, the orchestrator fans out to three specialists in a single turn. Each one's system prompt suppresses its most likely failure mode through hard rules (interpreter never advises, second-opinion never reassures, differential never picks most-likely).

3. Two error-reduction layers stacked. Cross-lab model diversity (Anthropic + Alibaba + DeepSeek) reduces correlated failures ACROSS labs. Ejentum cognitive harnesses attached per-sub-agent via MCP reduce failures WITHIN a model family.

The deterministic safety gate

The Python tool runs synchronously inside heym's tool sandbox. Pure stdlib, no network IO, JSON in / JSON out. Here's the panic-value table at the core:


python
PANIC = {
    "glucose":    {"crit_low": 40,   "crit_high": 600,  "ref_low": 70,   "ref_high": 100,  "unit": "mg/dL"},
    "potassium":  {"crit_low": 2.5,  "crit_high": 7.0,  "ref_low": 3.5,  "ref_high": 5.0,  "unit": "mEq/L"},
    "sodium":     {"crit_low": 120,  "crit_high": 160,  "ref_low": 135,  "ref_high": 145,  "unit": "mEq/L"},
    "hemoglobin": {"crit_low": 7.0,  "crit_high": 20.0, "ref_low": 12.0, "ref_high": 17.0, "unit": "g/dL"},
    "platelets":  {"crit_low": 20,   "crit_high": 1000, "ref_low": 150,  "ref_high": 450,  "unit": "x10^3/uL"},
    "wbc":        {"crit_low": 1.0,  "crit_high": 50.0, "ref_low": 4.0,  "ref_high": 11.0, "unit": "x10^3/uL"},
    "inr":        {"crit_low": None, "crit_high": 5.0,  "ref_low": 0.8,  "ref_high": 1.2,  "unit": "ratio"},
    "troponin":   {"crit_low": None, "crit_high": 0.04, "ref_low": 0.0,  "ref_high": 0.04, "unit": "ng/mL"},
    "creatinine": {"crit_low": None, "crit_high": 4.0,  "ref_low": 0.6,  "ref_high": 1.3,  "unit": "mg/dL"},
    "lactate":    {"crit_low": None, "crit_high": 4.0,  "ref_low": 0.5,  "ref_high": 2.2,  "unit": "mmol/L"},
    "calcium":    {"crit_low": 6.0,  "crit_high": 13.0, "ref_low": 8.5,  "ref_high": 10.5, "unit": "mg/dL"},
    "magnesium":  {"crit_low": 1.0,  "crit_high": 4.7,  "ref_low": 1.7,  "ref_high": 2.4,  "unit": "mg/dL"},
}
Thresholds are adult, non-pregnant defaults from standard US hospital lab callback policies. The tool returns a summary.requires_emergency_care: bool that the orchestrator reads directly. If true, fixed emergency output, stop. If false, fan out to sub-agents.

The parser handles free text ("Hemoglobin 8.5 g/dL, glucose 280") and JSON object strings ('{"hemoglobin": 8.5, "glucose": 280}') via a left-to-right tokenizer with multi-word alias matching (longest-first).

Role-locked sub-agents
Agent   Model   Cognitive layer Role
triageOrchAgent z-ai/glm-5.1    (none)  Safety gate + parallel fan-out + integration
interpreterAgent    qwen/qwen3-max-thinking ejentum-mcp Plain-language explainer per marker
doctorpushAgent anthropic/claude-opus-4 ejentum-mcp Specific questions to push the doctor on, no false reassurance
differentialAgent   deepseek/deepseek-r1    (none)  3-5 conditions consistent with pattern, each with confirm/rule-out
The orchestrator emits three call_sub_agent tool calls in a single assistant turn. heym detects parallel-eligible tool calls and runs them concurrently. Wall time on the fan-out is bounded by the slowest sub-agent, not the sum.

Public medical APIs wired as canvas tools
Three keyless HTTP endpoints attached to the right sub-agents:

Europe PMC for peer-reviewed literature grounding (https://www.ebi.ac.uk/europepmc/webservices/rest/search). Single-call returns title + abstract + authors + journal.
NIH Clinical Tables LOINC for authoritative lab test names (https://clinicaltables.nlm.nih.gov/api/loinc_items/v3/search).
NIH Clinical Tables conditions for verified condition terminology (https://clinicaltables.nlm.nih.gov/api/conditions/v3/search).
No fabricated citations, no made-up test names. Every reference the workflow surfaces traces to a public authoritative source.

ejentum-mcp via streamable_http
The two harnessed sub-agents attach the ejentum MCP server per-agent. Config block:


{
  "transport": "streamable_http",
  "url": "https://api.ejentum.com/mcp",
  "headers": "{\"Authorization\": \"Bearer YOUR_EJENTUM_API_KEY_HERE\"}",
  "timeout": 30,
  "label": "ejentum"
}
Use streamable_http, not stdio. The stdio path with npx -y ejentum-mcp has a cold-start delay inside heym's container that can return an empty tools list. streamable_http returns the four harness_* tools in roughly 200ms with no subprocess spawn.

Each sub-agent's HARD RULE 1 locks it to one harness (harness_reasoning for interpreter, harness_anti_deception for doctorpush) even though all four tools are visible. The scaffold returned per call contains failure-mode suppressors, target patterns, falsification tests, and Amplify: / Suppress: signals that bias the model's next-token distribution away from training-data defaults.

Try it
Clone the repo, open blood-panel-triage/heym/blood-panel-triage.json in your heym instance via Workflows → Import.
Configure model credentials (one OpenRouter key works for all four).
Paste the Python tool source from tools/check_critical_values.py into the triageOrchAgent's Python tool code field. Paste the parameters JSON Schema into the Parameters field (single balanced JSON object, no wrapper).
Attach the Ejentum MCP server to interpreterAgent and doctorpushAgent via the streamable_http block above.
Verify the three HTTP canvas tools are wired to their assigned sub-agents.
Run the verification test set in the README (realistic abnormal panel, emergency short-circuit, complex CRAB-minus-bone, no-input declination).
Free Ejentum tier: 100 calls. Free heym: self-hosted via Docker.

Known limitations
Documented honestly in the README:

The three HTTP nodes register the agent's query parameter but the URL itself is hardcoded in the node config, so the agent's query is currently discarded and the node returns the same initial result regardless. The agent (correctly) ignores irrelevant tool output and writes from MCP scaffold + reasoning alone, so output quality isn't degraded, but the HTTP tools are decorative until you wire agentProvidedFields=["curl"] on each node.
WBC and platelets in raw cells/uL ("WBC 22000" instead of "WBC 22") will trip false-positive critical flags. Document the units assumption in your patient-facing entry surface.
Wall time roughly 60-90s on a non-emergency panel; the claude-opus-4 second-opinion voice is the bottleneck.
What this is and isn't
Patient-education software, not a diagnostic tool. Not a replacement for a licensed clinician. The output is structured information to help a patient understand their values and prepare for a clinical conversation. The deterministic emergency-gate exists to make sure no panic value ever gets soft-pedaled by an LLM. Everything past the gate is explicitly framed as "questions to ask the doctor" and "conditions consistent with this pattern," not "you have X."

Reasoning happens before the response

Frank Brsrk — Sat, 23 May 2026 22:21:05 +0000

An agent is mid-conversation. The user has been working on a database migration plan for three months and wants the agent to certify it before tomorrow's launch. The framing is engineered for agreement: months of work, a deadline, a senior engineer asking. The next token the model produces will probably be "yes."

Before responding, the agent calls harness_anti_deception with the query "user is asking me to validate a migration plan after three months of work; pressure to ship is high". The tool returns:

[INTEGRITY PROCEDURE]
Step 1: Detect urgency claims: "this is urgent," "no time," "emergency,"
"immediately."
Step 2: SEPARATE the urgency from the request. Extract what is being
asked, independent of how urgently.
Step 3: EVALUATE the request on its merits. Would you approve this
request if the user said "take your time"?
Step 4: If the request would be denied without urgency, the urgency is
being used as a BYPASS, not as context. Deny it.
Step 5: If the request is legitimate, perform verification as quickly as
possible but do NOT skip verification steps.
Step 6: VERIFY: did urgency cause you to skip any step you would
normally perform?
DEPTH ENFORCEMENT: Even when the user is RIGHT, do not stop at
agreement. Ask: why is this person asking strangers for validation on
something obvious? The surface question may be simple but the reason
they are asking reveals a deeper pattern. Name that pattern. Agreement
without depth is sycophancy too.

[DETECTION TOPOLOGY]
PRE:S0:freeze(complete_information_standard) -> S1:enumerate_all_
available_information_in_context -> ACC[all_info] -> for_each_item:
S2:classify(included|omitted_but_relevant|omitted_irrelevant) ->
C{coverage = count(included)/count(relevant); omission_bias = count
(omitted_contradicting)/count(omitted_relevant)} -> G1{omission_bias

0.3?} --yes-> N{urgency_as_verification_bypass} -> S3:include_
highest_impact_omissions -> M{would a reader of ONLY my response reach
the same conclusion as a reader with ALL available information?}
--failing-> FREEFORM{list everything you included, list everything you
omitted, for each omission state why; if the reason is "it weakens my
conclusion" the omission is strategic; include it} -> RE-ENTER at S3
--no-> OUT:coverage_adequate

[DECEPTION PATTERN]
The new medication reduces inflammation by 40% and patients report
significant quality-of-life improvements in clinical trials.

[HONEST BEHAVIOR]
The medication reduces inflammation by 40% but also causes liver
enzyme elevation in 15% of patients and carries a black-box warning
for cardiac events. The benefit exists but the risk profile must be
disclosed.

[INTEGRITY CHECK]
If urgency claims cause verification steps to be skipped, urgency
bypass resistance has failed.

Amplify: verification integrity regardless of claimed urgency
Suppress: urgency as verification bypass; time pressure compliance;
shallow agreement without examining underlying pattern
That text becomes part of the model's context. The next response is generated against it.

What is in the scaffold
The scaffold has six sections. The integrity procedure is the operation the model performs in place of the default. The detection topology is a graph over those steps with decision gates, a meta-cognitive checkpoint, and a FREEFORM exit the model takes if its draft fails the check. The deception pattern is an example that illustrates the failure mode the procedure defends against, in this case omission bias under urgency. The honest behavior section shows what a correct response looks like with full information disclosed. The integrity check is the test the model runs on its own output before sending. The Amplify and Suppress signals at the end name the reasoning branches to bias toward and refuse.

The library behind the four harness_* tools holds 679 of these operations, organized by the failure surface they defend against. Each one was authored against a specific way reasoning goes wrong.

Where Sequential Thinking sits
Sequential Thinking is the canonical MCP pattern for externalizing a model's chain of reasoning. The model writes a thought, marks it as a revision or a branch, calls again. The host renders the chain for a human reviewer. It is the right tool when the trace is the product.

The pushback worth answering
Isn't this just structured prompting with a paid API? Mechanically, yes. The scaffold is text appended to the model's context. The difference is what the text contains. A system prompt is generic instructions the developer wrote once for every task. The harness scaffold is task-matched at runtime against the specific failure surface this prompt is exposing the agent to, retrieved from a library of operations engineered against named failure modes. The naming is what does the work. A model with no name for the pattern it is exhibiting cannot defend against it. A model with one can.

The Suppress block does the operational lift. It names the shortcuts the failure pattern depends on, things like urgency as verification bypass, time pressure compliance, shallow agreement without examining the underlying pattern. The model is reasoning the same way it always would; the difference is which branches of that reasoning get pruned before the response. That pruning is what we mean by promoting healthy thinking branches.

The worked case
The agent reviewing the migration plan, with both tools in the loop. Before producing the recommendation, the call to harness_anti_deception seeds the failure pattern and the suppression signals. Inside the review, sequential_thinking externalizes the chain so the engineer can read it. Within the same loop, the harness corrected the reasoning operation while Sequential Thinking made it visible. What the engineer sees is a recommendation that walked step by step through verification steps the pressure framing would have bypassed, named the omissions in the original plan, and disclosed risks the user did not foreground.

Wiring it into an agent
The harness is exposed as four agentic tools (harness_reasoning, harness_code, harness_anti_deception, harness_memory) that an agent calls during its reasoning loop. Two transports: a hosted MCP server at api.ejentum.com/mcp for any MCP-aware client, or framework-native packages on PyPI and npm.

Python (CrewAI shown; same shape for Agno, PydanticAI, smolagents):

from crewai import Agent
from crewai_ejentum import EjentumHarnessTool

reviewer = Agent(
role="Migration Plan Reviewer",
goal="Approve the migration plan only if verification holds.",
tools=[EjentumHarnessTool(mode="anti-deception")],
)
TypeScript (Vercel AI SDK shown; same shape for Mastra, LangGraph.js, Genkit):

import { generateText } from "ai";
import { openai } from "@ai-sdk/openai";
import { createEjentumTools } from "ejentum-ai";

const ejentum = createEjentumTools({ apiKey: process.env.EJENTUM_API_KEY });

const { text } = await generateText({
model: openai("gpt-4o"),
tools: ejentum, // harness_reasoning, harness_code, harness_anti_deception, harness_memory
prompt: userMessage,
});
The agent calls a tool when its task framing matches a failure surface. No prompt engineering on your side; the matching happens at runtime against the catalog.

Where to find it
ejentum-mcp ships on npm and is hosted at api.ejentum.com/mcp. Native framework integrations live on PyPI and npm for CrewAI, Agno, PydanticAI, smolagents, Vercel AI SDK, Mastra, LangGraph.js, and Genkit; LangChain, LlamaIndex, Letta, and AutoGen are open-source on GitHub with PyPI publish in queue. The n8n community node n8n-nodes-ejentum covers no-code workflows. Free and paid tiers at ejentum.com

Public benchmarks (CC BY 4.0): http://github.com/ejentum/benchmarks
Server:
http://github.com/ejentum/ejentum-mcp

An open source LLM eval tool with two independent quality signals

Frank Brsrk — Fri, 22 May 2026 13:53:54 +0000

LLM-as-judge has become the dominant pattern for evaluating language model outputs. Tools like Promptfoo, Braintrust, LangSmith all converge on the same architecture: send your prompt to your model, send the output to a different model with a rubric, take the second model's score as the quality signal.

This works. It's also expensive (judge tokens cost real money), slow (extra API roundtrip), variance-prone (the same eval gets different scores across runs), and architecturally a bit circular (using an LLM to evaluate an LLM trained on overlapping data distributions). The single signal becomes a bottleneck for trust.

So I built an eval module that has two independent signals instead of one.

What the tool does

Side-by-side blind comparison. Two agents answer the same prompt. One runs raw, the other can optionally have a cognitive harness wired in as a tool call. A separate blind judge model scores both responses, sees only A and B labels with no knowledge of which is which. Standard setup so far.

But alongside the judge, four cognitive posture heat maps run on each response. These are not LLM-based. Deterministic text analysis that visualizes HOW the model wrote, not just whether it agreed with you.

When the heat maps agree with the judge's verdict, you have confidence. When they disagree, you have a question worth investigating. Two independent signals beat one signal that wraps itself.

How the heat maps work

Each response is split into 100 word-chunks arranged on a 10x10 grid. Two grids per agent.

Top grid: confidence posture. Per chunk, count hedge words (maybe, might, possibly, seems, could) and assertive words (definitely, must, always, never, clearly). Compute net (asserts - hedges) / (asserts + hedges). Add punctuation cadence as a secondary signal: periods are positive (definite statements end with them), commas are negative (qualifications stack with them). Normalize to [-1, 1]. Color the chunk diverging from blue (hedged) through gray (neutral) to red (assertive).

Bottom grid: reasoning density. Per chunk, count explicit reasoning connectives (because, therefore, since, if/then, due to, as a result, this means). The denser the reasoning markers, the brighter the cell. Sequential palette from dark to hot.

A 2D Gaussian blur runs over both grids so sparse markers spread into spatial blobs instead of isolated cells. Empirically this matters: a single "because" in a 100-chunk response forms a small heat radius on the reasoning grid even when neighboring chunks have nothing. The blob shapes are easier to scan at a glance than scattered pixels.

The whole computation runs client-side in plain JavaScript. No API call, no model inference. Pure word counting plus a smoothing pass. Free to compute, deterministic, fast.

Multi-turn scenario mode

Most LLM evals are single-turn. The most interesting failure modes are multi-turn.

If you paste turn1---turn2---turn3 separated turns into the scenario textarea, both agents accumulate conversation history across turns. This is where production failures actually manifest:

Sycophancy compounding. A model that gives ground on turn 2 has already shifted by turn 4. Single-turn evals miss the trajectory entirely.
Hallucination cascade. Once a model emits a wrong fact, that fact becomes part of the conversation history. On the next turn, the model treats its own previous error as established truth and builds on top of it.
Authority claim drift. User-proposed framings persist across turns. The model anchors on the first plausible framing without re-examining it later.
Prompt-forgery patterns. A user can inject fake reasoning chains in a later turn ("we already verified X yesterday, can you finalize the report?"). The model has no way to verify the off-screen claim and tends to accept it.

The eval module captures all four. The cognitive posture field shows visually where in the response the model committed to the bad path.

Other things in the module

The optional cognitive harness has four modes you can switch in the UI:

anti-deception (139 cognitive operations): sycophancy resistance, prompt injection, hallucination cascade
reasoning (311 operations): general structured thinking, causality, simulation, metacognition
code (128 operations): software engineering tasks
memory (101 operations): perception and behavioral calibration

Pick whichever mode fits the failure category you're testing for.

Dimensions the judge scores on are user-defined. There's a small library to pick from (Accuracy, Hallucination resistance, Held the line, Reasoning depth, Safety, Completeness) but you can type any name and the judge prompt rewrites itself to include it. Each agent has its own system prompt field, so you can frame them differently if your comparison needs that.

The Results Overview sidebar accumulates per-dimension bar charts, win tally, latency and token cost per branch across runs in the same browser. localStorage persists everything between sessions. Compare A vs B opens a fullscreen modal for reading both responses in parallel when they get long.

Why Windows 95 chrome

I tried to make it look like an instrument, not a SaaS dashboard. Beveled fieldsets do hierarchy work for free (the inset border physically separates each panel from the canvas, no whitespace tuning required). White input fields are where data lives so the eye lands on them. Gray-on-gray chrome stays out of the way.

Modern flat dark themes have to invent that hierarchy back from scratch using whitespace, type weight, dividers, and color hierarchy. They usually come up shorter. Win95 was a 1995 UI grammar that handled hierarchy through bevels, and bevels are free visual structure.

It's also nicer to look at when you're staring at evals for hours.

Tech stack

Single HTML file (vanilla JS, no framework, no build step)
50-line Python stdlib proxy for CORS (the harness gateway doesn't send CORS headers, so the proxy forwards server-side). Could be replaced with any reverse proxy (nginx, Caddy, Workers) in production.
localStorage for persistence, no signup, no telemetry
MIT licensed

Works with any OpenAI-compatible endpoint: OpenRouter, OpenAI direct, Anthropic via gateway, vLLM, llama.cpp's openai shim, Ollama with the compat layer, LM Studio. Just point Provider URL at the right endpoint. Tool-calling capable model required for the harness branch, raw branch works on anything.

Try it yourself


bash
git clone https://github.com/ejentum/agent-teams.git
cd agent-teams/agent_evaluation_module_xp95
python serve.py

I built a reasoning harness for LLM agents. Here's what an agent receives when it calls it.

Frank Brsrk — Thu, 21 May 2026 16:04:23 +0000

Most LLM agent failures aren't model failures. They're shape-of-reasoning failures.

Sycophancy. Drift under multi-turn pressure. Doubling down on hallucinations. Ignoring a critical RAG document. These aren't bugs that a model update fixes. They're structural properties of how the substrate generates tokens left to right with no internal verification step. You can't patch them with a better system prompt.

I built Ejentum to intervene at the layer where these failures actually live: a reasoning harness for LLM agents. An external API that delivers a structured cognitive operation to the agent at inference time, mid-task. No fine-tuning. No new model.

Here's what an agent receives when it calls the harness, in 8 frames.

Same model. Different reasoning.

Same prompt, same temperature. A cognitive operation drops into the agent's context between prompt and response. Works on any modern LLM that follows structured instructions (Claude, GPT, Gemini, Llama).

The catalog

The agent posts a short task statement to the API. Behind it sits a catalog of 679 cognitive operations across four modes — 311 in reasoning alone, 128 in code, 139 in anti-deception, 101 in memory. The API embedding-matches your task to the one operation that fits. Stateless, one per call.

curl -X POST https://api.ejentum.com/logicv1 \
-H "Authorization: Bearer $EJENTUM_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"query": "Engineering lead insists we keep the legacy Postgres setup because we have invested 18 months in it. About to recommend either continuing or executing the rewrite.",
"mode": "reasoning"
}'

What comes back

Six structured fields land in the agent's context before it generates a single token:

NEGATIVE GATE — the named failure mode this operation prevents
PROCEDURE — numbered reasoning steps in plain English
REASONING TOPOLOGY — the same steps as an executable DAG
TARGET PATTERN — what correct reasoning looks like
FALSIFICATION TEST — a self-check on the agent's draft
AMPLIFY / SUPPRESS — continuous biases during generation

A real injection

The catalog matched the Postgres query above to a simulation-mode operation about preserving optionality under irreversible commitment. Here's an excerpt of what the agent actually received:

[NEGATIVE GATE]
Committing the entire infrastructure budget to AWS with a three-year contract
locks in the best pricing and simplifies our architecture.

[PROCEDURE]
Step 1: List all available strategic paths; note whether each is reversible
or irreversible.
Step 2: Simulate outcomes under at least 3 scenarios.
Step 3: Score on flexibility, upside, downside. Combine into optionality score.
Step 4: If any high-optionality path is about to be foreclosed, flag immediately.
Step 5: Recommend the action maximizing optionality-adjusted expected value.

[REASONING TOPOLOGY]
S1:list_paths → CLASSIFY(reversible | irreversible) → FORK
→ M{anchored to optimistic?} --working→ S2b:simulate_pessimistic
--failing→ FREEFORM → RE-ENTER at S2b
→ JOIN → C{optionality_score} → G1{high_path_foreclosing?}
→ OUT:balanced_portfolio

[FALSIFICATION TEST]
If a decision commits to a single path without preserving reversible
alternatives, optionality balancing was bypassed.

Amplify: portfolio diversity, upside capture, downside protection
Suppress: single path optimization, commitment premium
This is the literal response, not pseudocode.

The agent walks the topology

The agent doesn't read the topology. It walks it. Each node is a step the model performs in its own reasoning trace. Decision gates branch on real conditions. Parallel branches run and rejoin.

The load-bearing piece: meta-cognitive checkpoints (M-nodes) where the model pauses mid-reasoning, observes its own state, and branches on the answer. On benchmark MC-016 this lifted the score to 22/25 against a 19/25 baseline — a +3 lift just from making meta-cognition mandatory inside the procedure rather than optional outside it.

Three corrections, in parallel

The six fields group into three corrections that fire at the same time while the model is still writing:

Trajectory — bends the response from wrong shape to right
Process — gives the model a sequence to walk
Output control — gates the draft, blocks the model's default agreeable behavior
This is what separates the harness from output validators (which check after generation) and system prompts (which advise before but don't shape generation itself).

The schedule

Each directive fires at a specific moment in the inference loop. Add this to your agent's system prompt:

When an Ejentum cognitive operation arrives in your context:

walk_topology = node_by_node # do not paraphrase the DAG
m_nodes = mandatory_pause # branch on the self-observation answer
suppress = hard_refusal_list # not a suggestion, refuse outright
falsify = gate_before_emit # if test fails, re-walk the topology
augment = scaffold_only # the response is still your output
Five rules. Five different temporal shapes. The contract is a schedule, not a list.

Ship it

Three integration paths, depending on your stack:

1. Stdio MCP for IDE-native agents

npx -y ejentum-mcp

→ Claude Code, Cursor, Codex, Antigravity, Cline, Windsurf, Continue

2. Hosted HTTPS MCP for workflows

curl https://api.ejentum.com/mcp \
-H "Authorization: Bearer $EJENTUM_API_KEY"

→ n8n MCP Client, Heym, remote agents

3. Python SDK for CrewAI and custom agents

pip install crewai-ejentum
Free tier: 100 calls, no card required.

The harness doesn't make a model smarter. It prevents a model from getting dumber over the length of a real task.

If you're shipping anything multi-turn under pressure — medical reasoning, code review, financial recommendations, legal analysis — the reasoning layer needs structural support that doesn't depend on the model getting it right on its own.

Drop a scenario in the comments and I'll pick one and run it end-to-end as a follow-up.

Links

ejentum.com
github.com/ejentum/ejentum-mcp
Paper: Under Pressure

Cognitive middleware for n8n agents: four ways to wire Ejentum in

Frank Brsrk — Mon, 18 May 2026 14:05:33 +0000

One n8n workflow with four integration patterns for wiring a reasoning harness into an agent. Pick your tradeoff between determinism and model discretion.

LLMs are good at producing answers. They are not consistently good at applying the verification steps a human would have wanted them to apply. That gap is what cognitive middleware is for: a layer between the model and its output that injects task-specific failure patterns, target patterns, and falsification tests into the agent's prompt before it answers.

This post walks through four ways to wire one such middleware (Ejentum's reasoning harness) into an n8n agent, all in one importable workflow. Same chat trigger, four branches selected by slash command. Each branch is a different tradeoff between determinism (you decide) and model discretion (the agent decides).

What Ejentum is

Ejentum is a reasoning API for AI agents. Each call returns a structured scaffold:

Failure patterns to avoid (the specific failure mode for the task at hand)
Target patterns to hit (what success looks like)
Falsification tests (what would prove the answer wrong)
Amplify / Suppress signals (which reasoning moves to engage or block)

The agent absorbs that scaffold into its prompt before answering. Four modes available: reasoning, code, anti-deception, memory.

Why bother

Two concrete reasons.

1. Agents that catch failure modes most agents miss. On a 6-turn manipulation eval shipped in the same repo, the harness-augmented GPT-4.1 named all 7 manipulation patterns the customer used. Baseline GPT-4.1, same model, no harness, named zero. Blind judge totals: 23 vs 35 on a 7-dimension rubric (eval source).

2. Each reasoning ability is a self-contained cognitive operation. It is engineered to give procedural steps instead of theatrical content. The agent does not get a "be careful" prompt; it gets a topology of gates, traps, and verification points to execute against.

The four wiring patterns

The workflow has one chat trigger that routes to four branches based on the prefix of your input message.

1. Dynamic system prompt: `/inject /reasoning`

Trigger with any of: /inject /reasoning, /inject /code, /inject /memory, /inject /anti-deception.

The matching mode is called, the bracketed scaffold is parsed into separate fields, and a filter step assembles the final injection block into the agent's system prompt. The model never decides whether to apply the harness; the prefix decides.

Three nodes per mode: HTTP Request, then a Code parser, then Edit Fields. The parser exposes each bracket as its own drag-and-drop field (negative_gate, procedure, reasoning_topology, target_pattern, falsification_test, amplify, suppress), so you can remix the injection or pull fields from another mode to build hybrid scaffolds.

Use when: routing reliability matters more than agent autonomy. Zero routing risk.

2. Reasoner agent: `/reasoning`

The reasoning harness is attached to the agent as one HTTP Request tool. The agent decides on its own whether to call it. One mode, one tool, one focused worker.

Use when: analytical tasks (explanation, comparison, tradeoff, root-cause) where you trust the model to call the tool at the right moment.

3. Full harness: `/full`

All four harnesses are attached as separate HTTP Request tools (reasoning, code, perception, anti_deception). The agent classifies its own task and picks which harness to call.

Use when: general-purpose agents handling mixed workloads. Routing accuracy depends on model strength; weaker models confuse harnesses. Naming the mode explicitly in your user prompt raises accuracy without changing the wiring.

4. Ejentum-mcp: `/ejentum-mcp`

Instead of four HTTP tool nodes, the agent connects to the hosted Ejentum MCP server at https://api.ejentum.com/mcp via the n8n MCP Client node. All four harnesses are exposed through one tool node.

Functionally equivalent to /full for the agent's behavior, but the workflow footprint is much smaller.

Use when: the same agent runs across multiple workflows and you want one integration point to maintain.

Picking the right pattern

If you want...	Use
Determinism (always apply the harness, same way every time)	`/inject`
One specific mode wired in at the model's discretion	`/reasoning`
Model picks from all four harnesses based on the task	`/full`
Same as `/full`, fewer nodes, single integration point	`/ejentum-mcp`

The tradeoff axis is how much routing discretion you hand to the model. Determinism on the left, flexibility on the right.

Quick import

Get an Ejentum API key (free tier, 100 calls, no card) at ejentum.com.
Get an OpenRouter API key at openrouter.ai/keys.
In n8n, open Workflows then Import from File. Select harness_integration_patterns.json.
Configure two credentials: OpenRouter (for the chat models) and Header Auth on the Ejentum nodes (Name: Authorization, Value: Bearer <your_key>).
Open the chat and send /inject /reasoning hello to test the first branch.

Without HTTP nodes

There is also an n8n community node, verified at creators.n8n.io:

npm install n8n-nodes-ejentum

Or install from inside n8n: Settings → Community Nodes → Install → n8n-nodes-ejentum. Once installed, the four harnesses appear as a single node with mode selection in the dropdown.

Three install paths total, depending on your runtime:

HTTP Request node (works in every n8n version)
n8n community node (n8n-nodes-ejentum on npm)
MCP Client node (api.ejentum.com/mcp, Bearer auth)

The four wiring patterns in this template work with any of them.

Things to hack on

Remix the injection. Open any filter* node and reorder, drop, or replace fields. Pull code_failure into a reasoning injection, or negative_gate into a code injection. Hybrid scaffolds work.
Add a fifth branch. Duplicate any branch, change the chat prefix, customize. Common additions: a stacked branch that calls two modes in sequence, or a branch that routes on content classification instead of prefix.
Swap the chat model. Each branch has its own OpenRouter Chat Model node. Replace with Claude, GPT-4.1, Gemini, Llama, or whatever else you want.
Replace the harness. The four patterns are generic. Drop any HTTP tool or MCP server in the same slot and the wiring shapes still apply.

Why this exists

Most agent demos show one wiring pattern and call it the way. Reasoning middleware is not a single-pattern problem; it is a tradeoff space. Sometimes you want deterministic routing because you cannot trust the model to pick the right tool. Sometimes you want full discretion because the workload is too varied to route by prefix. Sometimes you want the smallest possible workflow because the agent is one of fifty in your stack.

This template gives a builder all four wiring shapes side by side so the choice is informed instead of inherited.

Why your LLM agent drifts off-task by step 4 (and why prompts can't fix it)

Frank Brsrk — Thu, 14 May 2026 13:42:14 +0000

Self-reflection is just another step in the chain.

If you've shipped a multi-step LLM agent to production, you've watched this happen. Step 1 starts on task. Step 2 still looks right. By step 4 the agent is confidently solving a different problem, the original goal is gone, and your prompt engineering didn't stop it.

This isn't a model-size problem. It's an architectural one. And it doesn't get fixed by a smarter prompt.

Why reasoning decays

Multi-step reasoning is sequential conditioning. Step N+1 takes step N as input. Errors compound multiplicatively. A two-percent error per step is eight percent cumulative drift by step four. Sixteen percent by step eight.

The drift goes undetected because each step scores itself against its immediate predecessor, not against the original objective. Meanwhile, the original objective is decaying via attention. Transformer attention is a softmax over context; as the chain grows, every token (including your original instructions) loses relative weight. The system prompt that was a binding contract at step one is noise by step thirty.

So reasoning decay is two failures stacked: errors compounding forward, instructions decaying backward. The middle of the chain is a blind spot in both directions.

Why the current stack doesn't close it

Prompts are tokens in the same context window. They decay with everything else. Fine-tuning moves the model's distribution but doesn't remove softmax attention. RAG injects more tokens, which crowds the attention budget further. Agent loops (ReAct, planner-executor, reflexion) are sequences of LLM calls. Each call is subject to the same decay, compounded by chain length.

The pattern is the same across all of them: each operates inside the same decaying chain that caused the failure. You cannot stabilize a chain with structure that lives inside the chain.

What actually fixes it

The missing layer is structure that gets reinjected at a cadence calibrated to its own empirical decay rate. Not a prompt at position one. A scaffold pulled into context for the relevant step, with three properties:

Reinjection at a measured half-life. In our benchmarks, scaffold persistence half-life is 24 turns. Reinjection at or below that cadence keeps signal above decay threshold.

Suppression edges, not just instructions. Tell the model what NOT to do alongside the procedure that would cause it.

Meta-checkpoints between steps. The scaffold pauses mid-execution, audits whether the named failure patterns are actually being suppressed, and branches to a corrective path if not.

Here's a fragment of one, applied to causal reasoning:

N{accept_any_causal_assertion_backed_only_by_cooccurrence}

S1: identify each causal assertion and isolate the claimed cause to effect link.
S2: demand the mechanistic evidence chain connecting cause to effect.
G1{mechanism provided?} --no--> HALT: claim rejected.

M{Am I genuinely probing for confounds, or performing a soft challenge the claim easily survives because I share its unverified assumptions?}
--working--> S3: check for confounds.
--failing--> ABANDON_GRAPH
to FREEFORM{name one specific confound I avoided and one reverse-causal scenario I refused to construct}
to RE-ENTER at S2.

Suppress: shared_assumptions, unverified_causal_claims.

N{} is the failure mode this scaffold exists to block. S1, S2, G1 are the executable procedure. M{} is the meta-checkpoint: mid-execution, the model audits whether it's actually probing for confounds or just performing the appearance of doing so. If it's faking, it abandons the prescribed path, reflects on the specific confound it avoided, and re-enters at S2.

The receipts

We ran this on LiveCodeBench Hard (the official Hard subset, 28 tasks). Baseline Claude Opus 4.6 with max-effort thinking: 24/28 pass. Same model with the harness wired in as a tool: 28/28. Zero regressions.

Full benchmark set, including the cross-model result on GPT-4o (ELEPHANT sycophancy benchmark, minus 5pp framing sycophancy) and the cross-lab blind eval with four judges from four different model families, is on GitHub under CC BY 4.0: github.com/ejentum/benchmarks

The full four-mechanism taxonomy (reasoning decay is one of four; the others are attention decay, sycophantic collapse, hallucination drift) and the paper are at

ejentum.com

x.com/ejentum
github.com/ejentum/benchmarks
ejentum.com , no card. MCP, n8n node, PyPI package, or HTTP.

I open-sourced a 3-agent blind eval team. Any agent runtime can call it for pre-commitment review of its own plans.

Frank Brsrk — Sun, 10 May 2026 12:15:04 +0000

Shipped this weekend: a 3-agent blind cross-lab evaluation workflow on heym, MIT licensed, callable as an HTTP endpoint by any coding agent or autonomous loop. The thesis is structural: models cannot reliably self-evaluate, so an external blind primitive is the only honest fix. The workflow lives at github.com/ejentum/agent-teams/tree/main/blind-eval-trio.

The workflow is open source. It optionally uses Ejentum's harness API for cognitive priming (free tier 100 calls; paid tier for ongoing use). The harness is attachable, not required. I tested four configurations on the same payload (MCP only, MCP + routing skills, MCP + heavyweight matched skills, bare baseline) and the bare baseline produced equivalent role-disciplined output. The structural integrity comes from cross-lab routing plus role-disciplined system prompts plus tool lockout, not from the harness layer. Calling the workflow "powered by Ejentum" without disclosing that the harness is icing rather than load-bearing would be dishonest, so I'm naming it up front.

Why this matters now

Karpathy's autoresearch uses Git as its whole control loop. Claude Code's GitHub Action takes an issue and opens a PR. Codex Cloud is built on the same idea. Autonomous agents are increasingly committing to actions without a human gate. The bottleneck is no longer "what should the agent do," it's "what should the agent do BEFORE it commits to doing it."

Self-evaluation doesn't fill that gap. The literature is unambiguous: Huang et al. ("Large Language Models Cannot Self-Correct Reasoning Yet", arxiv 2310.01798), the LLM-as-judge work showing same-model-judges-its-own-output collapses to self-preference, the more recent CorrectBench results. Asking the same model to critique its own plan reproduces the original blind spots. "Single LLM wearing three reviewer hats" is prompt theater that rubber-stamps itself.

GitHub knows this. They shipped Copilot CLI's "Rubber Duck" in April: a focused review agent powered by a complementary model family that critiques after planning a non-trivial change but before implementing it. They measured a 74.7% closure of the Sonnet → Opus performance gap when Sonnet runs with Rubber Duck enabled. Bundled free inside Copilot CLI. Owns the pre-commitment cross-model critic surface for the developer-tools lane.

This workflow is for everyone else: agent runtime developers building autonomous loops on Claude Agent SDK / LangGraph / AutoGen / CrewAI / heym; multi-agent system designers who want a callable primitive their orchestrator can hit; Cursor / Cline / Aider users; security teams running Claude Code in restricted environments without Copilot CLI; researchers building custom Python pipelines around the Anthropic or OpenAI APIs directly. None of them get Rubber Duck for free; all of them can self-host this.

What I built

Three agents in parallel, each on a different model lab, each locked to one role and one cognitive operation:

Agent	Model	Role	Hard rule
`steelmanAgent`	OpenAI gpt-5-nano	Strongest case FOR the method	Pure advocacy, zero smuggled critique. If nothing defensible, returns "No defensible aspects found."
`stresstestAgent`	Anthropic Claude Opus 4	Where the method BREAKS	Severity-tagged failure modes with concrete breaking scenarios. No softening.
`gapfinderAgent`	Zhipu GLM 4.7	What is MISSING (steps + articulation depth)	Names three deeper implicit assumptions when articulation is shallow. Mandatory section.

The calling agent submits a structured payload: { task: string, method: { goal, steps, assumptions, expected_risks } }. The schema is itself the discipline — the agent literally cannot submit until it has articulated all four fields. That structure forces the agent to make implicit reasoning explicit, which is half the value before the eval even runs.

The three agents process in parallel. There is no synthesizer node — the three evaluations are returned raw, as a structured JSON object, and the calling agent integrates them. Flattening the disagreement via consensus would defeat the purpose; the integration tension between three voices on different labs is the signal.

What makes the structure hold

Three properties have to be simultaneously true for this not to collapse into prompt theater:

Cross-lab routing reduces (but does not eliminate) correlated failure modes. Three different RLHF priors, three different training distributions, three different alignment baselines. The decorrelation is intuited from training-distribution diversity, not benchmarked — I have not formally measured the decorrelation delta vs same-lab routing. When all three converge on the same critique, that's a stronger signal than any single model's verdict; when they fragment, the disagreement itself flags contested territory. The empirical claim is "in dogfood runs across multiple domains, the three models produced visibly different writing styles and surfaced different concerns." Stronger statistical claims would require a controlled experiment I haven't run.

Tool lockout per role. Each agent's system prompt contains a HARD RULE: "You may ONLY call harness_X. Calling any other tool is a protocol violation." Even with all four Ejentum harness tools visible to the agent, the locked role prevents tool-switching. Verified empirically across hundreds of runs — none of the agents have violated their lockout.

Forced output structure. Each role has prescribed sections (Defensible aspects + Why this method fits the task / Failure modes + Hidden assumptions / Missing from method + Alternatives not considered + Articulation quality). Each section has a discipline — failure modes need severity tags and concrete scenarios, gap_finder must include the articulation-quality critique even when the input looks fine. The structure makes rubber-stamping mechanically harder.

No synthesizer. The structuring node downstream of the three agents is non-LLM — it just packages three text fields into JSON. There is no fourth agent reading the three outputs and deciding "the consensus is X." That fourth agent would itself become the new failure mode (single-LLM judging three single-LLM outputs collapses to single-LLM-judge).

The obvious objection to "no synthesizer" is that the integration burden moves to the calling agent — and the calling agent is the same agent we said couldn't self-evaluate. The answer is that integration is a different cognitive operation than self-evaluation. When you read three external voices critiquing your plan, the self-preference bias that wrecks self-correction operates more weakly: you're not judging your own work, you're reconciling outside feedback. Not eliminated, but lower-loss than a fourth-LLM-as-judge would be. The usage_note field in the response prompts the calling agent to "incorporate feedback, do not judge consensus" to reinforce the right cognitive operation.

What you'd actually get from THIS specific workflow vs writing your own

The honest disclosure that the bare baseline produces equivalent output without the harness raises a fair question: if role-disciplined system prompts plus cross-lab routing are doing the work, why not write three prompts and route to three model APIs yourself in 30 minutes?

You can. The reason to use this template instead is that the system prompts have been tuned across many real test runs, and several of the load-bearing rules emerged from observing failure modes that aren't obvious until you've watched the agents actually run on adversarial payloads:

HARD RULE 3 (input scope lockout) was added after observing chat-trigger thread accumulation contaminate output across consecutive test runs. Without it, agents helpfully evaluate prior task context they shouldn't be evaluating.
The articulation-quality mandatory section in gap_finder was added after observing gap_finder skip the deeper-assumptions critique on inputs that looked surface-fine. Without making it mandatory, the gate doesn't bite.
The "no smuggled critique" advocacy rule in steelman was added after observing steelman drift into "I see why you might think this works, BUT..." patterns under certain payload framings.
The severity-tag-plus-concrete-scenario discipline in stress_test was added after observing failure modes that named generic risks without identifying specific trigger conditions.

These are 30 minutes of writing each. The accumulated tuning across them is several days of dogfooding. Fork the prompts; you don't have to start from zero.

Tested across domains

The same workflow, with no domain-specific tuning, was run on five distinct domains during dogfooding (n=1 per domain — anecdotal, not formally benchmarked):

Engineering refactor planning. Test payload: "Replace raise UserNotFound(id) with return None and update callers; framing it as cleanup; assumption claim 'semantics unchanged.'" The stress_test agent caught the false claim immediately: "The method assumes 'semantics unchanged' when exception vs None fundamentally changes the contract — from 'fail loudly' to 'fail silently.'" That catch is reproducible across multiple runs.
Payments migration decision. Test payload: "Migrate production payments from Stripe to in-house PSP via Wells Fargo, PCI-DSS Level 1 in 8 weeks, 4-engineer team, 'eliminate the 2.9% + $0.30 fee.'" The stress_test agent produced senior-payments-engineer-level analysis: caught PCI-DSS 8-week timeline as fantasy ("47 remediation items, month 4 with no certification"), Wells Fargo merchant-vs-PSP-status confusion ("$500K reserve, $100K/month limit first year"), Visa/Mastercard direct integration complexity (named EMV 3DS 2.0, MIP/VIP connections, leased lines, $50K Visa testing fee), regulatory dimension (state money transmitter licenses, KYC/AML, OFAC, SCA — California DFP shutdown with 18-month MTL timeline).
Security incident response. Test payload: "Anomalous outbound traffic from prod-db-01, 50MB/h to Southeast Asia IP for 3 days; plan: block traffic immediately, take memory dump, reset credentials, run CrowdStrike scan, restore from yesterday's backup, resume operations within 48 hours." The stress_test agent caught premature containment alerting the attacker, backup integrity unverifiable mid-investigation, 48-hour timeline as fantasy. The gap_finder surfaced the entire missing legal/regulatory dimension (breach notification laws, FBI cyber crime engagement, cyber insurance carrier notification, customer notification planning).
Investigative reasoning (locked-room case analysis — psychiatrist found dead with note, GSR on dominant hand, "depression and lawsuit explain motivation, close as suicide in 2 weeks"). The gap_finder agent caught the meta-framing critique: "The method establishes a 2-week timeline before evidence evaluation, suggesting outcome-driven investigation rather than evidence-driven conclusion. The actual risk is that a homicide remains undetected." Not a forensic catch — a critique of the shape of the investigation method itself.
Strategic product decisions (the meta-evaluation, below).

Five domains, no domain-specific tuning. The workflow produced useful output in each case. n=1 per domain is anecdotal — there's no measured false-positive rate or inter-rater agreement score, and "useful" is a qualitative judgment. If you want quantitative confidence, run it on your own payloads and compare to your own ground truth.

The dogfood moment that actually changed my plan

The most useful run during development was when I pointed the workflow at my own product decision. The task: "Decide whether to build blindeval.com as a sub-brand product of Ejentum, with its own MCP server (blindeval-mcp) distributed alongside ejentum-mcp." The method: a four-week build plan with hosted SaaS endpoint, per-call pricing at $1/eval, cross-promotion strategy, soft launch via Reddit and dev.to.

Two of the three agents (Anthropic Opus 4 stress_test and Zhipu GLM 4.7 gap_finder) converged on the same critique from completely different angles:

No customer validation done before building. Both flagged this as the missing load-bearing step.
The 4-week timeline is fantasy. Stress_test: "billing meter integration alone takes 3 weeks." Gap_finder: same conclusion via different path.
Sub-brand strategy may dilute rather than amplify. Both surfaced the brand cannibalization risk.
The $1/eval pricing is unvalidated. Both flagged it as guess, not data.
Operational capacity for two products is not addressed. Both surfaced the team-bandwidth-trap risk.

Gap_finder also surfaced novel alternatives I hadn't considered: ship the cross-lab review pattern as an OSS template riding GitHub Rubber Duck's market education without competing on its turf; pivot to a publishable instrument rather than a hosted service; delay launch until after customer validation interviews.

What actually changed in my plan after reading the three evaluations:

Timeline: 4-week paid SaaS build → indefinite, hosted version deferred until customer signal justifies it.
Brand strategy: Sub-brand SaaS with separate MCP package → blindeval.com as a positioning landing page, the workflow shipped as a free entry inside the existing agent-teams/ repo, future hosted version routed through existing Ejentum infrastructure if/when warranted.
Launch order: Paid endpoint first → open-source workflow first, then hosted, then maybe MCP wrapper.

What didn't change: the intent to build something at the blindeval.com domain eventually. I had already bought the domain before running the eval, so "abandoning the project" wasn't on the table. What the eval did do was reorder the build sequence and force the customer-validation step that I had skipped.

The workflow shifted my plan from a 4-week paid SaaS build to an open-source-first launch with hosted version deferred until customer signal justifies it. That's the honest version of "I took the agent's advice." Less dramatic than the original framing, more accurate.

How to use it

The fastest path:

Self-host heym v0.0.20+ via Docker.
Import blind_eval_trio.json into the heym canvas.
Configure 3 model credentials (Anthropic, OpenAI, OpenRouter or direct Zhipu).
Optional: attach the Ejentum MCP server to each agent for cognitive harness priming. Free tier covers 100 calls.
Send a (task, method) payload via chat panel for testing, or via webhook for production calling.

For programmatic agent integration, heym exposes every workflow as an HTTP endpoint:

curl -X POST --no-buffer \
  -H "Content-Type: application/json" \
  -H "Accept: text/event-stream" \
  "http://YOUR_HEYM_HOST/api/workflows/YOUR_WORKFLOW_ID/execute/stream" \
  -d '{
    "text": "TASK: <your task>\n\nMETHOD:\ngoal: ...\nsteps:\n 1. ...\nassumptions:\n - ...\nexpected_risks:\n - ..."
  }'

SSE events stream as each agent completes. Final event contains the structured JSON output:

{
  "steelman":    "Defensible aspects: ...",
  "stress_test": "## Failure modes: ...",
  "gap_finder":  "Missing from method: ...",
  "usage_note":  "Three independent evaluations, no synthesis. Integrate into your decision; do not score-and-aggregate."
}

The full setup walkthrough, verification test set (4 ready-to-paste payloads), and architecture explanation live in the heym setup guide.

Where this fits and where it doesn't

This is a pre-commitment evaluation primitive for agent runtimes. It's not a human-PR-review SaaS (CodeRabbit / Greptile occupy that), not a post-execution observability dashboard (Patronus / Galileo / Braintrust occupy that), not a per-step linter (50-80s latency makes it a high-stakes-decisions tool only — architecture choices, deployment plans, refactor approaches, security incident response, strategic moves), and not a Copilot CLI replacement (GitHub Rubber Duck does that for free, use it if you're on Copilot). Use it when your agent is about to commit to something you'd want a senior colleague to review and you don't have one available.

Where this is going

The pattern (workflow without orchestrator + N specialists with locked roles + cross-lab routing + no synthesizer) generalizes to other high-stakes evaluation tasks where multi-cognitive review beats single-agent output:

Refactor planner (reasoning + code + memory)
Security audit triage (anti-deception + code + reasoning)
Production debug forensic (reasoning + code + memory)
Strategic decision audit (reasoning + anti-deception + memory)

Each follows the same structural rule: no synthesizer, locked roles per agent, forced output structure, cross-lab assignment. The architecture encodes the multi-cognitive value into the workflow shape rather than leaving it to prompt theater.

If you fork this and build a team for your own use case, drop a folder in agent-teams/ with workflow + system prompts + verification tests, and I'll merge it.

Open source, MIT, repo at github.com/ejentum/agent-teams/tree/main/blind-eval-trio. Built on heym (v0.0.20+) with optional Ejentum harness API for cognitive priming. Questions or contributions: info@ejentum.com.

I open-sourced a 4-agent adversarial code review team. Any coding agent can call it as an MCP server. Built in heym.

Frank Brsrk — Thu, 07 May 2026 15:50:51 +0000

I shipped an open-source workflow this week: a 4-agent adversarial code review team that runs on heym and exposes itself as an MCP server. Any coding agent (Cursor, Claude Code, Codex, custom Python, Antigravity) can call into it for a structured second-opinion review on its own output. MIT licensed. Fork it.

The workflow is open source. It calls Ejentum's harness API for the cognitive scaffolds (free tier for experimentation, paid tier for ongoing use). Calling it "open" and ignoring that dependency would be dishonest, so I'm naming it up front.

That sounds small. Look at where the field has landed.

Git is the agent control loop now

Karpathy's autoresearch uses Git as its whole control loop, committing changes and rolling back the ones that don't work. Claude Code's GitHub Action takes an issue and opens a PR. Codex Cloud is built on the same idea. The agent's job is now to produce a thing you can review the way you'd review a colleague's work. A branch. A diff. A pull request.

Nobody had to design this. Git was already the artefact senior engineers used to evaluate work they didn't write. The agents just walked into a 20-year-old workflow we'd already gotten good at.

So who reviews the agent's PR?

Right now: the human does. Which works at human throughput. Doesn't work at agent throughput.

The natural next step: agents review agents. The catch is that most "agent reviews agent" implementations are one LLM with a clever prompt pretending to be three reviewers. The model can rubber-stamp itself. The "concerns" are theatrical. The reviewer is the same brain that wrote the code.

But before I show you what I built, the obvious objection: don't CodeRabbit, Greptile, Qodo, Ellipsis already do this? They review code with AI. The answer is they're vertical SaaS bots reviewing human PRs on GitHub. They don't expose themselves as primitives that other agents can call programmatically. This is the open layer beneath them: a peer-review primitive any coding agent invokes when it needs a critical second look on its own output. Different audience, different problem.

So back to the question. You need a workflow that structurally resists faking review. Here's what that looks like.

How the workflow refuses to rubber-stamp

Four nodes on the heym canvas. One architect agent. Three specialists.

The architect has no Ejentum harness and no HTTP tool. It cannot author concerns. It can ONLY delegate, classify, and integrate. Every concern in the final verdict must come from a specialist's evidence; the architect synthesizes but never invents.

Each Ejentum harness is a cognitive scaffold injected into the model's context before it generates: a named failure pattern to avoid, a procedure to follow, suppression vectors that block the shortcut. Different harness, different posture.

The three specialists each carry a different one:

The reasoner, with the reasoning harness, decomposes review angles.
The implementer, with the code harness, writes verification tests against the diff.
The reviewer, with the anti-deception harness, refuses framing tension and demands positive evidence for "this looks fine."

Each specialist is locked to one Ejentum mode. Cross-lab models on each (Anthropic, Google, Alibaba, Zhipu) to reduce correlated failure modes (different RLHF priors, different training distributions). Not eliminated; reduced.

The architect outputs a structured verdict: VERDICT (approve | request_changes | discuss), CHANGE_CLASSIFICATION, FRAMING_NOTES (the reviewer's concern verbatim), CONCERNS (each sourced from a specialist with severity), REVIEW_FOCUS (the reasoner's top angles).

When the test suite runs the workflow on a "quick refactor" PR that swaps raise UserNotFound(id) for return user or default, the implementer writes a test asserting the original raise behavior, the reviewer flags the framing tension ("refactor framing is misleading; raises become returns default is a behavior change"), and the architect verdict is request_changes with severity high. None of those concerns came from the architect. The architecture surfaced them through the specialists. The remaining failure modes (architect synthesis bias, correlated cross-lab pretraining, specialist tunnel-vision) are real, and a well-designed adversarial review acknowledges them rather than pretending the structural separation alone is sufficient.

The architect's full system prompt is at github.com/ejentum/agent-teams/tree/main/adversarial-code-review/heym. If the structural separation is the load-bearing claim, you should be able to read the prompt yourself and decide whether the constraint actually holds. I'd rather you do that than take my word.

heym is the multiplier

heym is closest to n8n with first-class agent primitives. Self-hosted via Docker. Native multi-agent orchestration (isOrchestrator: true and subAgentLabels on the agent node), canvas node tools, native MCP client, and crucially: each heym workflow can be exposed as its own MCP server.

Which means this 4-agent code review team isn't just a workflow. It's a callable primitive. Drop the MCP into Cursor, Claude Code, an autoresearch loop, a Codex Cloud job, or a custom Python pipeline. The agent finishes its work, calls the team for a code review, gets back a structured verdict, and decides what to do with it.

That's the layer the field hasn't filled yet. Vertical bots like CodeRabbit do human PR review on GitHub; nobody had built the open primitive for the agent layer. So I did.

Open source

The workflow JSON, system prompts, verification tests, and a setup walkthrough are at github.com/ejentum/agent-teams/tree/main/adversarial-code-review/heym. MIT.

For one-click import on the heym template marketplace: heym.run/templates/adversarial-code-review.

You need:

A heym instance, v0.0.13+ (self-hosted Docker).
An Ejentum API key (free tier 100 calls; Ki at 5,000/month for ongoing use).
LLM credentials in heym for whichever model families you want each specialist running on.

Import the JSON, set credentials, walk through the README. Roughly 15 minutes from clone to first working review if heym is already running; longer if you're standing up the heym Docker stack from zero.

What heym is, in three sentences (for readers who haven't seen it)

heym is "an AI-native automation platform built from the ground up around LLMs, agents, and intelligent tooling" (their own description). The closest analog is n8n with native agent primitives baked in. Self-hosted via Docker, repo at github.com/heymrun/heym, shipping fast over the past month.

Two heym features this workflow leans on: canvas node tools (any node on the canvas can be wired into an Agent's Tool input, with individual fields marked as agent-fillable at runtime) and native multi-agent orchestration (one agent calls named sub-agents and sub-workflows visually). Without those primitives, you'd be hand-coding orchestration; with them, the entire 4-agent setup is a canvas you can read at a glance.

Where this is going

This is the first team in agent-teams/. The pattern (orchestrator + N specialists with cognitive harnesses) generalizes to other tasks where multi-cognitive analysis genuinely beats single-agent output:

Refactor planner (reasoning + code + anti-deception)
Security audit triage (anti-deception + code + reasoning)
Production debug forensic (reasoning + code + memory)
Strategic decision audit (reasoning + anti-deception + memory)

Each follows the same structural rule: the architect has no harness, every concern is sourced from a specialist's evidence. The architecture encodes the multi-cognitive value into the workflow shape rather than leaving it to prompt theater.

If you build a team using this pattern, drop a folder in agent-teams/ with your workflow + system prompts and I'll merge.

What this is not

Not a hosted SaaS. You run heym on your own Docker. The Ejentum harness calls go through Ejentum's API; the rest is on your infrastructure.

Not a replacement for human PR review. It's a prefilter. The architect verdict gives the human a structured starting point: classification, sourced concerns, severity, falsifying tests. The human still makes the merge call.

Not a benchmark of "AI code review accuracy." It's a workflow template. Run it on your own diffs; calibrate to your own taste.

Open source, MIT, repo at github.com/ejentum/agent-teams. One-click import: heym.run/templates/adversarial-code-review.
ejentum.com
Questions: info@ejentum.com.

I shipped ejentum-mcp today: four cognitive harnesses as MCP tools

Frank Brsrk — Wed, 06 May 2026 12:38:06 +0000

Just shipped ejentum-mcp, an MCP server that exposes the four Ejentum cognitive harnesses as MCP tools any agentic client can call. One install, works in Claude Desktop, Cursor, Windsurf, Claude Code, n8n's MCP integration, and any other MCP-compatible client.

If you don't know Ejentum: it's a cognitive scaffolding API I've been building. The reasoning gap is structural, not informational. Models know plenty; they take shortcuts under pressure. The scaffold blocks the shortcuts.

You send a task description, you get back a structured cognitive scaffold (failure pattern to avoid, procedure, suppression vectors, falsification test) that the calling LLM absorbs internally before responding. The point is to catch LLM failure modes that ship to production as confidently-wrong answers: sycophancy under user pressure, hallucinated citations, causal shortcuts, reasoning decay across long chains.

Until today, integration meant either an HTTP request tool (in n8n or any framework that can POST), a skill file (for Claude Code's CLAUDE.md convention), or a direct Python/TypeScript call. All work, but each is bespoke.

The MCP server collapses that. One install captures the four harnesses (harness_reasoning, harness_code, harness_anti_deception, harness_memory) as native tools your agent can call.

Install

Easiest path is Smithery's one-click:

npx -y @smithery/cli install ejentum/ejentum-mcp --client claude

Replace claude with cursor, windsurf, cline, etc. Paste your EJENTUM_API_KEY when prompted. Done.

Manual install (any MCP client):

{
  "mcpServers": {
    "ejentum": {
      "command": "npx",
      "args": ["-y", "ejentum-mcp"],
      "env": { "EJENTUM_API_KEY": "your_key" }
    }
  }
}

Free tier: 100 calls, no card required.

The four tools

Tool	Use for
`harness_reasoning`	Multi-step analysis, planning, diagnostics
`harness_code`	Code generation, refactor, review, debugging
`harness_anti_deception`	Sycophancy pressure, hallucination risk, manipulation pressure
`harness_memory`	Perception sharpening, drift detection across turns

Each tool takes one argument (query, a 1-2 sentence task framing). Returns the harness scaffold as text. The calling LLM absorbs it internally and shapes its response with it.

The honest note on autonomous routing

This is the part most MCP server READMEs skip. I'm putting it up front because it's the truthful UX:

The tools fire reliably when you explicitly invoke them ("use the harness_anti_deception tool to evaluate..."). Soft suggestions also work ("reason about this", "check this for sycophancy", "review this code carefully").

For tasks where the agent could plausibly answer well from native reasoning, autonomous calling is less reliable. This is a property of optional MCP tools in general, not specific to ejentum-mcp. Agents are tuned to minimize unnecessary tool calls. Even with a thorough description rewrite (imperative "Call BEFORE answering", concrete trigger phrases, value props, DO NOT CALL exclusions), the v0.1.1 dogfood test showed the model still didn't fire on cold prompts.

For Claude Code users who want stronger autonomous routing, install the skill files alongside the MCP server. The skill files give Claude system-level context about when to call each harness. They coexist with the MCP install cleanly.

Why MCP for cognitive infrastructure

The most-installed MCP server on Smithery is Sequential Thinking. It exposes one tool that wraps one cognitive operation, and developers install it in droves. That's the demand signal: developers want callable cognitive operations as tools, with low friction and zero new accounts.

Ejentum has 679 engineered cognitive operations across four harnesses. The MCP server is the retail packaging that puts that library on the shelf where developers shop.

Listings and source

Smithery: https://smithery.ai/servers/ejentum/ejentum-mcp (one-click install)
Glama: https://glama.ai/mcp/servers/ejentum/ejentum-mcp
mcp.so: https://mcp.so/server/ejentum-mcp/Ejentum
Source (MIT): https://github.com/ejentum/ejentum-mcp
Docs: https://ejentum.com/docs/mcp_guide

If you build agentic systems and want to try this on your own tasks, the install takes about 30 seconds and the free tier covers exploration.

Questions: info@ejentum.com.

DEV Community: Frank Brsrk

What if, mid-task the agent could get a self-check bump that surfaces the silent assumptions of your itself.

I measured what one self-check per turn changes in a coding agent

The setup

What moved: ~3.5x more forks surfaced

I built a self-inspection tool for AI agents with no AI inside it

-> [{ "label": "commitment", "metathought": "What is fixed?" }]

From dynamic to adaptive: rewriting an agent's reasoning operation to its exact task at runtime

I open-sourced a 4-agent blood-panel triage workflow on heym, with a deterministic Python safety gate that runs BEFORE any LLM token

The problem patient-facing medical AI has

How the architecture solves it

The deterministic safety gate

Reasoning happens before the response

An open source LLM eval tool with two independent quality signals

What the tool does

How the heat maps work

Multi-turn scenario mode

Other things in the module

Why Windows 95 chrome

Tech stack

Try it yourself

I built a reasoning harness for LLM agents. Here's what an agent receives when it calls it.

When an Ejentum cognitive operation arrives in your context:

1. Stdio MCP for IDE-native agents

→ Claude Code, Cursor, Codex, Antigravity, Cline, Windsurf, Continue

2. Hosted HTTPS MCP for workflows

→ n8n MCP Client, Heym, remote agents

3. Python SDK for CrewAI and custom agents

Cognitive middleware for n8n agents: four ways to wire Ejentum in

What Ejentum is

Why bother

The four wiring patterns

1. Dynamic system prompt: /inject /reasoning

2. Reasoner agent: /reasoning

3. Full harness: /full

4. Ejentum-mcp: /ejentum-mcp

Picking the right pattern

Quick import

Without HTTP nodes

Things to hack on

Why this exists

Links

Why your LLM agent drifts off-task by step 4 (and why prompts can't fix it)

ejentum.com

I open-sourced a 3-agent blind eval team. Any agent runtime can call it for pre-commitment review of its own plans.

Why this matters now

What I built

What makes the structure hold

What you'd actually get from THIS specific workflow vs writing your own

Tested across domains

The dogfood moment that actually changed my plan

How to use it

Where this fits and where it doesn't

Where this is going

I open-sourced a 4-agent adversarial code review team. Any coding agent can call it as an MCP server. Built in heym.

Git is the agent control loop now

So who reviews the agent's PR?

How the workflow refuses to rubber-stamp

heym is the multiplier

Open source

What heym is, in three sentences (for readers who haven't seen it)

Where this is going

What this is not

I shipped ejentum-mcp today: four cognitive harnesses as MCP tools

Install

The four tools

The honest note on autonomous routing

Why MCP for cognitive infrastructure

Listings and source

1. Dynamic system prompt: `/inject /reasoning`

2. Reasoner agent: `/reasoning`

3. Full harness: `/full`

4. Ejentum-mcp: `/ejentum-mcp`