I started building CortexPrism because I was tired of stitching together LangChain, Open WebUI, ChromaDB, and whatever security layer I could rig. Every upgrade broke something, and I spent more time debugging the glue than actually using AI. I wanted a single binary that handled everything — the agent loop, memory, tools, UI, security, and channel bots — because they were built to work together.
Today, CortexPrism v0.48.5 ships with an OS kernel, a custom terminal UI framework, 5 built-in agent profiles, an IDE-style code editor, and a virtual filesystem. It's no longer an "agentic harness" — it's an AI agent operating system.
Here's what changed, why it matters, and where we're going next.
The OS Kernel: From Feature Bag to Operating System
The biggest architectural shift in v0.48 is the introduction of an OS kernel (src/kernel/). Until now, CortexPrism's subsystems were well-organized but didn't share a formal execution model. The agent loop called tools directly, the scheduler polled independently, and there was no unified way to answer "what is the system doing right now?"
The kernel changes that. Every agent action now goes through a syscall dispatcher that enforces capability-based access control. Tools are organized into 12 capability groups — FILE, SHELL, NET, MEMORY, GIT, AGENT, CODE, UI, SYSTEM, SKILL, SCHEDULE, BROWSER — forming an OS-style syscall table. Four RBAC roles (admin, operator, user, agent) map to subsets of those capabilities. When an agent asks to execute a shell command, the kernel checks: does this agent have CAP_SHELL? Is the command within the agent's resource budget? If not, the call is denied before it ever reaches the tool.
This kernel/user-space split is the defining property of an operating system. The kernel dispatches to user-space agent code via kernelTurn() and kernelTurnStream(), automatically registering processes in a parent-child tree and tracking per-agent resource consumption — token counts, cost in USD, CPU time. The main server registers as process 0 (the root), and every sub-agent it spawns becomes a tracked child process. You can inspect the full process tree at GET /api/os/processes.
The kernel also enforces a formal boot sequence. When CortexPrism starts, it no longer fires up everything at once and hopes for the best. The supervisor follows an 8-stage boot order — migrate → supervisor → validator → executor → scheduler → services → channels → ready — with socket readiness checks between each stage. If the validator daemon isn't listening within 10 seconds, the boot fails fast with a clear error instead of limping along in a degraded state.
New OS API endpoints expose the kernel's state: /api/os/info (metadata, uptime, roles, process count), /api/os/processes (process tree), and /api/os/capabilities (group and role mappings). An OS Health dashboard in the web UI turns all of this into a visual system overview with green/red indicators for daemon status, database connectivity, job counts, and memory metrics.
The TUI Framework: Yes, We Built Our Own
Terminal UI libraries in the JavaScript/TypeScript ecosystem are scarce, and the ones that exist are either tied to Node.js, abandoned, or both. Deno has even fewer options. So we built our own.
The src/tui/ module is a full terminal UI framework with a double-buffered virtual screen (VirtualScreen in src/tui/buffer.ts) that tracks cells in a 2D grid and diffs only changed cells on flush. No clearing the terminal, no flicker — just the cells that changed get redrawn. The Renderer handles SIGWINCH resize events so the UI adapts when you resize your terminal window.
The component system is class-based with React-style lifecycle hooks: onMount, onUpdate, onDestroy, onResize, and onKeyPress. Components compose through a layout engine (src/tui/layout.ts) supporting HSplit, VSplit, ScrollView, and Box with flex and percentage sizing. If you've used React, the mental model transfers: components render, update when state changes, unmount cleanly.
The input handling was the hardest part. The InputEngine (src/tui/input-engine.ts) decodes raw ANSI escape sequences — distinguishing Ctrl+M from Enter, Alt+Backspace from Delete, Ctrl+Arrow from Arrow+modifier — and provides emacs-style keybindings: Ctrl+A (beginning of line), Ctrl+E (end), Ctrl+K (kill to end), Ctrl+W (kill word backward), Ctrl+U (kill to beginning), Alt+F/B (forward/backward word), Alt+D (kill word forward), Ctrl+R (history search).
Nine reusable components ship with the framework: Header, StatusBar, TextInput, CompletionMenu, MarkdownBlock, CodeBlock (with syntax highlighting for TypeScript, JavaScript, Python, Go, Rust, Bash, and SQL), DiffBlock (unified diff with +/- coloring), ToolCard (tool call status with spinner, checkmark, or cross icon plus duration), and ChatView (scrollable message list with streaming support). Three themes — dark, light, and contrast — live in src/tui/themes/.
Both agent chat (simple layout: header + chat + input + status) and agent tui (split-pane: header + 70/30 chat/tool panel + input + status) are fully rewritten to use this framework. The chat interface has 12 slash commands: /model to switch models mid-session, /compact to trigger context compaction, /status for session info, /clear to wipe history, /save and /load for transcripts, /export for markdown, /theme to switch themes, /diff to show the last file change, /review for pending approvals, /plan for planning mode, and /help to list everything.
Five Agents, Ready Out of the Box
A recurring piece of feedback was that CortexPrism asked users to build agents from scratch before they could do anything useful. v0.48 ships with five pre-configured agents you can use immediately:
- Assistant — the new default. General-purpose, helpful, conversational. Handles anything you throw at it.
- Developer — code writing, debugging, refactoring. Knows it should produce production-quality code with no TODOs.
- Researcher — web research, documentation, fact-finding. Cites sources. Stays focused on information gathering.
- Architect — system design, planning, trade-off analysis. Produces Architecture Decision Records with a 9-part template.
- Analyst — SQL, data exploration, statistics. Follows a 7-step analysis protocol and produces structured reports.
Each has a specialized soul prompt with domain-specific identity, behavior guidelines, tool usage instructions, and output format conventions. Built-in agents can't be deleted, but they can be customized through cortex agent update. The Agent Builder still lets you create fully custom agents with multi-select tool dropdowns, icon pickers (30 emojis), and one-click cloning.
The IDE Editor in Your Browser
The File Editor page was completely redesigned. It's now a proper IDE experience: resizable sidebar (180–500px), collapsible bottom panel with Problems / Output / Terminal tabs, and a drag-to-resize panel handle. The file tree has right-click context menus (Open, Rename, Delete). Editor tabs have context menus too (Close, Close Others, Close to Right, Close All).
Productivity features: Ctrl+P fuzzy quick-open with arrow-key navigation, Ctrl+F find, Ctrl+H find/replace with regex and case-sensitivity support, Ctrl+Shift+F find-in-files with results in the sidebar panel. The status bar shows live cursor position (Ln/Col), language mode indicator, and indent info. File type icons are color-coded by extension. Creating new files and folders uses inline inputs instead of browser prompt() dialogs.
All of this lives in a single HTML file (src/server/ui.ts as a template literal). No separate frontend build step. No node_modules. The entire IDE experience ships in the same binary as the agent loop.
A Virtual Filesystem for Agents
Agents need to interact with files, databases, and configuration, but exposing raw filesystem paths is both fragile and insecure. The virtual filesystem (src/vfs/) provides an OS-level namespace abstraction: /cortex/agents/:id/ maps to agent workspace directories, /cortex/memory/:tier/ maps to memory store database tables, /cortex/config/ maps to configuration values, /cortex/logs/ maps to log files, /cortex/workspace/ maps to the global workspace directory, and /cortex/plugins/ maps to installed plugins.
Agents and tools interact with VFS paths instead of raw filesystem paths. The VFS layer resolves, validates, and routes operations to the correct backend — filesystem or database — based on namespace. This is the same abstraction real operating systems provide: /proc/ for processes, /dev/ for devices, /sys/ for kernel objects. CortexPrism's VFS serves the same role for agent-accessible resources.
Everything Observed
Observability was incomplete in earlier versions. The main agent loop was instrumented, but LLM calls from secondary subsystems — reflection, autofix, the security supervisor, the compliance classifier, skill extraction, CLI setup — were invisible. If the security supervisor made a critical decision using an LLM, there was no trace of it in Langfuse or Prometheus.
The new ObservableLLMProvider wrapper (src/observability/provider-wrapper.ts) fixes this. It wraps every provider returned by buildProvider() and buildProviderFromConfig(), ensuring every complete() and stream() call — from any subsystem — generates a Langfuse trace, a Lens audit event, and Prometheus metrics. The main agent loop's explicit generation and lens logging was removed to avoid double-counting. Session and turn context propagates through a Symbol on CompletionOptions so wrapper generations attach to the correct parent trace.
The Hardening Sprint
v0.48 ships across five patch releases (0.48.0 through 0.48.5) because we ran a hardening sprint after the initial feature push. Some highlights:
Server reliability. cortex server restart had been silently broken for weeks — a Cliffy bug caused it to route to the parent's empty action instead of the restart handler. The server had no graceful shutdown, no PID file, and a fixed 1500ms sleep for port availability. All fixed. The server now writes a PID file at ~/.cortex/data/server.pid, handles SIGTERM/SIGINT by stopping services and chrome-bridge, polls for port availability (up to 10s with 300ms checks), and uses the PID file as the primary kill target.
Marketplace and supply chain. Plugin version enrichment from GitHub releases was broken because checkGitHubRelease() was passing an encrypted vault token (enc:...) to the GitHub API, getting 401 Bad credentials for every request. The fix detects 401/403 responses and retries without authentication. Supply chain verification had two issues: Deno.readTextFile() rejecting file:// URIs, and requireKnownHash defaulting to true which blocked community plugins that don't have pre-registered hashes. Both fixed.
Daemon reliability. Logs were always empty in the UI because the supervisor wrote to daemon-validator.log but the API read from validator.log — a filename prefix mismatch. Also, the supervisor only piped stderr, discarding all console.log() output. At startup, all three daemons ran migrations simultaneously, racing to ALTER TABLE the same column. All three problems fixed.
Job scheduler robustness. Jobs stuck in running state after a daemon crash were left there indefinitely because getDueJobs() only picked up pending jobs. recoverStaleJobs() now runs at daemon startup and every 30s, detecting stuck jobs and transitioning them to pending (if retries remain) or failed. Jobs also deduplicate by name — a double-click of the "Create" button or an LLM repeating a schedule tool call no longer creates duplicates.
What's Next
With the OS kernel, TUI, and VFS foundation in place, we're focused on three areas:
-
Distributed agent swarms. The kernel's process tree and resource accounting are designed to extend across machines. Multiple CortexPrism instances will be able to form a mesh, with agents dispatched to the node with available capacity.
-
WebAssembly tool plugins. Currently, plugins are Deno modules with sandboxed permissions. WASM would provide stronger capability-based isolation — a plugin that only needs stdout shouldn't have filesystem access at all.
-
Multi-user collaboration. Shared workspaces, per-user agent configurations, and collaborative sessions where multiple humans interact with the same agent team.
Get Started
CortexPrism runs on macOS, Linux, and Windows as a single Deno binary. No Docker required, no Python, no node_modules.
# Install
curl -fsSL https://cortexprism.io/install.sh | bash
# Setup and start
cortex setup
cortex serve
# Open http://localhost:3000
Already running? Upgrade in place:
cortex self update
The project is Apache 2.0 licensed, fully open source, and has zero telemetry. Everything runs on your hardware.
GitHub: github.com/CortexPrism/cortex
Changelog: CHANGELOG.md
Built with Deno. Runs anywhere. Owns nothing but your data.
