After months of using agents every day, I noticed that I kept starting with the same speech.
Read the project docs. Check the roadmap. Do not overwrite unrelated work. Use the current commands. Run the relevant tests. Capture evidence. Escalate the decisions that actually need me.
The wording changed, but the shape did not. I was already using agents across product work, implementation, research, testing, and UI review. The question was no longer whether they could be useful. The problem was that every new session still began with me rebuilding the same working context by hand.
Miss a verification step and the work might stop at a summary instead of producing evidence. Leave the scope fuzzy and an agent could build a reasonable version of the wrong thing. The agent was following the instructions it received. The important process just lived in my head and in a block of text I had to remember to paste.
That stopped feeling like a prompting problem.
It started feeling like a software problem.
I wrote the process down
In March, before I had formalized a skill library or started building loops, I began writing down how I wanted work to move from an idea to a release. I called the files process docs. In plain English, they were a development playbook stored with the project: how to clarify the problem, design the behavior, break the work down, implement it, verify it, and decide whether it was ready to ship.
I was not adapting a formal methodology. Review had exposed a systems problem: "done" could mean something different at the beginning and end of a build. The agents could write the code. The inconsistency came from important product and quality decisions being left inside individual conversations.
So I started forcing those decisions into the open before implementation began.
What problem are we solving? What is in scope? What should the user be able to do when this phase is complete? Which edge cases matter? What needs to be tested? What proof should exist before the work moves forward?
Those answers became the design and then the task graph. A task graph is a work plan that shows each task, what it depends on, and the pass-or-fail conditions for completing it. A task was not done because code existed. It was done when its acceptance criteria passed. A phase did not advance because every box had been checked. It advanced after the pieces worked together.
The next revision made the verification chain explicit. Unit and contract tests checked individual requirements. Integration tests checked whether a phase worked as a system. End-to-end scenarios and human review checked whether the user could complete the workflow the design had promised.
In current AI terminology, that was already an evaluation layer. The task graph was not the evaluation itself. It was the verification plan: what had to be true, where it should be checked, and what proof would close the gate. The tests and reviews produced that proof.
The playbook did not replace engineering judgment. It made that judgment durable.
Vague builds became easier to spot, unsupported claims of completion became harder to make, and the quality bar no longer disappeared when a conversation ended or a different agent picked up the work.
The first layer of infrastructure was not automation.
It was shared clarity.
The repeated prompt was still a signal
Writing down the development process also made the repeated procedures easier to see. The same questions kept coming back. How should an agent start and verify this app? What should a frontend review inspect beyond whether the page renders? How should a research pass record sources and dates?
Each was a recognizable kind of work with a repeatable method. That eventually led me to skills.
The open Agent Skills standard describes a portable folder of instructions and supporting resources that an agent loads when a task matches. Claude Code's skills documentation gives a useful rule of thumb: create one when the same procedure keeps getting pasted into chat.
That matched what I was seeing. A repeated prompt was an uncaptured procedure. A skill put its instructions, scripts, examples, and success criteria in one maintained place. It also forced useful questions: What should trigger it? What can vary? Which decisions are safe for the agent to make? Who keeps it current?
A saved prompt preserves words. A skill preserves a reusable way of working.
The development playbook and skills still solved different problems. The playbook explained why the work existed, what outcome mattered, and what counted as done. A skill helped an agent execute one recurring part consistently. A review skill could improve a review. It could not decide which pull request mattered most or whether that change supported the product goal.
Skills also had to be treated like maintained software. Commands change and assumptions expire. Research into public skills has found both procedures capable of changing system state and persistent prompt-injection risks. Reuse is valuable, but ownership, permissions, and maintenance still matter.
Even a perfectly maintained skill still had a larger limitation. It could tell an agent how to do a task. It could not tell the agent which task mattered.
The project became shared memory
A skill could explain how to review a change, but not which change was blocked. It could launch an app, but it did not know which behavior was under investigation. Those answers needed shared project state, and the repository gradually took on that role.
By repository, I mean the version-controlled workspace where the code, docs, and change history live. Each new artifact appeared because real work exposed missing context.
The onboarding guide explained the product, mission, and working rules. The roadmap recorded priorities. Design docs captured intended behavior and tradeoffs. Task graphs turned a version into dependent, testable steps. Issues carried scoped work between sessions. Pull requests carried the change and the proof needed to review it. A command map kept run and test instructions current.
Git became the durable memory layer. GitHub became the work surface.
The docs were no longer explanations written after the work was over. They were part of how the work operated. An agent could read the project playbook and know what to inspect, produce, verify, and hand off. The next agent did not need the conversation that came before it.
There was another reason to keep this context in the repo: the tools kept changing.
I might use one agent for implementation, another for review, and a browser-capable agent for visual verification. The operating model could not depend on one product's private memory or one long-running conversation.
The harness, whether Codex, Claude Code, or another tool, runs the agent. The project should explain how the work operates.
This is where prompts became infrastructure for me. Most prompts should remain prompts. But recurring, consequential work deserved a durable form: written process for the quality bar, skills for repeated procedures, and project state that another agent could inspect and continue.
Memory did not create motion
The project could now explain the mission, describe the process, preserve decisions, and show what was in flight. But none of those files woke up on their own.
A stale pull request could remain stale. A process failure could be documented without triggering an improvement. A recurring capability review could miss its cadence. The system had memory, but it still depended on a person to notice when that memory should become action.
That is where loops entered the picture. Not as a way to keep agents busy, but as a way to give recurring work a trigger, a clear outcome, a way to check the result, a stopping point, and a human decision when judgment was required.
The next step was making the process active without giving up control.
That is the subject of the final post.