OnMisn AI for You · User Guide
Intelligence you can supervise.
A generation of AI built that doesn't just answer questions — it does real work on your records, under permissions you set, along plans you can approve, and with a second opinion checking its actions. This guide explains what it can do and, more importantly, how it stays safe, predictable, and easy to manage.
Orientation · The whole picture
What this generation does
At its simplest, it's a chat assistant that can see your business data and help with it. What sets this generation apart is everything around that chat: reusable AI specialists, background tasks that run on a schedule or a trigger, and a layer of controls that keep every AI action accountable.
The connection between the AI and your data runs over a secure, tool-based bridge (an MCP server). The AI never touches the database directly — it can only use the specific, permission-checked tools you allow, and any change it wants to make can be held for a human to approve. Below is the toolkit; the three deep-dive chapters that follow explain the pieces that matter most.
Grounded chat
Ask questions and get answers backed by your real records — not guesses. Changes to data can require your approval before they happen.
Knowledge sources
Attach documents, spreadsheets, images or Knowledge articles. The AI reads them at the depth you choose, so answers stay grounded.
Personas
Reusable AI specialists — an accountant, a triage assistant — each with its own instructions, knowledge and permissions.
Long-term memory
Optional. A persona can learn durable facts from its conversations and recall them later — and only where it's allowed to.
Tasks
Package a goal, a team of personas and a schedule into a managed job that runs on time, on a record event, or on demand.
Plan-first orchestration
For multi-step work, the AI writes an explicit plan you can preview, approve and reuse — before it acts.
Independent verification
A second AI, on a different model, reviews the actions taken and marks each one pass, flag or fail.
Human-in-the-loop approval
The AI proposes changes; a person approves them. This is the one gate the AI can never skip.
Multiple AI providers
Use Claude or Gemini today — chosen per specialist, so each job runs on the right model.
Central monitoring
One place to see every AI schedule and automation, each run's outcome, and what it has cost in tokens.
Every feature is designed to serve at least one of three promises: it's secure (the AI acts only within permissions a person granted), predictable (you can see and approve what it will do), and manageable (you can schedule, monitor and cost it like any other business process). Those tags on the cards above show which promise each feature carries.
A note on speed and cost: behind the scenes the system caches stable context, reads large documents only when needed, and reuses uploaded files — so repeated work stays fast and inexpensive. You don't need to manage any of that; it's mentioned only so you know the efficiency is built in.
Foundations · Which AI runs the work
One system, several brains
A persona describes behaviour — what a specialist knows and how it should act. Which AI model actually powers it is a separate setting, tied to the user account the persona runs as. That separation is deliberate: it lets you send complex reasoning to a frontier model and simple, repetitive steps to a cheaper or more private one — without redesigning anything.
Anthropic's models, with server-side tools and strong multi-step reasoning — well suited to orchestrators and complex tasks.
Google's models, connected through the same controlled tools — a ready alternative or a second, independent opinion for verification.
For simpler, high-volume steps, run a local model on your own infrastructure — lower cost and data that never leaves the building, while frontier models handle the hard parts.
Because the model is chosen per specialist, a task's verifier can be pointed at a different provider or model than the one that did the work — so the check is genuinely independent, not the same AI grading its own homework.
Part I · The building block
Personas — reusable AI specialists
A persona is a saved specialist you can reuse across chats and tasks. Think of it as a job description rather than an employee: it holds the instructions, the reference knowledge, and the memory that define how that specialist behaves — but not the model or credentials, which come from whoever runs it.
What goes into a persona
- Core instruction — the system prompt that defines its role and manner ("You are a careful accounts-payable assistant…").
- Reference knowledge — attached prompts and knowledge sources (policies, price lists, a Knowledge article) the specialist should always draw on.
- Its own memory — durable facts it has learned, recalled when relevant (covered in Part II).
- A description — a short label used when an orchestrator picks specialists for a team (Part III).
A single chat can carry one or several personas. With several, their instructions, knowledge and memory are blended into one combined assistant that answers in a single voice — a convenient way to stand up a well-rounded helper from parts you already trust.
A persona is deliberately constrained to its approved knowledge. It cannot widen its own access — for example, turning on web search is a decision made at the account level, never something a persona grants itself. So attaching a persona adds expertise without quietly expanding what the AI can reach.
Personal vs shared memory
Each persona chooses how its memory is scoped. Per-user memory is private to the person whose conversations produced it — one colleague's remembered context never appears in another's chat. Shared memory is deliberately pooled across everyone who uses that persona (useful for a team bot). This is an explicit choice, defaulting to private.
Part II · How personas improve
Learning & long-term memory
Learning lets a persona get better over time by remembering durable facts from its conversations. It's powerful, so it's built around a simple, controllable idea: writing new memories and using existing ones are two separate switches.
Whether the persona writes new memories after a conversation. Off keeps a specialist perfectly predictable; turn it on for advanced assistants you want to grow. Pausing it later stops new learning but keeps everything already remembered.
Whenever a persona has relevant memories, a few are brought into a new conversation as background. There's no separate switch — a specialist always benefits from what it already knows.
How learning happens
Learning only considers completed chats — never a cancelled or failed one.
In the background, the system distils a short summary and a handful of lasting facts from the transcript — quietly, so it never affects the conversation you just had.
Facts are stored against the persona (and, for private memory, the person), with duplicates filtered out so the same thing isn't remembered twice.
How recall works
When a new conversation starts, the persona's memories are ranked by how relevant they are to what you're asking and how recently they were useful. A small, capped set — enough to help, never a flood — is added as clearly-labelled background context, with a standing instruction to verify remembered facts against current records before acting on them. Memories that keep proving useful become "stickier" and surface more readily.
Private memory cannot leak between people. Even if a private specialist is blended with a shared one in the same chat, one person's private memories will never surface in another's conversation. This boundary is enforced twice over — in the application and again by a database-level rule — so it holds even if something upstream is misconfigured.
Today a curated set of memories is provided automatically. A planned enhancement will let a specialist actively search its own memory for more when a task needs it, with smarter, meaning-based matching. It's noted here so you know the direction — nothing you need to do.
Part III · Putting specialists to work
Tasks — managed, automated AI work
Chats are for people. A Task is for work that should run on its own — a repeatable job with its own screen for setup, scheduling and monitoring. A task brings together a goal, a team of personas, guardrails, and a trigger. When it runs, it produces a full record of what happened, so nothing the AI does is invisible.
A team, not a lone assistant
A task has one orchestrator persona that leads the work and a pool of worker specialists it can hand sub-tasks to. Crucially, each specialist runs as its own user account — with its own AI model, its own credentials, and its own permissions. A worker can only ever see and change what its account is allowed to. This is how you give a "read-only researcher" and an "invoice editor" very different reach within the same task.
Two ways to orchestrate
The important choice for predictability is how the orchestrator works. Plan-first is the default.
The orchestrator first writes an explicit, step-by-step plan — which specialist does what, in order — then carries it out and reports back.
- You can preview and approve a plan before it runs.
- An approved plan can be saved and reused, so routine jobs run the same way every time — faster and cheaper.
- The plan is re-made automatically if you edit it or if verification finds a problem.
The orchestrator decides each step live as it reasons, delegating on the fly. More flexible for open-ended work, less predictable step-to-step.
- Best for exploratory or one-off tasks where a fixed plan doesn't fit.
- Same guardrails, same verification, same approval gate apply.
A written plan turns AI work into something you can read before it happens, approve once, and run the same way again. That is the heart of predictable, repeatable automation — and it makes it safe to hand simpler steps to cheaper or on-premise models, because each step is spelled out in advance.
Guardrails on every run
Whatever the mode, a task is bounded so it can't run away:
- Delegation cap — a maximum number of sub-tasks per run.
- Iteration cap — a limit on how many times the orchestrator can loop.
- Token budget — an optional ceiling on how much a single run may spend.
- Overlap guard — a task won't start a new run while its previous one is still going, so runs never stack up.
Independent verification
A task can include a verifier — a specialist on a different model whose only job is to review the actions the run took and judge each one. It's an assurance layer, not a gatekeeper: it never silently blocks or undoes anything. Instead it stamps a verdict and, on a failure, raises a flag for a person.
If the verifier ever resolves to the same model as the worker that did the job, the system warns you — independence is the whole point.
Scheduling, triggers & monitoring
A task can run three ways, and you watch them all from one place:
A "Run now" button — useful for testing and ad-hoc work.
Every few hours, daily, weekly — a shared dispatcher runs due tasks reliably in the background.
When a matching record is created or updated — e.g. "when a bill over €10,000 is posted" — the task runs against that record.
A central overview lists every AI schedule and automation in one screen, and each task shows its recent runs, the outcome of the last one, and the total tokens it has consumed — so an AI process is as visible and accountable as any other job in the business. You can also name a responsible approver per task, so its human-approval items always reach the right person.
The foundation · Trust, in detail
The security model at a glance
Everything above rests on a handful of principles worth stating plainly. The design assumes the AI should be useful but never unchecked.
- ✋You approve changes, not the AI
Sensitive edits and record creation can be held as human-in-the-loop items: the AI proposes the change and shows exactly what it would do — the record, the field, the old and new values — and a person approves or rejects it. This is the only gate the AI cannot bypass.
- 🪪Every specialist has an identity
Each persona runs as a specific user account, so the AI's reach is exactly that account's permissions — no more. Least-privilege isn't an add-on; it's how the system is wired. Give a worker only what its job needs.
- 🔐Access is enforced by You, not by trusting the AI
When the AI uses a tool to read or change data, the request carries a short-lived, scoped token and is executed as the specialist's user. Your own permission and record rules decide what's allowed — the AI can't talk its way past them.
- 🧩Memory stays in its lane
Private memory never crosses between people, enforced in two independent layers. Personas are confined to approved knowledge and can't widen their own tool access.
- 🧾Everything leaves a trail
Every proposed action, who set it in motion, the verifier's verdict, and the full tree of a run and its sub-tasks are recorded — and the accountable person is retained even if the conversation is later deleted.
- 🏢Scoped to the company
Tasks, personas and memory are bound to their company, so nothing bleeds across the boundaries your organisation already relies on.
The AI can only act through permission-checked tools, as a user you chose, along a plan you can approve, with a second model checking the result and a person holding the final say on any change.
Reference · Plain-language terms
Glossary
- Persona
- A reusable AI specialist: its instructions, reference knowledge and memory. Behaviour only — the model and credentials come from whoever runs it.
- Knowledge source
- A document, spreadsheet, image or Knowledge article attached so the AI can ground its answers in it.
- Memory
- Durable facts a persona learns from conversations and recalls later — private to a person or shared, by choice.
- Task
- A managed, automatable job: a goal, a team of personas, guardrails and a trigger, with its own screen for scheduling and monitoring.
- Orchestrator / Worker
- The lead persona that plans a task, and the specialists it delegates sub-tasks to. Each runs as its own user account.
- Plan-first
- The default way to orchestrate: write an explicit, approvable, reusable plan, then execute it — predictable and repeatable.
- Verifier
- An independent specialist, on a different model, that reviews a run's actions and marks each pass, flag or fail. Non-blocking.
- Human-in-the-loop
- The approval step where a person confirms or rejects a change the AI proposes. The one gate the AI can't skip.
- MCP server
- The secure, tool-based bridge the AI uses to reach Your data. The AI acts only through its controlled, permission-checked tools.