Search for a command to run...
The Missing Piece in Local AI Isn't Intelligence. It's Developer Experience.
I decode data, craft AI solutions, and write about everything from algorithms to analytics. Here to share what I learn and learn from what I share. 🚀 Data Scientist | AI Enthusiast | Building intelligent systems & simplifying complexity through code and curiosity. Sharing insights, projects, and deep dives in ML, data, and innovation.
No comments yet. Be the first to comment.
AI is everywhere right now. New models, new benchmarks, new capabilities every week.
Duplicate My Hugging Face Space and Build Your Virtual Self
Explaining Python’s concurrency models with clarity, context, and real understanding
Let AI handle the boilerplate while you focus on the fun part of analysis.
TechTrail
10 posts
Most conversations around local AI still revolve around the models themselves.
Which model should I run?
How much VRAM do I need?
Should I use a larger reasoning model or a smaller, faster one?
Those are valid questions, but they don't occupy much of my time anymore. We already have access to remarkably capable models, whether they're running in the cloud or on our own machines. The part I find far more interesting is everything around them.
I kept wondering what using a local AI assistant would actually look like as part of my everyday workflow. Something that naturally builds up context over time instead of starting every conversation from scratch. A place where notes, documents, and conversations all become part of the same workspace.
That line of thinking eventually led to Scratchpad.
Scratchpad came out of an attempt to make running a personal AI workspace feel simple and practical. The goal wasn't to push model capabilities further, but to make the experience around them something I'd actually enjoy using every day.
Cloud AI products have made the experience incredibly smooth. You open a browser, start typing, and everything is just there. Your conversations are saved automatically, there's almost no setup, and the entire experience feels effortless.
The open source ecosystem offers something different. You get complete control over the models, frameworks, retrieval systems, and tools that make up your workflow. The trade-off is that getting everything working together often becomes a project of its own.
Scratchpad grew out of wanting a bit of both. I wanted the convenience of a polished application without giving up the flexibility and ownership that come with running everything locally.
That idea ended up influencing almost every design decision, from how the application starts up to how conversations, knowledge, and models are managed.
One idea kept coming back while I was building Scratchpad.
Instead of treating AI as something you open whenever you need an answer, I wanted it to feel more like another contributor to the project.
When someone joins a team, you don't point them at your entire computer. You give them the project folder. Over time, that folder fills up with documentation, notes, research, design decisions, and everything else that gives the project context.
That's the same idea behind Scratchpad.
Every Scratchpad instance is tied to a workspace that you choose. The AI works within that workspace, and the conversations and knowledge naturally stay connected to it instead of existing as isolated chat sessions.
This workspace becomes the AI's desk.
It stores the notes it creates, the documents you ingest, the vector indexes built for retrieval, generated files, and conversation history. Everything the AI learns or produces belongs there.
The workspace is simply a clear place where both the user and the assistant collaborate.
Because everything lives together, the workspace becomes portable. It can be backed up, version controlled, moved between machines, or deleted without wondering where different pieces of state are hiding.
As the workspace model took shape, it became clear that the frontend didn't need to know much about AI at all.
Scratchpad uses a Go CLI, not because Go is the best language for AI, but because it makes for a fast, simple, and portable frontend. The CLI isn't responsible for reasoning or orchestration. It mostly acts as a thin client that talks to the backend.
Its job is limited to a few things:
Interacting with the user
Starting and stopping the backend service
Streaming responses
Storing session metadata
Forwarding requests over HTTP
Everything else, including reasoning, memory, retrieval, and tool execution, lives in the backend. That separation keeps the CLI lightweight while making it much easier to evolve the AI system without changing the user interface.
User
│
▼
Go CLI
│
HTTP
│
▼
Python Backend
│
▼
LangGraph Agent
│
▼
Workspace & Tools
This separation keeps the client lightweight while allowing the backend to evolve independently. A different frontend could talk to exactly the same backend without changing the AI system itself.
One part of local AI that doesn't get much attention is installation.
Setting up Python environments, installing dependencies, cloning repositories, configuring paths, and starting services are all normal engineering tasks. The problem is that they're usually the first thing users have to deal with, even though none of them are related to what they actually want to do.
I wanted Scratchpad to handle that initial setup without hiding how everything works.
On the first run, the CLI automatically:
Downloads the backend
Creates a Python virtual environment
Installs the required dependencies
Starts the backend service
Keeps everything inside the selected workspace
The only things you need to provide are a Python installation and a .env file with the required API keys.
Nothing is installed globally, and there are no background services running outside the workspace. The virtual environment, backend, and project files all live in the directory you selected, so it's always clear what's happening and where everything is. If you want to inspect, modify, or remove any part of it, you can.
The backend is where the AI actually lives.
It is responsible for:
LangGraph orchestration
Tool execution
Retrieval-Augmented Generation
Persistent conversations
Web search
Website scraping
Streaming intermediate reasoning
The CLI remains completely unaware of these details.
Communication happens over plain HTTP with newline-delimited JSON streams.
User Prompt
│
▼
Planning
│
▼
Tool Calls
│
▼
Streaming Updates
│
▼
Final Response
Choosing HTTP instead of something like gRPC wasn't about performance. It was about keeping the system easy to inspect, debug, and integrate with. Any client capable of making HTTP requests and consuming streamed responses can communicate with the backend.
One thing I realized while building Scratchpad is that different kinds of information need to be handled differently.
Documents are good at answering factual questions. Conversations provide context. Personal notes capture things that evolve over time.
Trying to store all of them in the same way didn't feel right, so Scratchpad keeps them separate.
Documents are ingested into a RAG pipeline for semantic retrieval whenever the agent needs external context.
Alongside that, the agent maintains its own collection of Markdown notes inside the workspace. It can create new notes, update existing ones, and gradually organize information as the workspace grows.
Over time, the workspace ends up containing two kinds of knowledge: information retrieved from your documents and information the agent has accumulated and organized through its own notes. Keeping those separate makes it much easier to manage both, while also making the workspace feel like something that grows with the project instead of a collection of disconnected chats.
Every design decision in Scratchpad comes with a trade-off.
The backend is written in Python because that's where the AI ecosystem already is. The downside is carrying a Python runtime and its dependencies.
The CLI is written in Go because it produces a small, portable executable. That choice also keeps the frontend simple and leaves the AI-specific logic to the backend.
Keeping everything inside a workspace makes the project easier to move, inspect, and manage. It also means the application only works within that workspace instead of having unrestricted access to the entire filesystem.
Even the decision to use HTTP instead of gRPC came down to keeping the system simple rather than taking advantage of additional protocol features.
None of these choices are universally right or wrong. They made sense for the kind of application I wanted to build, and together they led to a system that stayed consistent as it grew.
Scratchpad is still a relatively small project, and there are plenty of directions I'd like to explore.
Support for additional model providers, Model Context Protocol (MCP), plugins, better configuration, and richer frontend integrations are all on the roadmap. The current architecture was designed so that these kinds of features can be added without having to rethink the entire system.
For now, though, I'm more interested in refining the experience than adding features for the sake of it. If running a personal AI workspace becomes easier, more reliable, and a little less intimidating with each iteration, I'd consider that worthwhile.
The models are already remarkably capable. What I'm increasingly interested in is everything around them: how knowledge is organized, how context is preserved, how much responsibility belongs in the client, and how much setup users should have to deal with before they can get started.
Scratchpad is my attempt at exploring those ideas.
Under the hood, it uses familiar technologies like LangGraph, FastAPI, RAG, and modern reasoning models. Those choices matter, but they're only part of the story. What mattered more while building the project was finding an architecture that stayed simple, kept the workspace self-contained, and made running a personal AI assistant feel practical rather than experimental.
There's still plenty to improve, but I'm happy with where Scratchpad has ended up. If it encourages someone to try running their own local AI workspace, or even sparks a few ideas for their own projects, then I'd call it a success.