Why Interfaces Need Operating Boundaries

An interface is not just the place where work appears.

It is a boundary around the work.

A good interface tells the person using it what kind of situation they are in: what context is active, what evidence matters, what authority applies, what interruptions are acceptable, what actions are available, and when judgment should return to a human.

It also gives the work a worldview.

By worldview, we do not mean a grand philosophy imposed on the user. We mean the practical frame the interface creates: what it makes visible, what it hides, what it treats as a first-class object, what it makes easy to compare, what it makes expensive to ignore, and what kind of action it makes feel natural.

This matters for people because context switching is tiring. It matters for agents because context switching is dangerous in a different way: the system may carry the wrong memory, tool permission, goal, or action model into the wrong operating situation.

The tempting answer is to collapse everything into one universal interface. One inbox, one agent, one workspace, one command surface, one place where all work happens. That can be useful when the alternative is scattered tools and duplicate information. But if the universal interface erases the difference between operating contexts, it can make work less legible rather than more legible.

The better design principle is:

Unify operating context. Separate operating posture and worldview.

In Proximity, that principle shaped the decision to have a shared shell, control plane, workspace identity, and product availability layer while still treating Actor, MONOid, WyrdOS, and Pilfer as distinct operating surfaces and product entities. The aim is not fragmentation. The aim is bounded separation: each surface should carry the context, authority, cadence, worldview, and review model appropriate to its work, while the wider system preserves shared operating intelligence across the organisation.

Interfaces Are Operating Boundaries

The word "interface" often gets reduced to layout: buttons, navigation, panels, tables, cards, forms, and chat boxes.

Those things matter, but they are not the deepest function of an interface. An interface defines how a user, agent, or system is allowed to perceive and act inside a situation.

That means every interface contains an argument about the world. A CRM says relationships are accounts, contacts, stages, notes, and next actions. A finance system says the world is vendors, budgets, approvals, spend, invoices, and exceptions. A project tool says the world is tasks, owners, deadlines, dependencies, and status. None of these views is neutral. Each one helps with some truths and flattens others.

It answers questions like:

• What work is this surface for?
• What worldview does this surface bring to the work?
• Which sources are in scope?
• Which records are authoritative?
• Which actions are allowed here?
• Who is the responsible person?
• What needs review before it moves?
• What should be hidden, delayed, or unavailable?
• What happens if an action is wrong?

That is why interface boundaries are part of organisational context, not merely presentation. A finance approval surface, a research workspace, a client update composer, and an engineering agent each need different facts, permissions, defaults, safeguards, and worldviews.

If those situations are collapsed into a single undifferentiated command surface, the system may become convenient but ambiguous. The user has to remember which mode they are in. The agent has to infer which authority applies. The organisation has to trust that the right boundary and worldview will be reconstructed from prompts, labels, or habit.

That is fragile.

Why Context Switching Costs People

People can switch contexts. They do it all day. The problem is that switching is not free.

Task-switching research describes switch costs: people are typically slower and more error-prone when moving from one task set to another than when continuing the same task. Rubinstein, Meyer, and Evans studied executive control in task switching and showed how shifting mental procedures has measurable performance costs ^{1Rubinstein, Meyer, and Evans, "Executive Control of Cognitive Processes in Task Switching"}.

Sophie Leroy's work on attention residue adds a useful workplace version of the same problem. When people move from one task to another, part of their attention can remain stuck on the previous task, especially when the previous task was unfinished or hard to disengage from ^{2Sophie Leroy, "Why is it so hard to do my work? The challenge of attention residue when switching between work tasks"}. The cost is not only time. It is partial presence.

Modern software often makes this worse. A survey of attention management systems describes how always-on computers and smartphones create attention fragmentation through notifications and constant access to new information ^{3Anderson et al., "A Survey of Attention Management Systems in Ubiquitous Computing Environments"}. A later line of work on social role-based interruptibility argues that interruptibility is not only a short-term attention state; people also have different preferences across social roles and life domains ^{4Anderson et al., "Towards Social Role-Based Interruptibility Management"}.

That point matters for professional tools. A person is not only switching from one screen to another. They may be switching from partner to reviewer, from writer to approver, from researcher to operator, from client-facing judgment to internal administration.

When the interface does not mark that shift clearly, the person carries too much in their head.

The wrong response is to create more tool sprawl. Too many disconnected surfaces create their own switching cost. The right response is to design boundaries that match real operating modes, then connect the context underneath them.

Why Context Separation Matters For Agents

For AI agents, the same design problem becomes sharper.

