This appendix is for builders. If you own a small business and don't write scripts, you don't need it. The main guide covers everything you need.
These are working habits, not rules from a vendor. Tools change. The habits have held up for us. Updated October 2026.
The agent starts every session blank. A few short files give it the context a new hire would need.
Most agent runtimes load instruction files at the start of a session. Names vary by tool. The jobs these files do are the same. Keep them as four separate files so each stays short and has one purpose.
Who the agent is, how it writes, what it values, and the act/ask boundary. It answers: "If I can't reach my operator, what would they want me to do?" Give it a name; a named identity tends to keep tone steadier across sessions.
The person or team: goals, working style, what they dislike, how they want bad news delivered. What a good chief of staff knows without being told.
Active projects, locked decisions, lessons learned, where things live. Curated, not a chat log.
Your actual setup: hosts, services, where credentials are stored and which accounts it may use. References only. Never the keys themselves.
Prune as models improve. Stronger models need less instruction, not more. Every quarter, archive any instruction file, prompt or skill that nobody opened and that doesn't encode a real failure you learned from. A lean, current set beats a pile of stale playbooks.
If you don't design memory, you don't have it.
| Tier | What it holds | Lifespan |
|---|---|---|
| Session | The current conversation | Gone when the session ends |
| Daily notes | One short file per day: done, decided, pending, lessons | Recent days load at session start; older ones are searched on demand |
| Durable | Curated facts and locked decisions, plus deeper project files loaded on demand | Until you prune them |
There is no mental note in an agent system. The moment something worth keeping happens, write it to a file: an API quirk, a decision and its reason, a status change, a preference you learned. Not at the end of the day. Before moving on.
Memory files decay. Keep the always-loaded file small enough that the agent reads all of it every session; set a size limit and enforce it. When it grows past the limit, summarize old entries and move the full text to an archive. Move finished project detail to its own file. Delete what is resolved and will not matter again. Review monthly. Don't over-build: if the agent won't read a file, don't create it.
Before ending a session on any project, write the state: what was tried, what worked, what didn't, what's next. Skip it and the next session starts over and re-debates settled questions.
Cheap checks run all the time. Expensive reasoning runs only when there is something to decide.
Layer 1, process monitor. A small shell script or system service that checks whether long-running processes are alive and restarts them if they crash. No AI, no API cost.
Layer 2, intelligence. The model that reads results, handles odd cases and decides. It is called when there is something to decide, never as a heartbeat.
Never put a single-shot AI command under a "restart if exited" monitor. A command such as claude --print answers once and exits normally. The monitor sees "process exited," restarts it, which makes another paid call, which exits, which triggers another restart. It repeats silently until the bill shows up. Use the monitor only for processes meant to stay running, and have it tell a clean exit from a crash.
A job that is scheduled but doing nothing gives false confidence.
Scheduled jobs (cron, launchd, cloud schedulers, assistant task schedulers) are where neglect builds up fastest. Jobs outlive the projects they served, call scripts that moved, or hit endpoints that changed. You think data is being collected. It isn't. You find out weeks later.
Cost is the number of calls times the size of each call. Shape both.
Design
Build
Launch
Maintain (monthly, plus a fuller review each quarter)
Back to The AI Operator's Playbook · nyclaw.io