Geistr Core: Building a Desktop-First Foundation for Local AI Apps
I recently released Geistr Core — an open-source, desktop-first foundation for building local AI applications.
It is not a polished product announcement in the usual sense. It is more personal than that. Geistr Core is the result of months of building, breaking, testing, rebuilding, and slowly extracting the systems I kept needing again and again: chat sessions, memory, tools, permissions, MCP servers, skills, background loops, provider handling, attachments, and the strange little details that make an AI app feel alive instead of bolted together.
The project uses Pi as part of its AI provider layer, and the public repository is here: github.com/Asm3r96/geistr-core.
Why I built it
Most AI products start with the exciting part: the model, the interface, the magic demo.
But very quickly, the real work appears. You need persistent sessions. You need a memory system that does not feel like a black box. You need tool permissions. You need a way to connect MCP servers without turning the whole app into a security nightmare. You need user profiles, attachments, model selection, background tasks, approvals, logs, and a UI that still feels calm while all of this is happening.
I kept running into the same foundation problem: before I could build the actual experience, I had to rebuild the same agent-app infrastructure.
Geistr Core is my answer to that problem.
It is the boring foundation I wish already existed — and I mean "boring" as a compliment. The best infrastructure should not constantly ask for attention. It should make the next idea easier to build.
The idea behind Geistr
Geistr started as a local-first desktop AI workspace. I wanted an environment where an assistant could do real work with me while still keeping the human in control.
That means the app cannot simply be a chat box connected to an API. It needs a real runtime around the model:
- Sessions that persist and can be resumed.
- Memory that stores useful context over time.
- Profiles and identity so the assistant has continuity.
- Tools that can read files, edit files, search, fetch, and interact with the workspace.
- Permissions so actions remain explicit and inspectable.
- MCP support so external capabilities can be connected.
- Skills so repeatable workflows can be described as readable instructions.
- Background loops so approved long-running processes can exist without becoming hidden magic.
A model alone is not an app. The harness around it matters.
That belief also connects to my earlier thinking around Markdown Agent OS: agents become more useful when their workflows, constraints, and state are visible as files and text rather than buried inside opaque orchestration code.
How I worked on it
The development process was very practical. I did not sit down and design the perfect framework upfront. I built Geistr by using it.
Every feature came from friction.
When sessions became hard to manage, I improved sessions. When memory felt too vague, I worked on memory tools and indexing. When tool access felt too powerful, I built permission layers and tested read-only boundaries. When workflows repeated themselves, I turned them into skills. When one-off tasks needed to keep running, I added background loops.
The pattern was always the same:
- Build the smallest useful version.
- Use it in real work.
- Find where it feels unsafe, slow, or confusing.
- Tighten the system.
- Document the rule so the next run is more stable.
A lot of the work was not glamorous. It was type-checking, file-size guards, approval flows, local SQLite details, provider abstractions, and making sure the assistant does not just claim something happened when the underlying tool did not actually return success.
But that is exactly the layer that makes an AI app trustworthy.
Local-first as a product philosophy
For me, local-first is not only a technical architecture. It is a relationship with the user.
If an assistant is going to remember things, touch files, run tools, and become part of someone's daily workflow, the user should be able to inspect what is happening. Data should live close to the person. Workflows should be readable. Permissions should be visible. The system should respect the boundary between assistance and control.
This is why Geistr is desktop-first. The desktop is still the place where serious personal work happens: files, projects, notes, code, documents, and context all live there.
A local AI workspace should not feel like renting a brain through a browser tab. It should feel like owning your own workshop.
Why open source it now
I decided to release Geistr Core because I think many builders are hitting the same wall.
The AI ecosystem is full of model wrappers and demo apps, but the reusable foundation for serious local agent applications is still young. Every builder should not have to rebuild chat infrastructure, tool routing, permission checks, MCP wiring, memory handling, and provider selection from scratch.
Geistr Core is not the final answer. It is a working foundation.
It is also a public record of how I think AI apps should be built: human-in-the-loop, local-first, permission-aware, inspectable, and designed around real daily use rather than only impressive demos.
What comes next
The next steps are straightforward: keep improving the desktop app, harden the core systems, clean up the developer experience, and continue turning repeated patterns into reusable pieces.
I am especially interested in better memory injection, clearer user profile controls, voice input, token usage visibility, update flows, and more polished session management.
But the larger direction is already clear.
Geistr Core is the foundation for the kind of AI workspace I want to use myself: calm, local, capable, honest, and built with enough structure that the assistant can do real work without escaping the user's control.
You can find the repository here:
github.com/Asm3r96/geistr-core
And if you are curious about Pi, which Geistr Core uses in its provider layer: