Is ThumbGate a PreToolUse hook, a feedback collector, or a rule engine?

All three, in a loop. ThumbGate is the four-stage loop: (1) Capture — the user clicks 👍 or 👎 on any AI answer, decision, or proposed tool call; (2) Memory — the feedback record lands in a local lesson DB (SQLite + LanceDB vector index) on the user's infrastructure; (3) Rule promotion — recurring 👎 patterns get promoted to deterministic prevention rules via Thompson Sampling, and recurring 👍 patterns become reinforced routing; (4) Enforcement — the promoted rules fire at the PreToolUse hook before the agent's next proposed tool call executes. The PreToolUse hook is one stage of four. Customers buy the loop, not any single stage.

What is decision-layer governance, and why isn't it enough?

Decision-layer governance is anything that asks the model to reason about whether an action is safe: prompt rules embedded in the system prompt, AI 'judge' models that score proposed actions, human-in-the-loop workflow principles, ethics-training modules for the model. All of these can fail in three ways: the model forgets the rule under context compression, the model reasons around the rule as a new edge case, or the model produces output the human approver misses. Sullivan & Cromwell had every form of decision-layer governance — policies, mandatory training, verification requirements — and still filed AI-hallucinated citations with a federal judge in early 2026. Decision-layer governance is necessary. It is not sufficient.

What is action-layer enforcement, and why isn't it enough by itself either?

Action-layer enforcement is a runtime gate that inspects the proposed action (a tool call, a shell command, an outbound API request) before it executes and returns allow / warn / block / route-to-human deterministically — no LLM in the decision path. It catches what decision-layer governance misses. But action-layer enforcement alone is a static rule set. It doesn't learn from the team's actual incidents. It doesn't get sharper after each blocked action. It treats every team the same. The piece that makes the gate yours is the feedback loop that promotes your team's specific patterns into the rule set. Action-layer enforcement is necessary. It is not sufficient either.

Why does the loop matter more than the hook?

Three reasons. First, the loop encodes your team's specific failure patterns — not generic SOC2 boilerplate, not vendor-shipped rules. Every 👎 your attorney or engineer logs becomes part of your firm's governance. Second, the loop survives model upgrades — a rule promoted from a lesson DB lives in your infrastructure, not in a prompt that the next Claude or Gemini release will reinterpret. Third, the loop turns vendor incidents into competitor moats — Sullivan & Cromwell's hallucination is a one-time embarrassment for them; if their lesson DB had captured the pattern and promoted it to a rule, every subsequent intake at every S&C office would have the gate firing the moment a similar advice-shaped output was proposed. The PreToolUse hook is the moment of enforcement. The loop is what makes the moment intelligent.

How does the loop compare to RLHF or fine-tuning the model?

RLHF (Reinforcement Learning from Human Feedback) is decision-layer governance — it adjusts the model's weights so the model is statistically less likely to produce bad output. ThumbGate's loop is the opposite category: it doesn't touch the model. The lesson DB and the promoted rules live outside the model context. A model upgrade resets training-baked safety; rules in the lesson DB survive. RLHF needs millions of examples to shift behavior; one team's 👎 in ThumbGate becomes a rule after a small number of consistent flags (default Thompson Sampling threshold). RLHF is a model-vendor decision; the lesson DB is your team's decision.

The feedback loop is the product. The PreToolUse hook is its endpoint.

6 min read · For engineering leaders, attorneys, and risk teams deciding how to govern AI agents in their environment

TL;DR: ThumbGate isn't a PreToolUse hook with feedback bolted on. It's a four-stage feedback-to-enforcement loop. Capture the user's 👍/👎 on any AI answer → store the lesson locally → promote recurring patterns to deterministic rules → enforce at PreToolUse. The hook is one stage of four. The loop is the product. Decision-layer governance (prompt rules, AI judges, "human in the loop") is necessary but not sufficient — Sullivan & Cromwell had every form of it and still got sanctioned. Action-layer enforcement alone is a static rule set. The loop is what makes the rule set yours.

Two layers that everyone confuses

Most "AI agent governance" conversations are stuck in one of two camps:

Layer	What it does	Why it isn't enough alone
Decision-layer	Prompt rules embedded in the system prompt. AI judge models that score proposed actions. Human-in-the-loop workflow principles. RLHF training that adjusts model weights toward safe output.	The model can forget the rule under context compression, reason around it as a new edge case, or produce output the human approver misses. Decision-layer governance is what Sullivan & Cromwell had when they filed AI-hallucinated citations with a federal judge.
Action-layer	A runtime gate that inspects the proposed tool call (bash, SQL, file write, MCP call, outbound LLM call) at PreToolUse and returns allow / warn / block / route-to-human deterministically.	A static rule set is generic. It doesn't learn from your team's incidents. It doesn't get sharper after each blocked action. Every team gets the same starter pack. The piece that makes the gate yours is missing.

Both layers are necessary. Neither is sufficient. The product that makes them a system is the loop that connects them.

The four-stage feedback-to-enforcement loop

