Systemize Corrections

When an agent makes a mistake in my studio, I don't just correct the output; I codify the correction into the project's long-term memory, typically in a `CLAUDE.md` file or a dedicated feedback memory, to prevent recurrence.

What it is

Systemize Corrections is the practice of transforming ad-hoc agent feedback into structured, retrievable instructions. This means if a Claude Code agent generates an incorrect `package.json` dependency or if a Gemini-powered research agent misinterprets a data point for Total Formula 1, I don't merely edit the output and move on. Instead, I capture the specific error, the desired correction, and the context in a format the agent can reference in future runs. This often lives as a markdown file (`CLAUDE.md` or `GEMINI.md`) within the project's monorepo, or as a dedicated entry in a vector database serving as the agent's long-term memory. The goal is to ensure that the agent, or any agent operating on that project, learns from the mistake permanently.

Why I do it this way

I learned the hard way that re-correcting the same agent error is a significant time sink. In a Solo-Founder Portfolio setup, where I operate multiple brands like Pregnancy Power Hour and Inky, efficiency is not optional. Every minute spent on repetitive tasks is a minute not spent building new features or shipping products. This approach ensures that my agentic engineering workflow is cumulative. Each correction builds on the last, improving the agent's performance over time without requiring constant human intervention for known issues. It reduces cognitive load and allows me to focus on higher-leverage architectural decisions rather than debugging the same trivial mistakes. It also directly supports Building in Public by providing a clear, auditable trail of how the agents are being refined.

How it works in practice

For code generation, if Claude Code introduces a specific bug pattern related to Vercel deployments, I'll add a section to `CLAUDE.md` like: "Constraint: When deploying to Vercel, ensure `next.config.js` includes `output: 'standalone'` for serverless functions. Reason: Prevents build failures on specific Next.js versions." Before any new code generation task, the agent is instructed to read `CLAUDE.md` for project-specific constraints. For research agents, like the one I use for content generation on Pregnancy Power Hour, if it consistently misattributes a source or misinterprets a medical term, I'll add a memory entry: "Correction: 'X' term refers to 'Y' condition, not 'Z'. Prioritize sources from A, B, C domains." This becomes part of its prompt context for subsequent research tasks. This system is critical for maintaining consistency across products, especially in domains requiring Deep Domains, Not Wide Network expertise.

Where this breaks down

This system relies on the operator accurately identifying the root cause of an agent's error and formulating a clear, unambiguous correction. If the correction is too broad, the agent might over-correct, leading to new, unforeseen issues. If it's too narrow, it might only solve a specific instance of the problem, failing to generalize. There's also the risk of memory bloat; if `CLAUDE.md` becomes excessively long, it can consume too much context window, or lead to agents ignoring parts of it. I manage this by periodically reviewing and refactoring the correction documents, consolidating redundant entries, and ensuring each instruction remains concise and actionable. This requires discipline, as the system's effectiveness is directly tied to the quality of the human-authored feedback.