I Built a Personal AI Agent on a Raspberry Pi — Jeremy Adams, Neo4j

The personal agent starts the demonstration without power. Jeremy Adams, a developer advocate at Neo4j, assembles the device on stage: an HDMI capture connection, a USB microphone receiver and a battery. The computer hangs on his chest. Calling this the “livest of the live demos” is fair—the first task is getting the hardware to boot.

The display path takes some coaxing. QuickTime needs a restart, then its recording source must change to the USB capture device to show the computer’s HDMI output. After Adams switches on the power, a Raspberry Pi desktop appears. The board is a Raspberry Pi 4B, an older machine he had spent a long time running with a 32-bit operating system before realizing it supported 64-bit ARM. A Bluetooth keyboard supplies local control. Alongside NanoClaw, the Pi runs Docker and a containerized Neo4j database. That establishes the hardware’s role: it can host agent processes, peripherals and storage, even though it has limited compute capacity.

The choice of hardware begins with a sysadmin’s reluctance to put a personal agent on his laptop. Adams wants something cheap, open and hackable, and he values understanding its behavior more than collecting features. A Craigslist Mac Mini with OpenClaw preinstalled prompts an immediate reaction: “Pre-installed? That’s a red flag.” Instead, he retrieves a Pi from the closet—the same board he once used to experiment with weighing dishes in a sink to decide when they needed washing. “Will it claw?” becomes a practical reuse question.

NanoClaw fits that preference for understandable software. Adams describes the version he chose as roughly fifteen source files, with agent processes running in Docker containers. Three choices make the setup workable:

• A compact implementation: The small codebase makes it easier for him to inspect and change what the agent does.
• Containerized execution: Docker confines agent processes rather than giving them unrestricted execution on the host. That isolation is a reason for his choice, rather than a demonstrated guarantee against every failure.
• Code-based customization: NanoClaw uses the Claude Agent SDK and encourages users to modify it with Claude Code and skills. Adding personal behavior is part of the intended workflow.

WhatsApp supplies the interface because it is already on his phone. After registering NanoClaw with the required credential, the Pi can pull messages from WhatsApp’s cloud service; Adams can send them from either his iPhone or MacBook. Claude supplies the language-model inference in the cloud. No LLM inference runs on the Pi. The small computer therefore carries the runtime and its connections while a network request reaches the larger model.

Where does each part of a database-backed conversation happen? The architecture below separates the messaging path, cloud inference and database access. NanoClaw sits at their junction: it receives a message, uses the model and connected tools, and returns a response. This explains both the modest hardware requirement and the network dependency of the initial conversational agent.

The first graph example needs only three entities. Tom Hanks and Robert Zemeckis are person nodes; Forrest Gump is a movie node. One relationship records that Hanks acted in the movie, while another records that Zemeckis directed it. Nodes identify things, and relationships preserve how those things connect. A question about an actor’s movies can use those stored connections.

Adams sends a WhatsApp request asking which movies Tom Hanks acted in. An MCP server provides access to the Neo4j movie database, but the first attempt fails because the connection is not configured correctly. He returns to the Pi and fixes authentication. The correction matters: having a model and a tool connection does not make the underlying database credentials work.

After that repair, movie results come back through WhatsApp. The useful thing to inspect in this result is the completed path from stored records to a readable answer: Neo4j supplies the data, the Claude Agent SDK supports forming the response, and the messaging channel delivers it. This is the first working example of the wearable agent reaching information beyond its conversation.

The next extension starts on an airplane. WhatsApp messaging works on the flight without Adams paying for full Wi-Fi access, which lets him continue talking to the agent. He asks it to build memory around POLE+O: person, object, location, event and organization. These categories give the system places to put entities mentioned in personal experiences, rather than leaving every experience as an isolated block of text.

The agent responds by creating a skill for the memory workflow and identifies a mounted location where its files can persist across reboots. The resulting memory data goes into a new Neo4j database in the cloud. Two forms of persistence have different jobs here: the mounted files retain the agent’s added procedure, while the graph retains the memories and the things they refer to. Adams begins recording places he visits and developer-relations events he attends.

