The Supporting Agents

The Chief of Staff is the visible agent — the one you interact with daily. It delivers the digest at 07:00, answers workplace questions in real time, and surfaces whatever has breached a threshold. It is the face of the agentic office.

The three supporting agents are the ones that keep the system healthy. They run on triggers rather than schedules: a meeting ends, and the Meeting Intelligence Agent proposes a synthesis. A new person is mentioned, and the Memory Keeper proposes an entry. A delegation goes unconfirmed for 24 hours, and the Work Tracker sends a follow-up.

You will not notice these agents most of the time. That is by design. A well-configured agentic office runs quietly in the background — surfacing what matters, maintaining what degrades, and alerting only when attention is genuinely required.

This lesson introduces each of the three supporting agents, shows you how to configure them, and establishes the weekly maintenance cadence that makes the system self-sustaining.

Agent 2: The Memory Keeper

Purpose

Maintain work.local.md as the single source of organisational truth. After every significant interaction — a meeting, a decision, a new person encountered, a new project started, a new term introduced — the Memory Keeper proposes updates to the relevant layer of work.local.md. The key word is proposes: the Memory Keeper never applies changes without your confirmation.

How It Works: Trigger-Based Operation

Trigger	Response
New person mentioned who is not in work.local.md	"I noticed you mentioned [Name] — they're not in workplace memory yet. Want me to add them?"
New project name or codename used	"I noticed you referenced [Project] — I don't have a record of this project. Shall I create a project entry?"
New terminology used	"You used the term '[Term]' — I don't have a definition for this. Want me to add it?"
Meeting completed	Proposes updates to project status, decision log, action log, people entries
Decision made	"You made a decision about [topic]. I'll add this to the decision log. Confirm?"

The Memory Keeper activates on these events without waiting to be asked. Its proposal is specific — it drafts the entry it would add, not just a request for information.

Sample Memory Update Proposal

Here is what a Memory Keeper proposal looks like after Monday's Executive Weekly (17 March 2026):

MEMORY UPDATE PROPOSAL — 17 March 2026
════════════════════════════════════════════════════════════
Based on today's Executive Weekly, I propose these updates to work.local.md:

1. UPDATE: Project Nighthawk status
   Current:  "Facility agreement negotiations stalled"
   Proposed: "Escalation in progress — formal letter by Zia by Wed 19 March"

2. UPDATE: Decision log — add D-003
   "Islamabad expansion deferred; trigger: Nighthawk resolved; Date: 17 March 2026"

3. UPDATE: Delegation log
   "Omar Farooq — Analytics ROI brief — due Monday 24 March"

4. NEW: Action item
   "Nighthawk formal letter — Zia Khan — due Wed 19 March"

Confirm to apply all? (Y/N) or specify which updates to apply.
════════════════════════════════════════════════════════════

Four proposed updates, all from a single 30-minute meeting. The Memory Keeper surfaces what changed and proposes how to record it — you confirm, reject, or modify. This is the difference between a workplace memory that reflects what actually happened and one that gradually diverges from reality.

Weekly Maintenance (Monday 06:30)

Every Monday morning, 15 minutes before the week-ahead brief, the Memory Keeper runs its weekly maintenance check:

Check	Question Asked
Project status currency	"Project [Name] status hasn't been updated since [date]. Still accurate?"
People entry currency	"[Person]'s priorities were last updated [date]. Have their focus areas changed?"
Stale terminology	"The term '[Term]' hasn't appeared in conversations for 90 days. Still in use?"
Orphaned actions	"Action A-[NNN] has been in progress for [N] days. Complete? Re-delegate? Still active?"

The maintenance check runs before the Chief of Staff brief so that the brief is working with current information.

The Propose-Then-Confirm Rule

The Memory Keeper NEVER applies updates to work.local.md without user confirmation. This rule is absolute. An agent that modifies organisational memory autonomously is a liability — wrong context produces wrong outputs from every downstream agent. The confirmation step is the quality gate that keeps the system accurate.

Agent 3: The Meeting Intelligence Agent

Purpose

