Building a Personal Agent

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3672359) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Juha Pellotsalo Posted on Apr 28 Building a Personal Agent #ai #agents #claude #personalagent Shortly after OpenClaw came out I started building my own personal agent. I picked Claude Code as the harness, partly out of habit and partly because I wanted to see what it could do outside of coding. The agent lives in a single directory on my file system. Launching Claude in that folder launches the agent. Nothing about it is Claude-specific, though. It runs on skills, MCPs, and custom CLI commands, and stores everything in markdown or YAML. Any harness can work with these concepts. Bootstrapping Each session starts by loading AGENT.md (or CLAUDE.md in this case). It's deliberately compact, just enough to point the agent in the right direction: Agent identity and a link to SOUL.md, which holds the full description. Operating principles, like "auto-improve custom CLI commands when they fail." A short note on how skills are organized and how memory works. Rules for formatting bash commands so they pass permission lists cleanly. Everything else loads on demand. Skills, CLIs, and the file system Three pieces do most of the work, so it's worth introducing them up front. Skills are the agent's playbook. Almost every action it takes is driven by one. A skill contains instructions for calling CLIs, with examples and guardrails, and procedures for things like compiling memory prints, priming sessions, and writing or reviewing code. I use relatively few skills with larger instruction sets, rather than a long catalog of small ones. Sessions typically begin with a skill call appropriate to the task. If I'm working on a project, /project primes the session by reading the project wiki. CLIs are the arms and hands. They're custom-built commands the agent executes via bash, mostly thin wrappers around APIs: calendar-cli, gmail-cli, drive-cli. reddit-cli reads posts as JSON. youtube-cli pulls video transcripts. Going through CLIs instead of MCP gives me clearer control. The Google CLIs, for example, support multiple accounts, and the right credentials get picked up in code rather than from an agent-generated bash script. CLI calls are also cheaper than MCP calls, and I can bake error correction into the code itself. LLMs love to hallucinate imaginary args, and validating those inside the CLI is trivial. The validation error returns the correct usage, so the agent fixes the call on the next try instead of looping through trial and error. The file system is the database. Markdown and YAML for everything. Folder structure is the schema. Markdown as a data store Journals and logs are the unstructured side of this. The structured side looks more like a row in a database: front matter defines the shape, the body holds the content. --- id: project-axiom status: active priority: high related: [agent-system, langgraph-experiments] --- # The Axiom Notes and references for the agentic newsroom project... Enter fullscreen mode Exit fullscreen mode These files reference each other like foreign keys, with links as plain paths. This works because LLMs are, for some reason, very good at reasoning over directory trees, and markdown is plain text the model reads…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.