First-party packages
The first-party packages that ship with Neuralis installations, and what builtin-class means.
Every capability in Neuralis is a package, and the platform ships with first-party packages under the @neuralis scope. Together they are the
anatomy of the AI workforce: agent-core is the nervous system (the LLM
loop, streams, tools, skills, workflows, chat — and the terminal, the human's
own window into the same machine room), brain-core is the memory
(one URI filesystem and vector index over every source), machine-core is
the hands and eyes (a persistent desktop the agent drives), and admin is
management (roles, credentials, limits, audit). The host application stays
generic — identity, project boundaries, the workspace shell, routing, and
deployment — while these packages contribute everything users and agents
actually touch.
What "first-party" means
First-party packages are builtin-class packages:
- Admin-installed. They arrive as dependencies of the host application, installed by the platform administrator — not dropped into a project at runtime.
- In-process. They run with the embedded Node runtime inside the host
process and expose typed APIs to each other via
getPackageApi(). See lifecycle and execution. - Trusted by source, not by self-declaration. The act of adding a package
as a host dependency is the trust decision, so the host assigns the
first-partytrust tier to every builtin-class package it loads. A project-installed package can never claim this tier.
Despite their privileged position, first-party packages speak exactly the
same contract as any other package: a neuralis manifest block, file-first
discovery of tools and skills, feature-gated routes, URI policies, and
declared App surfaces. Nothing they do is hardcoded into the host.
The catalog
| Package | What it provides |
|---|---|
| @agent-core | The agent runtime kernel: the LLM loop, model providers, conversations and streams, tool execution, the skill protocol, MCP client and server, package loading, workflows, the chat UI, and the PTY terminal. |
| @brain-core | The URI-native filesystem: scoped source configurations, the connector registry, vector memory with Qdrant-backed sync, the fs_* agent tools, and the Files widget. |
| @admin | The administration console: dashboard and system health, user and project inventory, platform configuration, the credential store UI, audit views, and owner/admin management skills. |
| @machine-core | A per-user persistent virtual desktop (Webtop) with browser automation, in-container shell execution, screenshot and recording capture, and a machine:// filesystem source. |
The contract library @neuralis/package-system underpins all of them: it
defines the package vocabulary, validators, policy evaluator, and dispatchers.
It contributes no product surface of its own, so it is documented across
this section rather than as a catalog entry.
How these docs are organized
Each package has its own top-level tab describing its public surface — the features it provides, the routes and tools it exposes, its App surfaces, and its security behavior:
@agent-core
Agents, providers and models, tools, skills, workflows, the terminal, and stream security.
@brain-core
Sources and connectors, memory and sync, filesystem skills, and the Files UI.
@admin
Features and routes, the admin UI, management skills, and security.
@machine-core
The machine_use tool, machine sources, deployment, and skills.
Building your own package?
The full package-development contract — directory layout, manifest, tools, skills, routes, connectors, and testing — lives in the rest of the package system. The first-party packages are built on that contract and make good reading as large worked examples.