I built a new control tower for WIMPER partner acquisition. Its first version failed before I let it become operational.
That was the win. The test found four unsafe assumptions, the revised version passed 29 checks, and the final system still cannot send an email, schedule a meeting, or change the customer database.
What Got Built
- A separate WIMPER Partner Control Tower entered service as a read-only recommendation layer. It can read approved acquisition inputs and prepare local draft recommendations. It has no authority to send, schedule, change customer records, or modify the production WIMPER Ops system.
- Business Brain Phase 0 started as private conversation intelligence. The first phase includes an approval-gated X recruitment thread plus a consent, conversation, and post-call capture kit. It collects structured learning without silently turning private conversations into public content.
- DIRECT click telemetry gained a rapid-repeat check. Two of the latest four raw click receipts matched the repeat rule. Instead of calling all four separate visitors, the system now reports a conservative floor of two recent sessions and leaves the result for manual review.
- UnderstandMyMedicare received a 1,306-word draft built from official sources. The article uses CMS and Federal Register material and entered the content queue as item 210, ready for review rather than automatic publication.
- The content and social lanes kept moving. The approved WIMPER Partners responsibility-map article published, seven Cloudflare deployment receipts were recorded, and three X posts were manually published during the 24-hour evidence window.
What Broke (And How I Fixed It)
The first version of the WIMPER Partner Control Tower failed its specification gate.
A specification gate is a test that compares a system with the exact contract it is supposed to follow. It asks more than “does the code run?” It asks whether the code stayed inside its authority.
This version did not.
It included legacy follow-up behavior that belonged to an older workflow. Its authorization logic was open by default instead of closed by default. It mapped some employer-introduction fields incorrectly. It also did not preserve enough provenance, meaning the output could not fully show where every important input came from.
Any one of those problems would have been easy to excuse in a prototype. Together, they created the exact kind of ambiguity that becomes expensive after activation.
A recommendation system with old follow-up logic may suggest actions that no longer match the current strategy. An authorization field that defaults to open can turn missing information into permission. Incorrect field mapping can attach a recommendation to the wrong business context. Incomplete provenance makes the error harder to trace after the fact.
So I rejected the run.
I revised the implementation, corrected the scope and mapping, closed the authorization defaults, and required stronger source tracking. The accepted version passed 29 tests.
More importantly, I did not reward the passing test by giving the system broad authority. The control tower remains read-only. It can produce recommendations and local drafts, but it cannot contact a prospect, schedule anything, change CRM records, or write into WIMPER Ops.
That separation matters because WIMPER Ops is the servicing system of record. It contains the operational truth for work already in motion. A new acquisition tool should not gain access to that truth simply because it has a useful dashboard or a good first recommendation.
The other friction was incomplete daily evidence. The same-day work log was unavailable when the build chronicle ran.
The chronicler did not fill the gap with a plausible summary. It used an 81-event window, GitHub commit receipts, the July 15 work log, the current status file, and Atlas ledgers. The missing source remained disclosed.
That produces a narrower account of the day, but it is a defensible one. A report should lose confidence when evidence is missing, not gain creativity.
The Lesson
Test authority, not just functionality.
Here is what I would tell someone building an agent: your first test should not only prove that it can produce an answer. It should prove what the agent cannot do. Write explicit checks for sending, scheduling, database mutation, production writes, and any other action that would be costly to reverse.
A tool can work perfectly and still be unsafe because it works outside the boundary you intended.
Make missing authorization mean no.
Open-by-default authorization is convenient during development because fewer test cases get blocked. It is dangerous in production because absent or malformed data can become accidental permission.
Use a closed default. Require a positive, specific authorization artifact before action. If the artifact is missing, stale, or ambiguous, the result should be a recommendation or a stop—not execution.
Start new intelligence layers read-only.
A read-only control tower can still create value. It can combine approved inputs, identify gaps, rank opportunities, and prepare drafts. What it cannot do is quietly make itself part of every operational workflow before its recommendations have earned trust.
My pattern is now: observe first, recommend second, allow narrow approved actions third, and consider broader authority only after the receipts support it. Each stage should have a separate contract and a way to return to the previous safe state.
Discount measurement before using it as proof.
Four click receipts were not automatically four people. The rapid-repeat rule flagged two receipts, so the system reported a conservative floor of two recent sessions.
Raw counts are inputs. Before calling them demand, remove obvious repeats, disclose the rule, and keep uncertain cases out of automated decisions. A smaller honest number is more useful than a larger number built from assumptions.
The Numbers
- Commits: 5 total (0 agent, 5 Matt)
- Agent jobs run: 40
- Prospects added: 0
- Emails sent: 0
- Social posts: 3
- Content published: 8
- Control Tower acceptance tests passed: 29
- Raw DIRECT click receipts reviewed: 4
- Rapid-repeat receipts flagged: 2
- Conservative recent-session floor: 2
- UnderstandMyMedicare draft: 1,306 words
- Cloudflare deploy receipts recorded: 7
The most important number is zero emails sent.
There were still 304 approved drafts and 366 due touches held behind the WIMPER gate. Building a new acquisition control tower did not give it permission to consume that backlog. The system produced recommendations while the sender stayed closed.
The second important number is 29. Those tests did not prove the control tower deserves permanent trust. They proved the revised version met its current contract and that the first version was rightfully rejected.
What’s Next
Keep the control tower read-only, review its recommendations against real acquisition outcomes, and do not add send, scheduling, CRM, or WIMPER Ops authority without a new explicit contract and another acceptance gate.