Harness, loop, graph: three words everyone mixes up, and the gate that ties them together

Everyone building with AI agents now uses three words: harness, loop and graph. They are often used as if they meant the same thing. They don't, and the difference decides whether you can trust what your agents do.

Here is how I separate them, what each one is not, and how we tie all three together under one governed gate.

The harness: what the model sits in

A harness is everything wrapped around a model so it can do work: the tools it can call, the files it can read, the credentials it holds, the channels it talks through. Claude Code, Cursor and Copilot are harnesses.

What it is not: a harness is not governance. It decides what an agent can reach, not whether a particular action should happen. And it is not where your organisation's knowledge should live, because harnesses change as often as models do.

The loop: what the agent does over time

A loop is the cycle an agent runs: plan, act, observe, retry, until the task is done or it gives up.

What it is not: a loop is not learning. An agent that retries a hundred times has not learned anything unless something outside the loop decides which result deserves to be remembered. And a loop that only checks itself is marking its own homework.

The graph: what the organisation remembers

A graph is durable, typed state: documents, policies, code, decisions and lessons, with the relationships between them made explicit.

What it is not: a graph is not truth. Memory is not the same as correctness, and retrieved is not the same as trusted. A graph that anyone can write into without checks becomes a very organised way to keep mistakes.

How we tie them together

In GraQle the graph is the constant. The harness is the interface and the model is a swappable input. Change the model or the IDE and the graph is unchanged.

The loop runs through the graph, not beside it, in five named phases: ANCHOR, ACTIVATE, GENERATE, VALIDATE, COMMIT. Before a model runs, a pre-reasoning layer selects the relevant part of the graph instead of the whole repository. After it runs, answers below a confidence floor are refused rather than guessed. Lessons and decisions that survive go back into the graph, so the next loop starts from what the organisation already knows.

One caveat we state ourselves: when several agents debate, their agreement is not independent confirmation if they share a model family, a prompt or a source.

The gate between intent and action

Reading is low-stakes. Writing and acting are not. So the part I care most about sits between "the agent wants to do X" and "X happens".

Most governance systems blend several risk signals into one weighted score. That can be gamed: high marks on easy checks can hide one condition that should have stopped everything.

The design we published works the other way. An action passes through an ordered set of independent hard gates. Each gate asks one yes-or-no question, and any single NO stops execution:

• ✕ Is there an applicable policy, still valid and not contradicted?
• ✕ Is any evidence the action depends on invalidated?
• ✕ Does a high-impact action have provenance?
• ✕ Are the arguments the ones that were approved?
• ✕ Is a source poisoned?
• ✕ Is the actor authorised?
• ✕ Is there an unresolved material contradiction?

Four rules make it hard to bend. It is non-compensatory: no good score elsewhere offsets a failed gate. It never short-circuits: every gate runs, so the record of reasons is complete. It fails closed: a missing input, an error or a timeout counts as NO, never YES. And when any gate fails, a critical-failure cap bounds every later score, and no later stage can lift it.

Every gate also writes a determinism record: a hash of exactly what it read, its rule version and a commitment to the configuration. The decision can be replayed later without revealing the configured values.

The outcome is one of five: execute, replan, hold, reject or escalate. Execute is impossible when any gate failed, and that rule is enforced in the verdict schema itself, not left to good behaviour.

What is shipped and what is design

The verdict schema is public in the GraQle SDK from version 0.84.1, behind a feature flag that is off by default. The gates themselves are a design disclosure: written down in full and not yet implemented. No experiment has been run and there are no effectiveness numbers.

We published the design as a defensive publication on purpose. Anyone may implement it.

After the action: record and learn

For deployed systems, GraQle records what the AI decided out of band: canonicalised, Merkle-rooted, signed and anchored to a public transparency log, so a third party can verify a record without access to your infrastructure or ours.

The principle I work to on the other side of the action: an outcome is an observation, not a lesson. Only a validated lesson should change what the organisation believes. Two gates, one before the action and one before learning, with independent evidence in between.

What this is not

Not a smarter model. Not a claim that anything is "compliant". Not a proof that an answer is true. Not a finished product in every part: the gate design above is published ahead of its implementation, and says so.

It is the system around the model: memory, authority, an independent check, and a way to learn without becoming wrong faster.

My company builds this software and has pending European patent applications in this area, so weigh the argument accordingly. The SDK is source-available.

The design disclosure, free to read:

https://github.com/quantamixsol/graqle/blob/master/docs/dag/defensive-publication.md

If you are building a gate for agent actions: which of the seven questions would you add or drop?

By Harish Kumar, Founder, Quantamix Solutions B.V.