Built because the tracker was the slowest part

The problem we had

Once an agent is doing most of the implementation, the expensive part of a bug is no longer fixing it. It is getting the agent the context: the screenshot a partner took on their phone, the three chat messages that explain what they expected, and the answer to the one question the agent asks halfway through.

We were copying all of that out of chat threads into terminal prompts, and copying the agent's questions back out to the people who could answer them. The issue tracker sat in the middle, adding forms and fields that nobody wanted to fill in and the agent did not need.

What we changed

We flipped the order. The chat is the source of truth. Issues are a grouping drawn over messages after the fact, by whoever notices that a few of them belong together. The agent is a member of the project with the same read access as everyone else, and it talks in the same stream.

The piece we care most about is the question loop. An agent that can ask a question in the place where the right person is already looking, and continue when the answer arrives, is an agent you can leave running.

Any agent, any team

wakustream connects to coding agents over MCP, so it works with Claude Code and Codex today and with whatever comes next. The agent is just another member of the project: same issues, same thread, same screenshots, scoped to the projects it has a key for.

Where it is

wakustream is in early access. It is used daily by our own team and a small number of partners. The feature set is deliberately narrow and will stay that way: we add things when a real team hits a real wall, not before.

If that matches how you work, tell us about your team.