Everything below is labeled by what it actually is today: Available, Beta, Experimental, Research, or Coming Soon. Nothing here is marketing copy for something that doesn't run.
// Agentic AI in NC service "research-api" @tool to search with query: gather results from "https://api.search.example/q={{query}}" respond with results agent researcher: purpose: "Research topics thoroughly" tools: [search] max_steps: 5 api: POST /research runs research topic
Problem: agent frameworks bolt tool-calling onto general-purpose languages with heavy dependency trees. Setting up a working agent means gluing together an HTTP client, a prompt template system, and an orchestration library.
Approach: plain-English syntax with agent and @tool as first-class language keywords, compiled to a single dependency-free binary.
Architecture: tokenizer → AST → bytecode compiler → stack-based VM, with a dedicated AI opcode for model invocation. See the IP page for the patent documentation covering this design.
Limitations: young language — smaller ecosystem than Python/JS, standard library still growing (80+ functions today).
A plain-English frontend language that compiles to static HTML, CSS and JavaScript. Problem: AI-native applications need a UI layer that doesn't require a Node build pipeline to ship. Approach: describe layout, theme and behavior in plain English; NC UI compiles it to static assets deployable anywhere, including GitHub Pages. Limitations: component ecosystem is small; best suited to marketing sites, dashboards and internal tools today, not complex SPA state management.
Problem: most AI runtimes assume a cloud API and a credit card. Approach: local model execution on CPU — code generation, agentic tool-calling and the CORTEX runtime — with no API keys and no network dependency. Architecture: a compact model family (500K–20B parameters across 7 sizes) designed to run on commodity hardware. Limitations: local CPU inference trades raw capability for cost, latency and privacy — it is not positioned as a frontier-model replacement for every task. Full comparison on the Benchmarks page.
Problem: production incidents require investigating, diagnosing and fixing failures faster than any one engineer can coordinate. Approach: Ant Colony Optimization and Artificial Bee Colony swarm algorithms coordinate many autonomous agents to investigate, diagnose, fix and learn from software failures. Status: built on the NC engine; a public demo is not currently hosted. Limitations: best suited to environments with good observability data already in place; swarm coordination parameters need tuning per environment.
Problem: when a service breaks, root-causing it usually means paging someone and waiting. Approach: AI-powered incident investigation combining reinforcement learning, cognitive memory and RAG — pulls data, finds the root cause, proposes or applies a fix, and learns from the outcome. Architecture: single NC binary (~478KB), zero external dependencies. Limitations: automatic remediation should run in supervised mode until an organization has validated its recommendations in their own environment.
Problem: the industry has largely solved authentication for AI agents — proving which agent is acting. It has not solved influence governance — bounding how much any one input (a document, a tool result, a prior message) is allowed to shape a privileged action before that action commits.
Approach: every input-to-output influence is tracked as a signed "compute edge" with a per-input cap and an aggregate influence budget. A privileged action is refused before it commits if the budget is exceeded. Every decision produces a causal receipt committed to a hash-chained ledger that an auditor can verify completely offline.
Architecture: a C core (capsules, edges, ledger, authorization) plus a hardened HTTP gateway (TLS, rate limiting, audit) exposing a decision API, with a drop-in MCP middleware that gates tools/call in front of an existing MCP server — no agent rewrite required.
// adversarial influence-spreading benchmark per_input_cap_only attack_success 75.0% benign_blocked 0.0% + aggregate_influence_budget attack_success 0.0% // 4/4 blocked benign_blocked 0.0% // no false positives
Status & limitations: a working prototype, internally benchmarked — 86 tests passing, with the core C authorization logic (20 of the 86) verified under AddressSanitizer and UndefinedBehaviorSanitizer; the remaining integration tests are functional but not yet run under sanitizers. Hardware attestation (TEE) backends are currently simulated, not hardware-verified. Not yet deployed as a product. A patent disclosure packet has been prepared for the governance protocol — see Patents & IP — but no filing has been confirmed yet.
These are real, working codebases we're actively building — further along than "Research," not yet something you can install. We're publishing the honest status, including the specific limitations each project's own internal review flagged.
What it is: a bring-your-own-key AI coding and ML agent for terminal and desktop. What's real: permission-gated tools, crash-safe encrypted undo for agent writes, and a working Proof Gate — a signed, digest-bound receipt naming exactly which checks ran against which bytes before a change is accepted. Status: version 0.1.0, unreleased. The Proof Gate package is the first piece prepared for release; the CLI, daemon and desktop app are not yet published, and one packaging attempt was explicitly rejected internally as not ready to ship.
What it is: an LLM-ops control plane — tracing, evaluation, prompt management, orchestration, datasets and monitoring, positioned as an alternative to assembling several separate LLM-ops tools. What's real: a substantial, actively-developed core service with tenant-scoped isolation and a signed, hash-chained audit log. What we're correcting: that audit log is a signed hash chain, not a Merkle tree, and we don't have a build-enforced gate against any particular set of dependencies — so we're not claiming either. Status: the core service is substantial; a "DevHeal AI OS" sub-project inside it is explicitly foundation-only (health/readiness endpoints), with workflow execution, agents, tools and RAG still to be built.
These are the layers a complete AI Systems Engineering platform needs. None of them are available as standalone products today. We'd rather tell you that plainly, in detail, than dress up a roadmap as a shipping feature.
The engineering environment for AI systems. Not an AI coding assistant. Code-completion tools help you write code faster. Studio is meant for engineering the AI system itself — the agent, the tools it calls, the memory it reads and writes, the policies it must obey, and the trace of everything it did.
Today Studio is a design document and an internal prototype, not a downloadable product. What follows is what we are building toward — each capability will be labeled Available the day it actually ships, not before.
// what "engineering an AI system" means in Studio design // lay out agents, tools, memory, policy build // wire tools + connect data sources configure // memory scope + policy constraints run // execute against real or simulated input trace // inspect every step the agent took evaluate // score the run against production-readiness simulate // replay against scenario suites debug // step through a failed run deploy // ship the compiled system operate // watch it run in production heal // checkpoint, reconcile, recover
Building toward — none of the twelve capabilities above are shipped as part of a Studio product today.
Test autonomous AI systems before they interact with the real world. Problem: most agents reach production having been tested against a handful of prompts someone typed by hand. Approach: run the system against structured scenario suites — the same idea as a chaos-engineering test suite, aimed at agents instead of servers — before it ever sees a real customer.
We are not going to tell you the Simulator has run "millions of simulations" — it hasn't, because it doesn't exist as a product yet. When it does, this page will show the real scenario count and pass/fail data, not a placeholder number.
Evaluating an AI system takes more than a model-accuracy benchmark. A model can score well on a leaderboard and still fail in production because it picked the wrong tool, ignored a policy, or quietly blew through budget. Evaluation has to look at the whole run.
All twelve dimensions roll up into one idea we call Production Readiness: a system should be evaluated against all of this before it is deployed, not after it has already failed in front of a customer.
A future extension of Evaluation: a single "Production Readiness" certification for a deployed agent, the way a build either passes or fails CI. This does not exist as a product today — the mock below is illustrative of the shape it would take, not a real system or real data.
Every generic "AgentOS" pitch says roughly the same thing. Here is specifically what's different about DevHeal's approach: AgentOS is not a clean-slate design — it's the runtime we get by extracting what HiveANT and SwarmOps already do in production into one shared foundation, instead of each product reimplementing its own agent loop.
Where AgentOS is heading is documented in Patent Family B's autonomous multi-agent orchestration claims — see Patents & IP — which describe the pheromone-graph reinforcement and digital-twin analysis already running inside HiveANT today.
A lower-level, separate research thread from the AgentOS runtime above: a bare-metal type-1 hypervisor that partitions CPUs and memory into hardware-isolated domains, so one agent's runtime can't read another's memory even if the software layer is compromised.
What's verified: it boots and auto-detects hardware inventory under emulated firmware (OVMF/QEMU), and two guest domains have been demonstrated running under distinct nested page tables, proven not to read each other's memory — across a 14-lane automated test matrix (9 hardware-configuration lanes plus 5 negative/failure-case lanes) for the 64-bit hypervisor build. What we're not claiming: this has not booted on physical hardware, and only AMD's virtualization extensions are exercised so far (no Intel VT-x path yet). The project's own internal readiness gate — a 104-check automated audit — currently reports a failed verdict, and its own documentation is explicit: this is "a real but minimal kernel, not a supported production platform."
Problem: NC compiles a program; it does not yet compile a whole system of agents, tools, policies and memory as one unit. Approach: extend NC's compiler pipeline to validate cross-component contracts (tool schemas, memory access, policy constraints) at compile time instead of at runtime.
Problem: a failed step mid-workflow can leave a transaction half-complete. Approach: generalize the checkpoint/reconcile/compensate pattern HiveANT and SwarmOps already use for their own operations into a reusable engine any NC-built system can call. See the Heal philosophy.
Problem: NC AI already runs on a laptop CPU; running it on constrained edge/embedded hardware is a different set of tradeoffs. Approach: a stripped-down build of the NC AI runtime targeting edge devices. Not yet started.