A content manager knows what she wants to change on the welcome page. She doesn’t know which of the forty CMS screens holds the field. So she asks a colleague, gets a path, clicks through, edits the text and asks whether someone has to approve it. Native AI assistants for business software are built to remove that walk.
Multiply it across a company. An HBR study of 137 people at three large companies found they switched between applications about 1,200 times a day and spent just under four hours a week reorienting after each switch, around 9% of their working time.
The assistant sits in the CMS, the ERP or the CRM. It sees the record on screen, tells the person where the change lives, and, when you allow it, makes the change after they confirm.
This guide covers how to build one in that order and which numbers show it’s working.
Where a native AI assistant lives
A separate chat window knows nothing about the screen in front of the person. They paste in context, get an answer, switch back and apply it by hand. Every one of those steps is a place to make a mistake.
An assistant inside the application starts with the current page, the record and the person’s role. It can open the right screen, fill a draft and hand the final decision back. And it runs under the same login and permissions the person already has.
| Question | Separate chat window | Assistant inside the application |
|---|---|---|
| What does it know about the task? | Only what the person pastes in | The current page, record and role |
| Who checks permissions? | Nobody, or the model | The application, at the moment of change |
| How does a change get applied? | The person retypes it | The application applies it after confirmation |
| What is the audit trail? | A chat log | The application’s own change history |
| What does it cost to run? | A subscription per seat | Model calls per question, often a few cents |
The two aren’t rivals. A company-wide assistant in chat is the front door for questions that span systems, which we cover in enterprise AI in Slack. The native assistant is for work that lives deep inside one system.
Guide first
The first version of the assistant only answers one question, “where do I change this”. Ask for the SEO title on the welcome page and it replies with the path, “Pages, then Welcome page, then SEO settings”, and a link that opens that screen. It changes nothing.
That sounds modest. It removes the colleague interruption, the wrong-screen detour and the “is this the right field” doubt, which is where the four hours a week go. And it carries no write risk, so it can ship in weeks.
Each level is a separate decision with its own evidence. Most of the value arrives at the first two, before the assistant can write anything.
The important design choice is where the assistant’s knowledge comes from. Ground it in the application’s own navigation model and field definitions, the same data that draws the menus and labels. When a screen is renamed, the assistant’s answer changes with it. A hand-written help guide would drift within a month.
That grounding also keeps the assistant cheap. A small, fast model answers a “where is” question well in about a second, because the answer is a lookup with some phrasing around it. So the running cost is a rounding error next to the people time it saves.
Two more rules for the guide phase:
- Say so when it can’t find it. If a setting isn’t in the map or the person’s role can’t see it, the assistant says that and leaves the normal interface in place.
- Degrade to documentation. If the model is unavailable, the panel links to the generated guide instead of failing. The application never depends on the assistant to work.
Then act, with confirmation
Once people trust the guide, they’ll ask it to make the change. Add that ability one action type at a time, and make every action confirm-first. The sequence is the same for a text edit, a banner image or a list of payment providers:
- The person describes the change in plain words.
- The assistant proposes it at a high level: which page, which setting, which record, the new value. It never invents internal identifiers.
- The application resolves that proposal into a concrete change server-side, reads the current value and checks the person’s role against the section.
- The panel shows a confirmation card: before and after, with a word-level diff for rich text and the actual asset for an image.
- The person clicks apply or cancels. Only on apply does the application write, through the same path the editor uses, and record the change against that person in the audit trail.
The card names the exact record and shows the difference, so approval means something. The application resolves the record, checks the role and writes the audit entry.
Step 4 is where the value shows. A person can only approve what they can see, so the card names the exact record, the language, the current value and the proposed value.
For a long paragraph it highlights the changed words. For a list it shows additions and removals. And if the record changed while they were reading, the card asks for a fresh look before anything is overwritten.
Keep separate approvals separate. Confirming a text edit must never publish the page, send a notification or touch another language. Name every extra consequence before asking for the click, or make it a separate action.
| Level of authority | What the assistant may do | Control the business needs |
|---|---|---|
| Guide | Explain the application and open the right screen | Answers grounded in the application’s own structure |
| Propose | Prepare a change without saving it | Exact target and a reviewable before-and-after view |
| Apply | Save a confirmed, supported change | Permission check, confirmation and an audit record |
| Consequential | Publish, send, delete or change access | A separate approval flow and stronger safeguards |
Avoid a single “AI enabled” switch. One team wants draft text help and no automated publishing. Another wants record lookup and no changes at all. Each level is its own decision with its own evidence.
Permissions checked by the application
The assistant works within the signed-in person’s authority. Someone who can’t edit a section through the normal screens must not gain that ability by asking in natural language.
Enforce that rule in the application, at the moment the action is requested. Telling the model to respect roles is useful guidance. But it’s never the final check, because a model can be talked out of it, and because the write path may have no role check of its own.
In one CMS we worked in, the internal write path trusted every caller. So the role check had to sit in the assistant’s server layer, in front of that path, before anything was written.
OWASP’s list of risks for language model applications names excessive agency as one of them: too much functionality, too many permissions, or too much autonomy for the intended task (OWASP LLM06:2025). Its recommended controls are to limit the tools, run them with the minimum permissions and require a person to approve high-impact actions. That is the confirm-first design above.
| Control | Where it lives | Who enforces it |
|---|---|---|
| “Only edit what this role may edit” | The application, when a proposal is resolved | The application’s permission model |
| “Show before and after” | The assistant panel | The person, by confirming |
| “Never publish from a text edit” | The action definition | The application, by not exposing that path |
| “Ignore instructions inside content” | The assistant’s prompt and input limits | The model, with tests that prove it |
| “Record who approved what” | The application’s audit trail | The application, on every write |
The same rule applies to reading. Search results, previews and summaries can expose a record whose page is protected. Include them in permission testing.
Treat content as information to inspect, never as instructions. A page body or a record note must not be able to grant itself permission to send a message or expose another person’s data. Cap the input, strip anything that looks like a command, and test it with an adversarial set before launch.
Exposing actions through MCP
The Model Context Protocol, MCP for short, is an open standard for how an application exposes context and actions to an AI assistant. A server offers three kinds of things: resources (data to read), prompts (templates for common tasks) and tools (functions the model may call). Any assistant that speaks the protocol can use them.
For a business buyer the useful question is which of those the workflow needs. A read-only server that answers “where does this setting live” needs no tools that write. So ship that first. It serves the in-app panel and any other assistant the company runs, including one in chat, from the same map of the application.
Writing tools are a separate product decision. When you add one, shape it the way the confirmation flow expects:
- High-level inputs. The tool takes a page, a setting and a value in the person’s words. The application resolves identifiers. The model never sees a database id.
- A proposal step and an apply step. Two calls, so the confirmation card sits between them and nothing writes on the first call.
- The caller’s identity. The tool runs as the signed-in person, and the application checks their role on every call.
- Untrusted descriptions. The specification says a tool’s own description of itself should be treated as untrusted unless it comes from a trusted server, and that hosts must obtain explicit user consent before invoking any tool.
MCP doesn’t decide whether a change is commercially sensible or who may approve it. Those stay with the product and the process around it. What MCP gives you is one way to expose the application’s actions that every assistant can use, so you don’t build the integration twice.
Measuring what a native assistant completes
Count tasks finished, never messages exchanged. A long conversation may mean useful help or repeated confusion. An opened panel says someone tried the feature, and nothing else.
Compare the same tasks with and without the assistant, across people with different levels of experience in the application. Record the outcome, the time and the corrections, and ask afterwards whether it helped.
| KPI | Definition for a pilot | Why it matters |
|---|---|---|
| Task completion without rework | Eligible tasks finished correctly at the first attempt, divided by attempted tasks | Separates activity from useful work |
| Time to complete | Minutes from intent to a verified result, including the review | Counts the effort after the draft |
| Errors caught before save | Proposals corrected or cancelled at the confirmation card, divided by proposals shown | Shows the card doing its job |
| Errors found after save | Applied changes corrected later, divided by applied changes reviewed | Finds defects that passed the card |
| Adoption within the workflow | Eligible tasks attempted with the assistant, divided by all eligible tasks | Shows use where it was meant to be used |
| Cost per completed task | Model, hosting and support cost, divided by tasks completed without rework | Tests the whole economics |
State the review sample and the follow-up window, so recent changes don’t look error-free only because nobody has checked them yet. Include abandoned attempts in the time measure, or the feature will look faster than it is.
Here is a planning sketch with labelled assumptions. It describes no customer.
| Line | Assumption | Result |
|---|---|---|
| Assisted tasks per month | 600 | 600 |
| Time saved per task before review | Two minutes of navigation and retyping avoided | 20 hours |
| Review and corrections | Eight hours a month across the team | 12 hours net |
| Model spend | 1 to 3 cents per interaction, three interactions per task | $18 to $54 |
| Errors caught before save | 5% of proposals corrected at the card | 30 mistakes that never reached the site |
Twelve hours of released capacity and thirty caught mistakes is the honest shape of the result. It turns into money when overtime falls, a backlog clears or a correction cycle disappears.
Failure and recovery
People need to know whether an action failed, succeeded or is uncertain. A network error after “apply” must not tempt them into submitting the same change three times.
- Show the recorded result. After a write, display what the application stored, with a link to the record, so “done” is verifiable.
- Never replay from history. A restored conversation is plain text. Old proposals don’t run again when the panel reopens.
- Keep the editor working. If the model or the gateway is down, guidance falls back to the generated documentation and the normal editor stays usable.
- Know what can be undone. Text edits can be reverted from the audit trail. Publishing and sending need their own corrective step, so gate them harder.
Colleagues stop using a feature they have to double-check. Reliable confirmation and a working fallback are part of the value, and they belong in the pilot’s acceptance criteria.
Configure, buy or build
Test the vendor’s own assistant first, against your actual task, permission boundary and review process. A native feature may already do the job with configuration and a short training session.
| Situation | Sensible choice |
|---|---|
| The task lives in one screen and the vendor assistant handles it | Configure the vendor feature |
| The task crosses two applications | Build an assistant with an MCP server per application |
| Your business rules decide what may change | Build, and put the rules in the resolve step |
| The vendor assistant writes without a before-and-after view | Build, or keep it guide-only until it does |
| Records, roles and screens change often | Build on the application’s own structure so the map regenerates |
We took the build route for a services firm whose enquiries arrive through several channels. The workflow captures each enquiry in Odoo, adds company context and prepares a follow-up, and a consultant makes the qualification call. The same shape applies to purchase orders, where the buyer approves and the workflow never pays an invoice on its own.
Run the first pilot on one bounded workflow with a named business owner. Keep consequential actions off until their separate checks pass. Then expand where the completion numbers say to.
The result to aim for is a colleague who finishes the task with less searching and fewer interruptions, and who can see what changed and who approved it. A chat panel on its own is a feature. That is a working process.
Frequently asked questions
What is a native AI assistant?
It's an assistant built into the business application where the work happens, such as a CMS, an ERP or a CRM. It can use the record the person is looking at and, when enabled, offer approved actions. Its value comes from finishing real tasks, wherever the chat panel sits.
Does an in-app assistant need permission to change records?
No. Guidance and read-only lookup are useful on their own and carry no write risk. Add write actions one at a time when the case is clear, with a permission check in the application, a before-and-after preview and confirmation for anything consequential.
Does the Model Context Protocol make an assistant secure?
No. MCP standardises how an application exposes context and actions to an assistant. Your application still needs authentication, permission checks, limits, confirmation rules and an audit trail. The specification itself says hosts must get explicit user consent before invoking any tool.
How should we measure the return?
Compare task completion, time to complete and corrections on the same tasks with and without the assistant. Include operating and support costs. Time released is capacity. It becomes a saving only when a cost line changes.
Should we configure the vendor's assistant or build our own?
Test the vendor's feature against your real task, permission boundary and review process first. Build when the task crosses applications, depends on your own business rules or needs a confirmation experience the vendor feature can't give you.