Meet Albert — a focused specialist, not a generic chatbot
Albert, the Meles data agent, does one job: he turns vague business questions into validated source mappings, scoped read-only queries, and documented handoffs to reporting. He works only with trusted business context — your data model, your definitions, your access rules — and he writes his assumptions down. Two complete sample reports are on this page, below the interactive demo.
Five steps from vague question to documented answer
This is the fixed shape of every agent interaction. The agent never skips from question to answer — the steps in between are where the trust comes from.
-
Take the vague question seriously
"Why don't these numbers match?" is a legitimate starting point. The agent's first job is to make the question precise: which report, which figure, which period, compared against what.
-
Map it to validated sources
The agent checks metadata first — which tables and measures are involved, how each is defined in the semantic model, when the data was last refreshed. No querying yet.
-
State assumptions and confirm scope
Before touching data, the agent writes down what it's about to assume — definitions, filters, date ranges — and asks for confirmation. Wrong assumptions get caught here, not in the answer.
-
Run a scoped, read-only query
Aggregations and summaries, not raw record dumps. Sensitive fields — customer names, vendor details, ledger line specifics — stay out of the output unless explicitly approved.
-
Hand off with documentation
The result includes the finding, the query scope, the assumptions made, and — where useful — a proposal for a permanent report so the same question never needs asking twice.
Scenario: a report that doesn't match the ledger
Step through a scripted example of the workflow above. This simulation runs entirely in your browser — the dialogue is pre-written and the figures are sample data. No live systems, no real data, no AI model behind it.
You play the finance lead. The agent's replies are scripted to show the workflow.
What the agent's output actually looks like
Two complete reports and one live application, all produced under Albert’s working rules on fictional data — the same structure, definitions, and Data Basis documentation a real engagement produces. Fictional by design: it's the same confidentiality posture the agent applies to client data.
Revenue Reconciliation Statement
The "two revenue figures" problem resolved: a monthly bridge from dashboard to ledger, closed to zero unexplained residual, with every definition written down.
Month-End Close & Data Readiness
Tie-outs, pipeline outcomes, freshness, and close blockers — whether the data can be trusted before anyone reports with it. Includes one failed check, its root cause, and the fix.
AR Control Tower
A running accounts-receivable application: open positions, aging, customer risk and recommended actions — filter, slice and drill through the same fictional dataset the reports use.
The two reports reconcile with each other — one data model, one set of numbers. Reports like these are one of three delivery formats, alongside governed Power BI and interactive drilldown apps. About the demo report library →
The boundaries are the product
An agent near finance data is only useful if it's safe by construction. These rules are not settings a user can talk the agent out of — they're how the access is built.
Access rules
- Production finance systems are read-only unless a change is explicitly scoped and approved by the data owner.
- The agent queries the governed data layer and semantic model — never raw production databases directly.
- Access runs through your identity and permission model; the agent can't see more than the role it's given.
Data handling
- Sensitive finance, vendor, customer, ledger, invoice, payment and security data is protected by default.
- The agent prefers metadata checks, scoped queries, summaries and sanitized outputs over raw record access.
- Every answer documents its sources, scope and assumptions — so it can be checked, not just believed.
Most assistants answer. Albert inspects.
The difference between a chatbot and a data agent isn't the model — it's the discipline around it.
Inspection over recall
Most AI assistants answer from memory. Albert inspects: schemas, metadata, refresh status and documented definitions — before any query runs.
Artifacts over text
Most copilots generate prose. Albert builds things you keep: scripts, reconciliations, diagrams and reports — each with its sources and assumptions written down.
Durable, not disposable
Most agents forget context between sessions. Albert keeps durable workspace memory and metadata indexes, so answers get faster and more consistent over time instead of starting from zero.
The grain is the point
Most enterprise AI demos ignore source grain. Albert cares about legal entity, voucher, invoice, settlement, currency, date basis and workflow state — because that's where wrong numbers come from.
Albert is the reference implementation. A client engagement builds your agent on the same rules — your data model, your definitions, your access boundaries. Albert turns ERP complexity into verified, reusable business intelligence.
Curious what this looks like on your data?
Agents are the last step, not the first — they need a governed foundation to stand on. A short conversation about your current setup shows how far away that is.