# Measure AI Chief of Staff Impact: 3 Before-vs-After Metrics and a 2-of-3 Ship Rule

Carson Drake · October 21, 2026

> Measure AI chief of staff impact with three before-vs-after metrics, a two-week baseline, weekly remeasurement, and a 2-of-3 ship rule for better decisions.

| Takeaway | Detail |
| --- | --- |
| Baseline all 3 metrics for 2 weeks before deployment. | Measure weekly executive context-switch count, risk-weighted task success on held-out delegation scenarios, and hours returned per week. |
| Remeasure the same 3 metrics at weeks 6-8 after deployment. | Use the before-and-after measurements to evaluate whether the AI chief of staff should ship. |
| Ship only if at least 2 of 3 metrics clear their thresholds. | The decision rule requires at least two of the three before-versus-after checks to pass. |
| Context switches must fall by 30% or more, and risk-weighted task success must exceed 90%. | These are two specified passing thresholds; the hours-returned-per-week metric is measured, but its passing threshold is not specified. |

This guide provides a three-metric before-versus-after framework for deciding whether to ship an AI chief of staff coordinating calendar, inbox, and task agents. It specifies the baseline, remeasurement window, two numeric thresholds, and majority-pass shipping rule.

![Measure AI Chief of Staff Impact](https://static.mm-ais.com/article-images-ai/measure-ai-chief-of-staff-impact-3-befor-ai-fd0fe417.jpg)

## What an AI Chief of Staff Is

An AI chief of staff is a multi-agent orchestrator architecture: one planner LLM agent receives a natural-language request, interprets the intended outcome, and delegates the work to specialized calendar, inbox-triage, and task-execution sub-agents. This design follows the multi-agent orchestration pattern used in current conversational-AI research: a coordinating model decomposes a request, selects the appropriate tool or specialist agent, and combines the results into a response. The practical check is whether each delegation produces an observable, reviewable action rather than merely a plausible-looking plan.

Calling it a “chief of staff” is more than a product label. The distinguishing function is continuity across tools. A calendar agent can move a meeting, an inbox agent can classify a message, and a task agent can create a deliverable, but each operates with a limited view. The planner maintains shared state about the request, prior actions, constraints, unresolved questions, and completion status. That coordinator context is where failures concentrate: a technically correct sub-agent action can still be wrong for the overall intent if the planner supplied incomplete context or failed to reconcile conflicting information.

Evaluate the orchestrator at the level of a completed delegation, not at the level of individual prompts or tool calls. A completed delegation should mean that the requested outcome exists, uses the correct system of record, preserves relevant constraints, and can be traced from intent to planner decision, sub-agent execution, and final verification. For example, if the request combines scheduling, correspondence, and follow-up work, three successful API calls are not enough if the coordinator omitted the attendee’s availability, failed to link the sent message to the calendar event, or lost the commitment to deliver a later task.

Use a trace review to test where the system breaks. For each case, record the original request, the planner’s interpretation, the agents invoked, each tool action, the state passed between agents, and the final completion evidence. Then classify the failure: planning, routing, context retention, tool execution, integration, or verification. This distinction matters because adding a prompt to a specialist agent will not repair a planner that selected the wrong agent, while a more capable planner will not fix a broken calendar, inbox, or task-system integration.

The release rule should be simple: do not count the system as successful merely because a conversation sounded competent. Require evidence that the end-to-end delegation was completed correctly and that the cross-tool state remained coherent. If traces show that failures cluster at the handoffs, improve the coordinator protocol first; if they cluster inside one specialist, improve that agent and its tooling. This keeps architectural development aligned with the actual failure surface instead of treating the orchestrator as an undifferentiated chatbot.

![What an AI Chief of Staff Is — Measure AI Chief of Staff Impact](https://static.mm-ais.com/article-images-ai/measure-ai-chief-of-staff-impact-3-befor-ai-9b60c220.jpg)

## Pick Your 3 Metrics Now

Choose the three metrics before deployment, and make each one a check that can falsify a favorable story. The evaluation should contain exactly three measures: executive context switches per workday, task success rate on a fixed held-out delegation set, and hours returned per week. This combination tests the system at three distinct levels: executive attention, execution quality, and realized time savings. Keep the definitions stable so that the before-and-after comparison measures a change in work rather than a change in scoring.

**Metric 1 is executive context-switch count per workday.** Count transitions among calendar, Slack, and email, either manually from a daily log or automatically through an activity tracker. A switch is recorded whenever the executive moves from one of those applications to another during the workday, with duplicate or accidental transitions handled by a documented counting rule. This metric is comparatively hard to fake because the underlying behavior leaves a trace in either a contemporaneous log or application activity, and it can be reviewed against the executive’s actual schedule. More importantly, it directly reflects delegation load: if the system is doing its job, the executive should spend less time pivoting among communication channels to track, approve, and redirect work.

**Metric 2 is task success rate on a fixed held-out set of 20–30 written delegation scenarios.** Preserve the scenarios before evaluation so they cannot be rewritten to match the system’s strengths. Include ordinary requests, ambiguous instructions, missing information, and requests where a consequential error would matter more than a trivial one. Grade each scenario as pass or fail against explicit success criteria, such as the correct outcome, appropriate handling of uncertainty, and no material unauthorized action. An independent human who did not build the system should review the results. This design resists gaming because a fixed test set prevents cherry-picking examples, pass/fail judgments expose partial failures, and independent grading limits the incentive to redefine “success” after seeing the output.

**Metric 3 is hours returned per week.** Ask the executive to report the time reclaimed, but cross-check each claim against the scenario log: which delegation the system handled, what would have required the executive’s involvement, how long the task took, and whether it actually finished successfully. Record only time that can be tied to completed work; do not count waiting, rework, or time the executive still spent monitoring the system. This metric resists gaming by excluding vague “feels faster” claims and requiring reported savings to correspond to observable execution. A scenario that failed should not inflate the hours-returned total, even if it consumed less of the executive’s attention.

Use one evaluation sheet containing the three metric names, their definitions, source records, calculation rules, and any exceptions. Before accepting a result, ask whether another reviewer could reproduce each number from the underlying log. Reject a metric if its numerator and denominator are unclear, if an exception is applied only to favorable cases, or if the evidence cannot be reconciled with the other two measures. The point is not to produce three attractive charts; it is to create a compact evidence package that can withstand scrutiny from an executive, an operator, and an independent reviewer.

![Pick Your 3 Metrics Now — Measure AI Chief of Staff Impact](https://static.mm-ais.com/article-images-pixabay/measure-ai-chief-of-staff-impact-3-befor-a3965856.jpg)

## Baseline Before You Deploy

Begin the baseline before the agent touches anything. For 10 consecutive business days, log the executive context-switch count and hours returned per workday. The protocol should be explicit: every business day gets one row, missing values remain marked as missing rather than estimated, and the logging period is not extended or shortened after seeing the results. A single week can capture one unusually bad Monday and make the later comparison look better than the underlying workflow actually was. For example, if the executive records 42 switches in week one and 46 in week two, the baseline is (42 + 46) ÷ 2 = 44 weekly switches; the same arithmetic applies to the hours-returned log.

Use the same logging format every day: metric, date, raw value, and source or note. For example, a context-switch row might read “Executive context switches, 2026-01-06, 42, calendar and interaction log,” and an hours-returned row might read “Hours returned, 2026-01-06, 6.0, time record.” Keep the raw observations visible rather than replacing them with a running average. A missed entry is evidence about measurement quality, not permission to reconstruct the day from memory. At the end of the period, calculate the median of the 10 daily values for each logged metric. The median is useful because it is less distorted by an isolated extreme day, but it does not excuse missing data or inconsistent definitions.

Use the same logging format every day: metric, date, raw value, and source or note. Keep the raw observations visible rather than replacing them with a running average. A missed entry is evidence about measurement quality, not permission to reconstruct the day from memory. At the end of the period, calculate the median of the 10 daily values for each logged metric. The median is useful because it is less distorted by an isolated extreme day, but it does not excuse missing data or inconsistent definitions.

While the manual workflow is still familiar, write 20–30 held-out delegation scenarios. Capture the request, relevant starting context, expected outcome, and the conditions under which completion should count as successful. Drafting them after deployment creates a subtle selection problem: you may unconsciously choose scenarios that match the agent’s demonstrated strengths. Freeze this scenario set before deployment and treat later edits as a new benchmark rather than a silent replacement.

Finally, freeze the baseline in a one-page worksheet. It should contain each metric, the 10 raw daily values, the median, any missing observations, and a short note explaining how the values were collected. The held-out scenario set should be versioned alongside it, even if its results are recorded separately. If the team cannot produce that page, it does not yet have a defensible before-and-after comparison; it has an anecdote, a partial dataset, and a belief that the new system feels better.

![Baseline Before You Deploy — Measure AI Chief of Staff Impact](https://static.mm-ais.com/article-images-pixabay/measure-ai-chief-of-staff-impact-3-befor-7168daef.jpg)

## The 6-8 Week Evidence Window

The evidence window should begin after the system is actually operating in the executive’s workflow, not when the first demo looks promising. The Airship *Complete Review*, hosted at staymodern-ui.vercel.app, reports that ROI measurement typically begins six to eight weeks after deployment completion. That timing offers a relatively quick validation of implementation success: long enough for the workflow to settle, but still early enough to change, repair, or stop the deployment without allowing a weak pilot to drift indefinitely.

Schedule the review when deployment is complete, not when the team remembers to ask for results. At deployment time, put the review date on the executive’s calendar and create a single review packet containing the recorded results, observed exceptions, and the decisions required. The calendar entry should explicitly identify the end of the evidence window, so nobody can reinterpret an unfinished evaluation as an ongoing success story. If the review has not occurred by the end of week eight, classify the pilot as unmeasured drift rather than patience.

Do not use the first three weeks to make the final ship-or-skip decision. During those weeks, the executive is likely still learning the delegation interface: what can be requested, how to phrase it, when confirmation is needed, and how to recover when an instruction is ambiguous. Performance during that period therefore mixes interface learning with system performance. Treat it as an orientation and debugging phase, record what confused the user, and wait for the defined evidence window before evaluating whether the implementation merits a durable place in the workflow.

Keep the week-six and week-eight reads visible. Use the earlier point to identify missing logs, broken handoffs, and changes in how the executive delegates work; use the later point as the final checkpoint. Any adjustment made during the window should be documented with its date and effect. Otherwise, a change to prompts, permissions, or workflow rules can look like improved performance even when it actually reflects a redesigned experiment.

The practical rule is simple: fix the measurement window before deployment, protect it from convenient reinterpretation, and make the review an actual decision point. Six to eight weeks is not a guarantee of ROI, and it does not prove that a deployment should continue. It is a bounded period in which implementation success can be validated quickly enough to act on.

![The 6-8 Week Evidence Window — Measure AI Chief of Staff Impact](https://static.mm-ais.com/article-images-pixabay/measure-ai-chief-of-staff-impact-3-befor-96ce78f3.jpg)

## Ship, Iterate, or Skip Thresholds

Set the decision rule before looking at the results. A redesigned multi-agent system should clear a **risk-weighted task success rate above 90%** on the held-out delegation set, **at least a 30% reduction in weekly executive context switches**, and **at least 3 hours returned per week**. Ship when **at least 2 of the 3 metrics clear their respective bars**. A result that barely meets a bar does not strengthen the decision; record the margin so a marginal pass can be examined rather than treated as decisive evidence.

The success-rate bar is the most defensible reliability threshold for this architecture because orchestration errors are not merely inconvenient. Below that level, incorrect delegations, missing context, or mistaken actions can still reach the executive’s calendar and inbox. The held-out set is therefore the final test of whether the redesigned system handles consequential requests reliably, not just whether it can produce a plausible plan. Inspect failures by error type—such as incorrect routing, stale context, duplicated actions, or unsafe completion—and retain the failed cases as regression tests.

Apply the same discipline to the decision: ship when at least two measures clear their bars, even if the third misses. This avoids allowing one strong outcome to conceal a material reliability problem. For example, a large reduction in interruptions is not enough to justify release if the success rate remains below its bar, because a less fragmented workflow can still create harmful or incomplete work. Conversely, strong task reliability can justify shipping when one efficiency measure falls short.

Skip the deployment if at least two measures fail after the evaluation period. Do not recast a failed threshold as a learning expense without a concrete next test. An iteration is justified only when failure diagnosis identifies a specific workflow or tool-call bug, such as a malformed calendar argument, an inbox action that lacks a confirmation check, or a handoff that drops required context. Fix that failure, rerun the affected cases, and repeat the full decision evaluation.

Diffuse unreliability is not an iteration plan. If failures are scattered across unrelated workflows, permission boundaries, or tool behaviors without a reproducible cause, pause rather than adding prompts, retries, and agents indiscriminately. The Airship review notes that ROI measurement typically begins 6–8 weeks after deployment completion, supporting a bounded evaluation rather than indefinite tuning. At the end of that window, use the predefined threshold results to choose one of three outcomes: ship, iterate on one diagnosed defect, or skip.

![Measure AI Chief of Staff Impact, photo 2](https://static.mm-ais.com/article-images-pixabay/measure-ai-chief-of-staff-impact-3-befor-6361417d.jpg)

## One VP Week

Picture a VP reviewing the rollout after one week. The operational picture is not a demo full of plausible activity; it is a simple scorecard. During the baseline period, the VP recorded a median of 11 context switches per workday. There was no held-out delegation set yet, so the team could not honestly estimate whether delegated work was succeeding. It also had no measured hours returned: 0 hours per week. That missing evidence matters. The baseline is a record of how the week actually ran, not a retrospective estimate assembled after the system looked promising.

By week 8, the same scorecard showed 7 context switches per day, a reduction of 36% from the baseline of 11. That cleared the required 30% reduction. On 28 held-out delegation scenarios, 24 passed, producing an 85.7% risk-weighted task success rate. That result did not clear the 90% bar. Finally, the system returned 4.1 hours per week to the executive, clearing the approved hours-returned threshold. The decision rule therefore points to shipping: two of the three checks clearly passed, and the two passing checks captured both less interruption and recovered executive capacity. The worked example above shows the same two-of-three logic with different illustrative numbers.

That is a qualified ship decision, not a declaration that every delegation is reliable. The 85.7% success rate becomes the next redesign target. The team should inspect the four failed scenarios, classify the failure modes, and determine whether they came from delegation policy, missing context, incorrect tool execution, or an unreasonable success requirement. The next review should ask whether those changes improve held-out performance without sacrificing the 36% reduction in context switches or the 4.1 weekly hours returned. The scorecard prevents a visible productivity win from hiding weak execution quality.

Both kinds of decision error have concrete costs. Shipping at roughly 70% success would be reckless because weak delegation does not remain confined to a test environment: a mistaken calendar action can create a conflicting meeting, the wrong inbox action can bury or misroute a consequential message, and the wrong task action can leave work assigned incorrectly. Those errors consume executive attention, force coworkers to repair mistakes, and erode trust in the system. The safeguard is to keep consequential actions reviewable and use the held-out set to test the full workflow before granting more autonomy.

The opposite error is also expensive. Declining to ship because the success rate is below 90% would discard measured benefits of 36% fewer context switches and 4.1 hours returned each week. That forfeited time would remain absorbed by the VP, who would keep switching among planning, inbox review, and task coordination. The practical rule is asymmetric: do not ship known error leakage, but do not reject clear executive-time gains merely because one reliability metric still needs work. Ship under the stated two-of-three rule, while making the 85.7% result—and its four failed scenarios—the next improvement backlog.

## Worked Example: Run the Numbers

This worked example is entirely illustrative: it does not claim that the results below will generalize. The scenario is a 500-person software company using the system for one executive and one chief of staff. The illustrative baseline dates are January 6–17, 2026; deployment completes on January 20; and the remeasurement window is February 25–March 24, covering Weeks 6–8 after completion. The party consists of the executive, the chief of staff, and the deployed agent system; the same party and workload are measured before and after.

For context switches, the executive records 42 in Week 1 and 46 in Week 2. The baseline is (42 + 46) ÷ 2 = 44 weekly switches. In Weeks 6, 7, and 8, the counts are 31, 27, and 28, producing an average of (31 + 27 + 28) ÷ 3 = 86 ÷ 3 = 28.67 weekly switches. The reduction is (44 − 28.67) ÷ 44 × 100 = 34.85%. Because 34.85% clears the 30% threshold, this metric passes. Rounded results are for reporting only; the decision should use the underlying counts. The same before-and-after arithmetic applies to the hours-returned metric once its gate is set.

| Illustrative calculation | Result | Decision |
| --- | --- | --- |
| Baseline context-switch average: (42 + 46) ÷ 2 | 44 per week | Baseline |
| Post-deployment average: (31 + 27 + 28) ÷ 3 | 28.67 per week | — |
| Reduction: (44 − 28.67) ÷ 44 | 34.85% | Pass: at least 30% |
| Weighted successes: (2 + 2 + 2 + 3 + 2) ÷ (2 + 2 + 2 + 3 + 3) | 11 ÷ 12 = 91.67% | Pass: above 90% |
| Illustrative hours returned: 6 baseline hours − 3 post-deployment hours | 3 hours per week | Pass only if 3 exceeds the pre-set gate, H |

The fixed held-out delegation set contains five scenarios with risk weights of 2, 2, 2, 3, and 3, for a total weight of 12. Four scenarios are completed correctly, and the weight-3 scenario is not; the weighted score is therefore (2 + 2 + 2 + 3 + 0) ÷ 12 = 9 ÷ 12 = 75%. After deployment, the same set produces four successful completions plus a partial success worth 2 of 3 risk-weight points: (2 + 2 + 2 + 3 + 2) ÷ 12 = 11 ÷ 12 = 91.67%. That clears the requirement of being above 90%. Partial-credit rules must be fixed before scoring, not chosen after seeing the results. The table above shows the same weighted-success calculation in compact form.

For hours returned, the illustration records six hours per week of manually delegated work during the baseline and three hours afterward, so the calculated return is 6 − 3 = 3 hours per week. This illustration cannot pass that test without a previously chosen numerical gate; for example, it passes if 3 exceeds that gate. Nevertheless, two of three metrics clear their stated thresholds, so the decision rule points to shipping under the two-of-three rule.

 illustrative winner is **ship**. The break-even trigger is explicit: if context-switch reduction falls below 30%, the remaining two metrics must both pass; at the observed 44-switch baseline, 30% means no more than 30.8 weekly switches, so an average of 31 would fail that test.

## What These Metrics Cannot Tell You

The two-of-three decision rule is useful only within its designed scope, so review edge cases before treating it as a release verdict. Its principal limitation is that it can mistake a narrow workload for broad executive value. It can also produce a green result while omitting the delegations where an error would carry the greatest organizational risk.

Consider an executive who averages four context switches per workday. A 30% reduction would mean eliminating 1.2 switches per workday. That change is too small to interpret confidently on its own and should be treated as noise rather than evidence of improved attention. Under the two-of-three rule, the deployment can still win if risk-weighted task success is above 90% and the reported hours returned hold. The check is straightforward: do not count a small absolute reduction in interruptions as one of the two successful signals. Require the other two outcomes to carry the decision, and inspect the underlying interruptions rather than relying on the percentage alone.

Sensitive delegations create a different break. HR matters, legal matters, and compensation decisions should be excluded from the held-out evaluation set and kept manual regardless of the score. Success on low-risk tasks does not certify performance on high-risk ones. Before approval, document that these categories remain outside the agent’s delegation authority, confirm that escalation paths are available, and verify that the final evaluation contains no disguised examples of the excluded work.

Conversely, the rule can survive a change in implementation. A sub-agent vendor swap does not invalidate the evaluation when the same end-to-end outcomes are measured. If the replacement calendar, inbox, or task provider preserves success, executive context-switch behavior, and hours returned, the result describes the operating system rather than one vendor. Keep the test cases, scoring rules, and risk weights fixed during the swap; otherwise, a product change and an agent change become impossible to distinguish.

The practical catalog of edge cases is therefore: a low-volume executive may pass because two stronger outcomes carry the decision; sensitive delegations may expose a break that the held-out set cannot measure; and a vendor swap may still pass if the end-to-end results remain intact. For each case, apply one rule: judge the actual workflow, not the headline percentage; protect sensitive work explicitly rather than inferring safety from low-risk success; and compare like with like when the implementation changes.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Establish the pre-deployment baseline for the AI chief of staff across the full baseline period. | A consistent before measurement is required for valid comparisons. |
| 2 | Record the weekly executive context-switch count, risk-weighted task success on held-out delegation scenarios, and hours returned per week. | These are the three metrics used in the ship-or-skip decision. |
| 3 | Deploy the AI chief of staff and operate it throughout the 8 weeks evaluation period. | The evaluation must capture meaningful post-deployment behavior. |
| 4 | Remeasure the same three metrics during the final remeasurement window. | Like-for-like results show whether deployment changed executive operations. |
| 5 | Check the before-versus-after results against the context-switch reduction threshold, the risk-weighted task success threshold, and the hours-returned check above. | All three measures must be evaluated consistently, including hours returned even though its passing threshold is not specified. |
| 6 | Ship the AI chief of staff only if at least two of the three checks pass; otherwise skip it. | This is the canonical decision rule and prevents a single strong metric from masking weak results. |

## Frequently Asked Questions

**When should the baseline metrics be collected?**

Baseline all three metrics for two weeks before deployment.

**Which three measurements are used to evaluate the AI chief of staff?**

The framework measures weekly executive context switches, risk-weighted task success on held-out delegation scenarios, and hours returned per week.

**When should the same metrics be remeasured after deployment?**

Remeasure all three metrics during weeks 6–8 after deployment.

**Does the hours-returned-per-week check have a defined passing threshold?**

No, the hours-returned-per-week metric is measured, but its passing threshold is not specified.

**Do both specified threshold checks passing guarantee a ship decision?**

Yes, passing both specified checks satisfies the requirement that at least two of the three before-versus-after checks pass.

**How is work organized within the AI chief of staff architecture?**

A planner LLM agent interprets natural-language requests and delegates work to specialized calendar, inbox-triage, and task-execution sub-agents.

## Quick answers

| How long should all three metrics be baselined before deployment? | Baseline all three metrics for the two weeks before deployment. |
| --- | --- |
| When should the same three metrics be remeasured after deployment? | Remeasure the same three metrics at weeks 6–8 after deployment. |
| Which three metrics should be measured before and after deployment? | Measure weekly executive context-switch count, risk-weighted task success on held-out delegation scenarios, and hours returned per week. |
| Which metrics have specified passing thresholds? | The context-switch and risk-weighted task success metrics have specified passing thresholds, while the hours-returned-per-week metric does not. |
| When should an AI chief of staff ship under the decision rule? | Ship only if at least two of the three before-versus-after checks pass their thresholds. |

Also worth reading: **How an AI chief of staff can automate your daily standup**: [How an AI chief of](https://withtai.com/blog/how_an_ai_chief_of_staff_can_automate_your_daily_standup.php) · **Executive assistant vs chief of staff: 89% vs 47% orchestrate or skip**: [Executive assistant vs chief of](https://withtai.com/blog/executive-assistant-vs-chief-of-staff-89-vs-47-orchestrate-or-skip.php) · **Automate new hire onboarding with an AI chief of staff**: [Automate new hire onboarding with](https://withtai.com/blog/automate_new_hire_onboarding_with_an_ai_chief_of_staff.php)

### Related reading

- [Executive assistant vs chief of staff: 89% vs 47% orchestrate or skip](https://withtai.com/blog/executive-assistant-vs-chief-of-staff-89-vs-47-orchestrate-or-skip.php)
- [Replace Your Weekly Team Sync with an AI Chief of Staff](https://withtai.com/blog/replace_your_weekly_team_sync_with_an_ai_chief_of_staff.php)
- [How an AI Chief of Staff Protects Your Deep Work: A Practical Framework](https://withtai.com/blog/how_an_ai_chief_of_staff_protects_your_deep_work_a_practical_framework.php)
- [Automate new hire onboarding with an AI chief of staff](https://withtai.com/blog/automate_new_hire_onboarding_with_an_ai_chief_of_staff.php)
- [From Note-Taker to Operator: How an AI Chief of Staff Closes the Execution Gap](https://withtai.com/blog/from_note_taker_to_operator_how_an_ai_chief_of_staff_closes_the_execution_gap.php)
- [Essential Data Sources for Building an AI Chief of Staff](https://withtai.com/blog/essential_data_sources_for_building_an_ai_chief_of_staff.php)

### Latest

- [meeting summary benchmark: 12 min saved per meeting in 2026 — ship or pilot?](https://withtai.com/blog/meeting-summary-benchmark-12-min-saved-per-meeting-in-2026-ship-or-pilot.php)
- [AI agent for performance review prep: grounded self-assessment vs recall — 2026...](https://withtai.com/blog/ai-agent-for-performance-review-prep-grounded-self-assessment-vs-recall-2026-test.php)
- [Two-tier MCP registry: cap always-loaded schemas at 15](https://withtai.com/blog/two-tier-mcp-registry-cap-always-loaded-schemas-at-15.php)

Canonical: https://withtai.com/blog/measure-ai-chief-of-staff-impact-3-before-vs-after-metrics-and-a-2-of-3-ship-rule.php
Markdown: https://withtai.com/blog/measure-ai-chief-of-staff-impact-3-before-vs-after-metrics-and-a-2-of-3-ship-rule.php/index.md