Skip to main content

AI Agents

An agent is the reusable entity that carries the configuration of an AI-based check: what role the AI plays, what objective it pursues, what constraints to follow, which model to use. The same agent can be used across several pipelines, via an AI Agent node.

All agents are, as of today, always driven by a language model (LLM) — there is no separate "fully deterministic rule" agent type. What comes closest to that is built into the AI's reasoning via MCP tools: for instance, the hunspell connector (spellchecking) runs systematically and deterministically before the LLM call, and any of its findings not picked up by the AI are injected back afterwards — combining the reliability of a mechanical check with the LLM's reasoning. See MCP Connectors.

Built-in agents

Three business agents ship by default with every organization:

  • Spelling — spelling, grammar and conjugation.
  • Date control — consistency of dates across the document.
  • Price validation — consistency of financial calculations (totals, discounts, VAT…).

Configuring an agent

A manager with the module_manager role (or a legacy role) configures, for each agent:

  • Name and description shown in the interface.
  • Role / Objective / Constraints — three structured fields that make up the prompt sent to the AI (system message, system message addition, and human message respectively), or a raw full prompt in advanced mode.
  • Default AI model (see Language Models).
  • Attached knowledge base, if any (see Knowledge Bases) — automatically queried segment by segment during analysis.
  • Enabled MCP connectors (external tools the AI can invoke during its analysis).
  • Extraction passes — to split the agent's task into several targeted sub-passes (for example, the Spelling agent applies 3 internal sub-passes).
  • Author signature shown on the comments produced in the document.

Each AI Agent node in a pipeline can also locally override (for that pipeline only) the model, the role/objective/constraints, and enable the use of support documents — without changing the shared agent's global configuration.

Learning loop (manager validation)

From the Manager → Validation tab, a manager reviews the annotations produced on a job and can invalidate the incorrect ones (with a comment explaining why) or mark them as a duplicate. A correct annotation needs no action at all: it simply stays in the history.

Invalidating an annotation has two immediate, cumulative effects:

  1. A suppression rule is created for that exact piece of text — it will never be flagged again by that agent, on any future document.
  2. A few-shot example is added to the agent's memory (automatically enabled if it wasn't already): the wrongly-annotated text and the manager's explanation are fed back to the agent on future analyses, to help it avoid repeating the mistake.

This loop lets agents gradually improve with use, without any model retraining — purely through the accumulation of human feedback.