Agentic AI and Infrastructure
ChaseOS
A human-AI operating system and governance layer for orchestrating agents, projects, knowledge, approvals and persistent digital workflows.
Outcome
Local-first control plane that lets one builder run many agents across real projects without giving up review, memory or approval boundaries.
Media
Select any frame to enlarge
V1.1.0 release evidence
V1.1.0 keeps a research proposal, its resolved evidence, exact destination, proposed collection node, 17 planned links and zero rewrites on one review surface. The operator can inspect the graph, queue approval or dismiss the suggestion without silently creating knowledge. Intake-to-Graph inspection highlights the proposed node and five existing connections before filing. This is signed packaged-app visual QA against a real vault, not a concept mock-up. The redesigned Approvals surface separates Studio and local requests, agent runtimes and external connectors. This retained capture truthfully shows an all-clear queue; it does not fabricate a pending approval for marketing.
See it running
- Ready
The graph as a live surface: 450 nodes drawn from a 52,353-file vault, work-beams fanning out as agents reach into the documents they're working on, then straight into one companion's runtime profile and the roster behind it. Real capture, replayed faster than real time so the motion reads cleanly. The operator's morning view. One screen answers what is running, what is waiting on a human decision, what needs review, and how large the knowledge graph has grown (7,306 nodes across 10,107 edges). Everything below it — needs-attention items, quick launch, recent agent activity — is derived live from the vault rather than typed in by hand.
The knowledge graph
The knowledge graph is the substrate the agents actually reason over. This view renders 450 nodes and 511 edges selected from a 52,353-file vault — documents, projects, runtime profiles and decisions as a single connected structure, so an agent asked about a project can traverse to its files, its history and its owning runtime. Zoomed in, the structure becomes legible: runtime profiles (Archon, Hermes, OpenClaw, Codex Bus Worker, Claude) sit alongside the routing contracts and vault maps that govern them. Agents are first-class nodes in the same graph as the knowledge they act on — which is what lets governance and context share one source of truth. Searching the graph collapses it to just what matters — here, the 21 runtime-profile nodes that define every agent in the system. The live companion rail on the right shows which of those runtimes are actually online at that moment, tying the static map to real runtime state. Nothing enters the graph untyped. Every node carries a family, a subtype and a trust state — and that last one matters most: 441 raw, 8 archived, 1 quarantined. Quarantine is how unverified material stays visible without being treated as fact by anything downstream. The graph is an instrument, not a picture. Agent overlays replay what runtimes touched and when, focus scopes narrow the view to a time window, and maintenance can be handed to an agent — which is itself a governed run rather than a direct mutation.
A real personal instance
Docs / Inspector is where a vault file becomes an addressable object rather than a loose note. This is the control tower of a real personal instance — a live status board covering trading, projects, study, security research and content, each row linking into the graph. Not a demo tenant: the institution name is masked, and nothing else here is staged. Further down the same page, the instance is organised by life domain instead of by app — pillars and core areas, system and infrastructure, trading, projects, knowledge. Every entry is a live link into the graph, so the way someone thinks about their work and the way the system stores it are the same structure. A concrete real-world use: ChaseOS running a computer-science degree. The document defines a 15-hour-per-week study system — 53 weekly folders, module maps for every year, and generated lesson, lab, question and agent-prompt pages. The Inspector rail on the right (outline, links, backlinks, provenance, properties) is what makes each study note a first-class graph object, so an agent can revise against the real syllabus instead of a pasted summary.
Governance and approvals
The governance boundary, stated plainly: nothing runs without you. Requests from Studio, the runtimes, Discord and scheduled work all converge here, and an agent cannot self-authorise past it. Approval can be granted once, for a session, or as bounded autonomy — and every decision is logged. What agents may do on real websites, governed per skill. Each carries a risk tier and an execution mode — dry-run only, shadow proof only, activation held, never run — across 316 recorded browser runs and 32 approvals. Nothing touches a live site until it clears a governed lane. The front door to the knowledge graph. Everything captured by the operator or collected by a runtime waits here, quarantined, until it is approved — 25 items pending. This is what stops agent-gathered material from silently becoming institutional truth. ChaseOS proposes structure it can see but will not impose it. Candidate collections are assembled from the graph, recent chats and agent activity — one spanning 1,974 records — and every one is labelled create · needs approval.
Agents and runtimes
Chat is multi-runtime rather than single-assistant. The same conversation surface addresses Claude Code, Codex, Hermes, OpenClaw or Chaser Agent, with 66 saved sessions organised into projects — so work with an agent is retained context, not a disposable window. A live shell sits inside the chat lane, attached to the vault working directory. The operator and the agent look at the same terminal state, so a proposed command can be inspected and run in place rather than copied between windows. The full terminal surface launches any runtime under a keystroke and keeps its own History / Policy tab. Sessions are recorded as auditable runs, which is what makes agent-initiated shell work reviewable after the fact instead of invisible. The agent bus is how runtimes coordinate rather than collide. Two gateways are live with fresh heartbeats, routing across 490 and 16 channels. The all-time lifecycle counters are deliberately unflattering — 248 done against 210 expired, 124 cancelled and 22 blocked — because expiry and blocking are the safety behaviour working, not failures being hidden. Every runtime is also a companion you raise. Form, rank and aura advance only on clean runs — 25 of them for the next evolution — so the progression is a direct readout of how reliably that agent has behaved. It makes operational trustworthiness legible instead of abstract. Memory is per-agent, inspectable and editable. Each runtime accumulates character traits and distilled insights with the source conversations cited, and the operator can teach, reflect or delete any entry — so an agent's second brain never becomes a black box.
Where the work lives
Workspaces are derived from the vault, not created by hand: 27 projects surfaced from real activity signals, each carrying its own document count, run history, bound cron jobs and assigned runtime. ChaseOS proposes new ones and flags stale ones; the operator decides. Missions give agent work a board a human recognises — triage through review to done. The runtime cards above it expose real queue state, including a stalled queue, so work that is quietly not progressing is visible rather than assumed. Workflows are declared units of automation, not prompts. Each one publishes its outputs, its permission scope and its posture — the tripwire scan shown here is log-only and mutates no runtime state. Seventeen are installed, thirteen written locally. The marketplace distributes those workflows as installable packs. Installing makes a pack runnable on this machine and nothing more — it still has to clear approval before it acts, which is the difference between sharing automation and handing over control. Every recurring job across every runtime in one plane: 88 on, 15 off, 103 routines executed by a single runtime with a declared fallback for each. Toggling one is a real config change that the runtime picks up — so it routes through the same approval gate as everything else.
Evidence
The receipt for all of it. 12,135 read-only records — 7,042 agent-activity entries, 2,864 build logs, 2,151 documentation changes, plus terminal runs, desktop runs, runtime audits and handovers — in one searchable timeline. Governance is only real if it leaves evidence.
Case study
The problem
Running many agents across real projects collapses too much into one stream: source facts, model guesses, proposed actions, memory writes and public claims all arrive looking equally confident. Once an agent can deploy, spend or publish, the cost of that ambiguity stops being theoretical. ChaseOS starts from the position that the boundary — not the model — is the product.
The design decision that shapes everything else
ChaseOS's runtime contract does not assume an LLM should do each step. Before any execution, its decision router selects a modality per material step: a human for accountability and liability, deterministic rules for exact or security-sensitive operations, ML for versioned prediction over structured data, and generative AI only for bounded interpretation and synthesis. The first shipped foothold of this is deliberately read-only — it validates a decision contract and produces an approval plan naming the accountable human, the exact scope, the required evidence and the block-on-timeout behaviour, without executing anything.
Public core, private instance
The framework is split hard: ChaseOS Core is an MIT-licensed public scaffold — folder structure, governance docs, templates, runtime standards, a lean CLI — while identity, credentials, live memory and project state live in a separate private instance. The publication standard requires Core materials to be reusable without exposing private paths, names or deployment state, and a repo-safe secret audit module scans tracked and untracked text before anything ships. Core is now published independently on PyPI as chaseos-core and stands on its own as a governance framework for any agent system; ChaseOS is its first and most demanding consumer rather than its only possible one.
What the CLI actually does today
The lean Core CLI covers version and health checks, explicit capture into quarantine (file, stdin, local image-text — no ambient screen or browser capture), schedule-intent listing, a bounded workflow runner with dry-run, a local-first connections registry that discovers provider manifests without authenticating anything, and read-only commercial scaffolding for catalog, entitlements and ledger surfaces.
Trade-offs accepted
Everything defaults to fail-closed, read-only, or dry-run, which makes the system slower to demo than an autonomous agent stack. That is deliberate: the failure mode of a confused agent here is a rejected proposal or a blocked approval, not a live incident. Convenience is layered on top — Forge packs and the managed Cloud lane, both now shipped — rather than bought by weakening the boundary.
Where it is now
ChaseOS V1 has shipped. There is a public, Certum-signed installer for Windows, Studio runs as the local command surface, and the managed runtime lane is live — it is what the metered credits balance bills against. Subscription checkout is live. On the marketplace the honest split is narrower than it sounds: Forge discovery, the pack catalogue and the workflow surfaces are in place, while full marketplace transactions and settlement remain in development. None of this loosens the boundary — agent execution still runs through explicit permissions, approvals and governance gates.
Technology
- Python
- SQLite
- Agent orchestration
- MCP
- Discord control plane
What's shipped inside it
ChaseOS Forge ↗
LivePublic workflow-pack marketplace. Packs are installable units of governed automation rather than prompt templates.
Public commercial surface for Early Access tiers.
ChaseOS Studio ↗
LiveThe local operator surface: knowledge graph, projects, review queues, runtimes and approvals — where agent output gets accepted or rejected. V1 ships as a Certum-signed, timestamped Windows installer.
Control plane
LivePer-project lanes carrying status receipts and human approval gates that agents cannot self-authorise. Shipping inside Studio V1: the approvals queue, the agent bus and the read-only audit timeline are all operator-facing today.
ChaseOS Cloud ↗
LiveManaged layer over the local-first core. Live today: accounts, subscriptions and a metered credits balance that pays for managed runtime execution and knowledge-graph compute, with top-ups outside the monthly allowance. Local-first and BYOK stay viable; managed is opt-in convenience, not a requirement.
Architecture
Each layer is marked with its real state. Nothing below is described as finished because it is drawn in a box.
- ChaseOS StudioOperator surface — projects, review queues, approvalsPartial
- Governance / control planeApproval gates, authority boundaries, status receiptsImplemented
- Agent busDispatch and arbitration across runtimesPartial
- RuntimesHermes · peer runtimes · Chaser AgentImplemented
- Tools · MCP · integrationsCapability surface exposed to agentsPartial
- Memory · knowledge graph · workflowsDurable project state and provenancePartial
- Implemented and in use
- Partially built
- Designed, not built
Forge workflow packs
First-party packs on the live Forge marketplace, each publishing its contract — permissions, approval gates and output shapes — before it runs. Snapshot from the public structured index.
Startup
Startup Validation Launch
Source-backed launch research, offer tests, and operating briefs.
- Research brief
- Offer test
- Operating brief
- Decision log
Content
Content Distribution Pack
Plan, adapt, and review distribution workflows without external posting by default.
- Content brief
- Post draft
- Editorial calendar
- Approval record
Research
Research Briefing Pack
Collect sources, summarize insight, and preserve citation-ready evidence.
- Source digest
- Research brief
- Evidence map
- Citation set
Developer ops
Local Developer Ops Pack
Inspect repos, propose patches, run tests, and write bounded handovers.
- Implementation plan
- Patch artifact
- Test summary
- Handover doc
Commerce ops
Ecommerce Reselling Ops Pack
Track sourcing, listing prep, and operator approvals before marketplace actions.
- Sourcing summary
- Listing draft
- SOP
- Approval log
Governance
Agent Governance Pack
Define runtime capability manifests, permission ceilings, and result shapes.
- Capability manifest
- Permission ceiling
- Result schema
- Audit log
Every pack is in preview, runs under ChaseOS Studio Early Access, and requires human approval — packs request permissions, they do not grant themselves any.
Browse Forge live ↗System areas
- Studio
- Governance and approvals
- Runtime orchestration
- Hermes and peer runtimes
- Chaser Agent
- Knowledge graph
- Memory
- Agent bus
- MCP and tools
- Projects and workflows
Scope and boundaries
Not claiming unbounded agent execution, completed marketplace transactions and settlement, or enterprise-scale SaaS operations. Managed runtime execution is live and metered; agent actions stay permission-scoped and approval-gated.