Proposal for a Semantic Kernel for Business Workspaces - Part 3
Meaning vs. Exposure: One Graph, Two Surfaces
There is a multi-billion-dollar industry whose entire value proposition is teaching software to impersonate a human being. Robotic process automation - the robot that logs into the ERP, clicks the third tab, tabs through four fields, and presses Submit - exists because the machine surface of business software diverged from its human surface so badly that the only reliable API left was the screen. When a bank pays a robot to click through its own loan system, it is paying interest on an architectural debt: the human surface and the machine surface were built separately, by different teams, on different schedules, and only one of them was maintained.
The agent era is currently re-running this failure with better eyesight. "Computer use" agents that drive a GUI pixel by pixel are impressive as a capability and damning as an architecture - the same confession, restated: we cannot offer the machine a lawful surface of its own, so we let it borrow the human one. And in the other direction, the failure is worse, because it is invisible: APIs that expose actions no user interface ever shows, admin capabilities reachable by token but absent from every screen a supervisor will ever look at. The human surface and the machine surface of the same system routinely disagree about what the system can do - and no artifact anywhere records which one is right.
Part 1 of this series proposed a semantic kernel: seven primitives out of which every governed business operation is expressible. Part 2 gave the layer above it a grammar: three tiers of types, canonical storage units, meaning held invariant under presentation. Neither answers the question every architecture eventually fails on: who is allowed to see and do what, through which interface?
Two questions, one conflation
The proposal of this article is a separation: semantics define lawful meaning; contracts define lawful exposure and interaction shape. These are different questions with different failure modes, and conventional platforms conflate them - the database schema becomes the API shape, the API shape becomes the form layout, and within a release or two, what a thing is and who may interact with it, how are so entangled that neither can change without breaking the other.
The conflation is rarely a decision. It happens because exposure is never given its own artifact: the UI is hand-built against the schema, the API is hand-built against the same schema slightly later, and from that day forward the two surfaces are separate codebases that drift apart - Conway's law, operating on meaning. Every RPA robot and every shadow API is downstream of the same omission: nobody wrote down, in one governed place, what the system exposes.
So write it down. From one canonical operational graph - entity types with lifecycles, actions, policies, commitments, projections - the system compiles two parallel contracts:
canonical operational graph
(entity types, lifecycles, actions,
policies, commitments, projections)
| |
compiles compiles
| |
user contract agent workspace contract
(views, forms, (tools, resources,
navigation, safety envelopes,
approval surfaces, approval requirements,
presentation capability boundaries)
metadata) |
| |
human surface MCP tool surface
(rendered UI) (transport delivery)The user contract is the compiled human-facing contract: views, forms, navigation, approval and supervision surfaces. The agent workspace contract is the compiled machine-facing contract: tools, resources, capability boundaries, the conditions under which each action may be invoked. The MCP surface at the bottom right deserves a precision: it is a transport form of the agent workspace contract, in the sense of the Model Context Protocol's client-server discovery model - not a third place where capability is defined. If the MCP surface diverges from the contract it delivers, the MCP surface is wrong, by construction rather than by adjudication.
Two disciplines make the chain trustworthy. First, the derived contracts are compiled, never hand-authored - a hand-edited user contract is a schema drift waiting for its incident. Second, the two contracts have disjoint authority: the user contract governs presentation - ordering, grouping, disclosure, view composition; the tool contract governs mutation - editable inputs, required arguments, effect semantics. Neither may silently substitute for the other. A form layout inferred from a tool schema's parameter order, or a mutation boundary inferred from what a form happens to display, is the conflation returning through the back door.
Surfaces own no truth
The property that falls out of the chain is the one I consider the article's thesis: a surface can be deleted and regenerated from its source contracts without touching state or logic. Not "could be, in principle, after some cleanup" - the regeneration test is checkable, and a system either passes it or it does not.
Run the test mentally against any system you operate: delete the UI. Rebuild it from declared artifacts only. Is anything gone? Whatever was lost - a validation rule that lived only in a form handler, a status meaning that lived only in a rendering conditional, a permission that lived only in a hidden button - was truth owned by a surface, which is to say: ungoverned truth. It was invisible to policy, absent from the machine surface, unavailable to any agent, and enforced only for those consumers polite enough to enter through the front door. This is Parnas's information-hiding argument run in reverse: a module boundary only protects what actually lives behind it, and business logic that has leaked into a presentation layer is behind no boundary at all.
The regeneration property is architectural, not aspirational. It cannot be retrofitted by discipline, because discipline is exactly what erodes; it holds only when surfaces are compilation targets, with nowhere to keep truth even if they wanted to.
Parity is not symmetry
The second consequence follows from taking supervision seriously: surface parity is mandatory. A field may be grouped, summarized, collapsed behind disclosure, or rendered differently for different roles - presentation is the user contract's lawful business. What a field may not do is silently exist on the machine surface and vanish from the human one, or vice versa.
The two directions fail differently. A capability that exists for agents but is invisible to humans is a supervision hole: the human responsible for the system cannot see what the machine acting in it can do, and every attestation they sign is partly fiction. A capability that exists for humans but not for agents is quieter - it is the RPA failure, seeding itself: the moment that capability matters operationally, someone will teach a machine to reach it through the human surface, ungoverned.
Parity is not symmetry. The human surface and the machine surface are shaped by different consumers and lawfully differ in structure, grouping, and emphasis. Parity is a coverage claim, not a shape claim: both contracts derive from the same canonical graph, and any divergence in capability between them is a declared, reviewable fact - never an accident of two codebases aging at different rates.
Outcomes, not storage operations
What, then, does the machine surface expose? The industry default is to publish the storage layer: create, read, update, delete, per entity, and let the caller compose. For agents this is precisely wrong, and it is worth being precise about why.
A domain with an invoice entity and a schedule action does not expose create_invoice + update_invoice + a prayer that the caller sets the right status fields in the right order. It exposes create_and_schedule_invoice - one tool, compiled at the level of the business outcome, with its authorization conditions, approval gates, emitted events, and receipt behavior already bound to it.
The CRUD alternative fails on three counts. First, it forces the agent to reconstruct operational logic at runtime - which fields to set, in which order, under which lifecycle preconditions - and Part 1 already named that pattern: meaning reconstructed heuristically at the edge, now performed by a probabilistic model on every call instead of by an integration engineer once. Second, it makes governance inexpressible: "agents may not schedule invoices above 10,000 without approval" attaches naturally to an outcome-level action and attaches to a row-update roughly not at all - by the time policy sees a field diff, the business meaning of the mutation is gone. Third, it breaks the receipt: an outcome executed as one tool call produces one receipt recording what the operation meant; the same outcome smeared across four CRUD calls produces four field-diff records and no fact anywhere stating that an invoice was scheduled.
Storage operations are how a system remembers. Outcomes are how a business acts. The machine surface speaks the second language.
The human surface is not the lesser one
It is tempting to read "compiled UI" as "generic UI" - the dreary auto-generated admin panel. The abstraction rescuing the human surface from that fate is thirty years old. Endsley's model of situation awareness distinguishes three levels: perception of the elements (L1), comprehension of their meaning (L2), and projection of their near future (L3). Auto-generated interfaces stall at L1: all the fields, none of the meaning. But a compiler working from this architecture holds more than field lists - it holds typed contracts over lifecycles, commitments, and policies, and each maps to a level:
| Level | The supervisor's question | What the compiler already knows |
|---|---|---|
| L1 - perception | What is the state? | Typed fields, canonical units, lifecycle state - rendered per the display rules of Part 2 |
| L2 - comprehension | What does it mean? | Grouping and disclosure from the user contract; lifecycle position; which policies bind; what the last receipts say happened |
| L3 - projection | What happens next? | Commitment deadlines and breach semantics; pending approvals; declared effects of available actions |
The kernel's primitives are not incidentally helpful here - commitments are L3 objects (a deadline with breach semantics is a projection of the near future), receipts are L2 objects (the recorded meaning of what happened). A surface compiled from contracts over these primitives can present comprehension and projection by default, because the material is in the graph. This matters doubly in an agent-native system, where the human's role shifts from operator to supervisor: supervision is a situation-awareness problem before it is a permissions problem, and a surface that renders L1 only is a surface through which no one can lawfully supervise anything.
An honest boundary, in the spirit of this series: the compiler guarantees structure, not taste. Parity, regeneration, and level-2/3 presentation defaults are checkable properties; whether a particular view is well designed is not, and a design discipline above the compiled baseline remains human work. The claim is narrower: the floor is high, and the floor is enforced.
What follows
These proposals are drawn from the architecture of Coreline OS, the agent-native operational platform I am building, where the compilation chain is not a diagram but a body of law: a contract system of twelve families, with the canonical operational graph contract upstream of everything, the user contract and agent workspace contract as compiled derivatives, and the runtime MCP surface defined as a transport form that is invalid if it diverges from the contract it delivers. "Runtime surfaces are derived, never hand-authored" and "user contract governs presentation; tool contract governs mutation" are numbered rules in that law, enforced in review and CI, not aspirations in a slide deck. And the reference implementation demonstrates the thesis in the most literal way available: the forms its human operators fill in are parsed from the same MCP tool schemas its agents consume. One graph, two surfaces - and neither is anyone's screenshot of the other.
What this article has not done is govern the machine surface it just built. Compiling outcome-level tools with approval gates attached is exposure; guaranteeing that an agent holding those tools cannot exceed them - that no injected instruction, no clever composition of valid calls, no delegation chain can manufacture authority that was never granted - is security, and it deserves stronger material than prompts. That is Part 4: agent authority as a capability, in the lineage of Dennis and Van Horn, where the unauthorized action is not forbidden but unconstructable.
References
- Endsley, M.R. "Toward a Theory of Situation Awareness in Dynamic Systems." Human Factors, 37(1), 1995.
- Model Context Protocol. Specification. Anthropic, 2024-. modelcontextprotocol.io.
- Parnas, D.L. "On the Criteria To Be Used in Decomposing Systems into Modules." Communications of the ACM, 15(12), 1972.
- Conway, M.E. "How Do Committees Invent?" Datamation, 14(4), 1968.
- Dennis, J.B. & Van Horn, E.C. "Programming Semantics for Multiprogrammed Computations." Communications of the ACM, 9(3), 1966 (previewed; treated fully in Part 4).
