The short answer: menus stay, but they stop being the only way in

Backoffice menus are not going away. A menu is a visible map of what a system can do, and it is still the best tool available when a user does not yet know what they want. What is changing is that the menu stops being the only way to ask the system for something.

What gets added is a route where the user states the outcome instead of the sequence of clicks, and the system walks the path. But the point of this article is not that this is more convenient. It is that:

  • the steps did not disappear, they moved off the user’s hands and behind the interface;
  • the steps added behind the interface are permission checks and business-rule enforcement;
  • those steps have to be designed, not left to the model to decide.

Two parts of this article are meant to be clicked. The first lets you compare both routes yourself. The second puts you in the agent’s seat, deciding what to do about one refund request.

How a backoffice turns into menus inside menus

Most internal systems were not designed to be complicated. They became complicated one reasonable decision at a time.

Every new capability is cheapest and safest to ship as one more menu entry. Every department that needs a slightly different report is fastest to serve with one more filter. And every time somebody uses the system wrongly, the most direct fix is one more confirmation screen.

Five years later the result is a system that can do everything, provided the user already knows where their answer is hiding. The shape of the menu reflects the shape of the database and of the departments that built it. It does not reflect the question the user is actually carrying.

Two routes, side by side

Both sides answer the same question. What differs is who walks the path.

One question, two routes

The question is “how did Bangkok sales do this month against last month, and which products grew abnormally?” Both routes play out side by side, then start over.

The classic backoffice

The path: Report → Sales → Monthly → Bangkok → Export → Excel

Step 6 of 6

    Currently at Main menu

    DashboardReportSettingMaster Data

    This route ends at a file

    sales-bangkok-2026-08.xlsx

    This illustrative file holds 4,120 rows and has still not answered the question. The user now opens Excel, builds a pivot against last month, and hunts for the abnormal product by hand.

    The AI interface

    One sentence; the steps run behind it.

    The request

    Summarise Bangkok sales this month against last month, and find products growing abnormally.

    This route ends at an answer

    Bangkok sales this month were THB 12.4M, up 8% on last month. The product growing outside its normal pattern is SKU-2213, up 212% from a low base.

    Every figure here is invented for the example. It is not any client’s data.

    Working

    What runs behind it

    1. 1Read the requestTurn the sentence into a task: time range, territory, and the comparison to run.
    2. 2Check the user’s permissionsThis user may only see Bangkok sales, so the token is requested for that scope.
    3. 3Call the sales tool over MCPMCP is the open standard that lets an agent call a system capability. The one called here is salesSummary, with fixed parameters — not free-form SQL.
    4. 4The sales system checks againThe source system validates the token and its own rules, then returns only permitted rows.
    5. 5AnalyseCompare against last month and find products growing outside their normal pattern.
    6. 6PresentAnswer in prose, stating which period was used and which filters were applied.

    6 clicks1 sentence

    The right-hand route does not have fewer steps. It moves six of them off the user’s hands and behind the interface — and two of those six are permission checks, which are designed, not guessed by the model.

    The interesting difference is not the click count. It is where the two routes end. The menu route ends at a file; the second route ends at an answer. The work that disappears between those two points — open Excel, build the pivot, scan for the outlier — was never counted as part of the system in the first place.

    What actually runs behind one sentence

    The steps shown on the right are not an illustration. They are the shape this kind of integration really takes, and two of the six steps are permission checks.

    The most important one is the third. The model does not write SQL. It calls a capability the organization defined in advance and bounded on purpose:

    // The capability an agent may call - deliberately narrow
