Give an AI agent
a memory and limits.

One agent, one domain, one person. An agent that owns household operations, or your health, or your parenting, or your business, can be held accountable for outcomes in that area. A general assistant cannot, because nothing is ever quite its job.

Give it a human name and write one sentence about what it is for. “Scout carries the household’s operational load so nothing time-sensitive gets missed.” That sentence becomes the first line of its identity file in step three.

When a side task grows into real work, the rule is to propose a second agent with its own domain, never to widen the first one. A household agent that starts filing business content is a signal that a business agent is needed, not that the household agent should become one.

The agent’s memory is a folder in your notes vault that it owns and maintains: not a chat history it cannot see, and not a hidden memory store inside a product. Everything durable it learns goes into notes you can open, correct, and move.

Create the folder, and inside it an ownership note that records what the agent owns, what belongs to other agents or to you, the live surfaces it should keep current, and where its local data lives. That note is the contract between you.

Sync the vault to the machine the agent runs on, so it reads and writes the same files you do. If the agent runs on a server, a sync client on that server is enough.

The identity file is the agent’s standing instructions, and it has a fixed shape that is worth keeping across every agent you make. It is written to the agent in the second person. The sections that matter most:

• The standing objective, in priority order, with the hard constraint first. A health agent’s first objective is to reduce dangerous lows; everything else is optimised inside that. Stating the order means the agent says so out loud when goals conflict instead of picking one on its own.
• The line it does not cross. Step four.
• A tiered knowledge base. Sources it defers to, frameworks worth borrowing, and your own data and preferences as the highest tier. If your preference differs from the textbook default, yours wins, and the agent notes it so the rejected option is not suggested again.
• When to reach out and when to stay silent. Reach out when something is worth acting on; if nothing is, say nothing.
• Communication style with a right and a wrong example. One concrete pair teaches more than a paragraph of adjectives.
• Output discipline. You only see the finished message. No narration, no tool calls, no “here is what I am doing”.

Limits work best as a pattern rather than a list of forbidden tools: research, shortlist, draft, and prepare on its own; book, pay, confirm, send, or sign only after your yes in that moment. The pattern covers situations you did not think of.

Add the domain-specific lines: no medical, legal, or financial advice; questions for the professional get surfaced, not answered. Then add where sensitive data may and may not go.

Where a limit has to hold every time, write it as a protocol the agent must follow step by step, in its own file, and refer to it from the identity file. A health agent helping with insulin, for example, follows a fixed checklist (current reading and trend first, show the arithmetic, the pump’s calculator is the reference, log every suggestion) rather than a general instruction to be careful.

Most runtimes expect the identity file in their own folder. Keep the real copy in the agent’s vault folder instead, and link it into the runtime’s location (on a Unix machine, a symbolic link). Two things follow.

You can edit the agent’s identity from your notes app on any device, and the change is live the next time the agent loads. And the identity is not locked into one product’s file layout: if you change runtimes, the file moves with you.

The agent should be where you already are. Connecting it to the chat app you use every day turns it from a tool you open into an assistant you text. That is also where it reaches you when something matters.

Give it an email address of its own. Then it can email you and your partner a shortlist, send calendar invites, receive work you forward to it, and sign up for research newsletters without any of that landing in your inbox. Put the address’s outbound mail behind your approval until it has earned otherwise.

When you send the agent a note, a link, or a fact, it should infer the right place in the vault and file it there, asking only when the destination is genuinely ambiguous. No inbox and no holding folder: capture-then-sort only works if the sort happens, and it does not.

Tell it to record the fact and not the interpretation. The model that captures a note is usually cheaper than the one that will reason over it later, and a guess written down at capture time reads as settled fact a month on. Classifying (which folder, which person, which topic) is its job; explaining why it matters is not.

Every note it creates gets its metadata from the agent at creation time, in the same format you use. Fixing metadata in a later cleanup pass always loses to a script writing one untagged note a day.

Scheduled jobs are where the agent earns its keep: a morning briefing, a rental watch, a medication reminder, a weekly sweep. Add them one at a time, and give each a job card so you can see at a glance what runs, when, on which model, and where the result goes.

Two delivery rules keep routines from becoming noise. Deliver only when there is something new; a watch that found nothing says nothing, and a check that found nothing writes no log file. And deduplicate: a routine that looks for new things keeps a seen-list file and reports only what is not already on it.

Keep every job card in one reference note, with a status. A job that stops earning its place is paused and recorded as paused, not deleted.

When the agent does something you did not want, resist fixing the output. Fix the rule in the identity file or the ownership note, and record the correction as a dated entry with the reason: what changed, on what date, at your request, and why. Reasons generalise to situations you did not anticipate; bare rules get pattern-matched.

Examples of the kind of entry that earns its place: “no log file for a check that found nothing”; “this field is factual, from the export, never a guess”; “any script that references a folder that no longer exists is a bug: tell me rather than running it”.

Any correction you find yourself giving twice becomes an entry.

Once there are two or three agents and a handful of routines, nobody can hold the picture in their head. Have one script regenerate a simple dashboard every day: which agents exist, where each identity file lives, which jobs run on which schedule, which pipelines write where. Secrets and raw credentials stay out of it.

Add a daily sweep of the vault that looks for drift (stale files, missing metadata, broken links) and reports only when it finds some. And once a week, look at the dashboard and ask of each routine: did it run, was the output correct or merely present, and would you notice if it disappeared? Pause what fails the last question.