Company OS: The Architecture, Vision, and Plan
Operating Note 001: Company OS is under active development. This note explains the problem I am working on, the architectural model, and the direction of travel. It is not a finished-product announcement or a detailed implementation guide.
Over the past decade, my work has moved through native products, enterprise infrastructure, analytics, data platforms, automation, and agentic systems. The technologies changed, but the underlying problem remained surprisingly consistent: how do you turn intent into reliable action, learn from the result, and keep responsibility clear?
Company OS is the name I now use for that problem space.
My working thesis is that organisations adopting autonomous systems will need an operating layer between human intent and machine execution. Models, agents, workflows, and business applications are capabilities inside that layer. None of them is the operating model on its own.
What I mean by an operating system
I do not mean a desktop operating system, and I am not proposing another all-in-one business suite.
Every organisation already has an informal operating system: priorities, meetings, permissions, processes, software, data, decisions, and feedback. Much of it is fragmented across tools and held together by human attention.
A Company OS would make more of that coordination explicit and programmable. It should help answer six basic questions:
- What matters now?
- What context should inform the work?
- Who or what is responsible for acting?
- Which systems may be used, and within what limits?
- Which decisions require human judgment?
- Did the work create the intended outcome?
The point is not maximum autonomy. The point is reliable progress with visible ownership.
The high-level architecture
I currently think about Company OS as six connected layers.
1. Intent and priorities
Goals, constraints, ownership, and current priorities must be explicit. Without direction, autonomous execution produces activity rather than progress.
2. Context and memory
Agents and people need access to relevant data, decisions, history, and live signals. Context must be retrievable, inspectable, and governed rather than trapped in individual conversations.
3. Agents and workflows
Some work benefits from agents that can plan and adapt. Other work should remain deterministic. A useful operating layer needs both, with clear handovers between them.
4. Tools and systems
Execution happens through existing systems: data platforms, code, communication tools, business applications, and APIs. Access should be scoped to the task and identity—not granted as a universal key to the organisation.
5. Approvals and guardrails
Money, production changes, publishing, sensitive data, and irreversible actions require explicit boundaries. Human involvement should be placed where judgment and accountability matter, not inserted into every routine step.
6. Outcomes and feedback
The system needs to observe quality, cost, reliability, and business outcomes. Those signals should influence what happens next. Otherwise it is automation without learning.
Together these layers form an operating loop:
intent → context → coordinated work → governed action → outcomes → feedback
What exists today
This thesis did not start from a blank diagram. Across my current and previous work, I have built and operated the underlying capabilities separately: data pipelines, analytical models, workflows, agent-based execution, scoped system access, approval points, and observability.
That experience is the evidence base. Company OS itself is the work of turning those capabilities into a coherent operating model. That part is still being built.
I am deliberately not publishing detailed internal flows, security boundaries, agent instructions, or implementation diagrams yet. The architecture is changing, and premature detail would create certainty where there is still active design work.
The vision
The longer-term vision is an organisation where routine coordination does not depend on a person continuously moving information between systems.
Such an organisation could:
- recognise bounded work from live signals;
- assemble the relevant context;
- assign work to specialised capabilities;
- act through scoped tools and permissions;
- pause for human judgment at consequential boundaries;
- measure the result and update what happens next.
This should be possible without building an enormous, expensive platform. One of my central hypotheses is that a small team—or in some cases one person—can operate a surprisingly capable organisation when the coordination layer is designed well.
Cheap infrastructure alone is not the goal. The goal is a system that remains understandable, governable, and economically useful as autonomy increases.
The plan
I see the work progressing in three broad stages.
Stage one: connect proven capabilities
Bring existing data, workflow, agent, tool-access, approval, and observability capabilities into a shared operating model.
Stage two: make coordination legible
Create a clearer view of intent, active work, organisational context, permissions, human decisions, and outcomes across projects.
Stage three: enable bounded adaptation
Allow the system to identify and coordinate more work from measured signals while preserving explicit limits, auditability, and escalation paths.
These are directions, not release promises. I expect the boundaries and vocabulary to evolve as the system is used.
What I will publish next
For now, I will write about the architectural model, the questions guiding the build, and lessons that have become stable enough to transfer.
Later notes can go deeper into individual layers once the implementation has earned that level of explanation. I would rather publish fewer durable observations than document a moving prototype as if it were settled infrastructure.
The current reference page is Company OS. The broader path that led here is documented in my technical journey, and The Unnamed Roads is the venture studio where I am applying the thesis.