ThumbGate is the loop, not the hook. Four stages, all in your environment, all closing the gap between "the user noticed something was wrong" and "the next agent action that pattern matches is gated automatically."

Stage 1 — Capture The user (attorney, engineer, risk officer) reviews an AI answer — a Claude for Legal drafted clause, a Cursor proposed refactor, a Claude Code shell command, a Codex agent's research summary. They click 👍 (the answer was good) or 👎 (the answer was wrong, unauthorized, or unsafe). One click. The record stores the context, what worked or went wrong, and what should change next time.

Stage 2 — Memory The feedback record lands in a local lesson DB on the team's infrastructure — SQLite with FTS5 for keyword/lexical recall, plus LanceDB for vector/semantic recall. Wins, mistakes, and edge cases all stored. The DB is searchable: when a new agent task matches a prior pattern, the relevant lessons surface as context before the agent answers. Nothing leaves the team's perimeter.

Stage 3 — Rule promotion When a 👎 pattern recurs across distinct sessions, Thompson Sampling promotes it from a one-off lesson to a deterministic prevention rule. Wins reinforce preferred routing the same way. The rule is human-readable and editable — the team's ethics or platform lead can audit, soften, or override it. The promotion logic is deterministic, not a black box.

Stage 4 — Enforcement Promoted rules fire at the PreToolUse hook before the agent's next proposed tool call executes. Allow, warn, block, or route-to-human, with an artifact-level audit log (rule ID, version, matched pattern, audit ID, ISO 27001 control mapping). The user's vote from Stage 1 is now an enforced constraint that fires deterministically before any human is asked to approve again. The loop closes.

Why the loop matters more than any single stage

It encodes your patterns, not vendor boilerplate

Generic governance rules ("don't push to main") are table stakes. The rules that actually matter for your firm or your team are the ones derived from your incidents — the specific UPL phrasing your associates flag, the matter-number conventions your privilege review uses, the deploy commands your platform team blocks. The loop encodes those automatically.

It survives model upgrades and prompt resets

A rule in the prompt vanishes when the next Claude or Gemini release reinterprets context. A rule promoted from your lesson DB lives in your infrastructure, separate from any model vendor. Model upgrades reset training-baked safety; the lesson DB doesn't.

It turns one incident into permanent prevention

Sullivan & Cromwell's hallucination was a one-time embarrassment for them. If their lesson DB had captured the pattern and promoted it to a rule, every subsequent intake across every S&C office would have the gate firing the moment a similar advice-shaped output was proposed. The first 👎 becomes the rule that catches the next ten cases.

It composes with model providers, not against them

Anthropic's Claude for Legal, Harvey's BigLaw assistants, Cursor's agent mode, OpenAI's Codex CLI — all of these are decision-layer products. The loop runs underneath them, agnostic to which vendor generated the proposed action. You don't pick a vendor and live with their generic safety; you pick the vendor for capability and own the safety yourself.

How this differs from RLHF and other "model-side" approaches

RLHF (Reinforcement Learning from Human Feedback) is decision-layer governance — it adjusts the model's weights so the model is statistically less likely to produce bad output. ThumbGate's loop is the opposite category. It doesn't touch the model. The lesson DB and the promoted rules live outside the model context.

Property	RLHF / model fine-tuning	ThumbGate feedback loop
Where the change lives	Inside the model weights	Outside the model, in your lesson DB
Who controls it	Model vendor	Your team
How many examples to shift behavior	Millions	Default Thompson Sampling threshold — a small number of consistent 👎
What happens at model upgrade	Training-baked safety partially resets	Rules survive; loop continues
Auditability	Opaque weights; explainability is best-effort	Rule ID + version + matched pattern + audit ID, deterministic

The loop is the product. The hook is the moment of enforcement. The DB is the memory. The promotion is the learning. Without all four, "agent governance" is either a prompt rule or a static gate — both useful, neither sufficient.

What to do with this if you're evaluating ThumbGate

Don't ask "does it have PreToolUse hooks?" — every governance tool will say yes. Ask "does the gate get sharper after each incident, automatically, in our environment?"
Don't ask "what rules ship out of the box?" — the rules that matter are the ones derived from your team's incidents. Ask "how does a 👎 from one of our reviewers become a rule that fires for everyone next week?"
Don't ask "does it work with Claude?" — ask "does it work with whichever vendor we pick next quarter?" The loop is vendor-agnostic by design.

Install the loop, not just the gate

The PreToolUse hook is the endpoint. The loop is what makes it learn. Two minutes to install.

$ npx thumbgate init

The feedback loop is the product. The PreToolUse hook is its endpoint.

Two layers that everyone confuses

The four-stage feedback-to-enforcement loop

Why the loop matters more than any single stage

It encodes your patterns, not vendor boilerplate

It survives model upgrades and prompt resets

It turns one incident into permanent prevention

It composes with model providers, not against them

How this differs from RLHF and other "model-side" approaches

What to do with this if you're evaluating ThumbGate

Install the loop, not just the gate

Related articles