Plain-language answers about the substrate model, the core concepts, and working with ContextOS. New here? Start at the top.
The basics
ContextOS is an operating model for AI-run operations — AI on watch, operators on call. Instead of bolting a chatbot onto your product, it gives your software a structured foundation (a substrate) that decides what to watch, when to act on its own, and when to ask a human.
Read: What is ContextOS →The substrate is the load-bearing layer beneath the interface: the durable record of what your system watches, the work it tracks, the signals it listens to, and the rules for when it acts versus asks. Build the substrate first and the UI becomes a thin view over it — not the other way around.
Read: How we build →Teams building AI-native operations products — Series A/B SaaS, ops-heavy businesses, and MSMEs that run on people watching dashboards. If your product has outgrown a chat box and needs to act reliably across many cases, it's for you.
Read: Use cases →A chatbot answers when spoken to; an agent improvises a plan each time. ContextOS instead defines durable threads of work and routes every signal by confidence, so behaviour is auditable and predictable rather than improvised.
Read: Operator inversion →Both. ContextOS is a method (the substrate-first model) and there are products built on it — OrderHubX and IntelliTeli, with more coming soon. We also engage with teams to apply the method to their own product.
Read: Products →Core concepts
A trigger is the event that starts or advances work — an order placed, a payment missed, a sensor crossing a threshold. Triggers are the entry points that wake the system.
Read: Triggers →A thread is the unit of orchestration: one ongoing piece of work (for example, "fulfil this order") with a clear start, the events that move it, and a terminal state. The system reasons about threads, not loose messages.
Read: Threads →A stimulus is any input the system reacts to; a stimulus channel is where it arrived (a webhook, an email, an operator action, a scheduled tick). ContextOS is source-blind — it normalises every input and scores each channel's trust.
Read: Stimuli → · Channel reference →A heartbeat is the regular pulse that lets a thread check on itself even when nothing external happened — "has this been waiting too long?" It's how the system notices silence, not just events.
Read: Heartbeats →Every signal gets a confidence score that decides its path: high → silent automation, medium → a human approves in seconds, low → a human owns the decision. The system automates what it's sure of and escalates what it isn't.
Read: The confidence model →A surface is where the system reaches a person — an approval queue, a timeline, an alert — assigned per persona so each operator sees only what they need to act on.
Read: Surfaces →The engine is the runtime that reads events, updates threads, scores confidence, and routes actions. The decision graph is the record of every decision and its outcome, which feeds back to make routing sharper over time.
Read: The engine → · The decision graph →It flips the default: instead of humans driving and AI assisting, AI stays on watch and handles the routine, calling a human only when confidence is low or stakes are high. Operators move from doing the work to supervising it.
Read: Operator inversion →The method
Decide what the system watches, tracks, and acts on before drawing any screens. The UI is the last step — a view over a substrate that already works — which avoids rebuilding everything when the interface changes.
Read: How we build →A written blueprint for your product: a thread catalog, a stimulus-channel taxonomy, a heartbeat policy, a confidence-routing model, and surface assignments per persona. It's the deliverable of a substrate audit.
Read: Work with ContextOS →The common traps — chat-box-as-product, agents that re-plan from scratch each run, automate-everything or approve-everything defaults, and treating every input source as equally trustworthy.
Read: Anti-patterns →Working together
Two engagements: a fixed-price substrate audit (two weeks, one written spec) and a fractional architect engagement (three to six months, hands-on through to production). Both start with a discovery call.
Read: Work with ContextOS →A two-week, fixed-price engagement that produces one deliverable: a written substrate spec for your product's next twelve months, plus a working session to walk your team through every decision.
Read: Engagement details →A three-to-six-month, deeply involved engagement where we pick the substrate primitives with your team, write the specs, train your engineers, and stay until the substrate is load-bearing in production. One engagement at a time.
Read: Engagement details →The substrate audit is fixed-price and runs two weeks; the fractional engagement runs three to six months. Pricing depends on scope — book a discovery call and we'll size it together.
Read: Get in touch →Deployment & integration
ContextOS can run inside your own infrastructure or chosen jurisdiction so your data and decisions stay under your control — important for regulated and data-residency-sensitive operations.
Read: Sovereign deployment →With sovereign deployment your data stays in your environment, and every AI-suggested action is logged with its inputs, confidence, and channel trust for a full audit trail. See our privacy policy for handling details.
Read: Sovereign deployment → · Privacy policy →Yes — because stimuli are source-blind, the system ingests events from webhooks, emails, APIs, schedulers, and operator actions, normalising them into one canonical envelope regardless of origin.
Read: How it works → · Stimuli →OrderHubX and IntelliTeli are live today, with FactoryHubX and OpsSignal coming soon. They're proof the method runs real operations.
Read: Products →If your question isn't here, the fastest path is a short conversation.
Calm technology with teeth.