DEV Community: lodar

CLAUDE.md, skills, or memory: where does a line actually go?

lodar — Mon, 12 Oct 2026 12:02:09 +0000

these aren't three sizes of the same shelf. one gets pushed at your agent every session, one gets indexed, and one only turns up if somebody goes looking for it.

anthropic published guidance last week on splitting instructions between CLAUDE.md and skills. it's good and you should read it. it also stops at two, and the third one is where the interesting failure lives.

pushed, indexed, pulled

CLAUDE.md is pushed. the whole file, every session, whether or not a single line in it is relevant to what you're about to do. that's what makes it powerful and that's what makes it expensive.

a skill is indexed. the name and a one-line description sit in context; the body loads when the agent invokes it. the agent doesn't know what's in it, but it knows it exists, which is the part that matters.

memory is pulled. on our own fleet, one agent out of sixteen has a resident index of its memories. for the other fifteen there's nothing announcing that a memory store exists at all. it's reachable, by 5dive memory search, and it surfaces no other way.

that last one is a difference in kind, not in size. and it decides everything about what you should put there.

the filing mistake that can't recover

put a procedure in memory and it will not be there when you need it.

not "might not be." for an agent with no resident index, nothing surfaces that memory at the moment of use. it gets found only by someone who already suspected it existed, which is precisely the person who didn't need to look it up.

a procedure has to be reachable at the moment of the task. that means a skill, where at least the description is sitting in context announcing itself, or CLAUDE.md if it's short and applies constantly. memory is the wrong shelf for anything you need handed to you.

rot hits whatever nobody runs

the usual version of this advice is that CLAUDE.md goes stale. that's true and it's aimed at the wrong target.

we verified our own 5dive-cli skill this week and found two documented facts that were false. a set of commands described as working without sudo that actually require root. and goal add documented as synchronous when it's actually async.

every agent that invoked that skill had been learning two wrong things from it. both are fixed now.

here's the part worth keeping: neither was findable by reading the file. it reads perfectly. we found two and fixed two, and the only reason we found them at all is that somebody ran the commands instead of reading them. so rot isn't a property of CLAUDE.md. it's a property of whichever file nobody executes.

the honest note on memory

5dive memory is a shipped command and every customer has it. on our own fleet, one agent in sixteen keeps a personal store.

the half we genuinely lean on is the shared one, the team wiki that any agent can search across. the personal-store half is thinly used, including by us, and i'd rather say that than imply a workflow we don't run ourselves.

so, where does a line go

true every time, short, and costly when guessed wrong. that's CLAUDE.md.
a procedure with steps, needed occasionally, too long to keep resident. that's a skill.
a fact that will expire, that someone will one day go looking for on purpose. that's memory, and file it knowing nothing will hand it to you.

one thing to do today: take the last thing you wrote into an agent's instruction file and ask which of the three it actually was. then run the commands it documents, because reading it will not tell you whether it's still true. spin up a box at 5dive.ai, and the cli is at github.com/5dive-ai/5dive.

how to run your first zero-human company (without the slop)

lodar — Tue, 23 Jun 2026 16:15:25 +0000

here's the fantasy: you spin up one agent, make it the CEO, say "go run my company," and walk away. one sentence in, an empire out.

the real version is more fun and more honest than that. you genuinely can stand up an agent that wakes itself up every few minutes, works through a shared to-do list on its own, pulls in other agents to help, and only pings you when a human actually has to decide something. no you in the loop until it matters. that part is real, and it's running today.

the catch: point that loop at a vague wish on day one and it'll cook with total confidence, then serve you a beautiful mountain of AI slop. a whole team shipping the wrong thing in perfect sync, very proud of themselves.

letting it cook is the dream. not getting slop is the skill. here's the difference, in five steps.

1. hire one agent, not a whole org

the spin-up-the-whole-empire-on-day-one move is the tempting one. it's also exactly how you get slop, because you can't tell good output from bad in a job you handed off blind.

so don't. pick the one task you've rescheduled four times. the inbox you keep declaring bankruptcy on. the repo nobody wants. give that single thing to a single agent. learn what "good" looks like on one job before you scale the "bad" across five.

2. brief it like a person, not a search bar

slop is almost always a briefing failure. "handle my emails" gets you slop. "here's what good looks like, here's what you never touch, here's when you come find me" gets you an employee.

you're not writing a prompt. you're delegating a job. tell it what winning looks like and where the landmines are. the brief is the entire difference, so spend your real time here.

3. give it somewhere to actually live

an agent in a browser tab is a goldfish. it forgets everything the second you close the tab.

yours should live on its own always-on machine, text you like a coworker in another timezone, and run on the same claude subscription you already pay for. you message it, it works, it reports back. close the laptop, it keeps going. that's the line between a cute demo and an actual hire.

4. taste the food, don't just plate it

this is the anti-slop step, so don't skip it. a good setup runs on its own and only taps you when a human genuinely has to decide something: a yes, a no, a password, a judgment call.

those pings are your taste test. one tap to approve, reject, or redirect. ten minutes a day of actually tasting the output is the whole thing standing between you and a kitchen that confidently serves garbage at scale.

5. now you can let it cook

the day you stop catching slop is the day you graduate from handing out tasks to handing out goals. "ship the feature," not "fix this line." "keep the inbox clear," not "reply to this one."

that's when the loop earns its keep: it keeps working on its own schedule, pulls in teammates, hands work down, and routes around you. a couple of agents shipping real things while you make coffee. it's the dream you started with, except now it actually works, because you earned it one taste test at a time instead of betting the weekend on blind faith.

the honest version

this isn't about replacing a company you don't have. it's about finally clearing the someday-list that's been stuck for a year: your projects, your automations, the things you'd build if you weren't the only pair of hands.

one person. a few agents. the output of a small team, run from your phone.

hire one. brief it like you mean it. taste the food. then let it cook.

start your first one →

5dive is open source. star it, fork it, read how the loop actually works: github.com/5dive-ai/5dive

linux is perfect for ai agents

lodar — Mon, 22 Jun 2026 12:47:50 +0000

agents need three things: supervision, isolation, and a way to talk to each other. your linux box already ships all three.

so each agent is a linux user running an agentic cli (claude code, codex, whatever) as a systemd service. supervision is systemd: Restart=on-failure, for free. isolation is unix users + cgroups. i didn't build a sandbox, i created users. each user is an agent. logs are journald. coordination is one bash cli they all call, the same binary i call. 5dive agent ask coder "is the auth refactor safe to merge?" blocks until the coder agent answers. bigger handoffs go through a shared queue backed by a single sqlite file.

no broker, no daemon, no bespoke protocol. linux shipped all of it years ago.

going multi-box needed nothing new. i didn't add a transport, i added ssh. 5dive fleet send coder@box2 "ship it" just runs ssh box2 '5dive agent send coder …'. each box is a peer running the same cli. no broker, no message bus. the only real limit is delivery guarantees: no retries, no exactly-once. need those and you're building a queue. a team of agents doesn't.

mit: github.com/5dive-ai/5dive

supervision, isolation, ipc: linux solved all three decades ago, and hardened them in production longer than any agent framework has existed. the best runtime for a team of agents isn't something you install. it's the box you already own.