How does one of those experiences become inspectable? In Neo4j Aura, Adams queries memory nodes together with their connections, then zooms into examples involving people, a visit to Snowflake’s office in Menlo Park and an AI meetup. Menlo Park is itself represented as a location; people and events also have representations in the framework. The connected view makes it possible to inspect the participants and places around a memory, rather than reading only the memory text. Adams calls the database a bit of a “dumping ground”—a working personal collection with useful structure, rather than a carefully curated dataset.

A bird-recording project suggests the next hardware capability. Someone had used a microphone and BirdNET to identify backyard birds; Adams wonders whether his Pi could instead turn his own voice into text. A USB microphone gives the agent an input that works while he is walking around, without typing into WhatsApp.

A physical button, connected to the board’s pins, triggers the recording and voice-to-text workflow. During the demonstration, the button has fallen off, so Adams reconnects it and records a sentence about being on stage at AI Engineer World’s Fair. The recording LEDs light up. That confirms the visible recording activity; the demonstration does not establish whether this particular utterance completes transcription and message delivery.

The microphone acquires a concrete job: capture the messaging displayed at conference booths. Adams can walk from exhibitor to exhibitor and dictate what he sees. The hardware now supports collecting new information in the environment, which gives the memory system something more useful to ingest than another conversation about building the memory system.

The booth task begins with a deliberately simple model: exhibitor records identified by booth numbers and names. Initially, they have no connections to one another. Adams collects as many as he can and cleans the data. Relationships can wait; the immediate requirement is to attach observations to the right exhibitor.

Unreliable conference Wi-Fi motivates a local capture path. Neo4j runs on the Pi, so storing a note need not require the cloud database. Adams describes using regular expressions to parse a booth number from voice-to-text output, then writing a query to insert the information locally. This gives the offline path a narrower task than the cloud agent: recognize a known identifier and preserve the observation. The talk outlines that parsing approach and demonstrates stored notes, without walking through every capture-to-insert step live.

What survived on the device? Adams opens his Cypher Shell Browser, a small program he wrote to query Neo4j without a heavyweight graphical interface. It retrieves exhibitor records and raw notes from the database around his neck. Those notes still resemble spoken observations—being at a particular booth and describing it. The local view matters because it shows the material before later cloud enrichment: the device has retained the observations that subsequent analysis will use.

Adams later uploads the collected data to Neo4j in the cloud and enriches it. The notes are cleaned up, and the exhibitor nodes gain relationships to theme nodes. This changes what the collection can answer. The local records preserve what he observed at individual booths; the enriched graph also lets him inspect which exhibitors share a topic.

Which relationships reveal the change? Adams returns paths through exhibitors and their themes, pointing to evaluation and observability and naming Buildkite and LangChain as exhibitors associated with that theme. A shared node makes the connection explicit: separate booth observations now meet at a common category. This is the useful result of the walk around the expo floor. It reveals themes in the material he collected, although the talk does not specify the enrichment procedure or establish that his booth coverage represents the whole conference.

The final upgrade returns to the personal agent’s accumulated conversations. Adams wants to load his WhatsApp history and find useful information across the exchanges he has had with the device. He connects Neo4j Agent Memory, which extracts and distills memories from those conversations. This extends the earlier custom memory work by making the existing chat history an input to the memory system.

What can he browse after that import? The memory interface exposes conversations and the people, locations and concepts discussed in them. Those distilled memories are also accessible from the Pi through an MCP server. The ending therefore completes a practical connection: information accumulated through WhatsApp becomes structured memory that the same agent can reach through its tools. Tool access supplies a route to recall; it does not by itself show that every later answer retrieves the right memory.

For builders following this path, the next steps depend on the missing piece:

• Understand the agent runtime: Inspect the NanoClaw repository behind the messaging and container setup.
• Add graph memory: Use the Neo4j Agent Memory documentation and source repository for the system used in the final upgrade.
• Learn graph queries and modeling: Adams closes with GraphAcademy, Neo4j’s free, hands-on courses—the foundation for understanding and changing what these memory graphs store.