A desktop app that runs a fleet of agents. Graph a codebase into local memory, give Cortex an objective and let it split the work across agents that loop until it is done, and keep every byte on the computer in front of you. In development now.
Concretely: you download an application and install it, the same as any other desktop program. It opens on a dashboard. One of its tabs is a chat with Cortex, the assistant that runs the place, and the rest are the screens where the actual work happens.
Underneath that, it graphs your repository, holds what it learned last week, and dispatches sub-agents to do the jobs you hand off. All of it on the machine in front of you.
Cortex assigns the work and everything reports back up to it, so nothing runs unwatched and you are only asked when the decision is actually yours. They all read from memory and save to it, which is why what one run works out is there for the next. Nothing here leaves your computer unless you connect an outside model and allow it to.
Memory is only useful if reaching into it is free. These are measured numbers from the search benchmark in the NeuralVault source, run over a real vault of 3,479 notes, not a demo corpus built to flatter the index.
Stated honestly, because you will find this out yourself: semantic search also has to embed your query first, and that round trip to the model costs more than the index lookup does. The numbers above are the part NeuralVault controls.
Point it at a repository and it indexes files, symbols and call paths into local memory, so answers cite real locations instead of plausible-sounding ones.
Hand a job off and the agent taking it decides whether it needs breaking up, then spawns sub-agents for the pieces. You see which tools each may touch and get the diff back for approval, not a fait accompli.
Agents get a defined set of things they may touch and nothing outside it. You decide what is on that list before anything runs.
What ran, when, and why it decided to. When something changes unexpectedly, there is a trail rather than a shrug.
What it learned about your stack last week is still there this week. It gets sharper the longer you run it, without manual retraining.
Use an outside API while you evaluate it, then move the model onto your own hardware and cut the last thing that leaves the machine.
Give it a finish condition rather than a single instruction. It makes the change, runs the suite, reads what failed, fixes that and goes again, and comes back when the condition is met or when it is genuinely stuck rather than after one attempt.
This is the part that makes it a harness rather than a chat window. You are not managing a list of bots. You brief one controller, it works out who does what, and the results come back up to it rather than landing in your lap piece by piece.
The assistant in the chat tab is also the controller. You give it the objective, it decides which agents the job needs, hands them their share of it and watches what comes back. You are talking to the thing in charge rather than to one worker among many.
An agent is a Markdown note: its standing instructions, the tools it may call, the folders it may touch, when it runs and what it may spend. Write a new one in your editor and it joins the fleet. There is no hidden config and no opaque registry, so an agent that behaves oddly is a file you open and read.
Delegation is a tool an agent can call, so an agent handed something large breaks it up and hands the pieces down to sub-agents of its own. Each inherits a narrower scope than its parent, never a wider one, and reports its result back up the chain rather than off to the side.
Decisions climb the same chain the work came down. A sub-agent that needs a call asks the agent that gave it the job. That agent settles what it can and passes up only what it cannot. Cortex does the same, and puts something in front of you when the answer is genuinely yours: an executive call, a judgement it should not be making alone, or a case where it is simply not sure. The point of the hierarchy is that you are the last resort rather than the first interruption.
Underneath all of it: every agent is held to the tools and folders it was given, every call it makes is written to an audit log and a run ledger, and files are snapshotted before any agent writes to them so a bad run rewinds byte for byte. Agents can even propose edits to their own instructions, and those proposals wait in a review queue for you rather than taking effect.
You are not locked to one model, and you are not limited to one at a time. Run any Ollama model locally, point it at any OpenAI-compatible endpoint, or add an API key for any cloud provider at all, then choose per role which model does what. There is no approved list: if it has an API, it can take a seat.
That is what makes the three protocols possible, and it works across vendors rather than within one. Put a frontier model from one lab against a frontier model from another, or either against something running on your own hardware, and have them mark each other. A model checking its own work is the weakest check there is, and this is the way around it.
The same question put to several models independently, with none of them shown the others first. You get the genuine spread of opinion instead of the first plausible response.
One job split into parallel pieces and handed out at once, then merged. The work that would have been sequential stops being sequential.
One model produces, another is pointed at it specifically to attack the result. Adversarial by design, because a model reviewing its own output is the weakest check available.
Not a feature list. This is the loop you are in most days, and every step of it happens without your code leaving the machine.
It graphs the project into local memory. Nothing is uploaded; the index lives beside the code.
Not "explain this file" but "where does this break". It answers from the graph, with paths and call sites you can open.
Not "change this line" but "fix every call site and keep going until the suite is green". Cortex assigns it, the agent splits it across sub-agents, and it loops rather than stopping at the first attempt.
Nothing lands without you. Reject it and the correction goes into memory, so the next attempt is better.
Personal is not a code assistant with extras bolted on. It is the whole application, and the repository work above is one of the things you can point it at. These are the other screens, all of them included, none of them an upgrade.
The app, the graph and everything it remembers sit on your own computer. Run the model locally too and no external provider ever sees a line of your source.
Not just the current conversation. Corrections stick, context carries between sessions, and it stops re-learning your stack every morning.
No subscription to lapse, no per-token meter running while you think, and no provider swapping the model underneath you mid-project.
If you have spent months tuning standing instructions, skills and slash commands for another agent, none of that is wasted. Point NeuralVault at the same folder and it picks them up untouched. No migration, no second file to maintain, nothing to rewrite in a proprietary format.
CLAUDE.mdStanding instructions read as written, up to 12,000 characters, and exactly one file per directory so nothing is injected twice.
AGENTS.mdThe same idea in the format every other harness uses. A project set up for one of those runs here with no second file to maintain.
*/SKILL.mdSkills discovered in the standard folder layout. The ones you have already written are found and read, not re-declared.
.claude/commands/Slash commands picked up from the same place they already live, right beside your skills.
MCP serversConnect the servers you already run. Their tools arrive as tools, inside the same permission model as everything else.
CORTEX.mdThe one that is not optional. It is what tells the model how NeuralVault itself works, and it gets its own section below.
Your instructions, your skills, your commands, your MCP servers. What changes is underneath them: memory that survives the session, permissions on every action, and a record of what ran.
A CLAUDE.md by another name, after the assistant that reads it. The difference is what goes in it. Instructions for a coding agent say how you like your code. This says how NeuralVault works, and it is what turns whatever model you point at it into something that can operate the place.
You are most of the way there. NeuralVault reads Claude Code's CLAUDE.md as written, so a project you have already tuned works on day one. It just works better converted, because a CLAUDE.md says nothing about NeuralVault: it was never written for it. Left as-is, your rules get followed by a model that does not know the board or the approvals queue exist.
The conversion is one instruction: ask Cortex to read your CLAUDE.md and write it out as a CORTEX.md, keeping your rules and adding the core sections.
One thing to know first. Exactly one instruction file is read per directory and CORTEX.md is checked first, so adding one does not stack on your CLAUDE.md, it replaces it. Convert rather than copy, or rules you spent months on quietly stop being read.
Edit it freely, and you should: it is the main way you shape how the whole system behaves. What you should not do is delete the core sections. They are not preferences, they are the instructions that tell the model these capabilities exist. Strip them out and you keep the features while losing the thing that knows how to use them.
Not two products. One application, one download, and Business is what you get when the company parts are switched on. Nothing above is removed, downgraded or held back: every screen, every agent and every capability on this page is in both editions. Business adds to it, and the things it adds are the ones that only start to matter once other people depend on your output.
So the question is not which product fits, it is whether you need that layer yet. If you do, go to NeuralVault Business. If you do not, nothing on this page is a compromise.
The whole harness. Agents, persistent memory, the board, workflows, approvals, the audit trail, local models, the plugin API, sync across your own devices.
It is in active development and the interface is still moving. That is the reason to be early rather than a reason to wait: the people who get in first are the ones whose friction decides what ships. Leave an email and you get exactly one message, on the day it is ready to download.
One email, the day it is ready to download.Nothing before it, nothing after it, and your address goes nowhere else.
Thanks. You will hear from us the day it ships.
Takes about four seconds. No account, no card.