I did not set out to build another project-management tool. I already have Jira. I already have a calendar. I already have chat threads, recaps, and more Markdown than is polite.
What I did not have was a place where that material stayed useful after the day ended.
The last few years of working with coding agents made the gap obvious. An agent can only help with what it can see. If the day's context lives in a terminal, a meeting chat, a half-finished ticket comment, and my head, the next session starts from scratch. Prompts get longer. Memory gets worse. Status reporting turns into archaeology.
So I started treating the document library as an operating layer: Markdown that humans still want to read, structured enough that an agent can plan a day, write an agenda, close out the evening, and roll a week into something a manager can use. That experiment is the subject of the eight posts that follow. This page is the reason I am turning it into a product.
The job I actually have
A large part of my work is not writing code. It is keeping work connected after it leaves a meeting, a ticket, or a 1:1.
That includes delivery: what moved, what is blocked, what Jira says versus what actually happened. It also includes people. I accumulate notes from one-on-ones, performance reviews, and every other kind of feedback with an employee. Those notes should not live in a private notebook that I have to reconstruct twice a year. They should land in action trackers, stay attached to the person and the work, and show up in the reports I need when I need them.
Manage is for that whole surface. The document system described in this series is the delivery half. The people half is the same idea applied to the manager's other job: remember what was said, what was asked, what was promised, and what still needs a follow-up.
What Manage is for
Manage is an agent-readable workbench for managing delivery and people.
It should:
- Capture messy inputs from the day — tickets, meetings, chats, notes, calendar, pull requests.
- Turn them into purpose-built outputs — daily agendas, blocker reports, weekly reviews, monthly narratives.
- Keep people context in the same loop — 1:1 notes, review evidence, feedback, and commitments.
- Put follow-ups in action trackers instead of hoping someone retypes them into five systems.
- Report from the trackers when a meeting, a review cycle, or a stakeholder asks.
The product is not a prettier notebook. It is a closed loop. Meetings create actions. Actions become tickets or tasks. Tickets shape the next agenda. The day becomes a summary. The summaries become weekly and monthly reporting. One-on-ones and reviews feed the same trackers so people work does not fall out of the operating picture.
Why a product, not just my repo
The library I have today is Markdown, MkDocs, Git, Jira, Microsoft Graph, and a set of scripts. It works because I designed the contracts. That is also why it does not travel.
A teammate should not have to clone my folder structure to get a daily operating brief. A manager should not have to invent their own closeout command to keep 1:1 notes from disappearing. Agents should not need a private dialect of my repo to be useful on Monday morning.
Manage is the version of that system other people can sit down in. Same design principle: every automation leaves a receipt. Same bias toward inspectable files and visible follow-through. Less of my personal wiring.
How to read the series
The eight posts after this one walk through the operating system as I use it now. They are the intent document for Manage, written from the inside of the work.
- The document library as an agent operating system
- QUITTING TIME!!! and the end-of-day closeout
- From meetings to Jira to reports
- Inputs and outputs
- The daily agenda as an operating brief
- The daily blocker report as project triage
- Weekly summaries for meetings and management
- The monthly strategic narrative
If you only read one after this wrapper, read the first and the third. The first is the premise. The third is the loop. The rest are the rooms.
Manage is in design on jasonkoch.io. There is no public host yet. The writing is the spec I am building against.