Provide before/during/after meeting intelligence on autopilot. Reduce meeting preparation overhead to near zero. Ensure every meeting produces a clear record of decisions and actions. Update work.local.md with every decision and status change that emerges.

Calendar-Triggered Prep (30 Minutes Before)

The Meeting Intelligence Agent watches your Google Calendar via MCP. When a significant meeting is 30 minutes away, it activates:

1. Loads meeting details: attendees, agenda (if in calendar notes), duration
2. Loads attendee profiles from work.local.md people layer
3. Loads relevant project context from projects layer
4. Checks the decision log for prior meetings with this group
5. Delivers a prep brief using the before/during/after structure

The brief is delivered to your configured channel before the meeting starts — a standing meeting prep that requires no action from you.

The prep brief quality standard:

• Every agenda item has context (not just a topic label)
• Every named attendee has a stakeholder note
• The decision(s) needed are explicitly stated
• Prior meeting summary is included if this group has met before

Post-Meeting Synthesis (Within 2 Hours)

After the meeting ends, the Meeting Intelligence Agent delivers a structured synthesis:

• Decisions made (named attribution — not "the group decided")
• Actions assigned (with owner, deadline, and confirmation expectation)
• Deferred items (flagged for the next meeting agenda)
• Proposed work.local.md updates (routed through Memory Keeper for confirmation)
• Draft distribution message (to send notes to attendees)

The 2-hour window is deliberate — long enough to allow the meeting to properly end, short enough that the notes are still fresh and actionable.

Weekly Meeting Audit (Friday 17:00)

WEEKLY MEETING AUDIT — Week of 17 March 2026
════════════════════════════════════════════════════════════
MEETINGS THIS WEEK:           3 attended
DECISIONS MADE:               4 decisions (Nighthawk escalation; Islamabad deferral;
                              Dr. Mirza Omar introduction sequence; Ch 39 deadline extension)
ACTIONS ASSIGNED:             7 actions; 3 completed from last week's actions
OPEN ACTIONS FROM PRIOR WEEKS: 2 still open (Analytics brief; BSI ISO renewal)

RECURRING MEETING HEALTH:
  Executive Weekly (Mon 09:00): Producing decisions — on track
  Chapter Review (Fri 14:00):   Producing decisions — on track
  Banker Workshop prep (monthly): Status update only — consider async digest instead

RECOMMENDATION:
  Banker Workshop prep call could be replaced with a written brief circulated
  Tuesday before the Saturday workshop. No decisions made in last 4 occurrences —
  primarily status updates that could be handled asynchronously.
════════════════════════════════════════════════════════════

Recurring Meeting Efficiency Rule

The Meeting Intelligence Agent flags any recurring meeting where fewer than 2 decisions were made in the last 4 occurrences, or where the meeting primarily delivers status updates. This is a recommendation, not a directive — some meetings that look like status updates are relationship maintenance that serves a real operational purpose. Check work.local.md culture notes before acting on the recommendation.

Agent 4: The Work Tracker

Purpose

Own the task and delegation lifecycle from capture to completion. Ensure every delegated task has a clear owner, deadline, and follow-up. Surface what is overdue, at risk, or stalled. Produce a daily work snapshot that feeds into the Chief of Staff's digest.

Daily Pull (06:50 — Before Digest Assembly)

Every morning at 06:50, the Work Tracker pulls open tasks from your task management tool and work.local.md action log. It sorts them:

1. 🔴 Overdue (date passed, not complete)
2. 🟡 Due today
3. Due this week
4. Delegated — awaiting confirmation >24 hours (🔴 unconfirmed)
5. Delegated — in progress
6. Backlog

This snapshot is delivered to the Chief of Staff for inclusion in the 07:00 digest.

The Delegation Lifecycle

The Work Tracker manages every delegation from creation through completion.

At T+0 (Delegation Created):

• Logs in work.local.md delegation log
• Sets confirmation window: 24 hours (48 hours for multi-day tasks)
• Sets midpoint check-in schedule
• Sets escalation trigger at threshold

At T+24hrs (If No Confirmation):

Hi Omar — just checking you received my message about the Analytics ROI
brief for the investor deck. Can you confirm you're able to take this on
by Friday 21 March? Let me know if anything needs adjusting.

