Foundation
Capabilities in use
Portfolio, Operator API, decision/learning contracts, provider registry, Inngest workflows, Raindrop signals, and Focus growth loops are already running against real studio work.
A working thesis by Emil Ingemar Karlsson
Company OS
The operating layer between human intent and autonomous execution.
A Company OS connects people, data, AI agents, workflows, and tools so work can continue across systems—not just inside a chat. It makes autonomy legible: priorities are explicit, access is scoped, consequential actions are governed, and outcomes are measured.
The premise
A model is a capability.
An agent is a worker.
Neither is an organisation.
Companies already have an operating system, even when nobody calls it that: goals, meetings, permissions, processes, software, data, and feedback. Today these parts are fragmented across tools and held together by human attention.
Company OS is my attempt to make that coordination layer programmable. It is not another all-in-one suite that replaces every business tool. It is the connective operating layer across them. The hard problem is reliable progress across boundaries while keeping responsibility clear.
Why I arrived here
Company OS is a synthesis, not a departure.
The name is new. The underlying problems have followed my work from native products through enterprise operations, analytics, governance, and data platforms.
- 01
Product
Native apps and product analytics taught me to connect intent with observed behaviour.
- 02
Operations
Infrastructure, GDPR, and security taught me that reliability needs ownership and visible controls.
- 03
Data
Power BI and Databricks taught me how shared context, models, and feedback support better decisions.
- 04
Autonomy
AI, workflows, and MCP made execution programmable; Company OS coordinates the whole loop.
Live system map · Aug 2026
How the connected systems fit together.
Company OS is no longer only a thesis diagram. The control plane, knowledge store, durable workflows, growth signals, and venture edges below are the systems I have actually wired into TUR Company OS — still behind adapters, still with explicit trust boundaries.
TUR Company OS — connected architecture
Human intent enters through mobile and web surfaces. Company OS owns state, policy, and memory in Supabase. Work, models, and ventures attach through replaceable adapters — not as the source of truth.
Operator surfacesWhere priorities and approvals become visible
primary
iOS / Linear Mobile
daily decisions · work queue
preview
Control plane web
Next.js on Vercel
build
Cursor
local + cloud agents
vault
Bitwarden
human-held credentials
Control planeGovernance, contracts, and the learning loop
Signal→Decision→Work Unit→Artifact→Outcome→Lesson
runtime
Next.js + Operator API
OpenAPI-checked · mobile-first
policy
MethodPolicy · ModelRuntime
budgets · allow-lists · scorecards
growth
Growth Operating Loop
≤3 daily proposals · Focus projects
Knowledge planeSource of record
SoR
Supabase Postgres
Auth · RLS · events · outbox · Growth Memory
git
GitHub
code · ADRs · registries · CI
objects
Cloudflare R2
artifacts · raw evidence
analytics warehouse
MotherDuck
THA domain facts only
Execution planeReplaceable workers
workflows
Inngest
durable jobs · intent processing
models
OpenRouter
multi-model routing · spend gates
acquisition
Apify
commodity crawls · THA store actor
deploy
Vercel
control plane + venture fronts
Signals & work projectionEvidence and queues — never the full specification
queue
Linear
Work Unit projection
product
PostHog
read-only Growth adapter
inbox
Raindrop
→ decision_signals
inbox
Gmail
TUR/Inbox label → signals
pulse
ByteByteGo RSS
tech pulse capture
mail
Resend
digests · TAN outreach
Portfolio edgesOrganization → Cluster → Project → Application
hockey
THA
site · analytics · MCP · Apify actor
print
TAN + The Print Route
campaign front · fulfilment kernel
legacy
Coolify / Hetzner
n8n · LiteLLM · Paperclip · MCP
mobile
Apple Developer
signing · TestFlight path
uptime
UptimeRobot
status checks
Operator
Control
Knowledge
Execution
Signals
Portfolio
Operator
- iOS / Linear Mobile
- Control plane (Vercel)
- Cursor
- Bitwarden
Control & knowledge
- Supabase Postgres
- GitHub
- Operator API
- MethodPolicy / OpenRouter
Execution
- Inngest
- Apify
- Cloudflare R2
- MotherDuck (THA)
Signals & edges
- Linear
- PostHog
- Raindrop
- Gmail inbox v0
- TAN / TPR
- Coolify heritage
The self-hosted Coolify / n8n / LiteLLM / Paperclip stack remains part of the execution heritage. Company OS owns state, policy, and memory; those providers stay replaceable. The day-to-day application list is on Tools.
Reference architecture
Six layers, one operating loop.
Each layer has a different failure mode. Treating them as one “AI agent” hides the interfaces that need to be designed, secured, and measured. The system map above is how those layers show up in the current build.
- 01
Intent & priorities
A shared view of goals, constraints, ownership, and what matters now. Autonomy without direction only automates activity.
- 02
Context & memory
Business data, decisions, histories, and live signals made available in a form agents can retrieve and people can inspect.
- 03
Agents & workflows
Specialised roles that plan and execute, combined with deterministic workflows where consistency matters more than improvisation.
- 04
Tools & systems
Scoped access to code, data, communication, and operations through APIs and MCP—not a universal key to the company.
- 05
Approvals & guardrails
Explicit boundaries for money, publishing, production changes, and irreversible actions, with a human decision where judgment matters.
- 06
Outcomes & feedback
Observability, cost, quality, and business outcomes flow back into the system so it can be evaluated and improved.
Autonomy ladder
Autonomy is a progression, not a switch.
Most useful systems combine several levels. High autonomy belongs in well-observed, reversible work; consequential decisions should retain explicit human ownership.
- 01AssistAI helps a person complete a bounded task.
- 02ExecuteA workflow performs a defined process after a trigger.
- 03CoordinateAgents divide work, use tools, and maintain shared state.
- 04OperateThe system finds work, executes it, monitors results, and escalates exceptions.
- 05AdaptPriorities and methods change from measured outcomes within explicit policy.
Foundation, build, direction
A working thesis with a staged plan.
Active development
A coherent operating layer
The current slice tightens mobile decisions, evidence completeness, and venture edges (THA commercial, Print cluster) without turning every tool into a permanent dependency.
Direction
Accountable autonomy
The long-term direction is an organisation that can identify and coordinate bounded work from live signals while keeping ownership, limits, and escalation paths explicit.
Company OS is under active development. I publish the architectural model, the live system map, and operating lessons that are stable enough to transfer — not agent instructions or security internals.
Continue exploring
The thesis and the path behind it.
Read the first operating note, follow the technical journey that led here, or explore the practitioner definition behind the work.