Get a personalized demo of Stuut and see how it can help with AR automation.
If you've logged into Stuut recently, you've probably noticed a new face in the top-left corner of the dashboard — our logo, bouncing left and right, waiting to say hi. That's Ask Stuut, your AI analyst that answers questions about your accounts receivable in plain English:
Chatbots that answer questions about your data are easy to demo and hard to trust. The failure mode is well known: hand a language model raw database access, and it will confidently join the wrong tables, mix currencies, double-count partial payments, and return a number that looks plausible. For a finance product, plausible-but-wrong is worse than no answer at all.
So we built a governed data platform, and put a tightly-scoped agent on top of it. This post walks through the four layers that make that work.
.png)
Ask Stuut never touches the operational database. Change data capture streams every table from our application database into a dedicated analytics warehouse in near real time, landing in a raw schema that preserves the source shape (including soft-delete markers, which we filter at the next layer).
This separation matters for more than performance isolation. The raw layer is an immutable, replayable record — every downstream transformation can be rebuilt from scratch, and analytical queries can never degrade the app your collections team is working in.
Raw production tables are the right shape for running the application, but the wrong surface for analytics — answering a domain question like "was this invoice collected by Stuut?" involves complex joins, business logic that lives in application code, and transformations you don't want re-derived (differently) in every query. A version-controlled transformation pipeline rebuilds the raw data into analytics-ready tables through three layers: staging (clean, rename, type-cast), intermediate (business logic), and marts (wide, query-ready fact and dimension tables).
This is where the hard semantics get resolved once, in reviewed and tested code, instead of at query time by a language model. A few examples:
The pipeline ships with data tests — including reconciliation tests that assert warehouse numbers match what the application itself reports — and every mart carries a row access policy that filters reads to a single organization. More on why that's load-bearing below.
Between the marts and the agent sits a semantic layer: warehouse-native objects that declare, in DDL, exactly which tables an agent may query, which columns are dimensions, which are metrics (with their aggregation functions), and, most critically, a natural-language description of every one of them.
We maintain multiple semantic views, one per product domain:
Each is defined in the same repository as the transformation models and deployed by the same pipeline, so a change to a mart and the semantic view that exposes it ship atomically. The semantic layer is the single source of truth for governed metrics, there is no second definition of "DSO" hiding in a dashboard somewhere.
This is the layer that makes text-to-SQL reliable. The agent doesn't explore a database; it selects from a curated menu of described metrics and dimensions whose grain and aggregation rules are fixed ahead of time.
We also have a library of verified queries covering common analytical questions with the correct SQL for each, which has improved answer accuracy, response time, and token efficiency.
Ask Stuut isn't a single model trying to know everything about AR — it's one agent orchestrating a team of domain experts, all running inside the warehouse's managed agent harness:
Two implementation choices we'd recommend to anyone building something similar:
A thin streaming API in our backend fronts the agent: it authenticates the user, translates the agent's event stream into our dashboard's chat protocol, persists conversations, and handles the unglamorous edges — timeouts, disconnects, retries — so a deploy never eats an answer mid-stream.
We created multiple REST Agent API to serve multiple use cases:
Every agent run is traced end to end: general application telemetry on one platform, and LLM-specific traces — token usage, latency, per-tool calls, prompt and response inspection — forwarded to a dedicated eval platform. Each response carries a request_id tying our logs to the runtime's usage history, and in-product thumbs up/down feedback is persisted alongside the conversation. Together, traces and feedback give us the raw material for evals — real questions with known-good answers that we can score routing and accuracy against as the agent evolves.
We're not stopping at data pulls. Today Ask Stuut is deliberately read-only — it reports, you decide. The next chapters push further up the value chain: root-cause analysis ("why did DSO jump?", not just "it jumped"), actionable recommendations grounded in your own data, and eventually taking action — drafting the outreach, adjusting the workflow — once you approve it. Each step will get the same treatment as the rebuild itself: guardrails first, capability second.
We also want your best questions to compound. Soon you'll be able to save prompts, charts, and tables as reusable artifacts — so the analysis you built last month is one click away, not one conversation away.
The interesting engineering in Ask Stuut isn't the chat window — it's everything underneath it. The agent is reliable because it's the last layer of a governed stack: tested transformations resolve the hard semantics, semantic views constrain what can be queried, database-level policies enforce tenancy, and version control governs every prompt and metric definition.
Bounce on the logo and ask it something — and if it gets anything wrong, that thumbs-down button goes straight into our eval set.
If you're a Stuut customer, reach out to your account team to get a demo of Ask Stuut. If you're not yet working with us, this is a good reason to start a conversation.