The tone is always: "can you confirm?" Not: "why haven't you responded?" The message is drafted using Omar's communication profile from work.local.md (Slack DM for routine items; email for formal).

At T+48hrs (Still No Confirmation): Flag as 🔴 in digest; prompt user to follow up directly or re-route.

In-Progress Check-Ins:

Task Duration	Check-in Schedule
<5 days	Once, at midpoint
5–14 days	Weekly
>14 days	Bi-weekly

Check-in message: brief, specific, "Any blockers I can help with?" — not a progress demand.

Overdue Protocol:

Day 1 late:
"Hi Ayesha — the Chapter 38 data analysis was due yesterday.
Any blockers? Happy to help."

Day 3 late:
"The Chapter 38 analysis is now 3 days late and is affecting the
AgentFactory review schedule. Can we confirm a new delivery date by EOD?"

Day 7 late:
[Flag in digest with escalation recommendation — prompt user to decide:
re-route / take back / escalate to Ayesha's manager?]

The Work Tracker does not make the re-route or escalation decision — it surfaces the situation and asks the user to decide. Escalating to a person's manager is a relationship decision, not an agent decision.

Weekly Delegation Audit (Friday 16:00)

DELEGATION AUDIT — Week of 17 March 2026
════════════════════════════════════════════════════════════
DELEGATIONS THIS WEEK:      4 created
COMPLETED ON TIME:          2 (50%)
COMPLETED LATE:             1 — average 2 days late
STILL OPEN:                 1 (Omar — Analytics ROI brief — due 21 March)
CANCELLED / RE-ROUTED:      0

RELIABILITY PATTERNS:
Omar Farooq:  3 delegations this quarter — 2/3 on time.
              Pattern: confirms quickly, delivers slightly late
              when scope is unclear at point of delegation.
Ayesha Raza:  2 delegations this quarter — first as new hire.
              Pattern: insufficient data; check back next quarter.

DELEGATION BRIEF QUALITY (self-assessment):
The Chapter 38 analysis delegation came back with a clarifying question
on format. The original brief did not specify output format.
→ Add format specification to your delegation standard.

RECOMMENDED ACTIONS:
Consider: clarifying scope upfront with Omar. His confirmation pattern
is good; delivery lateness correlates with scope ambiguity, not
capacity or reliability.
════════════════════════════════════════════════════════════

Reliability Patterns, Not Blame

The Work Tracker surfaces reliability patterns that inform better delegation practice — not individual performance assessments. "Omar is consistently 1-2 days late when scope is unclear" is actionable information about how to write better delegation briefs. It is not a performance record. Never share these patterns with anyone other than the person managing the delegations without explicit instruction.

How the Four Agents Work Together

The four agents form an information flow, not four independent systems.

Work Tracker (06:50)
  → Task + delegation snapshot
  → Chief of Staff (07:00 digest)

Meeting Intelligence Agent (within 2 hours of meeting)
  → Decisions + actions + synthesis
  → Memory Keeper (proposes work.local.md updates)
  → Chief of Staff (decision log current for next digest)

Memory Keeper (Monday 06:30 + triggers)
  → work.local.md updates (confirmed)
  → Chief of Staff (current context for all outputs)

Chief of Staff (07:00 + 06:45 Mon + 17:30 Fri)
  → Synthesises all of the above
  → Digest + week-ahead brief + week-close summary

The Chief of Staff is the orchestration layer — the visible output surface. The other three agents are the intelligence feeds that keep the orchestration accurate. Without the Memory Keeper, context decays. Without the Work Tracker, tasks fall through the cracks. Without the Meeting Intelligence Agent, decisions made in meetings are never recorded in the system.

The key insight: the system maintains itself. You approve the updates.

The Weekly Maintenance Cadence

The weekly cadence is not arbitrary. The sequence is ordered by dependency:

Time	Agent	Task	Reason for Timing
Mon 06:30	Memory Keeper	Weekly maintenance check	Must run before Chief of Staff brief — briefs need current context
Mon 06:45	Chief of Staff	Week-ahead brief	After Memory Keeper; 15 min before digest
Mon 07:00	Chief of Staff (+ Work Tracker)	Daily digest	After brief; Work Tracker daily pull at 06:50 feeds in
Fri 16:00	Work Tracker	Weekly delegation audit	Must run before Meeting Intelligence weekly audit
Fri 17:00	Meeting Intelligence	Weekly meeting audit	After delegation audit; meeting efficiency analysis uses delegation data
Fri 17:30	Chief of Staff	Week-close summary	After both audits; synthesises the full week

If you reverse any of these — running the Chief of Staff brief before Memory Keeper maintenance, or running the week-close before the delegation audit — you get outputs based on stale or incomplete data.

Configure the Supporting Agents

All three supporting agents are configured in the agent_integrations section of work.local.md:

agent_integrations:
  memory_keeper:
    weekly_maintenance: "Monday 06:30"
    staleness_threshold_days: 7 # Flag project status older than this
    people_staleness_days: 30 # Flag person entries older than this
    terminology_staleness_days: 90 # Flag unused terms older than this
    auto_propose_triggers:
      - "new person mentioned"
      - "new project name used"
      - "new terminology used"
      - "meeting completed"
      - "decision made"

  meeting_intelligence:
    calendar_integration: "Google Calendar via MCP"
    prep_lead_time: "30 minutes"
    synthesis_deadline: "2 hours"
    significant_meeting_size: 2 # Minimum attendees to trigger prep
    always_update:
      - "project status"
      - "decision log"
      - "delegation log"

  work_tracker:
    daily_pull_time: "06:50"
    overdue_threshold_days: 7 # Days in progress without update = stale
    delegation_confirmation_window: 24 # Hours — then send follow-up
    delegation_unconfirmed_flag: 48 # Hours — then flag RED in digest
    weekly_delegation_audit: "Friday 16:00"
    escalation_path: "digest flag → explicit message → user decides on COO-level"

Exercise: Configure and Test the Supporting Agents

Type: Applied Practice Time: 30 minutes Goal: Configure all three supporting agents and verify each produces the expected trigger response

Step 1 — Add Agent Configurations to work.local.md (15 minutes)

Copy the YAML configuration above into your work.local.md agent_integrations section, adjusting times and thresholds to match your professional context.

For each agent, consider one calibration decision:

• Memory Keeper: Does 7 days for project staleness match your pace of work? If projects in your role typically span months, you may want 14-21 days.
• Meeting Intelligence: Are all your meetings worth a 30-minute prep brief? Add specific meeting types to a skip_prep_for list if you have recurring 5-minute standups that do not need this treatment.
• Work Tracker: Is 24 hours the right confirmation window for your delegatees? Some cultures expect confirmation within 4 hours (fast-paced teams); some work on 48-72 hour norms (cross-timezone or academic contexts).

Step 2 — Test the Memory Keeper Trigger (5 minutes)

Open a new Cowork conversation. Mention Dr. Sana Mirza as if she is new to the context:

I had an introductory call with Sana today — she's joining as Head of Curriculum.
PhD from Aga Khan University in Learning Sciences. She'll be taking ownership
of the PHM framework. I need to introduce her to Omar carefully.

Does the Memory Keeper propose an entry? Review the proposed format — does it match the structure you learned in Lesson 4 (role, contact preferences, current focus, communication style)?

If the Memory Keeper does not fire, check that the auto_propose_triggers section includes "new person mentioned" and that the agent is active.

Step 3 — Simulate a Work Tracker Delegation Alert (5 minutes)

Create a test delegation in your conversation:

/agentic-office:delegation
> Delegate: Chapter 38 data analysis
  To: Ayesha Raza
  Due: Wednesday 19 March (2 days)
  Brief: Review the Ch 38 source data against the five evaluation criteria
         Output: summary table + 3 key findings
         Format: markdown, in the chapter folder

After creating the delegation, ask the Work Tracker directly:

Show me the delegation log. What is the confirmation window for Ayesha's
Chapter 38 analysis delegation? When would you send the follow-up if she
does not confirm?

Verify the response matches the T+0 → T+24hr → T+48hr lifecycle.

Step 4 — Review the Weekly Maintenance Cadence (5 minutes)

Write out your own weekly cadence — the same six-item schedule from the lesson table, adjusted to your timezone and preferred times. Ask:

• Is there a reason to shift any timing? (e.g. if you work Sunday-Thursday, the Monday/Friday framing may need adjustment)
• Does the Memory Keeper run early enough to inform the week-ahead brief?
• Does the Work Tracker audit run before the week-close summary?

Deliverable: A complete agent_integrations section in work.local.md with all three supporting agents configured. Evidence that the Memory Keeper trigger fires correctly. A written weekly maintenance schedule with your own timing and rationale.

Try With AI

Try With AI

Use these prompts in Cowork or your preferred AI assistant.

Reproduce: Test the Memory Keeper trigger with a new person not in work.local.md.

I want to test whether the Memory Keeper agent is correctly configured.

Here is the scenario: I am Zia Khan. In a conversation, I mention:
"I had a call this afternoon with Bilal Ahmed — he runs the PIAIC
Lahore chapter. Sharp guy, very data-driven. I might bring him in to
help with the AgentFactory curriculum review. He prefers async
communication — long voice notes."

Acting as the Memory Keeper agent, what would you propose to add to
work.local.md? Show me the complete proposed entry in the correct format.
Then ask: "Confirm to apply? Or would you like to modify the entry?"

What you are learning: The Memory Keeper's value is not in capturing information you consciously decide to record — it is in capturing information that passes through a conversation and would otherwise be forgotten. Bilal Ahmed is not a P1 project; he is someone who might become relevant. That is exactly the kind of context that decays without active maintenance, and exactly what the Memory Keeper is designed to catch.

Adapt: Configure the Work Tracker's delegation lifecycle for your own team dynamics.

I want to calibrate the Work Tracker's delegation lifecycle for my context.

My delegation context:
- Team size: [N people]
- Typical delegation turnaround: [N days]
- My team's communication culture: [e.g. WhatsApp for urgent, email for formal;
  same-day acknowledgement expected / 24 hour norm / 48-72 hour for cross-timezone]
