Introducing dotDash
Most teams adopting generative AI end up with the same architecture by accident: data in a warehouse, a spreadsheet of rules someone maintains by hand, a BI tool on top, a chatbot somewhere else, and a growing pile of glue holding them together. Each part works. The seams are where the effort goes — and where the audit questions land.
dotDash exists because those parts belong in one system.
What it is
dotDash is a platform for running AI agents against your business data without losing control of either. Four moving parts share the same identity model, the same data and the same audit trail:
- Data. Files, databases and APIs land in collections — typed, batched and sealed, so a figure always traces back to the batch it came from. Rules classify the predictable part; what they cannot place lands in an exceptions queue instead of disappearing.
- Rules. Deterministic, versioned and auditable. A published rule set does the monthly work the same way every month, every classified record names the rule that decided it, and a change is a new version — not an edit nobody can find.
- Dashboards. KPIs, charts and tables over your collections. Click a member and the rest of the dashboard rescopes to it; break a figure down through its hierarchy to the lines behind it. Nothing on screen is a black box.
- Workflows, agents and conversations. Compose agents, tools and approvals on a canvas. Agents act through the Model Context Protocol — query collections, search documents, call your integrations — and the same assistant answers in web chat, WhatsApp Business and Slack, grounded in your documents and collections.
Because they are one system, a sealed batch can start a workflow, the workflow can classify it, an agent can propose rules for what the classification missed, and the dashboard moves the moment those rules publish — without a webhook in the middle translating between four products.
Agents propose. People decide.
Automation that cannot be stopped is not automation anyone will approve. In dotDash an agent can only propose: a rule, an action, a change. The proposal arrives in a person's Inbox with the evidence behind it, and a named reviewer accepts, modifies or rejects it — with the reason kept on the record. Approving does not publish; approved changes collect into a draft the reviewer publishes deliberately, so twenty approvals make one versioned change, not twenty.
A workflow can pause the same way: the run halts on an approval step, the approver decides in-product, and execution resumes from exactly where it stopped. Nothing is re-run and nothing is lost.
And every agent step, tool call and model response is recorded, so when someone asks why the system did what it did, the trace is there.
Built for more than one team
Your data is separated from every other customer's, and that separation is enforced by the database itself: rows are scoped to your organisation by Postgres row-level security, not by an application filter someone could forget to write. On top of that sit workspaces, role-based access, MFA and an append-only audit trail — so several teams can work in one organisation without sharing anything they should not.
Configuration travels the same way: data types, rules, workflows and dashboards ship together as a bundle, imported into a workspace with a plan preview of exactly what will change before anything is created.
Usage you can see
Processing units, search queries, storage and seats are metered and visible in-product as they accrue. Exceeding an allotment adds to the invoice at a published rate; it never blocks a workflow mid-run. We think a bill should be predictable before it arrives, not explicable afterwards.
Every plan includes the full REST API and its published OpenAPI spec. API access is not a tier here.
Getting started
Talk to us and we will set you up against your own data. Describing what you are trying to automate — and what a person needs to approve along the way — is usually enough for us to show you the shape of the answer.
