A real collision between two overlapping AI builds, a partner-recommender tool and a Databricks predictive model, kicked off this work. Nine days into the pilot at Shippo: 11 GTM AI tools surfaced, 3 formally registered, 4 risk and cost flags actively tracked, and a single intake path replacing ad-hoc Slack threads.
In a single Slack thread, a teammate shared a Claude-built XMS Graduation Qualifier, a partner-recommender tool. Separately, a Databricks-based predictive model covering related territory was already in progress. A third person suggested layering in Salesforce data. Three workstreams, overlapping signals, no shared registry, no one knowing who owned what.
Left ungoverned, this pattern compounds: people build the same thing twice, tools get abandoned when owners leave, and Anthropic API spend stacks up with no visibility. I designed and shipped a lightweight governance system, one rule, three tiers, a 5-minute intake card, to catch overlap in 24 hours instead of 24 weeks.
Pilot launched April 21, 2026 in #test-gtm-ai-ops with 4–5 GTM users. Numbers reflect actual pilot state. Quarterly audit cadence begins after the pilot graduates.
Before you build anything AI-powered for GTM, you check the registry and complete the intake card. Full stop.
👆 Click any stage to expandClick any page in the sidebar to navigate.
Click between channels to see how the program runs day-to-day.
The system, the one rule, and how it runs at Shippo.
Without governance, AI tools sprawl. People build the same thing twice, no one knows what already exists, tools get abandoned when owners leave, and Anthropic API and infra spend compounds with no visibility. This playbook turns AI adoption from chaotic to compounding, without becoming bureaucracy.
Before you build anything AI-powered for GTM, you check the registry and complete the intake card. Full stop.
| Role | Responsibility | Cadence / SLA |
|---|---|---|
| AI Ops DRI | Owns registry, T2/T3 sign-off, quarterly audit, real-time overlap flagging | ~2 hrs/month steady-state |
| Tool DRI | Keeps the tool alive, cost accurate, registry entry current | Quarterly check-in |
| Data/Eng Contact | Required for any T3 tool, architecture & integration review | 5 business days |
| T2 sign-off | AI Ops DRI only | 48 hours |
| T1 | No approval, register within 1 week of going live | n/a |
Search Registry → Intake Card → Tier Check → Sign-off → Register & Audit. Most T1 tools clear the path in under 10 minutes. T2 tools clear in under 48 hours. T3 tools require an architecture pass and budget pre-approval, that's the design intent, not a bug.
This isn't a tool blocker. The intake takes 5 minutes. Most T1 builds need zero approval. The bottleneck before this program was indecision and silent duplication, not process.
Passive scans of #shippo-does-ai surface tools people built without filing intake. Watch list ≠ shame list, it's how we close the gap between "I built something cool" and "everyone can find it."
A pilot is the cheapest place to be wrong. These are the calls I'd revisit if I were starting again, and the ones I already am.
The first scan of #shippo-does-ai surfaced 6 tools nobody had filed. Passive discovery turned out to be more valuable in week one than active intake. Next time, I'd build the scanner first and let it create the demand for governance.
A pilot with 4–5 users will never produce a real T3 case. Designing the T3 process in the abstract would have produced bureaucracy nobody asked for. I deferred it explicitly in the playbook, with a flag-it-to-the-DRI fallback until the first real T3 lands.
The Shippo AI Dedup Tool, a Streamlit app that searches Slack/Confluence/Databricks before you build, was a reaction to pilot-week-one feedback, not part of the original spec. If I'd interviewed 3 GTM engineers up front, I'd have built it in parallel from day one.