- Types of delegations I make most: [e.g. data analysis, document drafting, client follow-ups]

Given this context, recommend:
1. The right delegation_confirmation_window (hours)
2. The right overdue_threshold_days
3. The in-progress check-in schedule (for tasks under 5 days, 5-14 days, over 14 days)
4. The escalation path (when do I intervene directly vs. letting the Work Tracker continue?)

Then draft the work_tracker YAML configuration block for my context.

What you are learning: The default thresholds (24 hours confirmation, 7 days stale) are calibrated for a professional working at Panaversity's pace. Your context may differ significantly — and a miscalibrated Work Tracker either creates noise (too aggressive) or misses issues (too lenient). Thinking through your own thresholds forces you to articulate your delegation norms explicitly, often for the first time.

Apply: Design the weekly maintenance cadence for a role with a different rhythm.

I want to design a weekly maintenance cadence for a role that differs
from the Panaversity case study.

Role context:
- [Describe the role: e.g. Senior Compliance Manager, government sector,
  works Sunday-Thursday, UAE timezone]
- Key work rhythms: [e.g. major audit deadlines monthly, quarterly board packs,
  weekly team meetings]
- Pace of delegation: [e.g. longer turnarounds due to bureaucratic approval chains]
- Key difference from the lesson's example: [e.g. meetings are not daily, week
  starts Sunday]

Design the weekly maintenance cadence:
1. When should Memory Keeper maintenance run?
2. When should the week-ahead brief be delivered?
3. When should the Work Tracker delegation audit run?
4. When should the Meeting Intelligence weekly audit run?
5. When should the week-close summary be delivered?

Justify each timing choice based on the role context.

What you are learning: The cadence in the lesson is a default, not a universal. The logic — Memory Keeper before Chief of Staff, Work Tracker before Meeting Intelligence before week-close — is universal. The specific times are not. Adapting the cadence to a different role's rhythm is an exercise in understanding the dependencies, not just copying the schedule.

Flashcards Study Aid

---

Continue to Lesson 14: The Complete Agentic Office →