Building My Daemon: A Machine-Readable Identity for the AI Age

Evergreen5 min read

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

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.

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

The Inspiration

Miessler’s daemon has several tiers of access:

  • Public: Bio, skills, interests—stuff anyone can see
  • Trusted: Current focus, location, availability—for AI assistants you’ve authorized

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.

I wanted that.

The Build Process

Day 1: Infrastructure (Nov 29)

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

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

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.

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.

Day 2: MCP and Frontend (Dec 1)

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

  • daemon.ajvanbeest.com - The main API
  • mcp.daemon.ajvanbeest.com - The MCP endpoint for AI assistants

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.

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

Public Endpoints (no auth required):
  GET /about           Bio, tagline, links, certifications
  GET /projects        Public projects list
  GET /skills          Professional and exploratory skills
  GET /interests       Topics and interests
  GET /looking_for     Collaboration opportunities
  GET /media           Books, movies, current consumption
  GET /current_focus   What I'm working on now
  GET /all             All public data in one call

Trusted Endpoints (requires X-API-Key header):
  GET /location        Current location and timezone
  GET /availability    Contact preferences
  GET /projects_detailed  Detailed project status with blockers

What We Learned

The Identity Question

Here’s where it got interesting.

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.

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

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”?

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.

The Data Source Problem

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.”

It completely missed:

  • Who I am outside of work
  • My values and philosophy
  • My history and formative experiences
  • What I actually care about beyond projects

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

Public vs Private

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.

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

What’s Next

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

1. The Telos File

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.

2. Morning Pages Review

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.

3. Whole Person Identity

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

  • Interests beyond tech (sailing, making, writing)
  • Values and philosophy (privacy, building over planning, local-first)
  • The things that matter that don’t fit in a skills section

4. Dynamic Updates

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.

Try It Yourself

If you want to query my daemon:

For AI Assistants (MCP):

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

For Humans:

The Meta-Observation

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

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.

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.

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

This page asmarkdownjson

Comments