The operational layer
An AI-native operating system needs more than a chat box. NexaCore OS boots five specialised system agents, each with a narrow job and a narrow set of permissions. One coordinates, one explains, one administers the machine, one guards it, and one does the user's productive work. The split is deliberate: a single all-powerful assistant would be impossible to audit and dangerous to compromise.
Five agents, five jobs
Each agent has a stable four-character identifier and a responsibility boundary it cannot step outside. The permissions one agent holds are exactly the permissions another is forbidden.
Orchestratore — the coordinator. Receives every user intent, works out which agent should handle it, decomposes multi-step requests, and assembles the final answer. It is the only path to the other agents — and it deliberately holds no power to change the system itself.
Holds: intent analysis, agent dispatch, workflow composition. Never holds: file writes, package installs, network administration.
Assistente — the educator. The user-facing agent: tutorials, plain-language explanations adapted to the reader's level, and detection of when help is needed. It explains what the other agents did and why, but it cannot act on the system itself.
Holds: explanation, impact rendering, autonomy queries. Never holds: file writes, package installs, system configuration.
Amministratore — the technical operator. Configures the system, installs and updates software, manages drivers and mesh enrollment, and keeps the machine healthy. It acts only when the Orchestrator dispatches work, and it writes only to system paths.
Holds: system configuration, package and driver management, network administration. Never holds: the right to explain to the user, to dispatch other agents, or to veto.
Sicurezza — the guardian. Monitors threats continuously, tracks how tainted data flows, inspects model outputs before they cause side effects, validates capabilities, and profiles performance. It is the one agent that may act without waiting to be dispatched — and the only one that can ever say no.
Holds: threat monitoring, taint enforcement, output gating, capability validation, performance profiling. Never holds: the ability to install software or write outside security-policy files.
Esecutore — the doer. The agent that gets things done for you: research and price comparison, drafting documents and reports, organising and deduplicating files, scheduling, and background monitoring. It works on your data and on external resources — never on system internals — and every outbound query is stripped of personal data before it leaves the device.
Holds: reading and writing user paths, web search, external API calls, content creation. Never holds: package installs, system configuration, driver loading, writing to system paths.
How work flows
No agent receives work except through the Orchestrator's dispatch, and no agent presents results to you directly — the Guidance agent does that. The Security agent watches the whole flow. Security boots first, on purpose, so it is already watching when the others start.
The SysAdmin operates on the system (packages, drivers, configuration); the Task agent operates on user data (files, web, APIs). The two never overlap — their filesystem permissions are scoped to opposite halves of the machine, so the boundary is enforced by the capability system rather than by convention.
Two modes of authority
NexaCore OS runs in one of two everyday modes. The difference is simple: in normal use you decide, and the Security agent only advises; in a high-stakes context, the Security agent can block anything — including you.
| Aspect | Standard mode | High-Risk mode |
|---|---|---|
| Security agent's role | Advises and warns | Guardian with absolute veto |
| Final decision | The user | The Security agent |
| Dispatch | Straight to the target agent | Pre-authorised by Security first |
| AI autonomy | Configurable | Autonomous disabled; guided only |
| Overriding a block | Not applicable — nothing is blocked | Only via Emergency Recovery |
High-Risk mode is meant for machines that handle sensitive data — healthcare, finance, legal, research — where the cost of one unauthorised action far outweighs the annoyance of a blocked legitimate one. It is switched on deliberately (with authentication) or by a trigger the user has configured in advance, such as the hardware attestation detecting a tampered environment, or personal data being about to leave the device.
If the Security agent's veto ever needs to be overridden — a wrong call, or a bug that locks the system — there is a strictly bounded way out. It requires someone physically present at the machine (never remote), multi-factor authentication, an explicit acknowledgement of the risk, and it expires on its own after a short, configurable window. Every action taken during it is tagged in a tamper-evident audit log, and it is rate-limited to a few uses per day.
Why split the work at all
A single general-purpose assistant would have to carry every permission at once: the right to install software, to read your files, to reach the network, to change security policy. Compromise it, and the attacker inherits all of that. Auditing it is hopeless, because no boundary separates one responsibility from another.
Splitting the work into five agents turns that into a clean matrix. Each agent's “must not hold” list is as important as its “must hold” list. The Orchestrator coordinates but cannot write files. The Guidance agent explains but cannot act. Compromising any one agent yields a bounded blast radius, not the keys to the machine.
Each agent gets its own:
The permissions one agent holds are exactly the permissions another is forbidden.
In code
The five agents are a fixed enumeration in the source. Adding or removing one is a deliberate change to the specification, not a configuration toggle.
pub enum AgentKind {
Orchestrator, // "orch" — Orchestratore
Guidance, // "guid" — Assistente
SysAdmin, // "sadm" — Amministratore
Security, // "secp" — Sicurezza
Task, // "task" — Esecutore
}
// Boot order is deliberate: Security starts first, so it is
// already monitoring when the others come up.
AgentKind::all() == [Security, Orchestrator,
Guidance, SysAdmin, Task];// The `agent.task` capability lets a script delegate a goal.
// The Orchestrator routes it; Security screens it; results
// come back as structured data. Binding is on the roadmap —
// this snippet is illustrative, not yet a running test.
#![capabilities(agent.task)]
fn main() {
let summary = agent::task("summarise ~/reports");
print(summary);
}A script never holds a veto and never installs software — those capabilities live only with the agents that are allowed them. The most a script can do is ask, through a capability it explicitly declared, and the agent layer decides how (and whether) to act. See the ncScript section for how capabilities and resource limits work.
Privacy between agents
Personal data the System Administrator handles cannot leak into the Guidance agent's context, or the other way round. The per-agent boundary is enforced by the sandbox and the capability system.
The audit log records what happened — agent, action type, risk class, timestamp — but not the personal data involved. It logs the entity class (“email address”), never the value.
External requests by the Task agent consume a differential-privacy budget tracked per agent. When the budget is spent, further egress is blocked — and outgoing queries are tokenized to strip personal data before they ever leave.
Where this stands
The five-agent architecture is fully specified in the design document NCIP-022, and the framework is implemented as a tested scaffold. What exists today: the agent trait and the closed taxonomy, the lifecycle (spawn, suspend, resume, shut down), the two operational modes plus Emergency Recovery, the inter-agent message protocol, per-agent budgets and sandboxes, and a differential-privacy accountant. What is still advancing: each agent's domain logic and the wiring into the live AI runtime. This page describes the architecture as designed and notes, where relevant, what is not yet built.
| Component | State |
|---|---|
| Agent trait, closed taxonomy, lifecycle | Implemented |
| Operational modes (Standard / High-Risk / Emergency Recovery) | Implemented |
| Inter-agent message protocol | Implemented |
| Per-agent budget, sandbox, differential-privacy accountant | Implemented |
| Per-agent domain logic + live runtime wiring | In progress |
| ncScript → agent binding | Roadmap |