Wes Pomeroy

What Just Replaced Our Status Meetings

Fred, a Senior Digital Merchandiser on my team, had been running a project for weeks. I just caught up on the whole thing. So did his manager. Up to that point, neither of us had been in a sync with him about it. He shared the project at the end of his work day. We each opened it on our own time. The three of us came out fully aligned on the work, and we'd never held a status meeting about it.

The project we shared was a new kind of artifact - a workspace with an agent woven through it. Think of it like a living and growing command center, staffed 24x7 with research assistants who've read every document in the room, sat through every recorded meeting, and remember every conversation. Every time Fred attended a meeting, did research, generated an insight or a solution, got an answer, or sent any email or chat about the project, the command center took it all in. We could ask it questions in plain English, restructure its contents on demand, or have it render its material in different formats. Each cycle of use left it smarter than before.

How it built up

Fred had started by sharing a rough first draft project, intentionally rough, as the seed for a back-and-forth workflow we wanted to test. That first draft project really only had one thing in it: a one-pager he'd put together by extracting the key points from a deck his project team had been iterating on for a few weeks. Fred told his agent to save the project to our team server. I told mine to pull Fred's latest into my workspace. The whole project came over - chats, files, every prior interaction. The project itself was the unit being shared.

With Fred's project in my workspace, I asked my agent to restructure his rough draft into a brief I could work from: scope, decisions made, open questions, owners, status. The new brief joined his original draft in the project. Both stayed accessible. His original was still part of the project's working memory, available alongside everything else. I told my agent to save the updated project state back to our team server.

Fred was back up. There was a working session with his collaborators on the calendar, an hour-long meeting. They recorded and transcribed it, and Fred dropped the transcript into the project alongside the now-restructured "Project Brief" that I had evolved from his original first-pass status report.

He asked his agent to take a look at the transcript from that meeting and update that Project Brief. Then things got awesome. And weird.

What happened next

So again: Fred dropped an hour-long meeting transcript - the full recording of his collaborators' working session, every word - into the project, and asked his agent to update the brief from what was said.

The brief updated itself.

Open questions I'd left in there got answered from things people had said in the meeting. New tasks appeared with owners attached. Decisions the team had made on the call landed where they belonged in the document. Some of it needed his hand on the wheel - a revision he wanted phrased differently, context I didn't have, a formatting call - but most of the work happened from the transcript reading itself into place.

The transcript stayed in the project. So did everything else: his original draft, the source deck, my brief, the updated post-meeting brief, and now the meeting itself. Each cycle added to a substrate that grew richer.

So when the project came back to me, I had a current brief. I also had the meeting itself, available to query in plain English. Did anyone push back on the timeline? How did the team land on that owner for the integration work? Was there friction on the messaging direction? I asked the workspace, and the workspace answered, the way a colleague who'd been in the meeting would answer if I asked them, on my own schedule, without sitting through a recording, without making him write up notes he hadn't taken.

Fred's total work for that meeting: participate, record, drop the transcript in. Note-taking, write-up, formatting, status reporting all happened from those three moves.

Back with me, the brief had outgrown a one-pager. I described how I wanted it organized as a multi-page hub: an overview, a spec, a roadmap, a team page, a resources page, a Discussions area for open questions, a task list with due dates and owner placeholders. The project rebuilt itself from the description. The whole exercise took minutes, and I didn't have to draft anything or negotiate the change. Fred could revert anything he didn't like or layer ten more changes on top.

Where it landed

By the end of the day, Fred had told his agent to publish what had become a whole mini web site for his project, up to our group's web server. The hub now carried everything that had built up over our cycles: his original draft, the deck his team had been working from, the meeting transcript, the brief I'd structured, and the page-level organization I'd added on top.

His manager can also pull the project down to her own workspace. She can ask it questions in plain English. She can have it generate her a podcast-style audio briefing she listens to on her commute home. She can pull a section out and send it to a peer who needs to weigh in on one slice. Same source, different formats, all on her schedule.

What this gives a manager

1. Status reports stop being a deliverable. Stakeholders pull what they need at whatever level of detail they need it. The producer stops having to figure out who needs to know what.

2. Pre-meeting prep collapses. Instead of reading a long pre-read, you ask the workspace what you need to know for the meeting. Calibrated to you, calibrated to the meeting.

3. Ask questions inside the project. You can ask in writing. The other person answers when they're ready. The answer carries context. Your meeting calendar shrinks, because most of what you scheduled meetings to ask is now askable in writing.

4. Visibility two levels down, no meeting required. I can read what someone on my team's team is working on without going through their manager and without asking everyone to write me an update.

5. Reorganization is free and reversible. Want it organized differently? Just do it. Reverting is one click. The cost of reorganizing the artifact drops to zero.

6. Every claim traces back to its source. The transcript is right there. The deck is right there. The "where did this number come from" question always has an answer.

7. Institutional memory survives turnover. When the project lead eventually rolls off, the workspace still knows everything they knew. The next person comes up to speed by reading the workspace itself.

8. Drafting and formatting collapse into one move. The formatted artifact is what you build from the start. The "now make it look right" phase falls away.

9. Readers add no overhead. Two stakeholders or twenty, the support work is the same.

What this opens up

The calendar is the first thing that changes. Status reviews, catch-ups, alignment syncs - those meetings drop away. What's left are working sessions: hard tradeoffs, creative debate, decisions that need everyone in the room. Fewer meetings, and each one earns its place.

For Fred, the saved hours go into the actual work. More scope on the project, because the maintenance cost dropped. More depth on the questions that matter. Higher quality, since his attention isn't splitting between doing the work and packaging it for stakeholders. Less risk, because nothing falls between cracks: the substrate carries everything that happened in the project. And the path from idea to delivery shortens, since the coordination overhead between cycles isn't there.

And less of the work that grinds people down - the post-meeting writeup, the formatting hour, the "let me consolidate for leadership" Friday afternoon. The work that's left is the work he wanted to be doing.

What this requires

Not every team has the tools for this yet. The pieces that have to be in place:

  • Memory across sessions. The workspace remembers everything that's happened in it - chats, files, transcripts. Nothing has to be re-explained from scratch.
  • Sharing between people. I can pull the project down with all his prior context intact. He can pull it back with everything I added. The whole working state is shareable.
  • Integrating each other's changes. When two people work on the same project across cycles, new material weaves into what's already there. Additions integrate, old material stays accessible.
  • Publishing to a shared space. When the project is ready for an audience, it can be published to a URL anyone can access without each person needing their own working copy.
  • Plain-English everything. Asking questions, restructuring, requesting different formats - all in natural language. No technical fluency required to participate.

This used to take a dedicated program manager, a polished documentation system, and religious note-taking discipline. The good versions of those still help where they exist. Where the tools above are in place, the entry cost dropped through the floor. The work that used to happen in the gaps between meetings - the alignment, the context-passing, the catching-up - now happens in the project itself, available to anyone who needs it, on their own schedule.

I've been writing about how AI is going to change the way we work. This week I watched it happen, with my own team, in a real project, with real stakes. This is a very new way of working - and we're already inside it.

Generic example of the type of thing we evolved:

Project hub, Overview tab: the project goal, context, business requirements and constraints

Project hub, Spec tab: the four visitor variants and what each one gets

Project hub, Roadmap tab

Project hub, Team tab: stakeholders, their roles, and the project timeline

Project hub, Resources tab

More on this topic

All 9 pieces on this topic →

Wes Pomeroy helps businesses and people get more out of AI. Consulting · Contact · LinkedIn

Contact

wes@wespomeroy.com

LinkedIn