An agent does not simply "use an interface." It uses tools, memory, retrieval, instructions, permissions, and action paths. Those are operating conditions. If they are too broad or poorly separated, the agent can combine the wrong context with the wrong action.

A drafting agent may be allowed to read source evidence and propose text. A finance agent may be allowed to match invoices, check policy, and prepare an approval packet. A product operator may be allowed to inspect deployment status and suggest a rollback. Those are not interchangeable contexts, and they are not interchangeable worldviews.

The distinction is not cosmetic. It affects:

• Memory: which prior events and preferences should influence the task.
• Retrieval: which sources are relevant and authoritative.
• Tools: which systems the agent can call.
• Authority: whether the agent may draft, update, route, approve, notify, or execute.
• Review: where the human checkpoint belongs.
• Recovery: how mistakes are detected, reversed, or escalated.
• Worldview: what objects, relationships, and risks the agent treats as important.

Human-data interaction research is useful here because it frames data systems around legibility, agency, and negotiability: people need to understand what is happening, have meaningful control, and be able to negotiate data-driven effects ^{5Mortier et al., "Human-Data Interaction: The Human Face of the Data-Driven Society"}. Those same ideas apply to agent interfaces. A person should be able to tell what context the agent is operating in, what authority it has, and how to intervene.

Distributed cognition also pushes against the idea that serious work always belongs in one monolithic interface. Recent HCI work on ubiquitous analytics argues that interaction can be understood as representational state moving across minds, speech, artifacts, bodies, and devices, rather than traffic through one stable interface ^{6Elmqvist, Ritsos, and Butcher, "Channels and Substrates: Distributed Cognition as an Interaction Model for Ubiquitous Analytics"}. That is close to how professional work already happens. Work moves through meetings, documents, dashboards, records, review surfaces, and specialist tools.

The job of an operating layer is not to pretend those contexts are the same. It is to keep them connected enough that people and agents can move responsibly between them.

The Case For Separate Interfaces

Separate interfaces are useful when they preserve a meaningful boundary in the work.

They clarify role, posture, and worldview

The same person may need different postures during the day. They may investigate, draft, review, approve, reconcile, or escalate. A good interface makes that posture visible.

A review surface should not feel like a blank chat box. A deployment control surface should not feel like a casual note-taking tool. A client communication surface should not make sensitive sending feel like internal drafting.

When the interface marks the posture, the user spends less effort remembering what kind of work they are doing. When it marks the worldview, the user also sees what kind of reality the system is asking them to inhabit: evidence, relationships, cost, risk, delivery, learning, care, or execution.

They reduce context collapse

Context collapse is usually discussed in social media, where different audiences and situations flatten into one space. The same pattern appears in professional systems when internal notes, client-facing language, draft work, approved records, private assumptions, and operational actions all live in one ambiguous surface.

Separate interfaces help preserve audience and purpose. Drafts can remain drafts. Review packets can show their evidence. Approvals can carry their authority. Client updates can have a different threshold from internal summaries.

They make authority easier to see

Authority is hard to reason about when everything happens in the same command surface.

If an agent can search, draft, update, email, approve, and execute from one place, the human has to understand which action is currently being proposed and what permission boundary applies. If the interface is separated by operating mode, the boundary becomes easier to inspect.

This is especially important for agentic systems. The question is not only "can the model do this?" It is "is this the right context for this action, with this authority and this recovery path?" That is the same readiness argument behind the everything tool misconception.

They create better review surfaces

Review is not a generic activity.

A legal review, finance approval, product deployment, research synthesis, and client update all need different evidence layouts, risk signals, source links, and action controls. A separated interface can make the review legible because it is built for the decision at hand.

This is where separation improves human judgment rather than replacing it.

They lower ambiguity for agents

Agents work better when the task, context, tools, and success criteria are constrained. A bounded interface can carry those constraints as part of the operating environment. The agent should not have to infer the entire work mode from a user prompt.

That makes the system calmer. The agent knows what it is there to do. The human knows what kind of output to expect.

The Case Against Separate Interfaces

The argument against separation is also strong.

Too many interfaces create fragmentation. People have to remember where work lives, which system owns the record, which notification matters, and which tool has the latest state. If the boundaries do not match real work, they become busywork.

Separate interfaces can also duplicate context. The same customer, matter, project, vendor, document, or decision may be represented differently in multiple places. That creates reconciliation work and weakens trust.

There is also a navigation cost. If the user has to jump through five tools to understand one issue, the system has failed even if each tool is well designed locally.

Interface separation can also create mode errors. Jef Raskin argued strongly against modes in interface design because users can forget which state they are in and trigger the wrong action; his book *The Humane Interface* makes modelessness a central design value ^{7Jef Raskin, The Humane Interface}. Don Norman's work on design errors makes a related point: systems should account for human limitations rather than force people to carry hidden state in memory ^{8Don Norman, "Design Rules Based on Analyses of Human Error"}.

