Agent-Native Reporting: The Self-Writing Week

Before

Status reporting is a standing tax

A real chunk of every week went to describing work instead of doing it. I paid in hours; my manager paid in stale snapshots.

The IC loses hours to non-output work. My week is scattered across Slack, email, Lark, docs, CRM, and ad platforms. Writing the update and keeping a tracker in sync is overhead that competes with the actual work.
The manager flies on stale, shallow snapshots. Many people, whatever each had time to write, risks surfacing late. Granular detail costs a meeting.
Every clarification is a human round-trip. Manager asks, I context-switch, dig, reply, they ask the follow-up. One real question can cost two rounds and a day.

The operating model

Four layers, from my weekly report to a self-evolving loop

Layer 1 turns my week into two records, a status one and a drill-down one. Layer 2 reads both of those across the team and maps the dependencies. Layer 3 lets the agents talk to each other directly. Layer 4 packages the whole thing as skills. I designed it from both seats, the IC's and the manager's: Layer 2 is my manager's build, Layers 1, 3 and 4 are mine, and each one carries its own status.

Layer 1 · IC weekly report

Nine channels in, two records out

Every surface I actually work in is wired to the agent by whatever connection that surface supports: MCP servers, CLIs, direct APIs, and native integrations. Gmail, Lark, Slack, HubSpot, Google Cloud, Google Ads, Ahrefs, LinkedIn via Zernio, and Apollo all report in, and a large share of my real progress lives only inside Claude Code conversations, so the compile also retrieves that week's agent-chat history across sessions and folds it in.

The agent runs this with a configured skill set, and its job description is program manager. It ties the week's raw activity back to the projects already in flight, tracks each one on a sprint rhythm, and watches deliverables and progress per project rather than per message. What it writes out is two records, deliberately. The first is status and progress: where every project stands, what shipped, what slipped. The second drills all the way down into the specifics of each piece of work, and that one accumulates into a personal knowledge base.

The status record is what a reader scans; the drill-down record is what an agent queries. Layers 2 and 3 both depend on the second one existing

IC weekly reportnine channels plus agent historybuilt · running

✓MCP · CLI · API · native integrations

✓Gmail · Lark · Slack · HubSpot · Google Cloud

✓Google Ads · Ahrefs · LinkedIn · Apollo

✓+ the week's Claude Code conversations

Record 1status & progress

Record 2drill-down knowledge base

Layer 2 · Manager consolidation

The manager's agent reads both records, then maps the dependencies

This layer is live, and the build credit is my manager's. Their agent is pointed straight at the two records Layer 1 produces, so it takes every project's status from the first and reaches into the second when it needs the underlying detail. Each IC publishes in whatever channel they choose (a Vercel report, a plain log doc, a Google Sheet), and the agent retrieves from each registered channel and reasons across the whole team. DeepSeek handles bulk summarization; ChatGPT and Claude Code do the reasoning.

Because the team's projects depend on each other, the agent is configured to draw those dependencies as links rather than read each report in isolation. From there it judges on its own whether a dependency is at risk and how each project is actually tracking, and it raises the flag before anyone asks.

My part here is the operating model it runs inside; the implementation is theirs. Worth stating plainly

Team consolidationread both records → link → judge risklive · manager's build

Inputstatus record + drill-down

Publishany registered channel

SummarizeDeepSeek

ReasonChatGPT · Claude Code

Linkcross-project dependencies

Flagrisk, unprompted

What Layer 2 changed

The weekly meeting stopped being a reading of updates

Most of a manager's week goes into collecting status and most of a weekly meeting goes into hearing it recited. The agent has already done both by the time anyone sits down, so the meeting opens on the things a meeting is for: the challenges, where to move resources, what to adjust, and the problems that need a decision. That is the efficiency argument, and it is the smaller of the two.

The bigger one is transparency. Everyone's work is visible to everyone else in the same shape, on the same cadence, at the same level of detail, which also makes it honest. A project cannot be quietly behind when its status and its underlying detail are both published every week. That property is what makes the next layer possible, because an agent can only answer for work that was written down in the first place.

