One Surface: Why Our AI Control Plane Lives in Every Screen, Not in a Dashboard.
Most AI for business arrives as another window. There is the system you work in, and beside it there is a chat box, a copilot tab, an assistant that knows a little about what you are doing and nothing about what you are looking at. You describe your situation to it, it describes an answer back, and then you go and do the work in the system anyway.
We made a different design decision for our AI control plane, and it is the decision this post is about. The plane does not live beside the applications. It lives inside the screens people already use, as one surface, with the same gates and the same audit trail whether a person talks to it or clicks. This is how CodeStringers designs and delivers its AI-driven solutions, and it is worth explaining because the choice matters more than which model sits underneath.
What an AI control plane is, in one paragraph.
An AI control plane is the layer above a company's applications that observes what is happening in them, decides what to do next against a plan and a set of rules, and acts through the applications' own interfaces. It is not a chatbot and it is not a report. It is closer to an operations manager who can see every system at once, has written authority up to a limit, and has to ask a person before spending money or publishing anything. Our marketing function has run this way since September: the plane reads the ad platform, the analytics, the CRM and the content calendar, proposes the week, produces the pieces, and stops at every gate where a dollar or a public change is involved. The six-minute walkthrough shows the whole loop.
The question is where a person meets that layer. Most vendors answer with a dashboard. We think that is the wrong answer, for a reason that has nothing to do with taste.
The dashboard problem.
A dashboard is a place you go. It sits apart from the work, it summarizes, and it asks you to translate. You read a chart, form a view, then open the system where the record lives and do something about it. Every one of those steps is a place where context is lost. The chart does not know which customer you meant. The chat box beside it does not know which filter you applied or which row you selected. So you re-describe it, in words, to a thing that was looking at the same screen you were.
This is why most AI assistants in business software feel like a second job. They are not stupid. They are blind. They see a message and not a page, and a page is where most of the meaning is.
The one-surface design.
The design we build to has four parts.
The skin. A custom set of screens over the client's applications, built on Zoho's own tools, Creator pages and widgets, or as a React front end on the Zoho APIs and Catalyst. It is the client's working surface for inventory, orders, budgets, pipeline, reports, whatever the business runs on, drawn for that business rather than for every business.
The pane. Every screen of the skin carries a persistent conversation pane, docked in the same frame, present everywhere, never a separate window. The pane is the control plane's face. It knows the page. Each message carries which screen you are on, which record is open, the filters and date range applied, the rows you selected. "These parts," "this customer," "last quarter by region" mean what they mean, because the plane can see what you can see.
Talk or click on the same screen. What you ask for in the pane is done in the system of record through its own API, read back, and the page you are on redraws with the result. The same step can be done by hand with the page's controls. There is no mode switch. A production planner on an assembly page can type "build forty of these from the parts and tell me what we are short" or can fill in the build form; either way the same rules run and the same record changes.
The same brain everywhere else. Slack and Cliq remain surfaces of the same plane for phones, notifications and approvals. A gate raised in the pane can be answered from a phone with a 1, and the answer lands on the record. The gates are the same, the caps are the same, the log is the same.
That last point is the one we would ask a buyer to test any vendor on. If the AI can be told to do something in one place that it would have to ask permission for in another, it is not one control plane. It is two products with a shared logo.
Why this beats a dashboard on the three things that matter.
Context. The pane never has to be told what you are looking at. That removes the translation step that makes assistants tiring, and it removes a whole category of errors: the wrong customer, the wrong period, the wrong entity, because the reference was ambiguous in words and unambiguous on the page.
Governance. When the plane acts through the applications' own APIs, every action is a record change with a user, a time and a reason, and the system of record stays the system of record. Nothing runs on a credential a person can see. Every dollar has a gate a person controls, and the caps are enforced in code below the gate, so an approval cannot exceed what the plan allowed. A dashboard that summarizes what an agent did after the fact is not governance. Governance is the gate before the action, on the same surface where the action is requested.
Adoption. People do not adopt a second window. They adopt the thing that makes the first window easier. If the pane is where the work already is, using the plane costs nothing extra, and the choice between talking and clicking is a matter of which is faster for the task at hand, not a matter of learning a new tool.
What it changes for a mid-market operator.
Consider a purchase against a budget. A department user is on the budget page for her cost centre, the line and its balance on screen. She types: "buy the two replacement units from the approved supplier." The plane checks the line, the balance and the supplier, drafts the order, and because the amount is above her threshold it raises a gate to the budget owner, who answers from Slack on his phone. The order posts. The page refreshes with the new balance. The whole thing is logged with who asked, who approved and what the rule was. Nobody opened a purchasing system, a chat tool and an email thread and reconciled them afterwards.
Now consider the alternative most companies live with: a purchasing module, an approval email, a spreadsheet of commitments, and a monthly reconciliation to discover what was actually spent. The difference is not the AI. The difference is that the AI is on the surface where the decision is made, and the decision carries its evidence with it.
The honest state of it.
As of this writing the skin and the pane are designed, not built. AI Marketing OS, our own marketing function, runs through Slack, and through Cliq for demonstrations. Everything about the gates, the caps, the audit trail and the plane acting through the applications' own APIs is live today in that surface, and it is why we can say the design works. The pane in every screen is the next surface, built per solution as part of the skin, and we describe it as how we design and deliver, not as a screen a reader can open this afternoon.
We would rather say that plainly than sell a screenshot. The commercial commitments are the same either way: discovery you pay for only if you proceed, an estimate we guarantee and absorb if we are wrong, and a project plan you see in full before you commit to a release.
The one-line version.
An AI control plane should not be somewhere you go. It should be everywhere you already are, with the same rules in every place, so that you talk or click on the same screen, it acts, and you approve the money. That is the whole design, and it is why we will keep building it into the screens rather than beside them.
See the AI Marketing OS run a marketing function before you commit to it.
Watch the 6-minute guided demo, then book a walkthrough: we read your CRM, ad accounts and content and show what a governed system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments