# Geistr Core: Building a Desktop-First Foundation for Local AI Apps > Why I open-sourced Geistr Core: the reusable desktop-first foundation behind my local AI workspace, with chat, memory, tools, MCP, permissions, skills, and background loops built in. *Mohammed Reschreiter · 2026-07-10* Tags: AI Agents, Open Source, Geistr --- I recently released **[Geistr Core](https://github.com/Asm3r96/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](http://pi.dev)** as part of its AI provider layer, and the public repository is here: **[github.com/Asm3r96/geistr-core](https://github.com/Asm3r96/geistr-core)**. ![Geistr Core chat demo](/assets/images/geistr-core/chat-with-agent.gif) --- ## 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. ![Geistr Core memory galaxy demo](/assets/images/geistr-core/memory-galaxy.gif) That belief also connects to my earlier thinking around **[Markdown Agent OS](/blog/markdown-agent-os-maos)**: 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: 1. Build the smallest useful version. 2. Use it in real work. 3. Find where it feels unsafe, slow, or confusing. 4. Tighten the system. 5. 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](https://github.com/Asm3r96/geistr-core)** And if you are curious about Pi, which Geistr Core uses in its provider layer: **[pi.dev](http://pi.dev)**