Your apps can act on what they capture, not just store it.
The software Maleus builds doesn't have to stop at a form someone still has to process. Its apps can take the next step, call a feature, reach a tool you've connected, or pull in outside information, within limits you define and approve.
For teams who want their internal apps to act, not just store data.
Northwind Supply
Account · Open
Configured the way you build everything else.
You control, and can inspect, exactly what an agent is allowed to do.
An in-app agent isn't bolted onto a finished app. You describe what it should do, and it joins the same approved spec that directs the rest of the build: what it's for, the systems it may reach, the actions it may take, all signed off before it runs.
Assistant · specification
Approved in your specs- What it's for
- Surface buying signals
- Systems it may reach
- Your CRM · web search (bounded)
- Actions it may take
- Add a note · flag an account
Two things they do, within limits you set.
An in-app agent does two kinds of work, both defined in your specification:
Take an action
Invoke a feature inside the app, or reach a connected tool: add a calendar entry, update a record, or start a step elsewhere.
Bring in outside information
Run a focused web search for what it needs, restricted to the destinations you allow, not open-ended browsing.
Restricted to the destinations you allow, not open-ended browsing.
Both run as part of the app you ship, directed by the rules in your specification, not as an agent acting on its own.
Two apps that act.
A couple of examples, to show the shape of it:
A CRM that acts on signals
Its in-app agent watches the web for signs an account is warming up to buy, and surfaces them to your team.
A supplier app that drafts steps
When someone submits a new supplier, its agent checks your connected systems for a match, pulls its public registration details, and drafts the next step.
These are examples, not pre-built features. What your app's agent does is whatever you specify and approve.
An agent that acts only earns its place if it's bounded and yours.
You see, and bound, exactly what it touches.
Because the agent is built into your app, the same discipline applies. At runtime it does only what your approved spec defines, and its web access is bounded to destinations you allow, so untrusted web content can't redirect it. The build runs isolated, and the result, agent included, is yours.
See the full security model- At runtime, only what your approved spec allows
- Web access bounded to destinations you allow
- Build isolated: no database access by default
- Every action recorded for audit
- Ships in your own repository, on your own cloud
Why a bounded agent beats a loose one.
It acts as you approve
Its job, the systems it may reach, and the actions it may take are signed off in your spec before it runs.
Built in, not bolted on
The agent is specified and ships inside the same app you own, with no separate tool to wire up or trust.
You see what it touches
Its web access is limited to destinations you allow, it can't reach your data while building, and every action is recorded.
See it on a workflow you run.
In-app agents are one capability of the way Maleus builds. The clearest way to judge the fit is on a workflow you run today.
Built by the team behind a widely-used open-source backend and real-time data platform.