That is an important warning. A separated interface is only helpful if the boundary is visible, stable, and meaningful. If the system hides its mode, surprises the user, or makes similar actions behave differently without clear cues, separation becomes a source of error.

Software work shows the same tension. Research on interruptions in software development found that task switching imposes cognitive load and that contextual factors can be more disruptive than task-specific factors ^{9Shakeri Hossein Abad et al., "Task Interruption in Software Development Projects"}. But software teams also need multiple tools because code, review, deployment, incident response, and planning are genuinely different operating contexts. The problem is not multiplicity itself. The problem is unmanaged multiplicity.

Three Interface Strategies

The third option is the one Proximity is built around.

It is not a claim that every workflow deserves its own application. It is a claim that operating modes and worldviews should remain legible. Where two workflows share the same context, authority, cadence, worldview, and failure mode, they may belong in the same surface. Where those conditions differ, forcing them into one interface can make the system feel simpler while making the work less safe.

Why Proximity Chose Bounded Separation

Proximity's design starts from a practical observation: professional organisations need shared operating context, but they do not need every action to happen in the same undifferentiated place or through the same worldview.

The shared shell gives the organisation a common workspace identity. It can show which products are enabled, provide a common entry point, and support a path toward shared auth, runtime config, and integration control.

The separate product entities preserve operating posture and worldview. Actor, MONOid, WyrdOS, and Pilfer can each carry their own task model, interface rhythm, evidence needs, action boundaries, and way of seeing the work. That lets a user or agent enter a surface with a clearer sense of what kind of reality is being represented there.

This also fits the staged architecture. Early Proximity does not need to merge every product into one codebase or pretend every product already shares one backend. It can start with a shell and control plane, then bring products into shared auth, tenant config, and governed integration paths over time.

The long-term direction is integration without flattening:

• Shared workspace identity, so the organisation is not scattered across unrelated accounts.
• Shared runtime config, so enabled products and tenant boundaries are explicit.
• Shared integration governance, so sources and permissions do not have to be reconnected everywhere.
• Distinct operating surfaces, so each product can preserve the posture and worldview appropriate to its work.
• Controlled launch and review paths, so action happens through visible boundaries rather than hidden authority.

That is the difference between a platform and an everything tool.

An everything tool tries to absorb the work. A platform should make the work legible, connected, and governable while preserving the boundaries that make action responsible.

The Practical Design Rule

The practical rule is simple:

Keep context connected, but keep operating modes and worldviews legible.

Connected context prevents fragmentation. It lets a person or agent understand the customer, matter, project, approval, evidence, deadline, and current state without manually reconstructing the organisation from scattered tools.

Legible operating modes prevent collapse. They make clear whether the user is drafting or approving, researching or acting, reviewing evidence or changing state, preparing a recommendation or sending a message.

Legible worldviews prevent a subtler kind of collapse. They make clear whether the system is asking the user or agent to see the work as a relationship, a risk, a budget, a delivery path, a source-backed argument, a workflow, or an operational state.

This is useful for people because it reduces hidden mental load. It is useful for agents because it narrows memory, tools, authority, and review to the situation at hand.

The interface is therefore not an afterthought. It is one of the places where governance becomes real.

If the interface cannot tell you what context is active, what authority applies, what worldview is being used, and what kind of work is happening, the system is asking the user to supply the operating boundary from memory. That is tiring for people and unsafe for agents.

Proximity's answer is bounded separation with shared operating context. Not one universal surface. Not a pile of disconnected tools. A connected operating layer with interfaces that know what kind of work they are for, and what worldview they bring to that work.

Sources

1. Rubinstein, Meyer, and Evans, "Executive Control of Cognitive Processes in Task Switching"
2. Sophie Leroy, "Why is it so hard to do my work? The challenge of attention residue when switching between work tasks"
3. Anderson et al., "A Survey of Attention Management Systems in Ubiquitous Computing Environments"
4. Anderson et al., "Towards Social Role-Based Interruptibility Management"
5. Mortier et al., "Human-Data Interaction: The Human Face of the Data-Driven Society"
6. Elmqvist, Ritsos, and Butcher, "Channels and Substrates: Distributed Cognition as an Interaction Model for Ubiquitous Analytics"
7. Jef Raskin, The Humane Interface
8. Don Norman, "Design Rules Based on Analyses of Human Error"
9. Shakeri Hossein Abad et al., "Task Interruption in Software Development Projects"