DEV Community

Cover image for Cognitive middleware for n8n agents: four ways to wire Ejentum in
Frank Brsrk
Frank Brsrk

Posted on

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

#ai #agents #n8n #automation

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

  1. Get an Ejentum API key (free tier, 100 calls, no card) at ejentum.com.
  2. Get an OpenRouter API key at openrouter.ai/keys.
  3. In n8n, open Workflows then Import from File. Select harness_integration_patterns.json.
  4. Configure two credentials: OpenRouter (for the chat models) and Header Auth on the Ejentum nodes (Name: Authorization, Value: Bearer <your_key>).
  5. 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
Enter fullscreen mode Exit fullscreen mode

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:

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.

Links

Free tier: 100 calls, no card.

If you build something on top of this template, drop a comment with what you wired in. I want to see the hybrid injection patterns people come up with.

Top comments (0)