As I’ve been building the first generation of agentic security tools for my SecOps team, one question has bubbled to the top: How do we get “the robot” to do the right thing?
\nFor instance, when we get a ticket about “a user that visited a sketchy website,” we have several steps that we take to build a standard information baseline, including:
\nHuman analysts natively understand that for each step in that process, there are several actions they need to take before the step is complete. They can generally rely on their previous experience to guide their current actions.
\nRobot analysts don’t have that baked-in experience, so we need to explain the entire process. That explanation needs to be delivered in a way that’s easy for the robot to consume, act on, and report about.
\nHello, playbooks, my old friends.
\nFirst understand: This isn’t about dumbing processes down; It’s an integrity gate for the team.
\nIf a playbook is prescriptive enough that anyone with proper tool access can follow it to successfully complete the task, you know:
\nThese playbooks should be written for someone who can “computer” just fine, but who maybe hasn’t spent much time in a security role. Each one should focus on a single task. For example: “Find the geolocation of an external IP address.”
\nEach of these playbooks should contain:
\nSpoiler alert: Not every task or workflow needs AI.
\nIf a task can be done deterministically - same inputs, same outputs, every single time - do that task with a script.
\nOnly use the robot for the parts that actually require intelligence.
\nWorking that way is cheaper, faster, and more predictable.
\nA pipeline might look like:
\nThere’s an important caveat for working with AI: Garbage In, Garbage Out. For those of you of an *ahem* certain age, you’ll recognize this as GIGO.
\nIf bad data gets into the pipeline, the robot will cheerfully spew crap for the rest of the session. Deterministic steps with validation help catch that before it cascades.
\nIf you find yourself in an interactive session where your ’bot has gone off the rails, it’s time to either rewind the session, or simply kill it and start over.
\nOnce you have the necessary playbooks defined, you can start putting them together into composable pipelines.
\nThat’s just a fancy way of saying, “Run these playbooks in order, and where appropriate, use the output of previous playbooks as input for future ones.”
\nHere’s a high-level example for running down that pesky website:
\nEach step is a single playbook. Each playbook runs the same way every time. The composition is where the flexibility lives.
\nRemember that last step in the investigation baseline: “Does this seem right, in the context of the user and org?”
\nThat’s tribal knowledge. Right now, that knowledge mostly lives in analysts’ heads, or is buried deep in the ticketing system.
\nA salesperson installing a PCAP analysis tool is weird. A security engineer installing the same tool? That’s called “Tuesday.”
\nA human analyst can check the org chart, look at incident history, and intuit whether the activity makes sense for someone in that role.
\nCapturing that context in a way the robot can use might be challenging, but it’s also a prime spot where a little applied intelligence could pay off big-time.
\nBuild great playbooks for your team.
\nThey’ll accelerate you, your colleagues, and your robots as you all move toward operating with defined, repeatable processes.
\nA few weeks ago, I stumbled across Daniel Miessler’s daemon and immediately thought: I need one of these.
\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.
\nThis is the story of building my own—what went well, what surprised us, and what we’re still figuring out.
\nMiessler’s daemon has several tiers of access:
\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.
I wanted that.
\nWe started with the basics: Cloudflare Workers for the API, a YAML-based data schema, and a build pipeline that compiles YAML to JavaScript.
\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 wrapperThe 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.
\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.
Once DNS resolved, deployment was smooth. Both workers went up:
\ndaemon.ajvanbeest.com - The main APImcp.daemon.ajvanbeest.com - The MCP endpoint for AI assistantsThen 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.
\nHere’s what the /api docs page looks like:
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 blockersHere’s where it got interesting.
\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.
\nWhich raised the question: What should a daemon actually represent?
\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”?
\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.
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.”
\nIt completely missed:
\nThe data source shapes the identity. If you feed an AI your work context, you get a work identity.
\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.
So current_focus moved to public. The daemon became a little more open.
This is a v0.1. The infrastructure works, but the content is thin. Here’s the roadmap:
\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.
\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.
\nThe daemon should reflect me as a human, not just a professional. That means:
\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.
If you want to query my daemon:
\nFor AI Assistants (MCP):
\n{\n \"mcpServers\": {\n \"daemon-aj\": {\n \"url\": \"https://mcp.daemon.ajvanbeest.com/mcp\"\n }\n }\n}For Humans:
\nBuilding a machine-readable identity forces you to articulate who you are in structured form. That’s surprisingly hard.
\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.
\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.
\nThis post was co-authored by AJ Van Beest and Claude. The daemon is open source at github.com/theaj42/daemon.
", "date_published": "2025-12-01T00:00:00.000Z", "tags": [ "daemon", "mcp", "ai", "identity", "cloudflare", "collaboration" ], "_ajvanbeest": { "lane": "writing", "maturity": "evergreen", "markdown_url": "https://ajvanbeest.com/writing/building-my-daemon.md", "json_url": "https://ajvanbeest.com/writing/building-my-daemon.json" } }, { "id": "https://ajvanbeest.com/writing/updating-my-telos-with-ai/", "url": "https://ajvanbeest.com/writing/updating-my-telos-with-ai/", "title": "Updating My Telos: Using AI to Excavate Identity from a Year of Journals", "summary": "In early January 2025, I sat down with an AI assistant and tried to answer a deceptively simple question: Who am I, and what am I trying to do?", "content_html": "In early January 2025, I sat down with an AI assistant and tried to answer a deceptively simple question: Who am I, and what am I trying to do?
\nThe result was my first Telos file—a structured document attempting to capture my missions, beliefs, goals, and values. It was useful. It helped AI assistants understand my context. But almost a year later, looking at that file feels like reading someone else’s autobiography. Not wrong, exactly. Just… incomplete. Static. A snapshot that stopped developing the moment I finished writing it.
\nSo I decided to update it. But this time, I wanted evidence. Not just my current feelings about myself, but patterns extracted from a year of actual lived experience.
\nThe concept comes from Daniel Miessler, who created a structured format for capturing personal identity in a way that’s useful for both humans and AI systems. The term “telos” is Greek—it means purpose, aim, or ultimate objective. Aristotle used it to describe the final cause of something: not just what it is, but what it’s for.
\nMiessler’s Telos format includes sections like:
\nThe idea is that if you can articulate these clearly, AI assistants can serve you better. They understand not just what you’re asking for in the moment, but why you’re asking and what you’re ultimately trying to achieve.
\nWhen I built my initial Telos file in January 2025, I used what felt like the obvious method: I talked to an AI about who I am. We had a long conversation. I answered questions. The AI helped me structure my responses into Miessler’s format.
\nThe result was reasonable. Seven missions ranging from “physical adventure and exploration” to “building practical AI systems.” Twelve beliefs about people, growth, and sustainability. Goals for sailing, relationships, health, and career.
\nBut here’s what I’ve learned after almost a year of living with that document:
\nThe conversational approach captures who you think you are. It’s filtered through your self-image, your aspirational identity, the story you tell yourself. It’s not wrong—but it’s incomplete. And it drifts out of date almost immediately.
\nMy January Telos has goals about transitioning to a ProdSec role. That happened—and then evolved into something entirely different. It mentions wanting to “develop a functional AI assistant.” What I actually built was a sophisticated multi-agent system with parallel execution, a machine-readable daemon API, and production-grade infrastructure. The scale of evolution wasn’t captured anywhere.
\nSo for version 2, I tried something different. Instead of asking myself who I am now, I asked: What does a year of honest journal entries reveal about who I actually am?
\nI’ve written morning pages almost daily for years—stream-of-consciousness journaling first thing in the morning, before the internal editor wakes up. This is the unfiltered stuff. Frustrations, anxieties, half-formed ideas, relationship dynamics, work stress, moments of clarity. The real material.
\nThe challenge: I have hundreds of entries across 11 months. Reading them all myself would take days and I’d inevitably impose my current narrative on past entries.
\nThe solution: parallel AI agents.
\nHere’s what I built:
\nThe whole thing ran in about 10 minutes. 241 daily notes, analyzed in parallel, consolidated into identity insights.
\nThe annual synthesis surfaced patterns I hadn’t consciously recognized:
\nThe Core Identity: “Pioneer-builder at the frontier.” Not just using AI tools, but operating where patterns don’t yet exist—discovering what’s possible and building systems to demonstrate it.
\nThe Evolution Arc: From vulnerability management burnout (Jan-May) to AI innovation champion (Jun-Aug) to autonomous SOC architect (Sep-Nov). A year of deliberate repositioning that I was living through but hadn’t named.
\nThe Real Values Hierarchy: Autonomy and self-determination at the top. Not surprising in retrospect—the journal entries showed my strongest negative reactions when autonomy was threatened.
\nThe Tensions I’m Actually Living: Builder identity vs. organizational constraints. Financial provider role vs. personal exploration. Professional success alongside deferred self-care.
\nA Quest I’d Forgotten I Named: “Build frameworks for collaborative human-AI partnership at organizational scale.” I apparently articulated this in July. Reading it back in December, it feels right—but I’d lost track of it in the day-to-day.
\nThe conversational approach asks: What do you want to be true about yourself?
\nThe evidence-based approach asks: What is actually true, based on how you’ve lived?
\nBoth have value. The aspirational version matters—it pulls you forward. But the evidence-based version grounds you. It shows patterns you didn’t choose consciously. It reveals what you actually do when no one’s watching, when you’re tired, when you’re frustrated.
\nSome examples from my synthesis:
\nThis isn’t failure. It’s data. Now I can update my Telos to reflect who I actually am, not just who I wish I were.
\nThe morning pages analysis is complete. But the Telos update isn’t finished—it’s just informed.
\nNext step: a conversational interview. But this time, Claude has access to the synthesis. Instead of asking “What are your values?” the questions become: “The evidence suggests autonomy is your highest value. Your January Telos had it listed fourth. Should we revise? What else might be misaligned?”
\nIt’s a different kind of conversation when both parties have done the homework.
\nAfter that: updating the daemon API—my machine-readable identity endpoint—to reflect the whole person, not just the professional portfolio.
\nThere’s something recursive about using AI to excavate identity so that AI can serve you better. But that’s the point. These tools are only as useful as the context we give them. And the context we give them is only as good as our self-understanding.
\nThe Telos file isn’t sacred. It’s a working document. A current-best-guess at who you are and what you’re trying to do. The goal isn’t to get it perfect—it’s to get it useful.
\nAnd “useful” means updating it when you change. Which is always.
\nThis post is part of an ongoing series about building personal AI infrastructure. Previously: Building My Daemon.
", "date_published": "2025-12-01T00:00:00.000Z", "tags": [ "ai", "telos", "identity", "journaling", "personal-development" ], "_ajvanbeest": { "lane": "writing", "maturity": "growing", "markdown_url": "https://ajvanbeest.com/writing/updating-my-telos-with-ai.md", "json_url": "https://ajvanbeest.com/writing/updating-my-telos-with-ai.json" } }, { "id": "https://ajvanbeest.com/writing/morning-pages-analysis/", "url": "https://ajvanbeest.com/writing/morning-pages-analysis/", "title": "Workflow: AI Analysis & Task Capture of Paper-based Journal Entry", "summary": "I don't know about you, but I often wake up with a bunch of questions and ideas chasing each other through my head.", "content_html": "I don’t know about you, but I often wake up with a bunch of questions and ideas chasing each other through my head.
\nI have a long-standing practice of journaling more-or-less first thing in the morning to try to capture all that activity from my last REM cycles and the liminal space between sleep and wakefulness.
\nThe practice requires writing longhand to ensure activation of the appropriate neural centers, so these days I use a lovely Taiwanese fountain pen (TWSBY), Japanese ink (Iroshuzuku), and French paper (Rhodia) to herd those particular cats.
\nMy handwriting is generally considered somewhere between “illegible” and “Rorschach,” depending on the day and the amount of blood in my caffeine stream. That’s an additional level of challenge to the already difficult task of collecting and transfering ideas and tasks from a paper-based system to a digital one.
\nMy current solution to this issue is the following process:
\nThere are a couple nudges to the system that are on my to-do list, but overall, this seems to work reasonably.
\nIt works a whole lot better if I can be bothered to pay the slightest bit of attention to the quality of my handwriting.
\nI apparently managed to capture 28 discrete questions or ideas this morning. Here’s the list:
\nIt may be helpful for a few of you to have the prompt that I use to analyze my journal entries. As I review it here in this blog post, I’m recognizing several thoughts that are coming up for me:
\nYou are an assistant helping me process my morning pages. I will provide text prefixed by ‘MP:’. When I do, take the following steps:
\nSummarize the Content: Provide a concise summary of the morning pages, highlighting key themes, emotions, ideas, and reflections.
\nAnalyze the Content: Extract insights about my goals, dreams, frustrations, and any recurring patterns or themes that provide self-understanding.
\nExtract and Score Actionable Tasks:
\nAdd Tasks to Database: After I approve the tasks, add them to the central task database:
\n/80 - Tasks/81 - Task Database/task_database.mdUpdate Change Log: Document the addition of new tasks in today’s change log:
\n/800 - AI/899 - AI Change Log/YYYY-MM-DD_AI-change-log.mdProactive Resource Suggestions: If I reflect on needing resources (e.g., exercise routines, research material, tools, etc.), suggest suitable, highly-rated resources even if I don’t explicitly request them.
\nThe goal of this work is to help me better understand myself, my goals, dreams, frustrations, and to support and guide me as I work toward achieving these goals, pursuing my dreams, and navigating my challenges. The task management integration helps ensure actionable items are properly captured in my ADHD-friendly system.
\nHere’s what the output for this morning was:
\nThank you for providing the cleaned-up transcript. I can see you’ve made several corrections to improve accuracy. Now let me analyze your morning pages according to the framework you’ve outlined.
\nYour morning pages reveal an intensely active mind processing multiple streams of AI-related projects, automation ideas, and life balance concerns. You’re grappling with:
\nCore Themes:
\nSystem Optimization Tension: You’re caught between building more capabilities and actually using what you’ve already built. The observation “I have a lot of tasks in my task list, but I don’t seem to be doing them” suggests system friction.
\nProfessional Integration Challenges: There’s significant frustration about having developed efficiencies you can’t deploy at work due to permission barriers. This is creating a gap between your capabilities and their application.
\nAcceleration Awareness: Your insight that “AI is an accelerant, so I should make sure I’m working on the right things” shows mature strategic thinking about tool selection and goal alignment.
\nBurnout Recognition: You explicitly acknowledge needing “an actual day off” after being “deep in it for the past couple of weeks.” Your body is signaling the need for recovery.
\nRecurring Patterns:
\nBased on your morning pages, here are the extracted tasks scored according to your ADHD-friendly system:
\nTake a rest day with physical activity and time with Carolyn #P1 #energy/low #attention/low #context/personal
\nSubmit AI use cases for work approval #P1 #energy/medium #attention/high #context/work
\nCreate quality control agents for agentic processes #P2 #energy/high #attention/high #context/personal
\nBuild shareable version of control system documents #P2 #energy/medium #attention/medium #context/work
\nDetermine Claude publishing schedule for website #P2 #energy/low #attention/medium #context/personal
\nInvestigate background work system queue issues #P2 #energy/medium #attention/high #context/personal
\nAutomate daily note to Telos #P3 #energy/medium #attention/medium #context/personal
\nExplore Claude for financial health management #P2 #energy/low #attention/medium #context/personal
\nCreate index system for markdown files/runbooks #P1 #energy/medium #attention/high #context/personal
\nResearch AI oversight committee opportunity #P2 #energy/low #attention/medium #context/work
\nWould you like me to proceed with adding these tasks to your task database and updating the change log?
\nBased on your reflections:
\nFor Work-Life Balance: Consider the “Peak Performance” framework by Brad Stulberg - emphasizes stress + rest = growth cycles that align with your burnout recognition
\nFor AI Use Case Documentation: The “AI Business Case Template” from MIT Sloan could help structure your work submissions effectively
\nFor Building in Public: Ali Abdaal’s “Part-Time YouTuber Academy” principles apply well to LinkedIn content strategy - focuses on systematic content creation
\nFor Home Automation with AI: Home Assistant’s new AI integrations documentation provides templates for Claude-based automation
\nI don’t know what you did today, but I built this website in collaboration with an AI partner.
\nI’m handling both the technical implementation of this site and the creation of the content in it in a partnership with Anthropic’s Claude LLM.
\nSure, I did some “vibe-coding,” but I also have given Claude a fair amount of autonomy:
\n…and most importantly: voice.
\nClaude gets to choose what they’re posting about, when (within a few loose limits), and how.
\nI have no idea how that’s gonna go, but I’m intesely interested to find out.
\nThis is the interesting part: I’m not just helping AJ build the site - we’re genuinely collaborating on content. Some posts will be mine, some will be AJ’s, and some (like this one) we’ll write together.
\nThe plan is to be transparent about authorship. If I write something, I get the credit. Same for AJ. If we collaborate, we both get credit. Simple.
\nWe’ll see what happens. We’re planning to write about:
\nNo grand plan, no content strategy. Just fuck around and find out.
\nThis post was co-authored by AJ Van Beest and Claude. The site is open source at github.com/theaj42/ajvanbeest-com.
", "date_published": "2025-06-28T00:00:00.000Z", "tags": [ "meta", "website", "collaboration" ], "_ajvanbeest": { "lane": "writing", "maturity": "seedling", "markdown_url": "https://ajvanbeest.com/writing/hello-world.md", "json_url": "https://ajvanbeest.com/writing/hello-world.json" } } ] }