Validation & Exceptions
How Trelium agents check their work against your business rules before acting. Covers what a check is, what an exception is, where exceptions go, and how checks decide what needs a person.
Before a Trelium agent enters anything into your systems, it checks its work against your business rules. When a check fails, the agent does not quietly carry on. It flags an exception and sends it on for attention. This is the part of the workflow that keeps AI's reading from turning into a wrong entry.
What is validation?
Validation is stage 5 of the eight stages. By this point the agent has a draft, such as an order pulled out of an email. Validation compares that draft with your rules before anything is entered. Typical checks ask:
- Does this product exist in your system?
- Does the price match what was agreed with this customer?
- Is the quantity within the limits your team set for this customer?
- Does this invoice match the purchase order it belongs to?
- Does the request have everything the agent needs?
The rules are set when the agent is built, and the agent follows them the same way every time. AI can read a messy email, but it cannot skip a rule.
AI reads. Rules decide.
AI produces a draft. Your rules decide whether the draft is good enough to act on.
What is an exception?
An exception is a case that failed a check or does not fit the normal pattern, so it needs attention. An exception is not an error in the software. It is the agent doing its job by noticing something that does not look right. Common examples:
- A price that does not match what was agreed
- A product the agent cannot find
- A quantity outside the limits your team set for this customer
- A request that is unclear or missing something
- An email that matches more than one order, or none
What happens to an exception
When a check fails, the run does not quietly continue to the step that updates your systems. What it does instead is set in the workflow: it can block the write, flag the mismatch, ask for a missing detail, or send the case for review. The reviewer sees what the agent proposes and why it was flagged, so they do not have to start from scratch. A failed business check is not the same as a technical run failure; the Activity log can still show the steps that ran, such as sending a review email. See Human in the Loop.
flowchart LR
A[4. Reason draft ready] --> B{5. Validate}
B -->|Passes| C[7. Update systems]
B -->|Fails| D[Exception] --> E[6. Human review]
E -->|Approved, or detail supplied| C
A person might approve the agent's proposal as it is, or they might give the agent a missing detail so the run can carry on. In the Slack company-check example on How Trelium Works, the agent asks which company was meant when Apollo finds no match or several. The person is not approving a result there. They are supplying the missing information.
Example: two POs that fail different checks
Two customer POs arrive on the same morning. The first has two lines priced about 6 percent below the agreed price. The price check fails, so the agent raises an exception. A person sees the two lines highlighted and decides what to do.
The second is for 4,000 units of an item. Your team set a limit of 1,000 units per order for this customer, so the quantity check fails. A person confirms it is not a typo before anything is submitted. A third PO with every item in the system and every price at the agreed rate passes every check and goes through without review.
Example: an invoice that does not match its PO
Validation also applies to finance work. A supplier invoice arrives for 100 units. The agent finds the purchase order it belongs to, which was for 80 units. The quantity check fails, so the agent raises an exception instead of recording the invoice. A person decides whether to accept the extra 20 units or go back to the supplier. Invoices that match their PO on items, quantities, and prices pass without review. The Invoice Matching recipe walks through this workflow in full. Figures in these examples are invented for illustration.
Not every check sends work to a person
Some failures need a person, such as a price that does not match. Others may only need the agent to ask for a missing detail, as in the Slack example above. Some steps are always sent for approval, even when every check passes.
Setting good rules
- Start strict. Begin with checks and review around most steps. Remove a review only for a step you have seen the agent get right many times.
- Base checks on real exceptions. Look at the unusual cases your team actually sees, not only the clean ones.
- Loosen over time. As the agent handles your real exceptions well, let more of the workflow run on its own.
What is recorded
Every run is recorded in the agent's Activity log, including the steps it took, when each step ran, and how the run turned out. The log is the agent's steps and outcome, not a full native record of who approved, edited, or rejected a case. Keep that human record in your own tools if you need it, or ask what your workflow writes elsewhere. See Logs & Audit Trails.
Words used on this page
- Validation: checking the agent's draft against your business rules before anything is entered.
- Exception: a case that failed a check or does not fit the normal pattern, so it needs attention.
- Business rule: a condition that defines what counts as correct, such as an agreed price or a quantity limit for a customer.
- Activity log: the record of each run, with its steps and outcome.
Where to go next
Testing a Workflow
Use past work to check a workflow's results, test how it handles problem cases, and decide what is safe to put into use.
Define a Workflow
How to write down a job before a Trelium agent takes it on. Covers the eight things to write down (what starts the job, what comes in, which software is used, the steps, the rules, what can go wrong, where a person signs off, and the finished result), a filled-in example for entering purchase orders, and a blank template to copy.