The Agency Owner's Meeting Lifecycle: From Prep to Follow-Through on Fifteen Calls a Week

The operator

An agency owner running eight active client accounts with a five-person team has a calendar that looks like an airport departures board. Fifteen or more calls per week — status reviews, creative briefs, quarterly planning sessions, new-business conversations — each one requiring preparation that is different in kind and often different in depth. The team delivers the work; the owner is on almost every client-facing call, and is the person whose job it is to know the history, hold the relationship, and make decisions in the room.

The team uses a mix of Gmail, Slack, and shared Google Drive folders for client communication and deliverable management. There are five people generating threads, decisions, and commitments across those eight relationships every day. The owner is not on every thread. They are on every call. The gap between those two facts is where things go wrong.

The breaking point

Walking into a client call unprepared is not an abstract risk; it is a weekly occurrence. Not dramatically unprepared — the owner knows who the client is, what the project is, roughly what stage things are at. But the specific kind of prepared that actually matters — knowing what was decided two weeks ago, knowing which open item the client is going to ask about, knowing that there is a team member who is three days overdue on a deliverable that will come up in the first five minutes — that requires a prep session that rarely happens. Fifteen calls a week does not leave room for fifteen prep sessions.

The follow-up problem is the mirror image of the prep problem. After the call ends, the owner has a mental list of what was decided and what was committed to. That list starts evaporating immediately. The owner is often walking into the next call before they have a chance to write anything down. By end of day, two or three commitments from earlier calls have no trace in any system. The team does not know they exist. The clients remember them; the agency does not.

The result is a meeting lifecycle with two broken ends: the prep end, where the owner arrives with an incomplete picture, and the follow-through end, where commitments made in the room never make it onto a task board or into a client recap. The middle — the actual conversation — is fine. The infrastructure around it is not.

The setup

The agency owner connects their Gmail and the shared Google Calendar their team uses for client scheduling. They connect Google Drive, where the team keeps client briefs, creative assets, and status documents. Each of the eight clients gets its own organisation in Lodestar, with projects inside each one that map to the active engagements: a brand refresh project here, a paid media retainer there, a website build elsewhere.

The five team members are added to the relevant organisations and projects so their email threads and action items flow into the shared picture. The agency owner now has visibility into commitments their team made in threads they were never on — extracted by Lodestar, linked to the source quote, surfaced in the project view. They do not read every email; they see the extracted signal from all of them.

The workflow

The meeting lifecycle runs in two phases. The prep phase happens before the call — ideally a few minutes before, which is all the time available. The follow-through phase happens immediately after. Both are handled through a conversation with Claude via the Lodestar MCP, without opening any other application.

• ·Before — The owner asks Claude to prep them for the next call, naming the client. Claude calls `calendar_retrieve` to confirm the meeting details and attendees, then `emails_content` on the last two weeks of threads with those attendees.
• ·Before — Claude calls `knowledge_search` to surface relevant Drive documents: the current project brief, the last status deck, any outstanding proposals. It calls `contacts_retrieve` and `knowledge_org_charts` to confirm who is in the room — including any new stakeholders who have appeared in recent threads.
• ·Before — Claude calls `action_items_list` scoped to open items on that client's projects, flagging any that are overdue or were committed to by the owner personally. The prep brief comes back: meeting agenda context, last decisions, open items likely to come up, who is attending and their recent communication tone.
• ·Before — The owner reads the brief. It is one page. They walk into the call knowing exactly what the client is likely to raise, what the team still owes them, and what was decided the last time they met.
• ·After — The owner types their notes from the call into the same Claude conversation — decisions made, deliverables committed, who owns what, any dates mentioned. Claude extracts structured action items from the raw notes.
• ·After — Claude calls `action_items_create` for each commitment, assigning each to the right project in Lodestar. Where a team member was named as the owner, the item is assigned to them. Where a due date was stated, it is set. Claude calls `milestones_partial_update` if any milestone was affected by the call's decisions.
• ·After — Claude calls `timeline_events_create` to log the meeting itself against the client's project timeline. It then calls `emails_reply_link` to draft the post-call recap for the client: a clean summary of what was decided and what is coming next, ready for the owner to review and send.
• ·After — The owner reads the recap draft, makes any adjustments, and clicks send. The loop is closed: the client has a written record, the team has their assignments in Lodestar, and the project timeline reflects the meeting.

What changes

The prep problem is solved at the point where it was actually impractical to solve before — a few minutes before the call, on a busy calendar. The owner no longer needs a dedicated prep block for each meeting because the brief assembles itself from the live data in Lodestar. It is not a perfect deep-dive; it is a reliably accurate one-page that covers what actually comes up in the first ten minutes of a client call.

Commitments stop evaporating. The owner's post-call notes, however brief, become structured action items within minutes of the call ending. Team members see their assignments in Lodestar without needing a Slack message from the owner. Clients receive a recap email that was drafted from the real conversation record rather than reconstructed from a fading memory.

The team's shared picture of client status stays current. Because action items are extracted from threads as well as from calls, team members who generated commitments in email threads the owner was not on are still visible in the client's project. The owner can see the full state of each engagement before any call without asking the team to brief them.