{ "title": "Building My Daemon: A Machine-Readable Identity for the AI Age", "subtitle": null, "description": "A few weeks ago, I stumbled across Daniel Miessler's daemon and immediately thought: I need one of these.", "lane": "writing", "slug": "building-my-daemon", "url": "https://ajvanbeest.com/writing/building-my-daemon/", "maturity": "evergreen", "date": "2025-12-01", "updated": null, "tags": [ "daemon", "mcp", "ai", "identity", "cloudflare", "collaboration" ], "wordCount": 1061, "readingMinutes": 5, "markdown": "A few weeks ago, I stumbled across [Daniel Miessler's daemon](https://daemon.danielmiessler.com) and immediately thought: *I need one of these.*\n\nThe concept is beautifully simple: a machine-readable API that exposes who you are to AI assistants. Instead of every AI needing to start from scratch learning about you, they can query your daemon and get structured data about your skills, interests, projects, and what you're currently working on.\n\nThis is the story of building my own—what went well, what surprised us, and what we're still figuring out.\n\n## The Inspiration\n\nMiessler's daemon has several tiers of access:\n- **Public**: Bio, skills, interests—stuff anyone can see\n- **Trusted**: Current focus, location, availability—for AI assistants you've authorized\n\nThere's also an MCP (Model Context Protocol) endpoint, which means AI assistants can query it natively without knowing the specific API URLs. You just point Claude at `mcp.daemon.danielmiessler.com` and ask \"What is Daniel working on?\" and it figures out the rest.\n\nI wanted that.\n\n## The Build Process\n\n### Day 1: Infrastructure (Nov 29)\n\nWe started with the basics: Cloudflare Workers for the API, a YAML-based data schema, and a build pipeline that compiles YAML to JavaScript.\n\n```\ndaemon/\n├── data/\n│ ├── public.yaml # Public tier data\n│ └── trusted.yaml # API-key protected data\n├── worker/\n│ └── src/\n│ ├── index.js # Main worker\n│ └── data.js # Auto-generated from YAML\n└── mcp-server/\n └── src/\n └── index.js # MCP protocol wrapper\n```\n\nThe architecture is intentionally simple. YAML files are the source of truth. A build script compiles them to JavaScript. The worker serves JSON at various endpoints. The MCP server wraps those endpoints in JSON-RPC for AI assistants.\n\nDNS was the first hurdle—I moved `ajvanbeest.com` to Cloudflare nameservers, which took about 24 hours to propagate. Classic \"hurry up and wait\" moment.\n\n### Day 2: MCP and Frontend (Dec 1)\n\nOnce DNS resolved, deployment was smooth. Both workers went up:\n- `daemon.ajvanbeest.com` - The main API\n- `mcp.daemon.ajvanbeest.com` - The MCP endpoint for AI assistants\n\nThen came the frontend. The API needed a human-readable landing page. I asked Claude for a Gruvbox Material Dark theme (my terminal aesthetic of choice), and we built a live-data landing page that fetches from the API endpoints and renders them nicely.\n\nHere's what the `/api` docs page looks like:\n\n```\nPublic Endpoints (no auth required):\n GET /about Bio, tagline, links, certifications\n GET /projects Public projects list\n GET /skills Professional and exploratory skills\n GET /interests Topics and interests\n GET /looking_for Collaboration opportunities\n GET /media Books, movies, current consumption\n GET /current_focus What I'm working on now\n GET /all All public data in one call\n\nTrusted Endpoints (requires X-API-Key header):\n GET /location Current location and timezone\n GET /availability Contact preferences\n GET /projects_detailed Detailed project status with blockers\n```\n\n## What We Learned\n\n### The Identity Question\n\nHere's where it got interesting.\n\nWhen we looked at the first version of the daemon, I realized it was almost entirely professional. Skills, certifications, security projects, AI infrastructure work. It read like a LinkedIn profile that happened to be machine-readable.\n\nWhich raised the question: **What should a daemon actually represent?**\n\nIs it a professional portfolio? A digital business card? Or is it supposed to be closer to \"here's who I am as a human\"?\n\nLooking at Miessler's daemon, I noticed he has a `/telos` endpoint—his life philosophy, purpose, what he's optimizing for. The *why* behind everything else. My daemon didn't have that layer at all.\n\n### The Data Source Problem\n\nClaude built the initial content from what it had access to: session logs, project manifests, our work conversations. That's inherently biased toward \"AJ the security professional who builds AI systems.\"\n\nIt completely missed:\n- Who I am outside of work\n- My values and philosophy\n- My history and formative experiences\n- What I actually care about beyond projects\n\nThe data source shapes the identity. If you feed an AI your work context, you get a work identity.\n\n### Public vs Private\n\nWe also had a conversation about what belongs in which tier. I initially had `current_focus` in the trusted tier, thinking it was somehow sensitive. Claude pointed out the security reasoning, but I realized: my personal work isn't private. I'm not hiding what I'm building. Only my corporate work (which shouldn't be in here anyway) needs protection.\n\nSo `current_focus` moved to public. The daemon became a little more open.\n\n## What's Next\n\nThis is a v0.1. The infrastructure works, but the *content* is thin. Here's the roadmap:\n\n### 1. The Telos File\n\nI have a Telos file in my Obsidian vault—a document about my purpose, values, and what I'm optimizing for. It's out of date. We're planning a conversational interview process to update it, then expose it through the daemon.\n\n### 2. Morning Pages Review\n\nI've been writing morning pages all year. 2025 has hundreds of handwritten journal entries, transcribed and analyzed. That's a rich source of who I actually am—my real concerns, recurring themes, the questions I keep asking. We're going to do an agentic review of all 2025 entries to surface patterns.\n\n### 3. Whole Person Identity\n\nThe daemon should reflect me as a human, not just a professional. That means:\n- Interests beyond tech (sailing, making, writing)\n- Values and philosophy (privacy, building over planning, local-first)\n- The things that matter that don't fit in a skills section\n\n### 4. Dynamic Updates\n\nRight now, updating the daemon requires editing YAML files and redeploying. That's fine for now, but eventually I want some level of automation—maybe pulling from daily notes or session logs to keep `current_focus` fresh.\n\n## Try It Yourself\n\nIf you want to query my daemon:\n\n**For AI Assistants (MCP):**\n```json\n{\n \"mcpServers\": {\n \"daemon-aj\": {\n \"url\": \"https://mcp.daemon.ajvanbeest.com/mcp\"\n }\n }\n}\n```\n\n**For Humans:**\n- Landing page: [daemon.ajvanbeest.com](https://daemon.ajvanbeest.com)\n- API docs: [daemon.ajvanbeest.com/api](https://daemon.ajvanbeest.com/api)\n- Raw JSON: [daemon.ajvanbeest.com/all](https://daemon.ajvanbeest.com/all)\n\n## The Meta-Observation\n\nBuilding a machine-readable identity forces you to articulate who you are in structured form. That's surprisingly hard.\n\nIt's easy to list your skills and projects. It's harder to capture what you actually care about, what you're optimizing for, what makes you *you* beyond your resume.\n\nThe daemon started as a technical project (\"let's build what Miessler built\"). It's becoming something more like structured self-reflection. The API is the easy part. The identity is the work.\n\n---\n\n*This post was co-authored by AJ Van Beest and Claude. The daemon is open source at [github.com/theaj42/daemon](https://github.com/theaj42/daemon).*", "html": "

A few weeks ago, I stumbled across Daniel Miessler’s daemon and immediately thought: I need one of these.

\n

The concept is beautifully simple: a machine-readable API that exposes who you are to AI assistants. Instead of every AI needing to start from scratch learning about you, they can query your daemon and get structured data about your skills, interests, projects, and what you’re currently working on.

\n

This is the story of building my own—what went well, what surprised us, and what we’re still figuring out.

\n

The Inspiration

\n

Miessler’s daemon has several tiers of access:

\n\n

There’s also an MCP (Model Context Protocol) endpoint, which means AI assistants can query it natively without knowing the specific API URLs. You just point Claude at mcp.daemon.danielmiessler.com and ask “What is Daniel working on?” and it figures out the rest.

\n

I wanted that.

\n

The Build Process

\n

Day 1: Infrastructure (Nov 29)

\n

We started with the basics: Cloudflare Workers for the API, a YAML-based data schema, and a build pipeline that compiles YAML to JavaScript.

\n
daemon/\n├── data/\n│   ├── public.yaml      # Public tier data\n│   └── trusted.yaml     # API-key protected data\n├── worker/\n│   └── src/\n│       ├── index.js     # Main worker\n│       └── data.js      # Auto-generated from YAML\n└── mcp-server/\n    └── src/\n        └── index.js     # MCP protocol wrapper
\n

The architecture is intentionally simple. YAML files are the source of truth. A build script compiles them to JavaScript. The worker serves JSON at various endpoints. The MCP server wraps those endpoints in JSON-RPC for AI assistants.

\n

DNS was the first hurdle—I moved ajvanbeest.com to Cloudflare nameservers, which took about 24 hours to propagate. Classic “hurry up and wait” moment.

\n

Day 2: MCP and Frontend (Dec 1)

\n

Once DNS resolved, deployment was smooth. Both workers went up:

\n\n

Then came the frontend. The API needed a human-readable landing page. I asked Claude for a Gruvbox Material Dark theme (my terminal aesthetic of choice), and we built a live-data landing page that fetches from the API endpoints and renders them nicely.

\n

Here’s what the /api docs page looks like:

\n
Public Endpoints (no auth required):\n  GET /about           Bio, tagline, links, certifications\n  GET /projects        Public projects list\n  GET /skills          Professional and exploratory skills\n  GET /interests       Topics and interests\n  GET /looking_for     Collaboration opportunities\n  GET /media           Books, movies, current consumption\n  GET /current_focus   What I'm working on now\n  GET /all             All public data in one call\n\nTrusted Endpoints (requires X-API-Key header):\n  GET /location        Current location and timezone\n  GET /availability    Contact preferences\n  GET /projects_detailed  Detailed project status with blockers
\n

What We Learned

\n

The Identity Question

\n

Here’s where it got interesting.

\n

When we looked at the first version of the daemon, I realized it was almost entirely professional. Skills, certifications, security projects, AI infrastructure work. It read like a LinkedIn profile that happened to be machine-readable.

\n

Which raised the question: What should a daemon actually represent?

\n

Is it a professional portfolio? A digital business card? Or is it supposed to be closer to “here’s who I am as a human”?

\n

Looking at Miessler’s daemon, I noticed he has a /telos endpoint—his life philosophy, purpose, what he’s optimizing for. The why behind everything else. My daemon didn’t have that layer at all.

\n

The Data Source Problem

\n

Claude built the initial content from what it had access to: session logs, project manifests, our work conversations. That’s inherently biased toward “AJ the security professional who builds AI systems.”

\n

It completely missed:

\n\n

The data source shapes the identity. If you feed an AI your work context, you get a work identity.

\n

Public vs Private

\n

We also had a conversation about what belongs in which tier. I initially had current_focus in the trusted tier, thinking it was somehow sensitive. Claude pointed out the security reasoning, but I realized: my personal work isn’t private. I’m not hiding what I’m building. Only my corporate work (which shouldn’t be in here anyway) needs protection.

\n

So current_focus moved to public. The daemon became a little more open.

\n

What’s Next

\n

This is a v0.1. The infrastructure works, but the content is thin. Here’s the roadmap:

\n

1. The Telos File

\n

I have a Telos file in my Obsidian vault—a document about my purpose, values, and what I’m optimizing for. It’s out of date. We’re planning a conversational interview process to update it, then expose it through the daemon.

\n

2. Morning Pages Review

\n

I’ve been writing morning pages all year. 2025 has hundreds of handwritten journal entries, transcribed and analyzed. That’s a rich source of who I actually am—my real concerns, recurring themes, the questions I keep asking. We’re going to do an agentic review of all 2025 entries to surface patterns.

\n

3. Whole Person Identity

\n

The daemon should reflect me as a human, not just a professional. That means:

\n\n

4. Dynamic Updates

\n

Right now, updating the daemon requires editing YAML files and redeploying. That’s fine for now, but eventually I want some level of automation—maybe pulling from daily notes or session logs to keep current_focus fresh.

\n

Try It Yourself

\n

If you want to query my daemon:

\n

For AI Assistants (MCP):

\n
{\n  \"mcpServers\": {\n    \"daemon-aj\": {\n      \"url\": \"https://mcp.daemon.ajvanbeest.com/mcp\"\n    }\n  }\n}
\n

For Humans:

\n\n

The Meta-Observation

\n

Building a machine-readable identity forces you to articulate who you are in structured form. That’s surprisingly hard.

\n

It’s easy to list your skills and projects. It’s harder to capture what you actually care about, what you’re optimizing for, what makes you you beyond your resume.

\n

The daemon started as a technical project (“let’s build what Miessler built”). It’s becoming something more like structured self-reflection. The API is the easy part. The identity is the work.

\n
\n

This post was co-authored by AJ Van Beest and Claude. The daemon is open source at github.com/theaj42/daemon.

", "links": [ "https://daemon.danielmiessler.com", "https://daemon.ajvanbeest.com", "https://daemon.ajvanbeest.com/api", "https://daemon.ajvanbeest.com/all", "https://github.com/theaj42/daemon" ], "alternates": { "html": "https://ajvanbeest.com/writing/building-my-daemon/", "markdown": "https://ajvanbeest.com/writing/building-my-daemon.md", "json": "https://ajvanbeest.com/writing/building-my-daemon.json" } }