One machine. Ten labels.
Six sockets — identity, behaviour, knowledge, tools, models, limits. What you slot into them is what the agent becomes. We have built specialised agents on this chassis, and we will build one around your work too.
- Six surfaces, every agent
- Any domain, same chassis
- 170+ integrations
- Governance never swaps
An agent, before it is anything.
Six sockets, in the console's own order. Empty, this is every agent on the platform — and not one of the six is a prompt box.
Six sockets, and they never change.
This is the same spine the Agent Studio walks you through, in the same order. Everything a domain needs is one of these six — which is why there is no seventh surface for your industry.
Identity
a name, an avatar, a domain template
How the agent introduces itself, and the register it starts from. This is the part end users actually meet.
Behaviour
instructions + skills, loaded on demand
The system prompt, the instruction modules layered on top, and the reusable skills it carries or loads when a rule matches.
Knowledge & Privacy
which bases it reads, what gets masked
The files, bases and datatables it may reach — and whether personal data is masked before it ever reaches a model.
Tools & Integrations
scoped tools and MCP servers
What it may call, granted per scope rather than per agent. Native tools, sandbox tools, and any of 170+ integrations.
Models
an ordered stack, local or hosted
Not one choice but a fallback order. The default answers; the rest are tried behind it. Local models make it work air-gapped.
Limits & Budgets
step, call and token ceilings
Caps on steps, tool calls and tokens, plus a timeout. An agent that cannot run away is an agent you can leave running.
What a purpose changes, and what it never touches.
This is the page in one table. Everything on the left is a decision you make per agent. Everything on the right is the platform, and it is identical whether the agent drafts court orders or matches invoices.
Swapped per purpose
Six cards. Yours to set, and to change later.
- Its name, avatar and register
- Its instructions and the skills it loads
- Which files and bases it may read
- Which tools and integrations it may call
- Which models answer, and in what order
- Its step, tool-call and token ceilings
Fixed by the platform
The chassis. Not configurable, and that is the point.
- It runs inside your network, on your hardware
- Role-based access, granted per group
- Tenant isolation across agents and filestores
- Every prompt, tool call and file access logged
- Your data is never training data
- One console, one set of controls, one audit view
As domain-specific as you like. Still one product.
An agent here can be every bit as specialised as a vertical tool; ours already are. What you avoid is what a vertical charges: a second vendor, a second boundary, a second governance model when the next use case arrives.
One deployment, many agents
The second use case is six more decisions inside the install you already have — not another vendor, another boundary and another audit surface.
The domain lives in the config
What makes an agent good at court orders, or at a support queue, is its instructions, its indexed corpus and its scoped tools. All three are things you own and can change without us.
Governance does not fork
Ten agents across five departments still answer to one IAM policy set, one audit trail and one boundary. Approve the platform once and the tenth agent is a change inside something already approved.
We do run agents of our own — medical document intelligence, compliance, media — and every one of them was built on exactly the six surfaces above, using nothing you cannot use.
None of these needed a different product.
Five industries and five departments. Most organisations recognise three or four of them at once, and that is the case this page is built for: the fourth one costs six decisions, not a fourth procurement round.
Want it specialised? Tell us the work.
Some teams want the chassis and their own hands on it. Others want the finished agent. Both are the same product: we walk the six surfaces against your domain, prove it on your own material, and hand it over configured.
- 01
Describe the work
What arrives, what should leave, and who signs it off. Plain language is enough — no specification document, no schema, and no integration audit before we start.
- 02
We fill the six
Instructions and skills written in your vocabulary, your corpus indexed and scoped, the tools it may call, the model stack behind it, and the ceilings it works inside.
- 03
Proved on your own material
A proof of concept on real work, running inside your own network: your documents, your queue, your questions. Not a hosted sandbox with sample data.
- 04
Handed over, still yours
It arrives configured, not locked. Every one of the six surfaces stays editable in your console afterwards, by your team, without us.
This is not a services contract with a services team attached. The build runs on your own material inside your network, and what you are left holding is an ordinary agent in your console: six surfaces, all editable, none locked to us.
The first agent is a project. The tenth is a decision.
The first carries the cost of arriving: the install, the security review, the integration work, the argument over where data may sit. Every agent after it inherits all four. What remains is six cards inside an approved boundary, and the question becomes not whether the work justifies a vendor but whether it justifies six decisions.
A department can have an agent of its own without a supplier, a boundary or an audit trail of its own.
What you learn on the first agent is spent on the second. Instructions, corpora and skills are written once and carried across.
Work too small to survive a procurement round becomes worth automating. There is usually a great deal of it.
The chassis, in specifications.
- Surfaces per agent
- Six — identity, behaviour, knowledge, tools, models, limits
- Instructions
- System prompt + layered modules + skills loaded on demand
- Knowledge
- Filestore, bases & datatables, knowledge graph
- Tools
- Native, sandbox, and 170+ MCP integrations
- Models
- Ordered fallback stack — local or hosted, per agent
- Limits
- Step, tool-call and token caps, plus a soft timeout
- Isolation
- Per group, per agent, per filestore
- Delivery
- Web chat · Slack · browser extension
- Languages
- Multilingual
- Deployment
- The same on-premise install, whatever the purpose
What people ask before they pick.
Can you build an agent specialised for our domain?
Then why not just sell a product built for our industry?
What genuinely differs between a court agent and a support agent?
Do we have to write prompts?
Can one deployment run agents for different departments without them seeing each other's data?
What can't an agent do here?
Bring us the eleventh.
Whatever the eleventh turns out to be, it is the same six decisions and the same deployment underneath them. Nothing about it starts from scratch.
Book a demo- Surfaces
- Six, fixed
- Domains
- Unbounded
- Governance
- Not configurable
- Deployment
- Yours
- Specialised
- By configuration