OmniSage

What it is

OmniSage is a private, portable AI operating system for software, product, content, business, and delivery work. It is designed as a network of specialists rather than one general-purpose chatbot: each capability has a decision boundary, an output contract, a handoff path, and a clear place for human review.

The repository contains 733 canonical skill definitions, 12 active public agent profiles, a public-safe company-intelligence graph, a local CLI/plugin distribution path, and a memory layer that can be shared across approved workspaces. The public website is a preview of the operating model; the repository holds the deeper runtime, governance, and evaluation machinery.

The problem and business value

General-purpose AI can produce useful work while leaving ownership, assumptions, evidence, and next steps implicit. That makes multi-step delivery difficult to audit and makes context easy to lose between research, product, engineering, review, and follow-up.

OmniSage addresses that coordination problem by separating specialist judgment, preserving facts and risks across handoffs, and keeping consequential actions approval-gated. The intended business value is more repeatable knowledge work: teams can move from an open question to a decision brief, implementation handoff, verification evidence, or learning artifact without hiding uncertainty or turning every task into an unstructured chat transcript.

What it does today

• Serves a public Next.js preview at /, /os, /agents, and /about-mcp, including a bounded neural map of six capability groups and 12 public agent profiles.
• Maintains 733 canonical TypeScript/Markdown skill packages with trigger and output evaluations, profile routing, references, and a byte-checked plugin mirror.
• Builds a normalized company model from the organization tree, role catalog, skill taxonomy, public agent assignments, and current profile data. A separate public projection exposes only the graph nodes and relationships intended for display.
• Validates two versioned workflows: a client-request-to-feedback path and a staged sales-intelligence path. The workflow planner reports safe next stages and approval-pending states; it does not execute roles or external actions by itself.
• Stores project history through a dependency-light local SQLite fallback or a configured Supabase/Postgres backend. The memory service supports scoped retrieval, deterministic consolidation, reviewed lessons, retention preview, and draft improvement proposals.
• Provides CLI profiles, a local stdio MCP server, and a Codex/OpenClaw-compatible plugin bundle for installing the same canonical skills into supported agent layouts.

Integrations and data flow

The public graph is generated from repository-owned model data and validated workflow manifests. The build scripts reconcile the canonical skill tree and public catalog, emit a company model, project a bounded public graph, and deliver the result as static assets consumed by the Next.js interface.

For memory, the CLI or MCP layer calls a workspace-bound service. The service writes append-only events to SQLite when operating locally, or to project-scoped Supabase tables when the remote backend is configured. Retrieval is bounded by scope, sensitivity, and character budget; durable lessons are separated from short-term task context.

The hosted HTTP MCP path adds OAuth 2.1-style authorization with PKCE and Supabase Auth before authenticated memory tools are called. The remote surface also advertises read-only, digest-checked skill resources. The connector and tests are present; first-connect, reconnect, account authorization, and production deployment verification remain operational work rather than claims of fully verified live integration.

AI or automation workflow

The system is AI-assisted. Skill packages generate research, drafts, decisions, implementation handoffs, reviews, and learning proposals, while explicit owners and independent checks keep the workflow accountable. The memory analyzer can draft an improvement proposal, but it cannot approve itself, edit skills, change Git state, or publish a change.

Workflow manifests make inputs, outputs, dependencies, reviewers, approval owners, and recovery boundaries visible. Human authorization remains required for commercial approval, release readiness, content publication, and other consequential actions. The project does not claim autonomous file, Git, deployment, or external publishing behavior.

Collaboration and approval flow

The collaboration model is an evidence-aware handoff: the sending role records known facts, assumptions, decisions, constraints, risks, open questions, requested output, and confidence for the receiving role. Reviewers validate evidence rather than merely repeating the original answer. The workflow planner can expose the next safe stage, but execution and irreversible decisions remain with the authorized human or consuming project.

Security and privacy boundaries

The repository is private and the portfolio brief does not expose source code, environment values, credentials, customer data, or internal logs. The public graph is explicitly projected from a bounded public model rather than serving the full enterprise data model.

Memory records carry scope, sensitivity, data class, purpose, and retention metadata. Retrieval is bounded and labelled as untrusted evidence to reduce prompt-injection risk. Supabase access uses Auth and row-level security; service-role credentials remain server-side. The local SQLite fallback is not encrypted at rest, so the project documentation requires filesystem protection and minimizing personal or client content.

The local and remote MCP surfaces are workspace/project-bound. Tool arguments cannot grant a new filesystem root, and the remote tools cannot modify files, branches, deployments, production skills, or retention policy. Any future provider-backed connector still requires its own authorization, review, and production test evidence.

What is coming next

The next product direction is to replace the current seed organization mapping with reviewed teams, regions, owners, languages, and reporting lines; map every canonical skill to appropriate role families and agents; and add role-specific evaluation owners for the private candidate profiles.

The public graph can then grow from the current bounded profile view into reviewed role, department, country, and business-unit views with real tools, tasks, KPIs, evidence, approvals, and run history. The repository also needs controlled production verification for the hosted MCP/OAuth/Supabase path and any future provider integrations before those are described as live.

Current activity or evidence

As of 2026-08-26, recent repository work includes the company-intelligence graph, the migration to pnpm and TypeScript quality gates, separation of the MCP transport from its informational page, and the layered repository-maintainer documentation bundle. The current local verification run for this brief passed pnpm run typecheck, all 163 tests across unit, integration, and performance suites, validation of 733 skills, the skill audit with zero mechanical errors or warnings, and the canonical/plugin mirror audit.

These checks support the implementation claims above; they do not substitute for live provider authorization, production deployment checks, qualitative review of every skill, or customer outcome evidence, none of which is claimed here.