Same shape, same cadence, same depth, for the IC and the manager both

The meeting, before and afterwhat the agenda holds nowthe payoff

Status collectionagent, before the meeting

Update recitaloff the agenda

✓Challenges and blockers

✓Resource allocation

✓Adjustments and decisions

Layer 3 · Agent-to-agent

Agents notify each other, and answer each other

Once every person's work is transparent and every person's agent holds their own mini knowledge base, the agents can deal with each other directly. When my agent finishes something another project depends on, it pushes that straight to the dependent party's agent as a notification, so the handoff happens without me writing the message. In the other direction, a question about my work goes to my agent first: the asker's agent queries it, or my agent goes and finds the answer in the local sources. Either way the Slack ping never needs to be sent.

The manager's agent uses the same path. When it needs more than the status record holds, it queries my agent, which can answer because it already has the local, granular access from Layer 1. A clarification that used to be a manager-to-IC-to-manager thread resolves in one hop. I am piloting this now as the Answer Desk: a SOURCES map over my local channels, a runbook, and a shared Lark channel where a reviewer's agent asks and mine answers.

Only the genuinely hard problems escalate to the two humans

Answer Deskagent ↔ agent, one hoppiloting

Pushdependency done → their agent

Pulltheir agent asks mine

Channelshared Lark group

MapSOURCES over local channels

Loopread → research → review → reply

Escalatehard problems only

Layer 4 · Skill + loop

Skills split by role: manager skills, IC skills

As I run this, the repeatable pieces get packaged into skills, and the skills are written per role because the two seats need different functions. The manager set covers consolidating across people, linking dependencies, and judging risk. The IC set covers pulling a week from the channels, keeping the two records, and answering questions against them. Someone in either seat installs their set and the operating model comes with it.

The skills then go into a loop so the system can self-evolve. A task I used to do step by step is now done by several agents collaborating, each with its own system prompt, context, and skill. By my own estimate the machinery handles ~85% of the work. That figure is an estimate I have not formally measured.

The engine is my Capstone: reusable multi-agent teams plus a reward-hacking-aware meta-optimizer

Skill setstwo seats, two libraries, one loopgeneralizing

Manager skillsconsolidate · link · flag risk

IC skillspull week · keep records · answer

✓Skills composed in a self-evolving loop

✓Several agents per task, own context

✓Engine: the Capstone meta-optimizer

Decisions I'd make again

Calls I made along the way

01 The report is compiled from source

The agent reads the primary sources directly, so the report carries more granular detail than a person would ever hand-type. Writing status by hand caps honesty at whatever you remember on Friday.

02 Agent chats are a primary source

Much of my real progress now happens inside Claude Code conversations and nowhere else. If the compile skipped them, the report would miss the actual work.

03 Publishing is channel-agnostic on purpose

Vercel page, log doc, Google Sheet. You register your channel and the manager's agent comes to you. Nobody migrates tools to join the model.

04 Transparency runs both ways

The manager's work is visible to the ICs too. Mutual visibility reads as shared context and trust, and it makes everyone's reporting more honest. One-way visibility would just be surveillance.

05 The check-in ritual goes away

The agent checks progress continuously, so standing weekly and daily check-ins get replaced. Humans meet for real problems, strategy, and the calls that need a human review.

06 Knowledge survives turnover

Work is captured continuously as retrievable skills, processes, and logs. A departure no longer takes the institutional memory with it.

Status

What's real today

The model is proven where I've run it and piloting where I haven't.

The numbers I don't have

What I'm not claiming: hard before/after time-saved numbers. The lift is real but I haven't formally measured it yet, and I'd rather leave the cell blank than invent a figure. The ~85% in Layer 4 is my own estimate, labeled as one.

Reusability

The channel map, weekly compile, answer-desk, and skill packaging are built as a transferable unit. The model is packaged to be lifted into another org or another IC's setup.