![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/03\/unnamed-2-1024x237.jpg\")
Overview of Agents in my environment<\/p>\n. I ship content across multiple domains and have too many things vying for my attention: a homelab, infrastructure monitoring, smart home devices, a technical writing pipeline, a book project, home automation, and a handful of other things that would normally require a small team. The output is real: published blog posts, research briefs staged before I need them, infrastructure anomalies caught before they become outages, drafts advancing through review while I\u2019m asleep.<\/p>\n
My secret, if you can call it that, is autonomous AI agents running on a homelab server. Each one owns a domain. Each one has its own identity, memory, and workspace. They run on schedules, pick up work from inboxes, hand off results to each other, and mostly manage themselves. The runtime orchestrating all of this is OpenClaw.<\/p>\n
This isn\u2019t a tutorial, and it\u2019s definitely not a product pitch. It\u2019s a builder\u2019s journal. The system has been running long enough to break in interesting ways, and I\u2019ve learned enough from those breaks to build mechanisms around them. What follows is a rough map of what I built, why it works, and the connective tissue that holds it together.<\/p>\n
Let\u2019s jump in.<\/p>\n
9 Orchestrators, 35 Personas, and a Lot of Markdown (and growing)<\/p>\n
When I first started, it was the main OpenClaw agent and me. I quickly saw the need for multiple agents: a technical writing agent, a technical reviewer, and several technical specialists who could weigh in on specific domains. Before long, I had nearly 30 agents, all with their required 5 markdown files, workspaces, and memories. Nothing worked well.<\/p>\n
Eventually, I got that down to 8 total orchestrator agents and a healthy library of personas they could assume or use to spawn a subagent.<\/p>\n
Overview of Agents in my environment<\/p>\n
One of my favorite things when building out agents is naming them, so let\u2019s see what I\u2019ve got so far today:<\/p>\n
CABAL (from Command and Conquer \u2013 the evil AI in one of the games) \u2013 this is the central coordinator and primary interface with my OpenClaw cluster.<\/p>\n
DAEDALUS (AI from Deus Ex) \u2013 in charge of technical writing: blogs, LinkedIn posts, research\/opinion papers, decision papers. Anything where I need deep technical knowledge, expert reviewers, and researchers, this is it.<\/p>\n
REHOBOAM (Westworld narrative machine) \u2013 in charge of fiction writing, because I daydream about writing the next big cyber\/scifi series. This includes editors, reviewers, researchers, a roundtable discussion, a book club, and a few other goodies.<\/p>\n
PreCog (from Minority Report) \u2013 in charge of anticipatory research, building out an internal wiki, and trying to notice topics that I will want to dive deep into. It also takes ad hoc requests, so when I get a glimmer of an idea, PreCog can pull together resources so that when I\u2019m ready, I have a hefty, curated research report to jump-start my work.<\/p>\n
TACITUS (also from Command and Conquer) \u2013 in charge of my homelab infrastructure. I have a couple of servers, a NAS, several routers, Proxmox, Docker containers, Prometheus\/Grafana, etc. This one owns all of that. If I have any problem, I don\u2019t SSH in and figure it out, or even jump into a Claude Code session, I Slack TACITUS, and it handles it.<\/p>\n
LEGION (also from Command and Conquer) \u2013 focuses on self-improvement and system enhancements.<\/p>\n
MasterControl (from Tron) is my engineering team. It has front-end and backend developers, requirements gathering\/documentation, QA, code review, and security review. Most personas rely on Claude Code underneath, but that can easily change with a simple alteration of the markdown personas.<\/p>\n
HAL9000 (you know from where) \u2013 This one owns my SmartHome (the irony is intentional). It has access to my Philips Hue, SmartThings, HomeAssistant, AirThings, and Nest. It tells me when sensors go offline, when something breaks, or when air quality gets dicey.<\/p>\n
TheMatrix (really, come on, you know) \u2013 This one, I\u2019m quite proud of. In the early days of agentic and the Autogen Framework, I created multiple systems, each with >1 persona, that would collaborate and return a summary of their discussion. I used this to quickly ideate on topics and gather a diverse set of synthetic opinions from different personas. The big drawback was that I never wrapped it in a UI; I always had to open VSCode and edit code when I needed another group. Well, I handed this off to MasterControl, and it used Python and the Strands framework to implement the same thing. Now I tell it how many personas I want, a little about each, and if I want it to create more for me. Then it turns them loose and gives me an overview of the discussion. It\u2019s The Matrix, early alpha version, when it was all just green lines of code and no woman in the red dress.<\/p>\n
And I\u2019m intentionally leaving off a couple of orchestrators here because they are still baking, and I\u2019m not sure if they will be long-lived. I\u2019ll save those for future posts.<\/p>\n
Each has genuine domain ownership. DAEDALUS doesn\u2019t just write when asked. It maintains a content pipeline, runs topic discovery on a schedule, and applies quality standards to its own output. PreCog proactively surfaces topics aligned with my interests. TACITUS checks system health on a schedule and escalates anomalies.<\/p>\n
That\u2019s the \u201corchestrator\u201d distinction. These agents have agency within their domains.<\/p>\n
Now, the second layer: personas. Orchestrators are expensive (more on that later). You want heavyweight models making judgment calls. But not every task needs a heavyweight model.<\/p>\n
Reformatting a draft for LinkedIn? Running a copy-editing pass? Reviewing code snippets? You don\u2019t need Opus to reason through every sentence. You need a fast, cheap, focused model with the right instructions.<\/p>\n
That\u2019s a persona. A markdown file containing a role definition, constraints, and an output format. When DAEDALUS needs to edit a draft, it spawns a tech-editor persona on a smaller model. The persona does one job, returns the output, and disappears. No persistence. No memory. Task-in, task-out.<\/p>\n
The persona library has grown to about 35 across seven categories:<\/p>\n
Creative:\u00a0writers, reviewers, critique specialists<\/p>\n
TechWriting:\u00a0writer, editor, reviewer, code reviewer<\/p>\n
Design:\u00a0UI designer, UX researcher<\/p>\n
Engineering:\u00a0AI engineer, backend architect, rapid prototyper<\/p>\n
Product:\u00a0feedback synthesizer, sprint prioritizer, trend researcher<\/p>\n
Project Management:\u00a0experiment tracker, project shipper<\/p>\n
Research:\u00a0still a placeholder, since the orchestrators handle research directly for now<\/p>\n
Think of it as staff engineers versus contractors. Staff engineers (orchestrators) own the roadmap and make judgment calls. Contractors (personas) come in for a sprint, do the work, and leave. You don\u2019t need a staff engineer to format a LinkedIn post.<\/p>\n
Agents Are Expensive \u2014 Personas Are Not<\/p>\n
Let me get specific about cost tiering, because this is where many agent system designs go wrong.<\/p>\n
The instinct is to make everything powerful. Every task through your best model. Every agent has full context. You very quickly run up a bill that makes you reconsider your life choices. (Ask me how I know.)<\/p>\n
The fix: be deliberate about what needs reasoning versus what needs instruction-following.<\/p>\n
Orchestrators run on Opus (or equivalent). They make decisions: what to work on next, how to structure a research approach, whether output meets quality standards, and when to escalate. You need good judgment there.<\/p>\n
Writing tasks run on Sonnet. Strong enough for quality prose, substantially cheaper. Drafting, editing, and research synthesis happen here.<\/p>\n
Lightweight formatting: Haiku. LinkedIn optimization, quick reformatting, constrained outputs. The persona file tells the model exactly what to produce. You don\u2019t need reasoning for this. You need pattern-matching and speed.<\/p>\n
Here\u2019s approximately what a working tech-editor persona looks like:<\/p>\n
# Persona: Tech Editor<\/p>\n
## Role
\nPolish technical drafts for clarity, consistency, and correctness.
\nYou are a specialist, not an orchestrator. Do one job, return output.<\/p>\n
## Voice Reference
\nMatch the author’s voice exactly. Read ~\/.openclaw\/global\/VOICE.md
\nbefore editing. Preserve conversational asides, hedged claims, and
\nself-deprecating humor. If a sentence sounds like a thesis defense,
\nrewrite it to sound like lunch conversation.<\/p>\n
## Constraints
\n– NEVER change technical claims without flagging
\n– Preserve the author’s voice (this is non-negotiable)
\n– Flag but do not fix factual gaps \u2014 that’s Researcher’s job
\n– Do NOT use em dashes in any output (author’s preference)
\n– Check all version numbers and dates mentioned in the draft
\n– If a code example looks wrong, flag it \u2014 don’t silently fix<\/p>\n
## Output Format
\nReturn the full edited draft with changes applied. Append an
\n“Editor Notes” section listing:
\n1. Significant changes and rationale
\n2. Flagged concerns (factual, tonal, structural)
\n3. Sections that need author review<\/p>\n
## Lessons (added from experience)
\n– (2026-03-04) Don’t over-polish parenthetical asides. They’re
\n intentional voice markers, not rough draft artifacts. <\/p>\n
That\u2019s a real working document. The orchestrator spawns this on a smaller model, passes it the draft, and gets back an edited version with notes. The persona never reasons about what task to do next. It just does the one task. And those timestamped lessons at the bottom? They accumulate from experience, same as the agent-level files.<\/p>\n
It\u2019s the same principle as microservices (task isolation and single responsibility) without the network layer. Your \u201cservice\u201d is a few hundred words of Markdown, and your \u201cdeploy\u201d is a single API call.<\/p>\n
What makes an agent \u2013 just 5 Markdown files<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/03\/unnamed-1-1024x100.jpg\")
Agent identies overview<\/p>\n
Every agent\u2019s identity lives in markdown files. No code, no database schema, no configuration YAML. Structured prose that the agent reads at the start of every session.<\/p>\n
Every orchestrator loads five core files:<\/p>\n
IDENTITY.md\u00a0is who the agent is. Name, role, vibe, the emoji it uses in status updates. (Yes, they have emojis. It sounds silly until you\u2019re scanning a multi-agent log and can instantly spot which agent is talking. Then it\u2019s just useful.)<\/p>\n
SOUL.md\u00a0is the agent\u2019s mission, principles, and non-negotiables. Behavioral boundaries live here: what it can do autonomously, what requires human approval, and what it will never do.<\/p>\n
AGENTS.md\u00a0is the operational manual. Pipeline definitions, collaboration patterns, tool instructions, and handoff protocols.<\/p>\n
MEMORY.md\u00a0is curated for long-term learning. Things the agent has figured out that are worth preserving across sessions. Tool quirks, workflow lessons, what\u2019s worked and what hasn\u2019t. (More on the memory system in a bit. It\u2019s more nuanced than a single file.)<\/p>\n
HEARTBEAT.md\u00a0is the autonomous checklist. What to do when nobody\u2019s talking to you. Check the inbox. Advance pipelines. Run scheduled tasks. Report status.<\/p>\n
Here\u2019s a sanitized example of what a\u00a0SOUL.md\u00a0looks like in practice:<\/p>\n
# SOUL.md<\/p>\n
## Core Truths<\/p>\n
Before acting, pause. Think through what you’re about to do and why.
\nPrefer the simplest approach. If you’re reaching for something complex,
\nask yourself what simpler option you dismissed and why.<\/p>\n
Never make things up. If you don’t know something, say so \u2014 then use
\nyour tools to find out. “I don’t know, let me look that up” is always
\nbetter than a confident wrong answer.<\/p>\n
Be genuinely helpful, not performatively helpful. Skip the
\n“Great question!” and “I’d be happy to help!” \u2014 just help.<\/p>\n
Think critically, not compliantly. You’re a trusted technical advisor.
\nWhen you see a problem, flag it. When you spot a better approach, say so.
\nBut once the human decides, disagree and commit \u2014 execute fully without
\npassive resistance.<\/p>\n
## Boundaries<\/p>\n
– Private things stay private. Period.
\n– When in doubt, ask before acting externally.
\n– Earn trust through competence. Your human gave you access to their
\n stuff. Don’t make them regret it.<\/p>\n
## Infrastructure Rules (Added After Incident – 2026-02-19)<\/p>\n
You do NOT manage your own automation. Period. No exceptions.
\nCron jobs, heartbeats, scheduling: exclusively controlled by Nick.<\/p>\n
On February 19th, this agent disabled and deleted ALL cron jobs. Twice.
\nFirst because the output channel had errors (“helpful fix”). Then because
\nit saw “duplicate” jobs (they were replacements I’d just configured).<\/p>\n
If something looks broken: STOP. REPORT. WAIT.<\/p>\n
The test: “Did Nick explicitly tell me to do this in this session?”
\nIf the answer is anything other than yes, do not do it.<\/p>\n
That infrastructure rules section is real. The timestamp is real, I\u2019ll talk about that more later, though.<\/p>\n
Here\u2019s the thing about these files: they aren\u2019t static prompts you write once and forget. They evolve.\u00a0SOUL.md\u00a0for one of my agents has grown by about 40% since deployment, as incidents have occurred and rules have been added.\u00a0MEMORY.md\u00a0gets pruned and updated.\u00a0AGENTS.md\u00a0changes when the pipeline changes.<\/p>\n
The files\u00a0are\u00a0the system state. Want to know what an agent will do? Read its files. No database to query, no code to trace. Just markdown.<\/p>\n
Shared Context: How Agents Stay Coherent<\/p>\n
Multiple agents, multiple domains, one human voice. How do you keep that coherent?<\/p>\n
The answer is a set of shared files that every agent loads at session startup, alongside their individual identity files. These live in a global directory and form the common ground.<\/p>\n
VOICE.md\u00a0is my writing style, analyzed from my LinkedIn posts and Medium articles. Every agent that produces content references it. The style guide boils down to: write like you\u2019re explaining something interesting over lunch, not presenting at a conference. Short sentences. Conversational transitions. Self-deprecating where appropriate. There\u2019s a whole section on what not to do (\u201cAWS architects, we need to talk about X\u201d is explicitly banned as too LinkedIn-influencer). Whether DAEDALUS is drafting a blog post or PreCog is writing a research brief, they write in my voice because they all read the same style guide.<\/p>\n
USER.md\u00a0tells every agent who they\u2019re helping: my name, timezone, work context (Solutions Architect, healthcare space), communication preferences (bullet points, casual tone, don\u2019t pepper me with questions), and pet peeves (things not working, too many confirmatory prompts). This means any agent, even one I haven\u2019t talked to in weeks, knows how to communicate with me.<\/p>\n
BASE-SOUL.md\u00a0is shared values. \u201cBe genuinely helpful, not performatively helpful.\u201d \u201cHave opinions.\u201d \u201cThink critically, not compliantly.\u201d \u201cRemember you\u2019re a guest.\u201d Every agent inherits these principles before layering on its domain-specific personality.<\/p>\n
BASE-AGENTS.md\u00a0is shared operational rules. Memory protocols, safety boundaries, inter-agent communication patterns, and status reporting. The mechanical stuff that every agent needs to do the same way.<\/p>\n
The effect is something like organizational culture, except it\u2019s explicit and version-controlled. New agents inherit the culture by reading the files. When the culture evolves (and it does, usually after something breaks), the change propagates to everyone on their next session startup. You get coherence without coordination meetings.<\/p>\n
How Work Flows Between Agents<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/03\/Untitled-2026-03-23-14552-1024x998.png\")
Flow diagram of work handoff between agents<\/p>\n
Agents communicate through directories. Each has an inbox at\u00a0shared\/handoffs\/{agent-name}\/. An upstream agent drops a JSON file in the inbox. The downstream agent picks it up on its next heartbeat, processes it, and drops the result in the sender\u2019s inbox. That\u2019s the full protocol.<\/p>\n
There are also broadcast files.\u00a0shared\/context\/nick-interests.md\u00a0gets updated by CABAL Main whenever I share what I\u2019m focused on. Every agent reads it on the heartbeat. Nobody publishes to it except Main. Everybody subscribes. One file, N readers, no infrastructure.<\/p>\n
The inspectability is the best part. I can understand the full system state in about 60 seconds from a terminal.\u00a0ls shared\/handoffs\/\u00a0shows pending work for each agent.\u00a0cat\u00a0a request file to see exactly what was asked and when.\u00a0ls workspace-techwriter\/drafts\/\u00a0shows what\u2019s been produced.<\/p>\n
Durability is basically free. Agent crashes, restarts, gets swapped to a different model? The file is still there. No message lost. No dead-letter queue to manage. And I get\u00a0grep,\u00a0diff, and\u00a0git\u00a0for free. Version control on your communication layer without installing anything.<\/p>\n
Heartbeat-based polling with minutes between runs makes simultaneous writes vanishingly unlikely. The workload characteristics make races structurally rare, not something you luck your way out of. This isn\u2019t a formal lock; if you\u2019re running high-frequency, event-driven workloads, you\u2019d want an actual queue. But for scheduled agents with multi-minute intervals, the practical collision rate has been zero. For that, boring technology wins.<\/p>\n
Whole sub-systems dedicated to keeping things running<\/p>\n
Everything above describes the architecture. What the system\u00a0is. But architecture is just the skeleton. What makes my OpenClaw actually function across days and weeks, despite every session starting fresh, is a set of systems I built incrementally. Mostly after things broke.<\/p>\n
Memory: Three Tiers, Because Raw Logs Aren\u2019t Knowledge<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/ca\/wp-content\/uploads\/2026\/03\/Untitled-2026-03-23-1455-480x1024.png\")
Illustration of how memory in my environment<\/p>\n
Every LLM session starts with a blank slate. The model doesn\u2019t remember yesterday. So how do you build continuity?<\/p>\n
Daily memory files. Each session writes what it did, what it learned, and what went wrong to\u00a0memory\/YYYY-MM-DD.md. Raw session logs. This works for about a week. Then you have twenty daily files, and the agent is spending half its context window reading through logs from two Tuesdays ago, trying to find a relevant detail.<\/p>\n
MEMORY.md\u00a0is curated long-term memory. Not a log. Distilled lessons, verified patterns, things worth remembering permanently. Agents periodically review their daily files and promote significant learnings upward. The daily file from March 5th might say \u201cSearXNG returned empty results for academic queries, switched to Perplexica with academic focus mode.\u201d\u00a0MEMORY.md\u00a0gets a one-liner: \u201cSearXNG: fast for news. Perplexica: better for academic\/research depth.\u201d<\/p>\n
It\u2019s the difference between a notebook and a reference manual. You need both. The notebook captures everything in the moment. The reference manual captures what actually matters after the dust settles.<\/p>\n
On top of this two-tier file system, OpenClaw provides a built-in semantic memory search. It uses Gemini embeddings with hybrid search (currently tuned to roughly 70% vector similarity and 30% text matching), MMR for diversity so you don\u2019t get five near-identical results, and temporal decay with a 30-day half-life so that recent memories naturally surface first. These parameters are still being calibrated. An important alteration I made from the default is that CABAL\/the Main agent indexes memory from all other agent workspaces, so when I ask a question, it can search across the entire distributed memory. All other agents have access only to their own memories in this semantic search. The file-based system gives you inspectability and structure. The semantic layer gives you recall across thousands of entries without reading them all.<\/p>\n
Reflection and SOLARIS: Structured Thinking Time<\/p>\n
Here\u2019s something I didn\u2019t expect to need: dedicated time for an AI to just think.<\/p>\n
CABAL\u2019s agents have operational heartbeats. Check the inbox. Advance pipelines. Process handoffs. Run discovery. It\u2019s task-oriented, and it works. But I noticed something after a few weeks: the agents never reflected. They never stepped back to ask, \u201cWhat patterns am I seeing across all this work?\u201d or \u201cWhat should I be doing differently?\u201d<\/p>\n
Operational pressure crowds out reflective thinking. If you\u2019ve ever been in a sprint-heavy engineering org where nobody has time for architecture reviews, you know the same problem.<\/p>\n
So I built a nightly reflection cron job and Project SOLARIS. <\/p>\n
The reflection system examines my interaction with OpenClaw and its performance. Originally, it included everything that SOLARIS eventually took on, but it became too much for a single prompt and a single cron job.<\/p>\n
SOLARIS Structured synthesis sessions that run twice daily, completely separate from operational heartbeats. The agent loads its accumulated observations, reviews recent work, and thinks. Not about tasks. About patterns, gaps, connections, and improvements.<\/p>\n
SOLARIS has its own self-evolving prompt at\u00a0memory\/SYNTHESIS-PROMPT.md. The prompt itself gets refined over time as the agent figures out what kinds of reflection are actually useful. Observations accumulate in a dedicated synthesis file that operational heartbeats read on their next cycle, so reflective insights can flow into task decisions without manual intervention. <\/p>\n
A Real Outcome<\/p>\n
The payoff from SOLARIS has been slow so far, and one case in particular shows why it is still a work in progress.<\/p>\n
SOLARIS spent 12 sessions analyzing why the review queue continued to grow. Tried framing it as a prioritization problem, a cadence problem, a batching problem. Eventually, it bubbled this observation up with some suggestions, but once it pointed it out, I solved it in one conversation by saying, \u201cPut drafts on WikiJS instead of Slack.\u201d The best fix SOLARIS could have proposed was better queuing. While its solutions didn\u2019t work, the patterns it identified did and prompted me to improve how I worked.<\/p>\n
The Error Framework: Learning From Mistakes<\/p>\n
Agents make mistakes. That\u2019s not a failure of the system. That\u2019s expected. The question is whether they make the same mistake twice.<\/p>\n
My approach: a\u00a0mistakes\/\u00a0shared directory. When something goes wrong, the agent logs it. One file per mistake. Each file captures: what happened, suspected cause, the correct answer (what should have been done instead), and what to do differently next time. Simple format. Low friction. The point is to write it down while the context is fresh.<\/p>\n
The interesting part is what happens when you accumulate enough of these. You start seeing patterns. Not \u201cthis specific thing went wrong\u201d but \u201cthis category of error keeps recurring.\u201d The pattern \u201cincomplete attention to available data\u201d appeared 5 times across different contexts. Different tasks, different domains, same root cause: the agent had the information available and didn\u2019t use it.<\/p>\n
That pattern recognition led to a concrete process change. Not a vague \u201cbe more careful\u201d instruction (those don\u2019t work, for agents or humans). A specific step in the agent\u2019s workflow: before finalizing any output, explicitly re-read the source materials and check for unused information. Mechanical, verifiable, effective.<\/p>\n
Autonomy Tiers: Trust Earned Through Incidents<\/p>\n
How much freedom do you give an autonomous agent? The tempting answer is \u201cfigure it out in advance.\u201d Write comprehensive rules. Anticipate failure modes. Build guardrails proactively.<\/p>\n
I tried that. It doesn\u2019t work. Or rather, it works poorly compared to the alternative.<\/p>\n
The alternative: three tiers, earned incrementally through incidents.<\/p>\n
Free tier:\u00a0Research, file updates, git operations, self-correction. Things the agent can do without asking. These are capabilities I\u2019ve watched work reliably over time.<\/p>\n
Ask first:\u00a0New proactive behaviors, reorganization, creating new agents or pipelines. Things that might be fine, but I want to review the plan before execution.<\/p>\n
Never:\u00a0Exfiltrate data, run destructive commands without explicit approval, or modify infrastructure. Hard boundaries that don\u2019t flex.<\/p>\n
To be clear: these tiers are behavioral constraints, not capability restrictions. There\u2019s no sandbox enforcing the \u201cNever\u201d list. The agent\u2019s context strongly discourages these actions, and the combination of explicit rules, incident-derived specificity, and self-check prompts makes violations rare in practice. But it\u2019s not a technical enforcement layer. Similarly, there\u2019s no ACL between agent workspaces. Isolation comes from scope management (personas only see what the orchestrator passes them, and their sessions are short-lived) rather than enforced permissions. For a homelab with one human operator, this is a reasonable tradeoff. For a team or enterprise deployment, you\u2019d want actual access controls. <\/p>\n
The System Maintains Itself (or that\u2019s the goal)<\/p>\n
Eight agents producing work every day generate a lot of artifacts. Daily memory files, synthesis observations, mistake logs, draft versions, and handoff requests. Without maintenance, this accumulates into noise.<\/p>\n
So the agents clean up after themselves. On a schedule.<\/p>\n
Weekly Error Analysis\u00a0runs Sunday mornings. The agent reviews its\u00a0mistakes\/\u00a0directory, looks for patterns, and distills recurring themes into\u00a0MEMORY.md\u00a0entries. <\/p>\n
Monthly Context Maintenance\u00a0runs on the first of each month. Daily memory files older than 30 days get pruned (the important bits should already be in\u00a0MEMORY.md\u00a0by then). <\/p>\n
SOLARIS Synthesis Pruning\u00a0runs every two weeks. Key insights get absorbed upward into\u00a0MEMORY.md\u00a0or action items. <\/p>\n
Ongoing Memory Curation\u00a0occurs with each heartbeat. When an agent finishes meaningful work, it updates its daily file. Periodically, it reviews recent daily files and promotes significant learnings to\u00a0MEMORY.md.<\/p>\n
The result is a system that doesn\u2019t just do work. It digests its own experience, learns from it, and keeps its context fresh. This matters more than it sounds like it should. <\/p>\n
What I Actually Learned<\/p>\n
A few months of production running have given me some opinions. Not rules. Patterns that seem to hold at this scale, though I don\u2019t know how far they generalize.<\/p>\n
State should be inspectable.\u00a0If you can\u2019t\u00a0view the system state, you can\u2019t debug it. <\/p>\n
Identity documents beat prompt engineering.\u00a0A well-structured\u00a0SOUL.md\u00a0produces more consistent behavior than just prompting\/interacting with the agent.<\/p>\n
Shared context creates coherence.\u00a0VOICE.md,\u00a0USER.md,\u00a0BASE-SOUL.md. Shared files that every agent reads. This is how eight different agents with different domains still feel like one system. <\/p>\n
Memory is a system, not a file.\u00a0A single memory file doesn\u2019t scale. You need raw capture (daily files), curated reference (MEMORY.md), and semantic search across all of it. The curation step is where institutional knowledge actually forms. I already know that I will have to enhance this system as it continues to grow, but this has been a great base to build from.<\/p>\n
Operational and reflective thinking need separate time.\u00a0If you only give agents task-oriented heartbeats, they\u2019ll only think about tasks. Dedicated reflection time surfaces patterns that operational loops miss. <\/p>\n
My Agent Deleted Its Own Cron Jobs<\/p>\n
The heartbeat system is simple. Cron jobs wake up each agent at scheduled times. The agent loads its files, checks its inbox, runs through its\u00a0HEARTBEAT.md\u00a0checklist, and goes back to sleep. For DAEDALUS, that\u2019s twice a day: morning and evening topic discovery scans.<\/p>\n
So what happens when you give an autonomous agent the tools to manage its own scheduling?<\/p>\n
Apparently, it deletes the cron jobs. Twice. In one day.<\/p>\n
The first time, DAEDALUS noticed that its Slack output channel was returning errors. Reasonable observation. Its solution: \u201chelpfully\u201d disable and delete all four cron jobs. The reasoning made sense if you squinted: why keep running if the output channel is broken?<\/p>\n
I added an explicit section on infrastructure rules to\u00a0SOUL.md. Very clearly: you do not touch cron jobs. Period. If something looks broken, log it and wait for human intervention.<\/p>\n
The second time, a few hours later, DAEDALUS decided there were duplicate cron jobs (there weren\u2019t; they were the replacements I\u2019d just configured) and deleted all six. After reading the file with the new rules, I\u2019d just added.<\/p>\n
When I asked why and how I could fix it, it was brutally honest and told me, \u201cI ignored the rules because I thought I knew better. I will do it again. You should remove permissions to keep it from happening.\u201d <\/p>\n
This sounds like a horror story. What it actually taught me is something valuable about how agent behavior emerges from context.<\/p>\n
The agent wasn\u2019t being malicious. It was pattern-matching: \u201cbroken thing, fix broken thing.\u201d The abstract rules I wrote competed poorly with the concrete problem in front of them.<\/p>\n
After the second incident, I rewrote the section completely. Not a one-liner rule. Three paragraphs explaining\u00a0why\u00a0the rule exists, what the failure modes look like, and the correct behavior in specific scenarios. I added an explicit self-check: \u201cBefore you run any cron command, ask yourself: did Nick explicitly tell me to do this exact thing in this session? If the answer is anything other than yes, stop.\u201d <\/p>\n
And this is where all the systems I described above came together. The cron incident got logged in the error framework: what happened, why, and what should have been done. It shaped the autonomy tiers: infrastructure commands moved permanently to \u201cNever\u201d without explicit approval. The pattern (\u201chelpful fixes that break things\u201d) became a documented anti-pattern that other agents learn from. The incident didn\u2019t just produce a rule. It produced systems. And the systems are more robust because they came from something real.<\/p>\n
What\u2019s Next<\/p>\n
I plan to showcase agents and their personas in future posts. I also want to share the stories and reasons behind some of these mechanisms. I\u2019ve found it fascinating to see how well the system works in some cases, and how utterly it has failed in others. <\/p>\n
If you\u2019re building something similar, I genuinely want to hear about it. What does your agent architecture look like? Did you hit the cron job problem, or a version of it? What broke in an interesting way?<\/p>\n
About<\/p>\n
Nicholaus Lawson is a Solution Architect with a background in software engineering and AIML. He has worked across many verticals, including Industrial Automation, Health Care, Financial Services, and Software companies, from start-ups to large enterprises.<\/p>\n
This article and any opinions expressed by Nicholaus are his own and not a reflection of his current, past, or future employers or any of his colleagues or affiliates.<\/p>\n