Cloud, or your own hardware
The same product runs both ways.
In the cloud, models are configured for you and billed through credits.
On your own hardware, everything stays inside your perimeter - and you connect your own models: an open-weight checkpoint you run yourself, or any provider with an OpenAI-compatible endpoint. No data leaves for analysis, because the analysis happens where the data already is.
There is no reduced edition on-prem. The same agents, the same skills, the same tool access, the same audit. See Privacy and on-prem for the hardware this actually takes - published, not "contact us".
A set of specialists, not one chat
A single general assistant is a compromise: instructions that must cover everything cover nothing precisely, and a tool list that includes everything makes wrong choices.
So there are separate agents, each with its own instructions and its own scope of what it may touch:
Nova is the one you meet first - the lead agent, and the one that routes. It handles general data work itself and passes a question to a specialist when the question belongs to one.
The specialists are domain agents, and the set is not fixed:
| Kind | What it is for |
|---|---|
| HR | Headcount, turnover, payroll, recruiting, performance |
| Sales | Revenue, funnels, LTV and CAC, cohorts, churn |
| Processes | Designing processes, tasks, catalogues, org structure |
| Data engineering | Data models, the semantic layer, ETL, query design |
| Visualisation | Charts, dashboards, colour schemes, annotations |
Several ship with the platform, and an administrator adds their own: a domain, a set of instructions, a scope of what it may touch. A finance agent, a procurement agent, a support agent - whatever the company actually has.
The right one is chosen for you. Routing looks at the domain of the data in front of you, then at what you actually wrote, and falls back to a fast classification step. The chosen agent is pinned for the conversation, and you can switch it from a menu at any point.
And they work with each other. One agent can ask another a focused question and keep the conversation, or hand the conversation over entirely when the subject has changed. You do not manage that; you see the answer.
The difference between guessing and acting
A language model on its own produces text that looks like an answer. Ask it about your revenue and it will write a confident number.
Here a request becomes an operation - a declared action in the platform, with named parameters, checked against your permissions, executed, and recorded.
| A model alone | An AIpril agent |
|---|---|
| Writes a number that looks right | Runs a query through the platform's engine and reports what came back |
| Describes what a process could look like | Creates the process, with its statuses, forms and routing |
| Suggests a chart | Builds the chart on the dashboard, bound to the data |
| Says it sent the notification | Sends it through a connector, and the send is in the record |
| Has no idea what you may see | Sees exactly what you may see, because access is applied to the query |
| Cannot be audited | Every call, its parameters, its cost and its outcome are on the audit trail |
Two consequences:
- It cannot invent a capability. An agent can only call operations that exist, with the parameters they declare. There is no path where it improvises an action that the platform does not have.
- It cannot exceed the person asking. Row-level rules and column masks are applied to the query, for the identity asking. An agent working for a regional manager sees that region.
What agents can do
Skills are the vocabulary. A sample of what ships:
Working with data
- Query a data model and return the rows or the aggregate
- Read the structure of a dataset and list what is available
- Filter the table you are looking at, by describing the filter
- Build a chart or assemble a dashboard
Working with processes
- Create a business process with its stages, forms and routing
- Fetch a task, its status, or a readable summary of what is outstanding
- Move a task, update a field, comment on a record
Working with records and text
- Extract structured facts from a block of text - a letter, a document, a message
- Update a record from evidence, keeping the evidence attached
- Find and merge duplicates across records
Reaching outside
- Notify a person or a channel in Slack or Telegram
- Read a balance from the ledger
- Read rows from a spreadsheet
- Call an external service through an installed connector or an installed third-party skill
Your own team can add skills, and a catalogue of installable ones exists. See Skills.
Why the answers are about your data
An agent is not guessing what your tables mean from their column names.
Every dataset is scanned when it arrives and re-scanned on demand. The scan works out what the data is about, what business domain it belongs to, what it is useful for, which query shapes actually work against it, and which business rules hold that no column type expresses - a status that only follows another status, an amount that is always net, a code that identifies a customer rather than an order.
The important part for a business reader: agents do not invent queries. They work from stored query patterns for that dataset, which is the difference between an answer that is right and an answer that is plausible. A model asked to write SQL against an unfamiliar schema invents joins; a model given the patterns that work does not have to.
And it accumulates. What worked is kept as a fourth layer of knowledge next to the dataset context, the patterns and the rules, so the same question asked next month is answered from what was learned instead of rediscovered.
The detail is on Data scanning and retrieval.
Where you meet them
Not in one window. The same agents appear where the work is:
| Where | What it does there |
|---|---|
| Chat | Free dialogue, cross-domain questions, mentioning a dataset by name |
| A table you are exploring | Anomalies, trends, filters, calculated fields |
| The chart lab | Describe a chart and get it, including chart types nobody prepared |
| The data model editor | Build models and metrics through dialogue |
| A dashboard | Edit it, arrange widgets, add what is missing |
| A dataset card | See what the scan found, trigger a re-scan |
| Your own AI tools | Through an MCP endpoint - Claude Desktop, Cursor, or something you wrote |
All of them stream as they work, take file attachments, keep the conversation, and use the same skills.
And they run under rules
This is the part that makes it usable in a company instead of a demo:
- A budget per employee, with a hard monthly limit and suspension. See Budgets and metering.
- Approval in front of consequential actions, which denies when nobody can answer it instead of proceeding. See The invocation contour.
- A record of everything - what was asked, which model answered, what it called, what it cost. See The decision trace.
- A mandate, so an AI employee is limited to a subset of the authority of the person accountable for it. See AI organisation.