AI in your processes, under your rules.
Agents that hold permissions the way people do, read only what the person asking is allowed to read, and cannot reach a system they have no right to. Configure your own, or use the ones a module brings with it.
The problem
Sound familiar?The pilot worked. Then somebody asked which documents it had read, whose permissions it used, and what would happen if it were wrong about a client. There were no answers, so it stayed a pilot.
And the vendor who offered to fix that wanted the architecture to depend on them.
Your agents ask for a capability, not for a vendor.
An agent is configured to want a fast model, a capable one, or the most powerful one available. Which vendor and which version answers that is a setting, changed without touching a single agent.
Adding a vendor is configuration, not a release. Where a provider's terms are a problem for you, a deployment can run entirely on models you host yourself.
Not every task needs the biggest model.
A lot of the work inside a business process is narrow and repetitive: reading a document that always has the same shape, pulling the same fields out of it, turning a structured record into a paragraph. For work like that a small model running on hardware you control is often the better choice, not a compromise.
The data never leaves
For the steps that touch the most sensitive material, nothing has to cross your network boundary. That is often the difference between a process going live and staying in review.
Volume stops being expensive
A step that runs thousands of times a day is priced very differently when it runs on your own hardware. High-volume, low-judgement work is exactly where a per-token bill hurts.
Narrow beats clever
On a task with one right shape of answer, a smaller model is more predictable and easier to keep stable over time than a general one that could always phrase it differently.
One process can use both. The narrow, high-volume steps go to a model you host; the steps that need judgement go to a large one. It is the same runtime, the same permissions and the same record either way.
Configure your own agents
Not a support ticket to us, and not a developer. An administrator in your organization defines what an agent is for and what it may touch.
What it is asked to do
Its instructions, the model tier it should use, how long an answer may be, and the individual tasks it is allowed to perform. All of it edited in the administration screens.
What it is allowed to touch
The tools it may call and the knowledge it may read, chosen from what your organization has. An agent cannot grant itself more than it was given.
Every change is a version
Editing an agent creates a new version rather than overwriting the old one, so you can see what it was instructed to do at the time it did something.
Tools are permissions, not suggestions.
Every tool an agent could call is registered with the right it requires. When somebody runs an agent, it is only offered the tools that person is entitled to use, and the entitlement is checked again when the tool actually runs.
The requester's rights, not the agent's
Two people running the same agent do not get the same reach. An agent borrows the permissions of whoever asked.
Refusal is a designed answer
Asked to do something outside its permissions, an agent declines instead of improvising a way around it.
Your knowledge, not the model's memory
An agent answers from documents your organization put there, and it says where the answer came from.
Knowledge per organization
Each organization has its own knowledge, and an agent can be pointed at a specific part of it. Nothing crosses between organizations.
Two kinds of search, one answer
Meaning-based search and exact-term search run together and their results are merged, so a question phrased loosely and a question with an exact clause reference both land.
Documents carry their audience
A document can be restricted to named people or groups, so what an agent may quote to one person is not necessarily what it may quote to another.
An assistant that knows where you are.
Not a separate website with a text box. It sits inside the system, next to the work.
- It knows which screen and which record you are looking at, so you do not have to describe your own context back to it.
- It asks you a question back when it needs one, as a form rather than as a guess.
- It can answer with a dashboard, not only with a paragraph.
- It only ever sees your organization's knowledge, under your own permissions.
Cost you can look at
A ceiling on every run
How many steps an agent may take, how much it may read and write, and how many tools it may call are all bounded before it starts. A run that hits the ceiling has to conclude rather than continue.
A price on every run
Each execution records what it consumed and what that cost, per module and per period. AI stops being a number that arrives at the end of a quarter.
What it deliberately does not do.
- It does not act outside a person's permissions in order to be helpful.
- It does not train on your data. Your material runs your processes and nothing else.
- It does not send work to a client on its own. Where policy requires a person, the process requires a person.
- It does not switch models behind your back. You know which provider answers, and you can change it.
It is part of the core. Identity, access rules and the audit trail are not built into the runtime. They belong to the system underneath, which is what lets an agent hold permissions in the first place.
Inside OmnicornBring one decision you would not let AI make.
That is usually the most useful place to start, because it forces the real conversation: what the agent prepares, what a person decides, and what the record has to show afterwards.
Let's meet