# I Was Paying an AI to Reread My Stack Traces, So I Built oowl

> Thirty prompts into a feature, I noticed my AI coding agent was rereading my old stack traces and abandoned plans on every request. I built oowl, a workflow layer for OpenCode, so each role gets only the files and notes its job needs.

- Date: 2026-06-08
- Tags: showdev, opensource, ai, tooling
- Also on dev.to: [https://dev.to/jimzandueta/i-realized-i-was-paying-an-ai-to-reread-my-stack-traces-and-what-i-did-to-fix-that-5d59](https://dev.to/jimzandueta/i-realized-i-was-paying-an-ai-to-reread-my-stack-traces-and-what-i-did-to-fix-that-5d59)

I was thirty prompts into building a new feature when I noticed my AI coding agent was rereading my own stack traces on every request. It also kept rereading my abandoned plans, the package docs I had pasted in, and assumptions from an hour earlier. The agent was still writing useful code, but I was paying for that whole history on every call. No API invoice has a line item for stale context. I felt it when a small UI tweak took way too long, and when the agent reasoned from information that was no longer true.

My sessions started clean, with one request, a couple of files and clear constraints. As the chat went on, pasted errors sat next to guesses about the architecture, and old corrections sat next to new instructions. Partial plans stayed in the window long after the task had changed. By the time I asked for a small frontend change, the agent could still be carrying my database migration history into the prompt.

I was also using one general agent for everything. Architecture, implementation, review, security and debugging all happened in the same chat, so it all landed in the same context window, whether the current task needed it or not.

## How oowl splits the work

I wanted each concern kept separate, so I built oowl. It's a workflow layer for OpenCode that turns one long chat into roles that hand work to each other through scoped artifacts, the files each step leaves behind. I chose OpenCode because a main agent there can start sub-agents while it works, and give each one its own prompt and its own model. That was what I needed to build artifacts, approval gates, file locks and a separate review phase.

A request goes through these steps.

```text
request
  -> dispatcher
  -> architect writes design.md
  -> user approval
  -> planner writes implementation.md
  -> user approval
  -> builder schedules locked tasks
  -> implementation agents execute
  -> reviewer writes review.md
```

Each step leaves a record behind:

- `design.md` holds the architecture before any code changes.
- `implementation.md` holds the work breakdown.
- The file locks say which files each task may change.
- `review.md` holds the final check.

The next agent gets the artifact and the files for its own job, not the whole transcript. The database agent, for example, reads the schema context and migration notes. The dispatcher decides whether a request fits one implementer or needs the full design, plan, build and review flow. For the full flow, I approve the design and the plan before any building starts, and a separate reviewer checks the result.

Because each role has a narrow job, each one can also run on its own model. Cheap models route, schedule and handle low-risk edits. Balanced models plan, build and review normal work. I keep premium models for architecture escalation and security review. A standard profile looks something like this.

| Agent | Model | Tier |
| :--- | :--- | :--- |
| dispatcher | deepseek-v4-flash | cheap |
| builder | deepseek-v4-flash | cheap |
| low-engineer | deepseek-v4-flash | cheap |
| architect | minimax-m2.7 | balanced |
| planner | minimax-m2.7 | balanced |
| frontend-engineer | minimax-m2.7 | balanced |
| backend-engineer | minimax-m2.7 | balanced |
| reviewer | minimax-m2.7 | balanced |
| database-engineer | deepseek-v4-pro | balanced |
| high-architect | qwen3.7-max | premium |
| security-auditor | glm-5.1 | premium |

## Installing it

Installing oowl adds the OpenCode agent framework to your project. From your project root, run this.

```bash
npx @jimzandueta/oowl install

opencode
```

![Terminal output from installing oowl with npx][install]

*The install writes the agents, commands, prompts, model profiles, runtime config and workflow instructions into the project.*

I also added an optional `oowl init` command. It reads the shape of your project and recommends extra skills for each agent, and you can approve, edit or skip each one.

```bash
oowl init
```

![Terminal output from the optional oowl init setup][init]

*Here init read a one-line description of a TypeScript CLI, recommended 23 optional skills across 9 agents, and the run skipped them.*

Right now oowl only works with OpenCode. My next goal is to make the same workflow work in Codex and Claude Code.

![The oowl owl logo][logo]

---

* **Docs:** [jimzandueta.github.io/oowl/docs/](https://jimzandueta.github.io/oowl/docs/)
* **GitHub:** [github.com/jimzandueta/oowl](https://github.com/jimzandueta/oowl)


[install]: /blog/i-realized-i-was-paying-an-ai-to-reread-my-stack-traces-and-what-i-did-to-fix-that/1.png "Installing oowl with npx"
[init]: /blog/i-realized-i-was-paying-an-ai-to-reread-my-stack-traces-and-what-i-did-to-fix-that/2.png "Optional oowl init setup"
[logo]: /blog/i-realized-i-was-paying-an-ai-to-reread-my-stack-traces-and-what-i-did-to-fix-that/3.png "oowl logo"