A Raspberry Pi AI agent can run a personal assistant with graph memory when the language model stays in the cloud and the Pi handles capture, storage, and retrieval. Jeremy Adams, a senior developer advocate at Neo4j, demonstrated exactly that at the AI Engineer World's Fair in San Francisco, wearing the computer around his neck.
Raspberry Pi AI Agent: What Adams Actually Built
A Raspberry Pi AI agent is a personal assistant whose agent process runs on a small single-board computer instead of a laptop or a rented server, with inference still handled remotely. Jeremy Adams, a senior developer advocate at Neo4j, demonstrated his build at the AI Engineer World's Fair in San Francisco in October 2026 according to the published talk recording.
The hardware is a Raspberry Pi 4B, the 2019 model, not the newer Raspberry Pi 5. Adams said he ran a 32-bit operating system on it for a long time before realizing the board was 64-bit ARM capable, which widened what he could install. It runs Raspberry Pi OS Desktop, Docker, a containerized Neo4j database, and the agent software, all powered by a battery pack and driven by a Bluetooth keyboard.
The chat channel is WhatsApp. The reasoning happens in the cloud through the Claude Agent SDK, so no language model inference runs on the Pi itself. Adams described the arrangement plainly: the Pi is the body, and the model is a big brain reached over a wire.
Why a Small, Hackable Agent Beat a Mac Mini
Adams chose a Raspberry Pi over a Mac Mini because he wanted something cheap, open, and small enough to understand completely, not something feature-rich. He described himself as coming from a sysadmin and DevOps background, and said he prefers to wait until a category of software is solid before depending on it.
The decision came with a specific anecdote. While living in Portland, Oregon, he saw a Mac Mini listed on Craigslist with an agent framework already installed. The pre-installed configuration struck him as a warning sign, and he noted that Mac Mini pricing has since risen well above the roughly $600 entry point he remembered.
The Raspberry Pi 4B had been sitting in a closet since an earlier pandemic-era project where he hacked it to weigh dishes in a sink. He pulled it out to test whether it could run an agent at all, and found it could. The framework he settled on, NanoClaw, appealed to him because it was compact, around fifteen source files, and ran its agent processes inside Docker containers so they could not run amok on the host system.
The tradeoff is real. Adams did not claim the Pi outperforms larger machines; he said you cannot run everything on it, but you can run quite a bit.
How Graph Memory Works With the POLE Schema
Graph memory in this build is a property graph in Neo4j where memories become nodes and their relationships become edges, following a POLE-style schema. POLE stands for Person, Object, Location, and Event, with Organization as a common addition. Adams attributed the pattern to European policing work, where investigators have drawn link diagrams for decades.
A property graph differs from a relational table in a way that matters for agents. Adams used a movie example: a Person node for Tom Hanks connects through an acted-in relationship to a Movie node for Forrest Gump, and a directed relationship connects Robert Zemeckis to the same movie. Adding a new kind of connection does not require changing a table definition.
The practical benefit for an agent is traversal. When Adams asked his agent through WhatsApp which movies Tom Hanks acted in, the agent reached a Neo4j instance through a Model Context Protocol server, queried the graph, and returned results through the WhatsApp channel. His first attempt failed because of a configuration problem, which he fixed before getting results.
Memories in his own database include locations such as the Snowflake office in Menlo Park, an AI meetup event, and person nodes for people he spoke with. He described the store as somewhat of a dumping ground, which is an honest description of early personal memory graphs.
Offline Capture on the Device, Enrichment in the Cloud
Offline capture works because the Pi keeps its own Neo4j instance on the device, writing raw notes locally and syncing them to a cloud database later. Adams built this for conference floors, where Wi-Fi is often unreliable, after deciding to walk the AI Engineer World's Fair booths and record what each vendor was promoting.
The capture path uses a USB microphone, local speech-to-text, and a physical button wired to the Pi's pins. The button triggers a recording, indicator lights show that recording is active, and the resulting text is parsed for a booth number, which the agent can then write into the local graph. Adams rebuilt the button on stage after it came loose during the demonstration.
The local schema for this task is deliberately simple. An Exhibitor node holds the booth data with no relationships at first, which he described as flat on purpose. He cleaned the exhibitor list by hand and loaded it into the on-device graph, then queried it through a small Cipher shell browser program he wrote to talk to Neo4j without an expensive graphical client. The query for all exhibitors returned names including Microsoft and Minimax.
Later, he uploaded the same raw notes to Neo4j Aura, the managed cloud service, and enriched them. The enriched version connects exhibitors to theme nodes. Evaluation and observability is one theme he found attached to more than one vendor, which turned booth notes into a small map of what the conference was actually about.
Cloud Inference Changes the Privacy and Cost Math
Inference in this build is not local. Adams stated directly that no language model inference happens on the Raspberry Pi, and that all of it runs in the cloud through Claude, Anthropic AI assistant family, reached through the Claude Agent SDK. Anyone evaluating a similar build should treat the Pi as a capture and storage device with a remote reasoning backend.
That split has consequences worth naming. The device stores memories locally, which supports offline note capture and keeps a usable copy on hardware you own, but memory content still travels to maintainer-hosted services when the agent reasons about it. Local storage is not the same claim as fully local processing.
Cost also splits the same way. The Pi and its battery pack are a one-time purchase, while ongoing expense belongs to the inference provider and to whichever cloud database tier holds the synced graph. Adams used Neo4j Aura for the Claude Code, so a reader rebuilding this would be paying for two services, not one.
Agent Memory at a Larger Scale: Distilled Conversations
Storing raw conversation history and querying it directly stops scaling once the history grows, so Adams later moved part of the work to a distillation service. He upgraded his setup using Neo4j Agent Memory, a service that ingests conversation history and produces structured memories rather than storing every message verbatim.
He fed it the accumulated WhatsApp history from his agent and let it distill the contents into memory objects. The result is browsable by category, including people he had spoken with, locations, and concepts, and it is reachable from the Pi through an MCP server. That last point is what keeps the small device useful: heavier processing happens elsewhere, then comes back as queryable structure.
The distinction between the two approaches is worth keeping straight. The POLE memory graph is a schema Adams and his agent build incrementally during use. The Agent Memory service is a separate distillation pipeline applied afterward to a large message archive. Both end up readable by the same agent, through the same protocol.
Build Choices Compared
The table below compares the main components Adams described, using only what the talk and public project documentation support.
| Component | Role in the build | What Adams reported |
|---|---|---|
| Raspberry Pi 4B | Host device running the agent | Works, 64-bit ARM capable, not every workload fits |
| NanoClaw | Agent framework | About 15 source files, agent processes in Docker |
| Neo4j on device | Local memory and offline capture | Docker container, queried with a custom Cipher shell |
| Neo4j Aura | Cloud memory and enrichment | Holds synced and enriched graph data |
| Claude Agent SDK | Inference and agent loop | All language model inference runs remotely |
A reader deciding whether to copy the build should weigh two things the talk makes clear. The device-side stack is modest and reproducible. The memory quality depends on how well the agent extracts structure from captured audio, which is the part Adams iterated on repeatedly.
Frequently Asked Questions
- Can a Raspberry Pi 4B run a personal AI agent? Yes, if the language model runs elsewhere. Adams ran NanoClaw inside Docker on a Raspberry Pi 4B with a local Neo4j container, and the device handled capture, storage, and retrieval while Claude handled inference in the cloud.
- What is the POLE schema in agent memory? POLE stands for Person, Object, Location, and Event, a node categorization pattern borrowed from investigative link analysis. Adams attributed the pattern to European policing practice and used it to give memories consistent types that an agent can traverse.
- Does this agent work offline? Capture works offline, and the on-device Neo4j instance keeps storing notes without a network. Reasoning about those notes does not, because all inference happens in the cloud, so the agent cannot answer new questions until connectivity returns.
- What is the difference between NanoClaw and OpenClaw? They are separate agent frameworks. Adams chose NanoClaw for this build because it was small, around fifteen source files, and isolated agent processes in Docker containers. He evaluated but did not use OpenClaw for this project.
- How does the agent connect to a Neo4j database? Through a Model Context Protocol server. The agent sends a request over MCP, the server queries Neo4j, and the results return to the agent, which then replies through the WhatsApp channel.
- What does the Neo4j Agent Memory service add? It distills a large conversation archive into structured memory objects instead of storing every message. Adams used it on accumulated WhatsApp history to get browsable people, locations, and concept memories.
- Is storing memories locally the same as keeping data private? No. The graph sits on hardware you own, which supports offline use, but text still reaches cloud services during inference and sync. Privacy depends on those external services, not on the Pi alone.
- Why use a graph database for agent memory instead of a vector store? Relationships carry information that similarity search does not. Adams's booth example connects each exhibitor to themes, which is a traversal question about explicit edges rather than a nearest-neighbour lookup.
- What hardware does the agent need beyond the Pi? A microphone, a battery or power supply, a storage card, and a keyboard or another way to drive the desktop. Adams used a USB microphone, a wireless receiver, and a small Bluetooth keyboard.
Why the Constraint Is the Interesting Part
The value of Adams's build is not that it produces better answers than a laptop agent. It is that the size limit forces decisions about what actually belongs on the device. Capture, storage, and structured memory stay local. Reasoning and heavy distillation go to services with more capacity.
That division is the part worth copying, and it applies well beyond a Raspberry Pi. Anyone building an assistant that collects observations in the field faces the same question of where each function should live. The graph memory layer is the answer to the storage half. The MCP server is the answer to the retrieval half. Both were necessary for the small device to stay useful over months of accumulated conversation.
Thinking through a build like this means weighing choices that map to your own setup. GraphAcademy provides free hands-on Neo4j courses if you want to practice before committing to a hardware build.
Turn a Spoken Build Walkthrough Into a Written Guide
Adams's talk works because he narrates the reasoning behind each decision, the failed first attempt, the choice of framework, the offline mode he added after worrying about conference Wi-Fi. That reasoning is exactly what a reader rebuilding the project needs, and it lives in a video where search engines cannot reach it.
If you have recorded walkthroughs, interviews, or lessons like that, the knowledge already exists in usable form. Skala Blog takes a YouTube URL, transcribes the video, and generates an article draft from the transcript, so the explanation you already gave an audience can also exist as a page someone finds while searching for the same problem.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits