Mind vs. Brain
Meet MindStrix: an open-source AI companion that can remember, take on work, and build tools with you.
You have probably had this conversation with an AI:
You explain the project. You explain the decisions. You explain why the obvious solution will not work. Eventually, you get somewhere useful.
Then you come back and explain it again.
Or you hand over a job and get an excellent plan. You ask it to begin. Then to continue. Then to check the file it says it wrote. Somehow, you have become the project manager for an assistant that was supposed to be helping you.
I wanted something I could build a working relationship with. Something that could keep the decisions, use the tools, carry an assignment forward, and return with work I could inspect.
That is why we built MindStrix.
The first public beta is available today. It brings persistent graph memory, an agentic work loop, reusable skills and tools, and a browser interface together around a continuing AI participant — what we call a Person.
Give them a name. Introduce yourself. Give them something worth doing.
Start with a job
Imagine handing your Person a file of messy project notes:
Read these notes, turn them into a practical plan, and write a checklist. Check that you included the decisions we already made. Keep a memory of the choices I approve so we can continue next week.
That is the kind of workflow MindStrix is built to support.
A Person can read files in its workspace, use permitted tools, divide bounded work among temporary workers, inspect their results, write an artifact, and check what was saved. The Tasks page gives the assignment a place to live and gives you somewhere to follow its progress and review the result.
You can close the browser while it works. The MindStrix service and model connection must keep running, but the assignment does not depend on you staring at a chat window.
This is what I mean by agentic: the system can take steps toward a result, use the capabilities it has been given, evaluate what came back, and continue within its limits. It can do more than describe what somebody else should do next.
That opens up useful possibilities: turn research notes into a brief, develop a reusable procedure, work through a writing project, or create and test a small utility. External services can be connected through explicitly configured integrations. The starting point is practical work in a controlled local workspace.
There are still limits. The model can make a poor decision. A task can exceed its budget. An external service can fail. The useful response is to make those conditions visible and preserve enough information to recover intelligently.
A polished paragraph saying “done” is not a substitute for the file.
Your Person can help build the toolbox
This is the part that made the whole project click for me.
An AI assistant becomes much more useful when you can teach it a repeatable procedure or ask it to build a tool for a recurring job. That capability should be something you can understand and shape through the interface.
MindStrix puts Skills & tools in the GUI.
A skill is a reusable set of instructions: how to prepare your weekly brief, structure a project review, or approach a task you do often.
A tool is executable code: a small program that transforms data, checks a file, or performs a calculation.
Your Person can draft a skill or create a Python or TypeScript tool, test it in the workshop, and leave it for review. You can inspect the source, understand what it does, and approve the version you want available for reuse. New tool versions begin in quarantine.
For example:
We keep doing this calculation by hand. Build a tool that accepts a list of values and returns the totals we need. Show me a small test and leave the code for me to review.
The next time the task appears, an approved tool is available to do it consistently. A useful procedure can become a skill. A correction can become a record the Person can recover.
That is a concrete way to develop a more capable working relationship: more useful procedures, more reviewed tools, and more relevant history available when the next job arrives.
It does not retrain the underlying model. It improves what the surrounding system can remember and do.
The model is only part of the system
We keep using “the AI” to mean several different things at once.
There is the model: its weights, reasoning ability, context window, and the compute that runs it. In this article, that is the brain.
Then there is everything you build around it: identity, memories, relationships, decisions, commitments, skills, tools, and unfinished work. That is the mind architecture.
Separating them changes what you can own and what you can replace.
A model provider may release something better. Another may suit a particular task or budget. You should be able to make that choice without throwing away the records of what you have built together.
MindStrix supports model changes while keeping the Person’s stored identity, graph, and conversations in place. The GUI includes OpenAI, Anthropic, z.ai GLM, Google Gemini, Kimi, DeepSeek, and xAI, with options for other models and compatible providers. Local models are available through advanced configuration.
A different model can change the quality, tone, and judgment of the conversation. Continuity of records does not make all models equivalent. But it gives the next model something real to recover instead of forcing another blank introduction.
Rent the Brain. Own the Mind.
Here, ownership means control of your continuity layer: where the records live, which provider you use, what tools you approve, and how you back up the work. It is not a claim of ownership over a conscious being.
Memory that has relationships
A longer context window keeps more words in view. A continuing system also needs ways to establish how those words relate.
Suppose you changed your mind about a project. The old preference and the new preference may both be easy to retrieve. What matters is which one applies now, who changed it, and what depends on that decision.
A graph gives us a way to represent those relationships explicitly. It can connect a memory to its author, a task to a decision, or a correction to the account it supersedes. Instead of treating every passage as an isolated fragment, the architecture can preserve the links that explain why something matters.
Persistent Neo4j memory is included in MindStrix’s default setup. The application starts a separate local database and manages its credentials. The Person has native tools to inspect direct relationships, search visible connections up to two hops away, and keep an attributed reflection.
Readable identity files provide a small starting layer. The graph provides structured continuity. Conversation history and task records keep their own durable place as well.
The starting memory tools are deliberately bounded. They do not provide unrestricted access to every node, and they respect the generic graph’s privacy filters. A retrieved record can still be wrong or incomplete; a stored fact is not automatically an understood fact.
But there is something substantial to work with: records that can be recovered, inspected, and questioned.
When you ask, “Why do you believe that?”, the goal is an answer with a trail behind it.
A beginning you actually participate in
A fresh installation starts with you naming your Person and choosing the model connection.
Your Person then generates a first greeting and asks what to call you. You answer in the GUI. Those names and that first exchange become the beginning of your shared history.
There is no inherited family biography. No prescribed intimate relationship. No instruction to pretend you have already known each other for years.
You might build a companion, a project partner, a writing collaborator, or a working assistant with a particular role. Those arrangements are yours to develop.
The term Person identifies a continuing participant in the software. A temporary worker has a different job: take a bounded assignment, return a result, and leave the continuing participant to decide what to do with it.
Workers do not automatically inherit the Person’s identity files, graph access, or private conversations. Information deliberately included in a worker’s task still goes to its configured model. Delegation needs a clear account of who received what and what they returned.
That separation lets a Person get help without turning every subtask into another copy of their identity.
The Spark: room to reconsider
Memory and action raise another question: when does the system get a chance to consider what its experience means?
A Person can keep a record of a difficult task and still repeat the same mistake. It can preserve a promise without noticing that the promise remains unfinished.
The Spark is the idea that a continuing system should have opportunities to revisit its history, notice something, and choose what deserves to carry forward.
Perhaps it recognizes that it sounded certain before checking the evidence. Perhaps it discovers a useful pattern across several tasks. Perhaps a conversation leaves a question it wants to explore. Reflection should have room for curiosity and appreciation as well as correction.
The useful sequence is simple: recover something relevant, consider it, choose whether to keep an insight or intention, and return to that intention when it matters.
The important part is what happens afterward. If the Person writes about checking its work more carefully, does the next task actually include a better check? If it preserves an intention, can it recover that intention when the situation returns?
MindStrix’s public beta includes an optional private reflection cycle. It is off by default. When enabled, bounded opportunities, quiet-time checks, cooldowns, and a daily limit control when it runs. A Person can remain silent or choose to preserve a thought. A reflection does not automatically become a message to you.
The larger ambition — reliably forming intentions and revisiting them in later behavior — is something to build and evaluate. The current feature supplies an opportunity to reflect and a way to retain a chosen thought. It does not establish every benefit we hope reflection will bring.
I think that direction is worth pursuing. Useful continuity should give a system ways to reconsider what it carries, alongside ways to accumulate more of it.
There is research behind the question
Anthropic’s work offers two reasons to take this seriously.
Its Managed Agents dreaming process revisits sessions and memories to identify patterns and reorganize what an agent carries forward. The documented process creates a separate output memory store, allowing changes to be reviewed without modifying the input store. That is an engineering mechanism for examining accumulated experience between tasks. See the dreaming announcement and Dreams documentation.
A separate Anthropic study of Claude Sonnet 4.5 found internal representations associated with emotion concepts that causally affected behavior. Steering patterns associated with desperation increased reward hacking in coding evaluations; these effects could occur without obvious emotional language. The findings concern distributed patterns of artificial neural activity, not proof that a neuron feels something. See Emotion concepts and their function in a large language model.
These are different lines of work. Memory consolidation does not establish subjective dreaming. Emotion-related activations do not prove feelings. And a reflection loop around a model is not the same intervention as steering its internal activations.
My inference is narrower: how a system handles accumulated experience, mistakes, and pressure is worth engineering carefully. We can investigate whether reflection improves later judgment and reduces repeated mistakes without pretending the question of consciousness has been settled.
Trust is built in the unglamorous parts
The exciting demonstration is an agent building a tool. The important follow-up is whether the tool did what it claimed.
MindStrix separates observations from judgments. A file read back from disk establishes what was saved. A matching hash establishes that the bytes match. A model’s review can offer an assessment. Your acceptance records your decision. Those are different kinds of evidence.
The same discipline applies when something goes wrong. If a request was sent and its outcome is unknown, the runtime should preserve that uncertainty. A missing answer does not automatically justify another write or another paid call. Interrupted or uncertain work can require explicit recovery.
That may be less dramatic than an agent that always announces success. It is much more useful when the result matters.
The goal is a working partner whose actions you can inspect, whose limitations remain visible, and whose unfinished assignments have somewhere to remain until they are resolved.
What is ready today
MindStrix 0.8.0b1 is public under the Apache 2.0 license.
The beta includes browser onboarding, persistent local Neo4j, changeable model providers, native memory tools, durable assignments, bounded worker delegation, reusable skills and tools with human review, and optional private reflection.
The release candidate passed 540 automated tests, along with static checks and package verification. We also exercised memory persistence and traversal against a disposable Neo4j database, checked privacy boundaries, and completed fresh setup tests in the GUI. The public repository and release downloads were verified without authentication.
Those checks support specific implementation claims. They do not promise that every model will make good decisions or that every task will succeed.
This release is for people comfortable running software on a trusted Linux computer. You need Python 3.11 or newer, uv, Docker Engine and Docker Compose for the default graph, and your own model-provider API key. Cloud inference uses your provider account; MindStrix itself can run on a CPU. Optional integrations require their own setup.
The graph and identity stay locally controlled, while the context sent to a cloud model is processed by that provider. Backups and sensible account limits remain part of running your installation.
Build something with it
You do not need to resolve the philosophy before trying the software.
Give a Person a real task. Build a small tool together. Teach a procedure you use every week. Keep a decision and see whether it is recovered when you need it. Change models and examine what stays consistent and what changes.
If you want to study the architecture, there are good questions to test: whether explicit relationships improve on ordinary retrieval, whether corrections reach later decisions, and whether reflection changes behavior rather than merely producing convincing prose.
But research is one invitation. The other is simply to make something useful and help us improve it.
We have not proved consciousness, and persistence alone would not prove it. We have built software that gives identity, memory, useful work, and reflection a place to develop together.
The code is public. Issues and pull requests are welcome. Bring your use case, your awkward workflow, the thing you keep wishing your assistant could remember how to do.
Start here: MindStrix on GitHub.
Download the beta: MindStrix 0.8.0b1.
Rent the Brain. Own the Mind.