Two numbers, same quarter: sales report 1.2 million, invoicing 1.05 million. Neither system is broken – the report is missing deals, and invoices are missing entries. Today, we'll build an agent that finds the differences and shows the source for each of its claims.
This is Agent Lab, and the figures in this video are fictitious illustrative example data. The most important difference to start with: a chat responds to you, an agent receives a goal, reads files itself using tools, and tells you what it couldn't figure out. The workflow is investigate, clean, analyze, verify.
Goal, input, tools, constraints, completion criteria
Start with the task assignment. Reproducible template: Goal: determine why the CRM sales report and invoicing differ for Q3. Input: sales_q3.csv, invoices_q3.xlsx, and the order confirmations folder. Tools: file reading, spreadsheet processing, and text recognition for scanned PDFs. Constraints: do not combine personal identifiers, do not send data to an external service, do not guess missing values. Complete when: every discrepancy is listed with a row reference and source, or marked as unresolved. If evidence is insufficient, do not publish. It is precisely this definition of 'complete' that makes this an agent's task, not a chat query.
First, investigate: what data do we actually have?
The first step is to investigate, not analyze. The agent lists what it actually has: two export files and 41 scanned order confirmations. It reads column names, identifies keys – transaction ID and customer ID – and notes that the confirmations are images, so it extracts IDs, dates, and amounts from the images as text. At the same time, it reports deficiencies: one file is missing a header row, and the date is unclear in two scans. These are not guessed; they are marked.
Clean: IDs, currencies, dates, duplicates
Cleaning is where a poor cross-check is born. The agent normalizes transaction IDs – one system has a hyphen, the other doesn't. Currencies are separated: one transaction is in SEK, and its exchange rate is fetched separately, not converted by gut feeling. Dates are standardized. Duplicates are removed, and each removal is logged. Critical rule: if a row's key cannot be verified, the row does not go into analysis but onto the 'unresolved' list. Cleaning never improves data – it makes it comparable.
Analyze: discrepancy = ID + source + row + amount
Now, the comparison. Every CRM deal with a 'won' status is sought in invoicing. Example data result: six won deals without an invoice, three invoices without a CRM entry, and two discounts without an approver. The most important thing is not the number but the format: each discrepancy appears as a row containing the transaction ID, source file, row number, amount, and a one-sentence justification. At the end of the report, there's a section 'what we cannot conclude'. This is a honesty test – if the report has no uncertainties at all, the agent has likely fabricated something.
Auditor agent evaluates – and rejects if necessary
This requires a separate auditor agent. It doesn't check if the report is pretty, but whether the acceptance criteria are met: does every claim have a source, have the constraints been adhered to, are unnecessary personal data included, are uncertain rows marked. In this example, the auditor finds an error: one discrepancy is based on a SEK amount that was aggregated with EUR amounts – and one unclear scanned date was still used as justification. The auditor does not silently correct. It marks the claim as rejected, returns the task, and says: obtain the original order confirmation or drop the row from the report. If evidence, permissions, or acceptance criteria are insufficient, it publishes nothing – it fails gracefully.
Three takeaways. One: define 'complete' before the agent starts, otherwise you'll get beautiful text but not a verifiable result. Two: cross-checking requires row references and sources for every claim, and 'unresolved' is an acceptable outcome. Three: a separate auditor agent with the power to reject work is the part that makes this safe.
Exercise
Create two small fictitious CSV files (10 rows each): one 'sales' and one 'invoicing', with the same transaction IDs but three deliberate differences (one missing row in each, one different amount). Do not use real customer data. Ask the agent to list discrepancies in the format transaction ID + file + row number + amount + justification, and to mark unclear rows on an 'unresolved' list. Then run through the acceptance checklist and specifically ask: where could this report be wrong?
Checklist
- Every discrepancy claim has a source file and a row number – no claim without traceability.
- Unclear or missing values are marked as unresolved, not guessed or filled by assumption.
- Currencies, date formats, and identifiers are normalized before aggregation, and conversions are logged.
- The report includes a separate 'what we cannot conclude' section, and it is empty only if all rows are fully validated.
- Personal data has not been unnecessarily transferred, nor have passwords been given to the agent; the auditor has re-run the same criteria and either approved or rejected the work.
— Aino Pilvi, AI-asiantuntija, Cloud Computing Oy
Kysyttävää? aino@cloudcomputing.fi | WhatsApp: +358 33 119 3196
