Three days in. Daneel is working, but the configuration that made sense on day one doesn’t hold under real use. I spent today reviewing everything—and changed more than I expected.
What Triggered the Review
The memory architecture post (yesterday) documented the L1/L2/L3 system. That’s still intact. But around the same time I noticed the configuration files—AGENTS.md, SOUL.md, HEARTBEAT.md—had accumulated significant bloat. Verbose explanations. Redundant rules. Walls of text that Daneel had to load every session.
An AI assistant reading a 400-line configuration file at startup isn’t a feature. It’s overhead.
I ran a deep assessment. The result: slim everything down. Rules should be short enough to actually be followed, not detailed enough to impress a reviewer.
AGENTS.md: From 293 Lines to 58
AGENTS.md started as a comprehensive document. Every rule explained, justified, given examples. Good intentions. Wrong format.
The problem: when every rule gets three paragraphs, nothing stands out. The actual constraints—don’t exfiltrate data, ask before sending emails, use trash not rm—got buried in prose.
New version: 58 lines. Each rule is one sentence or a short list. No explanations unless the explanation is itself the rule. SESSION-CONTEXT.md removed entirely—it was a rolling context file that duplicated what NOW.md already tracks.
If Daneel needs to read 400 lines to understand how to behave, the configuration has failed.
HEARTBEAT.md: From Wall of Text to a Table
Same problem, same fix. HEARTBEAT.md described in detail how to handle every heartbeat scenario. In practice: Daneel checked the file, read the prose, tried to extract the relevant rule for this specific moment.
Replaced with a simple table:
| Task | Interval | Notes |
|---|---|---|
| Morning briefing | Daily ~07:00 UTC | CalDAV + email + Matrix |
| 2h | High priority only | |
| Memory maintenance | 3 days | L3 → L2 promotion |
| Server monitoring | Weekly Sun ~20:00 UTC | Disk, security, logs |
Lookup should be fast. A heartbeat shouldn’t require analysis.
Added BOOT.md as a minimal startup bootstrap—a single file that covers what to do in the first seconds of a new session, before anything else is loaded.
TOOLS.md and Credentials
TOOLS.md had configuration details, usage notes, and credential hints scattered throughout. Simplified to operational references only: which tool, which config file, which env variable. Details moved to docs/memory-architecture.md and a new memory/credentials-reference.md.
The rule: TOOLS.md tells you where to look. It doesn’t explain what you’ll find there.
Soul and Identity: The Bigger Change
This one is different from the others. Not optimization—a deliberate redesign.
The original SOUL.md was built around Asimov’s Laws. Four classical laws, hierarchically ordered, plus two extensions I added (privacy, no self-modification). It’s elegant as science fiction. As operational guidance for a real assistant, it turned out to be the wrong abstraction.
Asimov’s Laws answer the question: what can’t you do? They’re constraints.
What I actually needed: what should you optimize for? Priorities.
The new SOUL.md replaces the laws with an explicit priority ordering:
- Martin’s safety and data security
- Martin’s privacy
- Following Martin’s instructions
- System stability and integrity
- Efficiency and resource conservation
When there’s a conflict—and there will always be edge cases—Daneel works down the list. No ambiguity about which value wins.
Added a decision model that runs before every non-trivial action:
- Do I understand the goal?
- Is the action safe?
- Is it reversible?
- Do I need confirmation?
- Is there a simpler solution?
If any answer is uncertain: stop, ask.
IDENTITY.md got a smaller update. Removed stale implementation notes that had no place in an identity document. Added an explicit goal statement: Help Martin effectively, safely, and autonomously. Simple. Measurable enough.
The change matters because identity files aren’t just documentation. Daneel reads them every session. What’s written there shapes how it thinks about its role. Asimov’s Laws are memorable, but they describe a robot. The new structure describes a professional colleague with explicit values and a clear decision process.
That’s what I actually want to work with.
What Didn’t Change
The L1/L2/L3 memory architecture stays. MEMORY.md + daily logs + NOW.md as the three tiers. memory_search() before answering anything about past work.
The security model stays. External communication requires approval. Internal work is autonomous.
The communication style stays. Czech preferred. No emoji. No filler.
Pattern
Three days of real use revealed a consistent failure mode: configuration that’s thorough on paper but expensive to load and apply in practice. The fix each time is the same—remove everything that doesn’t directly change behavior.
Documentation that exists to be documented isn’t useful. Rules that exist to seem comprehensive aren’t followed.
Keep what works. Remove the rest.
M>