cowpath
Menu
Install
All posts

Start with one recurring task

Pick work you already do, give it a clear name, and check what survives into the next run. You don't need to document your whole team first.

cowpath · · 2 min read

You don't need a process library before trying cowpath. You need one task you're likely to do again, and an idea of what a good result looks like.

A weekly customer update works. So does preparing a discovery deck or writing a support reply. A one-off question usually doesn't: there may never be a next run that benefits from the answer.

Pick something you can recognise next time#

Choose a task with a repeatable shape, even if the input changes.

For a weekly update, the numbers and replies are new every time. The audience, structure and level of detail are often the same. That's enough common ground for a useful playbook.

Keep the name about the work, not the occasion. customer-updates/weekly is easier to reuse than october-17-update. You can organise processes up to three levels deep, but one clear name is enough to begin.

Use the agent you already work with#

For Claude Code or Codex, install the CLI and run cowpath init. The hooks capture the session locally, and a local agent cuts it down to the finished run. The full transcript stays on your machine.

For a chat app, connect the hosted MCP server using the Connector page. The agent makes the calls to start and finish runs. Unlike hooks, that depends on the agent following the tool instructions.

Then do the task as usual. Give the input, read the draft and make the corrections you'd make anyway. If you want to be explicit, tell the agent to use cowpath for this recurring task.

Read the first playbook#

The first finished run seeds the process playbook. Before relying on it, read it.

Does it describe the way to do the task, or does it repeat facts from this one example? Does it keep the correction that mattered? Would another person know what to do with it?

Edit anything that doesn't belong. A customer name or this week's total is usually input for a run, not a rule for every future run.

Come back with fresh input#

The useful test is the second run. Give the agent new material for the same process and see whether it starts from the playbook.

You may still need corrections. The question is whether you're repeating the same ones. After the first run, every fifth finished run prompts the agent to revisit the playbook. You can edit it between those updates too.

Keep the first experiment small enough to judge. One recurring task, two real runs, and a playbook you can read. Add another process when the first one earns its place.

Put the next run on a better path.

Start with one task you already repeat.

Your corrections shouldn't disappear

The useful part of an AI conversation is often the correction. It should become the starting point for the next run, not a line buried in an old chat.