If that sounds familiar, the problem is not your memory. The work simply lives in too many places.

Why results scatter

One AI tool is easy to keep track of. Most of us now use several: a chat assistant for thinking things through, a coding agent such as Codex or Claude Code for the repository, an image tool, a research tool, maybe a scheduled job that runs overnight. Each one has its own history, its own place where output lands and its own idea of what "done" means.

Three things go missing between them:

• The ask. What exactly you requested, with which constraints. Rephrase it later and you get a different result.

• The location. Which tool, which session, which folder or branch.

• The status. Whether it finished, failed quietly or is waiting on you.

Each tool remembers its own part. Nothing remembers the whole, so you end up doing it in your head.

One running log per goal

The habit that fixes most of this is small: keep one running log per goal, not per tool. A goal is something like "get the spring newsletter out" or "fix the import bug", not "chat with the assistant".

Every time you hand something off, add an entry. Every time something comes back, update it. A plain text file, a note or a single shared document all work. Here is a template:

GOAL: Spring newsletter out by Friday

ASKS
- Asked: three subject lines, friendly tone, under 50 characters
  Where: chat assistant, thread "newsletter subjects"
  Status: done
  Result: newsletter-draft.md, top section

- Asked: resize the header image to 1200x600, keep the text legible
  Where: image tool, project "spring"
  Status: running
  Result: -

- Asked: fix the broken unsubscribe link in the template
  Where: coding agent, branch fix/unsubscribe
  Status: done, waiting on review
  Result: change ready on the branch

DECISIONS PENDING
- Pick a subject line: A, B or C?
- Send to the full list: yes or no?

Four fields per ask are enough: what you asked, where it went, its status, and where the result landed. Copy the ask word for word when you can. The exact wording is what lets you run it again, or hand it to a different tool later, and get something comparable.

Review it in two minutes a day

Once a day, open each active log and do three things:

1. Update status. Look at anything marked running. If it finished, write down where the result landed. If it stalled, note why in a few words.

2. Close what is done. Move finished entries to the bottom or strike them through. The top of the log should show only what is still moving.

3. Read the decisions list. This is the part that matters most.

If the review regularly takes longer than two minutes, the log is trying to do too much. Remove fields until it fits.

Decisions are the real queue

Most handed-off work does not need you while it runs. It needs you at specific points: choosing between options, approving something that goes out under your name, signing in to an account, paying for something. Those are the points where work quietly stalls when nobody is looking.

Keep them in their own list at the bottom of each log, written as questions you can answer in one line. "Send to the full list: yes or no?" works. "Newsletter stuff" does not. During the daily review, answer what you can on the spot, and give anything you cannot answer yet a date.

Separating decisions from status changes how the log feels. Status is something you can check whenever you want. Decisions are the short list that actually needs you, and keeping that list short and visible is most of the benefit.

Where Octuo fits

Octuo is a personal assistant for people tired of playing go-between for their AI tools. Say what you want, and each part goes to the agent or tool that does it best, from code to music. The results come back to you. Octuo remembers what you've told it and calls you only when it truly needs you. Payments and the big calls are always yours. It's from the Octuo team at Tutuo, Inc., and runs on the web and Mac.

More on how it works: Octuo.

Did the file actually load?

In Claude Code, use /context to inspect the memory files loaded at launch and /memory to find and open instruction files. A file existing on disk is not enough evidence that it reached the session. Subdirectory CLAUDE.md files load on demand, so their absence from the startup list alone does not prove a fault.

Ask Claude Code to read another file in the relevant subdirectory to exercise that loading path. Then try one small task that requires the rule. Keep the test narrow: for example, ask for a proposed filename and check whether it follows your naming convention before authorizing a larger change.

For Codex, ask it to list the instruction sources it loaded. Its guide recommends restarting in the intended directory when guidance looks stale: the instruction chain is built once per run, usually once per launched terminal session.

Which discovery rules apply to this tool?

Claude Code concatenates discovered CLAUDE.md files into context; they do not mechanically override each other. Its memory guide warns that contradictory instructions may lead it to pick either one. Compare the actual text across relevant files instead of assuming that the nearest file wins.

For AGENTS.md, check Claude Code's documented project-instruction selection and availability conditions. A project-path CLAUDE.md or CLAUDE.local.md can prevent direct AGENTS.md loading under the default selection. The memory guide describes importing AGENTS.md or selecting both file types when both are needed.

Codex has different discovery rules. It reads global guidance, then project files from the root toward the working directory. AGENTS.override.md takes priority over AGENTS.md within a directory; at most one file per directory is included. Guidance closer to the working directory overrides earlier guidance. Empty files are skipped, and combined instructions have a default limit of 32 KiB.

If you use both tools, see using Claude Code and Codex together, then verify each tool's loaded sources separately.

How do I make a loaded rule easier to follow?

Rewrite a vague instruction as an observable requirement. Replace "keep things tidy" with a specific destination for new files. Replace "check the work" with the exact check and the evidence expected in the result. Remove outdated exceptions and contradictory copies before adding another reminder.

Claude Code recommends keeping each CLAUDE.md under 200 lines. That is a writing target, not the same limit as Codex's combined byte cap. Its troubleshooting guide also distinguishes guidance from enforcement: CLAUDE.md supplies context, while permissions and hooks serve enforcement needs. Do not treat a sentence in an instruction file as a technical access boundary.

Our guide to helping an assistant remember what you told it covers the broader habit. For this issue, keep a reproducible example of the missed rule and retest after one change.

Where Octuo fits

Octuo puts coding agents to work for you, no command line needed. Say what you want built or fixed, and the best agent takes the job while the best tools handle design and research. Octuo keeps long jobs moving and comes back when there's progress. Your coding agents run on your own accounts, under each service's terms. Easier and more natural than using Codex or Claude Code directly. The big calls are always yours.

Use the discovery checks above to diagnose the coding tool's own instruction files.

FAQ

Should I repeat the rule in every file? Prefer one clear rule in the appropriate scope. Check existing copies for contradictions before adding another.

Does a longer instruction file help? Not necessarily. Claude Code recommends concise files, and Codex has a combined size cap. Keep essential instructions easy to locate and verify.

What if Codex keeps showing old instructions? Restart it in the intended directory and ask which sources loaded. Inspect overrides and file contents before rewriting the rule itself.

Sources

• Claude Code: Debug your configuration

• Claude Code: How Claude remembers your project

• Codex: Custom instructions with AGENTS.md

The product names above belong to their owners. We have no affiliation with them. Originally published on the Octuo blog.