Product & Company Updates
The UI Is Collapsing Into Chat. The Backend Has to Change First.
A chat box on top of existing software is not an agentic interface. Here is the data access, memory, and governance architecture that has to exist behind it.
Most product teams approach conversational interfaces the same way. They take the product they already have, add a chat box to the corner of the screen, and wire it to a model. The demo looks impressive. The product is not meaningfully better.
There is a real difference between putting a chat box on software and making the software genuinely operable through conversation. The first is a UI change. The second is an architecture change. When Kingsley Hendrickse and I built Workforce Edge as an embeddable conversational layer for existing software, that distinction shaped almost every decision we made. The interface is the visible part. The work that matters sits underneath it.
A chatbot cannot fix the architecture behind it
This is the uncomfortable starting point. A chatbot placed over disconnected or poorly structured systems cannot repair the underlying product architecture. If your data lives in five places with five different schemas, if your permissions are enforced only in the UI rather than in the API, if your workflows exist as institutional habit instead of defined logic, then a conversational layer inherits all of that. It just delivers the mess in prose.
The reason so many chatbot wrappers disappoint is not the model. It is that the model was handed a thin slice of the system and asked to act as if it could see the whole thing. Users ask a question, the answer is shallow or wrong, and trust in the interface collapses within a week.
So before any conversation design, there is backend work. I think of it in three layers.
Layer one: access to structured data and actions
A useful conversational interface needs access to the underlying system. Not a screenshot of it. Not a nightly export. The actual system: its data, its permissions, its workflows, and its institutional context.
In practice this means the agent reads from the same structured sources the application uses, and it acts through defined operations rather than scraping the UI. When someone asks "which of these accounts is overdue and what did we last agree with them", the answer has to be assembled from live records, not guessed from a prompt. When someone asks the agent to do something, that something has to map to a real operation with real constraints.
This is also where honesty about scope matters. Not every action available in a host interface automatically becomes available through conversation, and pretending otherwise is how teams ship agents that silently fail. The set of things an agent can do should be explicit, versioned, and smaller than the set of things it can read. You grow the write surface deliberately. You do not start with it wide open.
Layer two: organisational context and memory
The second layer is the one most teams skip, because it does not demo well in a thirty second clip.
A one-off question and answer is not how organisations work. Work has continuity. The same customer comes back. The same project evolves. A decision made last month should inform the answer given today. Without memory, every conversation starts from zero, and the agent behaves like a new hire on their first morning, forever.
This is why the technical architecture behind Workforce combines memory, workflows, model routing, analytics, and a lessons loop behind the interface rather than inside it. Memory means the system retains what has happened and what was decided. The lessons loop means corrections and outcomes feed back into how the system responds next time. Model routing means the interface is not married to a single model's behaviour, because the backend decides how each task is handled. Analytics close the loop by showing what people actually ask and where the agent falls short.
None of this is visible in the chat window. All of it determines whether the chat window is worth opening.
Layer three: governance of what the agent may do
Answering questions and taking actions are two different trust problems, and teams get into trouble when they treat them as one.
Reading data badly gives you a wrong answer. Acting badly gives you a wrong invoice, a wrong email to a client, a wrong permission change. Controlled action-taking has to be governed with permissions, approvals, and auditability, and that governance belongs in the architecture, not in a policy document nobody reads. The security model behind autonomous agents covers how we think about this: the agent inherits the user's permissions rather than bypassing them, sensitive actions sit behind approval steps, and every action is logged so it can be reviewed and traced.
A useful test: if an agent does something and you cannot answer "who authorised this, what exactly happened, and can we reverse it", you do not have an agentic product. You have a liability with a friendly tone.
Governance is also what makes the first two layers safe to expand. You can widen what the agent reads and does only as fast as your ability to constrain, approve, and audit it.
Output has to be more than prose
There is a fourth observation that cuts across all three layers. A wall of text is rarely the right answer to a work question.
When someone asks about a pipeline, a workload, or a set of records, they often need the thing itself: the table, the list, the draft, the confirmation that an action completed. The conversational layer should be able to hand back structured results and completed work, not just commentary about them. This is a natural consequence of building on structured data and defined actions rather than on top of a page. If the backend is real, the output can be real too.
A readiness checklist before you add the chat box
If you are a product leader weighing an agentic interface, I would work through this list before any UI work begins.
Can an external layer read your core entities through defined APIs, with the same permission rules your application enforces?
Are your key workflows expressed as logic somewhere, or only as habits in your team?
Is there a clear, explicit list of actions an agent would be allowed to take, and a much longer list of things it may only read?
Do you have somewhere for organisational memory to live, so conversations have continuity across sessions and users?
Can you log every agent action in a way that supports review, audit, and reversal?
Do you have an approval path for the actions that should never run unattended?
Can you measure where the agent fails, and does that measurement feed back into the system?
If several of those answers are no, the right move is not a better prompt. It is backend work.
The interface really is collapsing into chat. I have written about what that shift means from an operator's seat, where the dashboard stops being the centre of gravity. But the collapse only produces something useful if the system underneath was built to be operated this way. Chat is the last layer you add. It should never be the first thing you build.
MORE RESOURCES
