A no-code system that cleans, queries, and monitors 3,680 business records.
A business analytics system combining deterministic data workflows, conversational querying, human-review controls, and scheduled operational monitoring across five connected business tables.
The language model interprets the question. Deterministic workflows own the business truth.
Filtering, calculations, aggregations, joins, and anomaly thresholds are handled by workflow logic; the LLM is limited to intent interpretation, explanation, and narrative generation.
Architecture
The system separates probabilistic language-model behavior from deterministic business calculations and controls.
System architecture: deterministic workflows own data quality, calculations, aggregations, and anomaly detection; the language model is limited to intent interpretation, explanation, and narrative generation.
Results
74 / 79
Seeded data issues detected
94% detection rate
68
Records routed to human review
5
Safe corrections automatically applied
30% → 60%
Query accuracy across three evaluation rounds
5.05s
Median query latency
Evaluation exposed both model and workflow failures, which directly informed the final architecture.
Problem
A services business was operating across five disconnected operational tables with 3,680 records, but there was no reliable way for an owner to ask questions across the data or understand what needed attention.
The dataset also contained quality issues that had gone unnoticed, while important business risks such as overdue receivables and client concentration were only visible if someone manually went looking for them.
Clients · Staff · Jobs · Time Entries · Invoices
System
The system scans Clients, Staff, Jobs, Time Entries, and Invoices using deterministic validation rules. Safe corrections are applied automatically, while uncertain or high-risk issues are routed into a human-review exception queue with the source record and issue context preserved.
Business questions are interpreted by an AI agent, but the agent does not calculate answers itself. It routes structured parameters into reusable n8n workflows that perform filtering, counting, sums, averages, grouping, joins, and receivables calculations against the actual Airtable data.
Every Monday morning, the system assembles verified metrics such as outstanding receivables, overdue invoices, active jobs, completed work value, and client exposure. An LLM writes the executive narrative around those verified values, while a separate deterministic threshold engine decides whether an anomaly exists and triggers an alert only when predefined business conditions are breached.
What I Learned
In an early version, the agent fabricated eight client names even though the underlying tools were returning real records. It also produced incorrect counts, sums, and averages when asked to reason over large raw result sets.
My first fix was to introduce a deterministic query workflow for filtering and aggregation. Surprisingly, evaluation accuracy dropped from 30% to 20%. The workflow itself was correct; the agent simply continued choosing the older raw-data tools whenever they remained available.
Removing those tools entirely and constraining the agent to parameterized deterministic operations improved final accuracy to 60%.
That changed the architecture: the language model stopped being the place where business truth was calculated.
Filtering, counting, joins, sums, averages, grouping, and anomaly thresholds moved into deterministic n8n workflows. The model was restricted to interpreting user intent and turning already-verified results into understandable business language.
The reporting layer follows the same rule. Every number in the weekly report and anomaly alert is inserted deterministically before the LLM writes any prose. The model explains the numbers; it does not own them.
Failure Analysis
The project exposed several different failure classes, and each required a different fix.
Fabricated or altered values in otherwise-correct retrieved results
Agent selected the wrong workflow or continued using obsolete raw-data tools
Required tool parameters were missing or incorrectly structured
Inactive sub-workflows and output-schema errors caused deterministic execution failures
Separating these failure modes was important because treating every bad result as “LLM hallucination” would have hidden the actual system problem.
Reliability Limits
Some query responses can still distort the presentation of otherwise-correct retrieved values. In one evaluation, the system substituted “Financial Services” for the source value “Finance” and omitted another valid category entirely.
Final query accuracy reached 60% on the fixed evaluation set. That is a meaningful improvement from the first version, but it is not production-grade reliability.
60%
Final query accuracy
Known limitation, not hidden
Roadmap & Scope
The project uses a synthetic business dataset rather than production company data.
The 3,680 records were intentionally seeded with data-quality issues so detection and remediation behavior could be evaluated.
Time Entries contains 3,000 records and was intentionally excluded from the final conversational query tool.
The goal was to keep the portfolio implementation focused rather than continuously expanding scope.
Current anomaly detection uses fixed business thresholds rather than historical baselines.
A production version would persist weekly snapshots and detect directional changes such as receivables growth, payment delays, utilization shifts, and concentration trends.