Company OS: The Architecture, Vision, and Plan

Operating Note 001 (updated 16 Aug 2026): Company OS is under active development. This note explains the problem, the architectural model, and what is connected today. It is not a finished-product announcement or a security runbook. For how Company OS differs from agent frameworks and orchestration tools, see Company OS vs agent framework vs orchestration.

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. The product implementation lives as TUR Company OS inside The Unnamed Roads.

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:

1. What matters now?
2. What context should inform the work?
3. Who or what is responsible for acting?
4. Which systems may be used, and within what limits?
5. Which decisions require human judgment?
6. 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

In the implementation that maps to a tighter learning loop:

Signal → Decision → Expected Outcome → Work Unit → Artifact → Actual Outcome → Human Correction → reviewed Lesson

Live system map

The conceptual layers are still the right vocabulary. What has changed is that enough of the stack is wired that I can publish a provider-level map without pretending every interface is finished.

The interactive diagram lives on the Company OS reference page. In short:

Company OS owns state, policy, audit, and memory. Providers stay behind adapters. Employer, personal, and studio data remain in separate trust realms.

I still do not publish agent instructions, approval endpoints, or security runbooks here. The map is deliberately provider-shaped, not exploit-shaped.

What exists today

This is no longer only separate capabilities waiting to be named. Inside TUR Company OS:

• a mobile-first control plane and versioned Operator API;
• portfolio hierarchy (Organization → Cluster → Project → Application);
• decision, outcome, and lesson contracts with organization RLS;
• a machine-readable provider registry with cost ceilings;
• durable workflows on Inngest;
• Growth Operating Loop v0 (at most three daily proposals across Focus projects);
• Raindrop inbox learning into decision signals;
• commercial Focus on THA, including a public Apify Store actor;
• Print cluster split: TAN as campaign frontend, The Print Route as fulfilment kernel.

The earlier self-hosted Coolify / n8n / LiteLLM / Paperclip stack remains part of the execution heritage. Company OS is the coordination layer those capabilities feed into — not another all-in-one replacement for every tool. The application list is on Tools.

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. Much of this stage is underway — the system map above is the evidence.

Stage two: make coordination legible

Create a clearer view of intent, active work, organisational context, permissions, human decisions, and outcomes across projects. Native iOS remains the primary long-term operator surface; Linear Mobile is the interim queue.

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

I will keep the Company OS page as the live reference — including the system map — and write operating notes when a lesson is 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 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.