A working-engineer's substrate for AI-on-watch operations. Threads, stimuli, heartbeats, and surfaces.
The system continuously watches a defined universe of activity. It joins facts with intents with deadlines on every live lifecycle. It enriches signals with context. It decides — most of the time, silently — what should happen next. Only when it genuinely needs a human does it locate one. The human is on call, not on duty.
ContextOS is a method. The method runs inside products — OrderHubX today, more to follow. The software that delivers it is downstream of the worldview.
This is the same posture as a great chief of staff or a senior operator: they handle the noise so the boss can handle the signal. ContextOS makes that posture deployable.
AI on watch. Operators on call.
AI finds the human. The human doesn't give AI work.
An order arrives from a retailer. That's a trigger. It spawns a thread — the order's lifecycle, from arrival to delivery confirmation. Along the way, stimuli land on the thread: the warehouse acknowledges, the carrier picks up, the customer asks to change the address. Between them, a heartbeat is scheduled at each step. If the warehouse doesn't acknowledge within the SLA, the heartbeat fires. The engine reads the event log and the stimulus log together, produces a signal with a confidence score, and routes it to a surface — automation if the call is clear, an action queue if a human should review, an approval surface if only a human can decide.
Everything below this paragraph is vocabulary for the moving parts in that story.
Four moves repeat. The same loop runs from a household to a hospital ward, an agency to a kitchen — different vocabulary, different tempo, identical shape. To build operations where AI is on watch and operators are summoned only when needed, follow these four verbs.
Triggers from external ecosystems — an order, a brief, a regulator window opening, a supplier confirmation, a sensor crossing threshold — spawn threads. A thread is one entity's lifecycle from creation to logical conclusion. The system runs thousands of concurrent threads at any moment.
Each thread is advanced by stimuli: source-blind inputs that arrive from any of nine channels — in-app human action, webhook, inbound email, SMS reply, sibling system pull, AI agent, scheduled pulse, in-app system event, or device reading. Three streams — events (facts that happened), interactions (intents pressed), heartbeats (what should have happened by now) — describe the three roles a stimulus plays. Heartbeats are scheduled at chain-birth and fire on time; that's how the system watches for absence, which by definition can't be detected from incoming events alone.
Mechanisms: triggers, threads, stimuli, heartbeats.
Each incoming stimulus joins the thread it belongs to. History attaches. Policy attaches. Persona attaches. Recent overrides attach. Channel trust attaches — a webhook signed by a government gateway carries different weight than a parsed inbound email. By the time a signal is ready for routing, it carries enough context for a decision to be made.
The same event means radically different things to different people. An 8% over-budget campaign is routine for the agency finance lead, an early-warning to the brand manager, and a non-event to the promoter. A 102°F temperature is a daily occurrence at a paediatric clinic, a concern in a normally healthy adult, and a crisis post-surgery. Enrichment is what makes meaning per-persona explicit before routing decides what to do with it.
Mechanisms: signal-centric design, persona lens, channel trust, context joins.
Each enriched signal carries a confidence score. High-confidence cases route silently to automation. Medium-confidence cases propose an action and await human approval. Low-confidence cases surface full context to a human who owns the call. Routing is by confidence and persona — not by signal type. Some actions never silently automate regardless of confidence; that's a policy guardrail tenants configure per jurisdiction.
Mechanisms: confidence model, engine, multi-surface routing, bounded autonomy.
When a human is needed, the system locates them on the surface they already glance at — a watch-face complication, a pinned conversation in Slack, the kitchen tablet, a voice assistant when they ask "what's next." Ambient surfaces are primary. Push notifications exist as a failsafe escalation, not a default delivery mechanism.
The discipline is to surface at the latest safe moment that still allows action. Don't show "homework due Friday" on Sunday afternoon. Show it Wednesday morning, when there's still time to act but no time to forget. Goldratt's theory of constraints applied to attention: don't release work into a system earlier than the bottleneck — in this case, human attention — can absorb.
Mechanisms: multi-channel locator and ambient surfaces, ALAP timing, channel preferences.
Every signal-routing-action-outcome chain is recorded in the decision graph — the loop that closes the method. Confidence sharpens. Routing sharpens. The locator sharpens. Operations gets better because the system remembers what worked. Read about the decision graph.
Underneath the four-verb method are five concepts. They're each independently obvious in hindsight; together they describe a different shape of operations than the one we've been building.
What ContextOS does borrow, freely, is the combination. CQRS gave us the idea that intents and facts are separate logs. Event sourcing gave us the immutable append-only log as a substrate. Goldratt's theory of constraints gave us the discipline of as-late-as-possible. PagerDuty gave us a working model of multi-channel escalation. The contribution of ContextOS isn't any single one of these. It's the assembly: persona-appropriate context delivered ALAP through chosen surfaces by an AI orchestrator over a thread-tracked, source-blind stimulus log.
ContextOS sits adjacent to several established categories. Knowing what it isn't sharpens what it is.
It isn't a workflow engine. Workflow engines like BPMN encode processes — the steps, the gates, the approvals. They execute a recipe. ContextOS doesn't care about the recipe; it cares about the moment when the recipe is about to fail and someone needs to act.
It isn't a state machine framework. XState and others are about declaring transitions; ContextOS is about watching them whether you declared them or not, and surfacing the human when a thread stalls between states.
It isn't an AI agent framework. Agent frameworks like LangChain or CrewAI are task-driven. A human poses a task, the agent decomposes and executes. ContextOS doesn't wait. It runs continuously over a thread-tracked stimulus log and acts where confidence is high.
It isn't a notification platform. Slack, PagerDuty, Pushover are plumbing. ContextOS sits above them. It decides whether anything should be said at all, when, on which surface, to whom. The platforms are how it sometimes delivers; they're not what it does.
It isn't a chatbot or AI assistant. Those are pull — you ask, they answer. ContextOS is push, but disciplined: only when needed, at the latest safe moment, on the surface you already look at.
It isn't a data integration platform. Stitch, Fivetran, Airbyte move data between systems. ContextOS sits above them — once the data is moving, ContextOS is what decides what to do about it.
For the precise differences, see Anti-Patterns.
The components needed to make ContextOS work have been quietly assembling for a few years. Cheap large language models with enough nuance to interpret messy human signals — voice notes, photos, free-text complaints — without dedicated training. Always-on glanceable surfaces in every persona's pocket. Mature multi-channel APIs from the messaging platforms. Durable schedulers — Postgres with pg_cron will hold the heartbeat layer for any single organization without a sweat. Privacy regulation that's making self-hosted look like the responsible deployment shape rather than the inconvenient one.
The other shift is cultural. After a decade of attention-economy software, people are exhausted. Calm technology with teeth — quieter and more correct, because it watches things humans were never going to track at scale.
For three decades we built systems of record — databases, ERPs, CRMs — that record what happened. ContextOS is what comes next: the operating layer that watches the lifecycles those records describe, summons humans only when needed, and lets operations act before reports arrive.
Left: Record → Summarize → Analyze. Right: Systems of Record → ContextOS (Watch, Enrich, Route, Surface) → Decisions & Actions on every live thread.
Information asymmetry can be weaponized. A boss who sees everything every employee sees, plus everything they don't, has too much. Apps built on ContextOS, used as a tool for surveillance, are a real risk the design must address. The answer is sovereign deployment — apps built on ContextOS run on your infrastructure, you decide what they capture, your data doesn't leave your boundary. Context for me, context for you, no central authority skimming context off the top.
Ready to see the four-verb method end-to-end?