What you get — AIpril

What an application knows on the day it is installed

Most software arrives empty and asks you to fill it in. Here the parts that are the same in every company are already connected.

Your people and your structure. The app knows who works here, in which department, in which position, who stands in for whom. A route that says "the head of the requester's department" resolves against the real org structure, and keeps resolving correctly when somebody moves. See also Master data for the catalogues it reads.
Responsibility, assigned and not typed in. A request has an owner, a watcher, an approver - resolved from the structure or named on the form, with substitution when somebody is away.
A process, not a status field. Requests move through statuses with conditions, approvals, timers and automations attached to the moves. See Processes.
Forms that are the record. Real field types - references to actual employees and catalogue entries, attachments, computed values, validation. See Forms and records.
Its own reporting. The app's records are queryable the moment they exist, so the dashboard is part of the application, not a separate project. See Analytics.
Notifications that reach people where they are - Slack, Telegram or email. And from Telegram or email it works both ways: a reply there comes back as a comment on the record.

What it can reach outside

An application is not sealed. It can call the systems you already run, and the world.

Any HTTP service, as a step in a process or a scheduled scenario.
Ready connectors - messengers, mail, databases, file storage, spreadsheets.
Enrichment and research. Services like Apollo.io plug in as ordinary connectors: enrich a contact card, find the people at a company by role, look companies up by industry, size and location. So a CRM app can research a record while it is being created, and a salesperson gets a qualified contact instead of a name and a guess.

And it is not a fixed list of blessed vendors. Any service with an API becomes a step the same way - a data provider, a credit check, a sanctions or registry lookup, whatever your industry uses. Connecting one is a step in a process, not an integration project.
Your own extensions. Where the built-in set stops, a node package adds capabilities to the palette without a deployment - see Automation.

What it can keep count of

An application that needs a running total does not have to invent one. Loyalty points, warehouse stock with batches and expiry, mutual settlements, a budget and what is committed against it - all of that is the ledger, which the app declares and uses.

So a points programme, a stock register or a limit control is part of your app, not a second system to procure and reconcile against.

How work happens in it

The shape people recognise, because it is how work goes when nobody is being watched:

Somebody sketches the ideas in a spreadsheet - a grid, because that is the fastest way to think. The ones worth doing become tasks in a process, from a button on the sheet's own toolbar. Colleagues comment on the rows and on the tasks, @-mention the person who knows, react instead of writing three messages agreeing. The board shows what is moving. The dashboard shows what it added up to. Nothing was exported, and nothing was re-keyed.

One app's data is another app's data

Applications on this platform are not islands with import and export. They share the same data model, the same catalogues, the same org structure, the same ledger. A purchase app and a supplier portal are looking at the same suppliers. A report can cross an application boundary because there is no boundary to cross: only access rules, which are the same rules everywhere.

So the integration work that usually dominates a project - matching identifiers, syncing lists, reconciling two versions of the truth - is not smaller here; it is absent.

And it can be made to look like yours

The screens are not fixed. Pages are built from the same widget catalogue everything else uses, so an app's interface can be rearranged, restyled and extended - a portal for one audience, a compact screen for another, your own branding and layout. See Portals and pages.

AI employees work in it

An agent in an application is not an assistant on top of it. It has a role, a defined scope of what it may see and do, and it works inside the same permissions and the same audit trail as a person.

It watches for deviations - the deal that has not moved, the stock that is running out, the request that has been sitting unassigned since Friday.
It takes the routine - checking a record against another system, filling what can be filled, preparing the summary a person will read.
It prepares decisions and does not make the ones that are not its to make: a person sees what it produced where that matters, and a step that needs approval still needs it.
It escalates what falls outside what it may do.

See AI employees for how far that authority goes and who sets it.

Built by AI, approved by you - how one of these gets specified, built and published, and where you approve.