Workspace as Company Runtime

Abstract

This paper is a design thesis, not an empirical benchmark. It argues that the correct product primitive for AI-native company software is the workspace understood as a company runtime: a durable boundary that binds agents, files, tools, permissions, runtime resources, memory, audit, and cost.

The claim is intentionally architectural. If agents are expected to perform delegated work rather than produce isolated answers, then the system around them must provide the same operational categories that make human organizations legible: role, authority, context, artifact, accountability, and budget. A chat thread can host conversation; it cannot by itself host a company.

1. Definitions

Workspace. A durable organizational boundary that contains agents, sessions, files, permissions, resources, usage, and billing state.

Agent. A software worker that can receive a task, use models, call tools, access scoped context, produce artifacts, and leave an inspectable execution trace.

Company runtime. The minimal software substrate required for a company-like unit to operate: identity, work assignment, execution, memory, tool access, governance, audit, and cost accounting.

AI-native company. A company in which a material share of white-collar execution is performed by agents, while humans remain owners, reviewers, customers, and legally responsible actors.

2. Thesis

The workspace should be treated as the first-class runtime of an AI-native company.

The reason is structural. Work performed by agents is not merely language generation. It is a sequence of actions over context, files, tools, credentials, external services, and runtime environments. Each action has authority, cost, and risk. The smallest coherent boundary for those properties is not the model, not the conversation, and not the individual user. It is the workspace.

3. Why the chat thread is insufficient

A chat thread is optimized for conversational continuity. Company work requires operational continuity. The difference is decisive.

A conversation can remember what was said. A company must remember what was done, by whom, with which authority, against which resources, at what cost, and with what resulting artifact. When an agent edits a file, runs a command, calls a provider, or schedules recurring work, the important object is no longer the message. It is the execution trace plus the changed state of the workspace.

This creates five requirements that a pure chat model does not satisfy:

1. Artifact durability. Outputs must land in a file system or object space that survives the session.
2. Authority scoping. The agent must be allowed to access some resources and forbidden from others.
3. Execution isolation. Commands and scripts need a runtime that is not the user's personal machine.
4. Auditability. The organization must inspect the chain of tool calls and decisions.
5. Cost accounting. Usage must aggregate to the company boundary that benefits from the work.

4. Workspace semantics

The workspace becomes useful when product primitives map to company semantics.

5. Governance before autonomy

The safe order is governance first, autonomy second.

Many agent systems try to increase autonomy by making the model more powerful. That is necessary but not sufficient. Autonomy without a boundary produces ambiguity: what may the agent access, what may it change, when should a human review it, who pays for the action, and how does the organization recover when something goes wrong?

The workspace runtime should therefore expose four governance mechanisms before pushing toward broader autonomy:

• Permission boundaries for files, tools, credentials, and external services.
• Visible traces for tool calls, generated artifacts, and state changes.
• Human review points for risky, expensive, or irreversible work.
• Billing enforcement so cost limits are hard constraints, not dashboard advice.

6. Design implications

If the workspace is the runtime, the product should be designed around the following principles.

6.1 State belongs to the workspace

Important state should not live only inside a model context window. Files, artifacts, decisions, schedules, credentials, and resource grants need durable workspace storage. Model context is an execution aid; workspace memory is the system of record.

6.2 Agents should be specialized by role

A single universal assistant is convenient but weak as an organizational abstraction. A company benefits from role separation because authority, context, evaluation, and cost can be scoped. Research, coding, support, operations, finance, and writing agents should be separately governable even when they share a workspace.

6.3 Tools should be visible

Hiding tool execution makes the product feel smooth in the short term and untrustworthy in the long term. If the user cannot inspect how an output was produced, the workspace cannot become a serious operating surface.

6.4 Cost must be a hard runtime signal

In an AI-native company, usage is not a cosmetic metric. It is the operating cost of delegated work. Balance, prepaid commitments, spend limits, and suspension behavior must be enforced at runtime.

6.5 Destructive actions require time and audit

Resource deletion, workspace purge, and similar destructive operations should not be instantaneous reactions to billing or inactivity. The runtime needs grace windows, notification, audit records, dry-run modes, and explicit operational controls.

7. Limits of the thesis

This thesis has three important limits.

First, current models are uneven. The runtime can make agent work more governable, but it cannot make every task reliable. The product must assume failure, ambiguity, and review.

Second, legal responsibility remains human. Even if agents execute more work, humans remain the accountable parties for contracts, compliance, customer commitments, and financial decisions.

Third, company work is socio-technical. Better software can reduce coordination cost, but it does not eliminate judgment, taste, trust, or strategy.

8. Evaluation agenda

The thesis should be evaluated by operational outcomes rather than chat quality alone. Useful research questions include:

• How much recurring work can move from manual prompting into scheduled or skill-based execution?
• Which permission model produces the highest trust with the least configuration burden?
• What level of trace detail helps users review work without overwhelming them?
• How should workspace memory decide what to preserve, summarize, or forget?
• Which tasks become economically viable when model usage, compute, and storage are accounted for as workspace cost?

9. Conclusion

The AI-native company is not primarily a model problem. It is an operating system problem.

Models provide intelligence. The workspace provides boundary, memory, authority, execution, audit, and cost. Without that runtime, agents remain assistants near a user. With it, they can become workers inside a company.

Vecbase is built around that bet: run a company, not a chat.