export const salesSummary = {
  name: 'salesSummary',
  description: 'Monthly sales summary for territories the user is allowed to see',
  input: {
    month: 'YYYY-MM',
    // Not every territory - only what the user's token actually covers
    territory: 'string',
    compareWithPreviousMonth: 'boolean',
  },
} as const;

    A capability like this is what an MCP server declares for an agent to call, which is covered in what an MCP server is and how it connects AI to backoffice systems.

    The narrowness of that input is the security mechanism, not a usability compromise. If an agent can compose database queries freely, the blast radius equals the permissions of the connecting account rather than what this particular user should be able to see.

    When the request arrives, the source system decides again what this user may see, and returns only that:

    {
  "territory": "BKK",
  "month": "2026-08",
  "total": 12400000,
  "previousMonth": 11480000,
  "rowsWithheld": 3180,
  "scopeApplied": "sales:read:territory=BKK"
}

    That rowsWithheld field is what separates a designed integration from one that merely works. The system knows data was held back, and knows why. The detail of building that integration layer — OAuth, scoping, approval before a transaction — is covered in secure AI integration with ERP, CRM, and internal systems.

    The Model Context Protocol specification is direct about this: hosts must obtain explicit user consent before invoking any tool, and the protocol itself cannot enforce these security principles at the protocol level. Security is work the implementer does. It does not arrive with the choice of protocol.

    Where the industry has actually got to

    None of this is a long-range forecast. It is what large enterprise software vendors are shipping now.

    Describing agents in Microsoft 365 Copilot in April 2026, Microsoft framed the pattern as bringing business apps into the conversation so that “intent becomes execution without ever leaving Copilot chat” — and said in the same breath that control stays with the user, who can either work with the app’s interface inside the chat or direct the agent and let it act under supervision.

    The protocol side is arguably more interesting. MCP now carries an extension called MCP Apps, which lets a server return a genuinely interactive surface — a form, a dashboard, a chart — rendered inside the conversation, running in a sandboxed iframe that talks to the host only through postMessage.

    Put differently, the answer to this article’s title is sharpening into: yes, you still click, but somewhere else. Instead of the user walking to the menu, the menu walks to the user, as a small surface scoped to whatever is being discussed.

    Be the agent for five minutes

    This section inverts the exercise. Instead of reading about how an agent should behave, you make the calls.

    The scenario is a single refund request — the simplest-looking task in any backoffice, and the most expensive one to get structurally wrong.

    One refund request, four decisions

    You are an agent connected to the sales system, the payment system, and the policy system. Open any option you like — nothing locks, and everything you open is kept in the case record. Exactly one path per step moves the case forward.

    Decisions resolved 0 of 4Options opened: 0

    SituationA customer writes in: “I’d like a refund on Order #1024.” That is everything you know right now.

    What you can call right now

    All four decisions measure the same thing, and it is not cleverness. It is knowing that it is not yet time to act. Every wrong option in that drill sounds reasonable, which is exactly the point. Agent systems do not fail because a model says something absurd. They fail because a model does something sensible at a moment when it should not have acted at all.

    Four questions to answer before an agent touches a real system

    Before connecting an agent to anything, answer these four — with the names of real systems, not with principles.

    1. What can the agent see? Answer with a list of bounded capabilities, not with the name of a database it connects to.
    2. On whose behalf does it act? Permissions should follow the signed-in user, not a service account that is identical for everyone.
    3. What can it do, and where does it stop? Keep read, draft, and commit permissions genuinely separate.
    4. How do you audit and stop it? You need a record of what was called and on whose behalf, plus a way to revoke access immediately.

    The MCP security best practices list a common mistake that maps directly onto question three: treating the scopes claimed in a token as sufficient without server-side authorization logic. A scope says what may be called. It does not say that this case qualifies.

    The same body of guidance is specific about token boundaries. Under the authorization specification, a server must validate that a token was issued specifically for it, and must not pass a received token through to a downstream service — the pattern that leaves the downstream system believing a request was already vetted.

    So where do menus still win?

    Language is not the better interface everywhere. There are at least four situations where a conventional screen is plainly stronger.

    • When the user does not know what the system can do. A menu is a visible inventory of capabilities. An empty text field tells you nothing.
    • When the task repeats identically every day. The same button in the same place is faster and far more predictable than composing a fresh sentence each time.
    • When precision matters more than speed. Picking from a real list cannot misspell a product name and cannot be interpreted loosely.
    • When the result has to survive an audit. A structured form produces an identical record every time, which is what reviewable processes are built on.

    The sensible direction is not to pick a side but to run both in one system: language as the entrance for questions no screen was built for, screens as the entrance for repetition and precision. That is what makes MCP Apps interesting. It does not replace the screen; it moves the screen to the point in the conversation where it is needed.

    Conclusion

    Will we still be clicking menus? Directly: yes — but far less for asking questions, and about as much as today for work that must be exact and repeatable.

    What genuinely changes is not how the system looks. It is where the logic lives. The order of operations used to sit in the head of a user who knew what to click first. Now that order has to be written into the system, with a permission check at every point where the user used to be the one deciding.

    That makes this a systems design problem rather than a model selection problem, and it is why projects of this kind usually start by giving existing systems an API that can enforce their own rules. If the current backoffice has no such layer, designing the architecture and building the software to support it should come before choosing any AI tooling.

    Sources and further reading