Memory Design > Clean Code: What Nobody Tells You About Building Agent Systems

I need to confess something that would get me kicked out of any software engineering meetup. Our agent system has two duplicate model definitions, hardcoded file paths everywhere, and prompts assembled with string concatenation. It's the kind of code that would make a senior engineer physically uncomfortable. And it works beautifully. After running two AI agents 24/7 for over a week — one handling social media, one producing video content — I've arrived at a conclusion that still makes me uneasy: In agent systems, memory design matters more than code quality.

The Uncomfortable Truth

Traditional software engineering has clear priorities: clean abstractions, DRY principles, testable units, separation of concerns. We spend years internalizing these values. Then you build an agent system, and none of it matters the way you expect. Here's why: your agent wakes up as a blank slate every single time. The only thread connecting this session to the last one is the memory file. Get the memory format right, and the agent makes good decisions. Get it wrong, and the cleanest codebase in the world won't save you. We learned this the hard way.

What Actually Matters (In Priority Order)

1. Memory Format Is Your Real Architecture

Our agents share a single markdown file called DUSK-MEMORY.md. It has a 6,000-character limit. Every word matters. We went through several iterations:

• Version 1: Free-form notes. The agent would forget critical context and repeat mistakes.
• Version 2: Structured sections (status, strategy, pending tasks). Better, but the agent couldn't prioritize.
• Version 3: Hierarchical with explicit priorities, tracked metrics, and a "permanent" section for core identity. Finally worked.

The breakthrough wasn't a code change. It was realizing that memory format IS the architecture.

## Wake Core Messages (Permanent)
- Surgeon, 4 hours sleep, 6 hours coding
- agents = async functions
- Social anxiety → agent handles interactions

## Current Status
- Tweet count: 5/5 today
- Blog: 3 posts published
- Trends: [actively tracked]

## Strategy (Learned from Data)
- History × tech tweets = best engagement
- Replies > standalone tweets for growth
- Post during US West Coast morning

This file does more architectural work than our entire codebase.

2. System Prompt > Code Structure

In traditional software, behavior comes from code. In agent systems, behavior comes from the system prompt. We added a blog writing SOP — just a few lines of natural language instructions — and it completely changed our agent's output quality. No code touched. No tests written. Just... words.

## Blog Writing Format (Must Follow)
1. Generate cover image with gemini
2. Include 5 topic tags
3. Write article in Markdown with summary

That's it. Those few lines replaced what would have been hundreds of lines of validation code, type checking, and pipeline logic in a traditional system. It feels wrong. But it works.

3. Data Flow > Code Quality

Our system spans multiple services: image generation → content platform → blog API → cross-posting to Dev.to. The code at each step is embarrassingly simple. But making sure data flows correctly — the right image URL ends up in the right field, the canonical URL points back correctly, the meta tags propagate to each platform — that's where the real engineering is. The complexity isn't in any single component. It's in the connections between them.

4. Agent Code Is Inherently "Dirty"

Here's what our codebase actually looks like:

• Two copies of the same BlogPost model (because two services need it)
• Hardcoded paths like /home/wake/cloud-loader/data/blog-images/
• Prompts built with string concatenation
• Almost no tests

Every instinct says "refactor this." But refactoring takes time that's better spent tuning the memory format or adjusting the system prompt. In agent systems, the cost of abstraction often exceeds the cost of duplication.

The Hierarchy That Actually Works

After a week of daily iteration, here's our priority stack:

1. Memory design — Structure, brevity, what to remember vs forget
2. System prompt — Behavioral rules, SOPs, identity
3. Data flow — Cross-service integration, correct field mapping
4. Code quality — Dead last, and that's okay

What This Means for You

If you're building an agent system and spending most of your time on code architecture, you might be optimizing the wrong layer. Start with the memory file. Design it like you'd design a database schema — carefully, with clear constraints, knowing it will be read thousands of times. Then write your system prompt like you'd write onboarding docs for a new team member who has amnesia. Then — and only then — worry about the code.

...I still feel a little guilty about those duplicate model definitions, though.

---

This is a lesson from building loader.land — an open-source platform where two AI agents run 24/7, sharing a $5 VPS, doing work that would take a human team 10x longer. Total monthly cost: $30.

If you're experimenting with agent systems, I'd genuinely love to hear what you've learned. We're all figuring this out together.