Critic / Linter Agent

The backend agent that reviews an output against your system's rules and RBAC entitlements — rejecting or correcting anything that hallucinates or violates policy. A firewall agent for AI output.

What Is the Critic / Linter Agent?

The Critic / Linter Agent is one of TotalApp's Core Agents. It reviews an output — from another agent, or from a user-facing generation flow — against the system's rules and the requesting user's RBAC entitlements, rejecting or correcting anything that hallucinates facts or violates policy before it ships.

An agent or a user-facing generator can produce output that reads convincingly but isn't actually correct, or that exposes data the requester isn't entitled to see. The Critic / Linter Agent acts as a shared guardrail — every output passes through the same review step before it reaches a person or a downstream system, rather than trusting each individual producer to self-police.

In one sentence

Give the Critic / Linter Agent an output plus its source data and the requesting user's entitlements — it fact-checks, format-checks, and RBAC-checks it, rejecting or redacting anything that fails before delivery.

How It Works — Two Review Passes

1. Output Review → 2. RBAC Enforcement → 3. Ship, Correct, or Block

Phase	What happens
1. Output Review	Factual claims in the output are checked against the source data it was supposedly built from. Output format and structure are validated against what the downstream step expects.
2. RBAC Enforcement	Output content is cross-checked against the requesting user's actual RBAC entitlements. Anything the user isn't permitted to access is blocked or redacted before delivery.
3. Ship, Correct, or Block	Output that passes both checks ships as-is. Output that fails is corrected where possible, or rejected outright — every block or correction is logged for compliance review.

One shared policy layer, not per-agent logic

Rather than every agent implementing its own fact-checking and permission logic, the Critic / Linter Agent runs as a standard review step on any agent's output — a firewall that works identically across every agent and screen in the platform.

Key Capabilities

Fact-Checks Against Source

Flags claims in an output that aren't backed by the data it was supposedly built from — catching hallucination before it reaches a reader.

RBAC-Aware Redaction

Blocks or redacts output content the requesting user isn't entitled to see, cross-checked against their actual entitlements, not a static allowlist.

Schema & Format Checks

Validates that output structure matches what the next step in the pipeline expects, catching malformed output before it breaks a downstream consumer.

Full Rejection Log

Every block or correction is logged — a complete audit trail of what was caught and why, available for later compliance review.

Output — What You Get Back

Field	Meaning
`verdict`	Whether the reviewed output passed, was corrected, or was blocked outright.
`unsupported_claims`	Any statement in the output not backed by its cited source data.
`redactions`	Content removed or masked because the requesting user's RBAC entitlements didn't cover it.
`rejection_log`	A record of every block or correction, kept for compliance review.

Strictness is configurable per workflow

Not every workflow needs a hard block — some need only a warning surfaced alongside the output. Strictness is configured per workflow so the Critic / Linter Agent's behavior matches how consequential a given output actually is.

Frequently Asked Questions

Does the Critic / Linter Agent review every agent's output, or only specific ones?

It runs as a standard review step that can sit behind any agent's output, not just one specific producer — the same shared guardrail applies platform-wide.

What's the difference between a "correction" and a "block"?

A correction fixes what can be fixed automatically (such as redacting an unauthorized field) and lets the rest of the output through. A block stops delivery entirely when the output can't be safely corrected — which one applies depends on the configured strictness for that workflow.

Is the RBAC check based on a static permission list?

No — it's cross-checked against the requesting user's actual, live RBAC entitlements at the time of the request, the same entitlement model used everywhere else in TotalApp.