Businesses are run by systems — for selling, fulfilling, billing, hiring — and for decades the recipe for building them has held: model the business process, build a backend that keeps the records and enforces the rules, and build the interfaces that let people do their part. Everything built this way has two inherent properties. It is static — process, schema, and screens fixed at build time, however the work changes afterward — and it hard-codes a division of labor: every screen and API a standing decision about which parts of the work belong to a person.
Capable language-model agents undo both. A computer can now operate the systems the way a person would — read the records, respect the rules, run the operations — and meet the user in plain conversation. So neither the interface nor the division of labor has to be pinned down in advance anymore, and both can be done better than before.
This article traces that shift from end to end. Part I lays out the current architecture, its problem, and the shape that replaces it. Part II follows the agent's side of that shape — what it takes to operate your systems, and where that capability can actually live. Part III follows the user's side — what people need alongside conversation. Part IV explains how such a system develops, and who is allowed to change what.
Every business application contains two layers: a durable substrate — the data, the rules, the operations that must hold, often called the backend — and a UX layer, the screens, forms, and reports that exist to get data in and out. The user reaches the substrate only through that UX, and the UX is frozen at release. Whatever the developers shipped is what everyone operates, however the work changes around it. That is the static property, made concrete.
A working day is never one system. It spans the CRM, the sheets, the accounting — each with its own frozen interface — and nothing connects them except the person. That is no accident. It is the old division of labor doing exactly what it was designed to do. Where moving work between systems could be reduced to a rule, an integration could carry it — but the routing that took judgment, reading each record and deciding where it belonged, was the job assigned to people.
The cost shows up on two planes at once. The mechanical plane: launching, navigating, entering, submitting. The cognitive plane: reading each output, deciding, feeding the next step. Conventional software automates neither end to end — the person is the workflow engine on both, and every hop between silos runs through the user's hands and head.
None of this made the old design wrong. For a while it was about as good as it could be — the UX patterns matured, the grid, the form, and the dashboard refined into efficient tools. What the design could not escape was the invariant beneath it: there was work only people could do. Reading a record and judging it, deciding the next step, carrying the result from one system to the next — computers couldn't, so the screens existed to route that work to a person. That invariant is gone. A capable agent can do that work now, and the whole layer built around it — with the mechanical and cognitive load it imposed — is what opens up. That is the opportunity.
Put a capable agent between the user and their systems and everything changes — the person need no longer be the engine that drives the work or the glue that carries it between the systems. But capability is not something the agent carries in on its own: a bare model has no reach into your systems and knows nothing of your business. It is conferred by the environment the agent runs in. In the right environment — the one that gives it access, so it can reach the systems and drive them, and understanding, so it knows what the data means and the rules it must respect — the agent can operate the substrates directly on the user's behalf, absorbing all of the mechanical friction and much of the cognitive load that weighed down the prior architecture. Access and understanding take concrete form as the agent's tools and skills: the tools are its access, its reach into the systems; the skills are its understanding, the know-how and rules for working them. The user talks to the agent in natural language, the agent works the substrates through those tools and skills, and communicates back through both natural language and a rich and dynamic collaborative interface. The substrates themselves do not move; only the front end changes.
Three interactions define the new picture:
This dissolves the problem at its root, because it redraws the division of labor. The agent takes over both planes, and the value is two-part:
What stays human is stating intent and confirming what matters; direction and accountability do not transfer. That is the new division of labor, and unlike the old one it is not hard-coded into screens. It is drawn conversation by conversation, at whatever line the work actually needs. We develop that argument in full, with worked examples, in Two Planes of Work.
Part I said an agent needs the right environment around it. To see what that environment is, look at how an agent is built and how it runs — the answer falls out of both.
An agent is an LLM in a loop with tools. Reaching anything outside the model — a business system, or the agent's own files — is a tool call. Those are its parts:
The model comes trained and fixed. The harness is a general-purpose program. The environment is the only part you supply.
Here is one turn, start to finish — and the step that matters most is easy to miss. Everything the agent reaches beyond the model is a tool call: reading one of its own files is the same kind of act as calling your CRM. But files get one privilege nothing else does. Before the model does anything, the orchestration layer has already loaded certain files on its own — the root instructions for this workspace, and the catalog of skills and tools on hand — straight into the context. The rest the model must elect: seeing a skill it needs, it calls the tool that reads that file. Only then does it act, reaching a business system through another tool, with the result fed back. Round and round until the work is done, then one reply returns to you.
That reading step is the whole game. The same message with nothing loaded gets a generic answer; the same message with your instructions and the right skill in context gets one that runs your business. Everything else in the loop is identical from one company to the next — so watch which part isn't.
Run the loop a thousand times, at a thousand businesses, and two of the three parts never change.
The model runs every turn, but its weights are frozen. It is the same model at Acme or at OtherCorp, and it brings the same generic capability everywhere: it can reason, write, and use its bundled tools, but it knows the world at large, not your business. And nothing it learns in a session survives to the next — every run starts blank.
The harness runs every turn too, but it is the same program for everyone — the same loop, the same tool-calling, the same file system. General-purpose by design, it holds nothing specific to you.
So the one thing that differs — run to run, business to business — is what the loop pulls from the file system. That is the only place your particulars can live: not in the frozen model, not in the generic harness, but in the files. And those files do just two things for the agent — the two Part I named:
Read and run, understanding and access: two moves over one folder of files.
Fill that file system on purpose and you have a workspace — the environment, made deliberate. It is the right environment Part I invoked — no longer a phrase, but a thing you can point at.
Two things follow.
It is what the application becomes. Part I split every application into a durable substrate and a disposable UX. Drop the frozen UX, keep the substrate, add the encoded skills and tools, and the agent runs the whole thing — an application written in two languages: exact code where exactness matters, plain language where judgment does.
It is shared ground. The person and the agent both read and write it. What gets agreed, learned, or decided lands in the files, not the conversation — so it is still there next session, for the next session's agent.
The other side of the new architecture is what the user sees. A conversation is one contact surface; it is not sufficient on its own.
Conversation is a natural, intuitive interface — and a poor surface for monitoring, comparing, glancing, approving from a phone, or noticing work you didn't ask about today. What the user's screen wants is two surfaces at once: the conversation, and a durable place to see.
So the user needs a second surface alongside conversation, and its requirements can be stated exactly.
These four are the specification of the second lane — the glass. The industry knows the gap and is mid-experiment: Canvas, Artifacts, generative UI that fabricates screens per request, agent inboxes and dashboards. Nothing has settled. The UX of agent-mediated work is open territory.
Our position has two parts — what gets rendered, and the surface it renders on.
The rendering. At any moment the user can draw from a library of familiar renderings — the board, the table, the report, the trend line, each a disposable projection of the substrate — or, when the situation or the wanted insight is novel, ask the agent to fabricate something new on the spot. Familiar by default, novel on demand; either way, nothing is hand-built or hand-maintained.
The surface. Renderings need somewhere to live that is decoupled from the chat surface: a place the user can arrange — move a rendering from one screen to another, keep several up at once — organized as named, precise spaces, so the user and the agent can work together the way people do around a meeting-room whiteboard. Everyone agrees on the space; ideas get parked visually; and what was parked stays exactly where it was put. It is the workspace's shared ground, one level up: common ground both parties can point at, made visual.
The first part the agent supplies. The second is the glass itself — a role, not a product.
BotBeam is the piece we are building to fill that role: an intelligence-free communication fabric between people and their agents. It exists because the conversation lane is not enough. Conversation is real-time and ephemeral — the right medium for direction and judgment, gone the moment you need to refer back — while work also needs a reference that is solid and durable. Agents work while users are away; users think of things while agents are off; a decision has to keep until the other side picks it up.
Four capabilities follow: agents project their work into the human world; people take part in unattended workflows, approving without having to be present; an intent inbox holds what the user drops in until the agent drains it; and artifacts can carry their own conversational context, so a report can be questioned by the reader's own agent. One discipline keeps it honest: BotBeam owns the glass and the delivery; the workspace owns the meaning and the work.
We named two properties of the old recipe: a hard-coded division of labor, and everything static, pinned down in advance. Part I redrew the first. This part retires the second.
The workspace is a set of files, and the agent is a loop that acts through tools. Put the two together and something follows: the agent can write files, and the workspace is files — so the same loop that uses the environment can extend it. There is no deploy boundary, because there is nothing to deploy. A new capability is not compiled into an application and shipped; it is a file laid down where the next session's loop will read it.
That is what living means: using the workspace and extending it are the same activity, done through the same interface — you talk to the agent. Every unit of work either finishes a task or deposits a permanent capability — a tool, a schema, a rule, a view — that every future task lands on. Every move pays twice: the task done, and the capability that remains. Nothing is finished; the workspace you have next month is more capable than the one you have today, as a side effect of use.
A workspace is not built and then used. It is built by being used.
One rule runs it. State what you want; if it is reachable with what exists, it gets done. If not, the next move grows the missing piece first — permanently, in place. What a move grows is access, understanding, or presentation: a tool that reaches, a rule that means, a view that shows. The first two are the agent's needs; the third is grown for the user. Orchestration is not grown move by move — it is the standing machinery, in the tools, the harness, and the user, that every move runs inside.
An environment has to be made, and there are two ways to make one.
Holding the substrate versus reaching it where it lives is a spectrum within one concept, not a boundary between two. Most real workspaces mix both.
A second axis sits across the first. Living means the same thing everywhere: the application is changed through the same interface it is used through. What varies is how deep a change is allowed to cut — and that is a different cut than the tools and skills of Part II. Those are the materials; this is a lens laid across them, and underneath it is one distinction: read versus write, with the write side split in two. Some tools and skills only read the substrate; others write to it; and among the writers, changing a rule over the existing schema is a smaller act than changing the schema itself. Three layers fall out, in order of how much a change can break.
The two expressions are the two extreme settings. In a Living Workspace, nothing is locked: the user and agent can change a schema in the same conversation that uses it. In Orchestra, the substrate is governed — a designated team changes schemas and rules through a deliberate process — while presentation stays fully open, any user's agent fabricating views on demand, and capability sits between, where users propose and the team ratifies.
The law underneath is simple: governance follows durability. The more durable the artifact, the more governed the pen that writes it. Orchestra is not less living; it is living at every layer for someone, and at the top layers for everyone. Between the extremes lies a spectrum of deployments — a personal workspace, a team workspace with a designated gardener, an organization-wide curated commons — each setting the dial per layer.
The through-line is one claim. The model is generic and the harness is generic; everything that makes an agent yours is the environment. So the durable assets of software are no longer programs or interfaces. They are workspaces — substrates plus encoded know-how — and an agent binds them to the people they serve.
We are building this in three pieces. The Living Workspace is the grow path: a runnable reference implementation that proves the concept from empty folders to finished work. Orchestra is the overlay path: the way an existing business adopts this without migrating its systems. BotBeam is the glass: the shared surface both paths render through.