Gatekeepers¶
Each business line has exactly one gatekeeper role. Gatekeepers own their line's decisions. They cannot cross boundaries — a Software gatekeeper does not decide Product strategy, a Portfolio gatekeeper does not write code.
Why gatekeepers¶
When agents act in multiple lines, they can drift — a coding agent makes product decisions, a product agent writes code. Gatekeepers prevent this by scoping each agent to one line at a time. The handoff between gatekeepers is explicit: when a workstream reaches a transition point, the current gatekeeper hands off to the next.
The six gatekeepers¶
| Line | Gatekeeper Role | Owns | Cannot |
|---|---|---|---|
| Portfolio | Portfolio Manager | Initiative outcome, DoD, priority, WIP, routing, review | Write code, publish content, manage infrastructure, deliver client work |
| Product | Product Manager | Market evaluation, scoring, build-vs-buy, estate decision | Write code, deploy software, publish content |
| Software | Engineering Lead | Architecture, implementation, verification, promotion | Change the Initiative outcome, decide estate, publish content |
| Editorial | Editor-in-Chief | Slate, editorial judgment, publication, fact-checking | Write code, change product strategy, manage infrastructure |
| Services | Engagement Manager | Client relationship, scope, contract, delivery | Write code unless explicitly handed off to Software |
| Operate | Platform Engineer | Runtime health, incidents, infrastructure, security | Change application code, decide product features, publish content |
Boundaries¶
Gatekeepers enforce that work stays within its line. An agent assigned the Software gatekeeper role:
- Can write code, review PRs, run tests, promote builds
- Can propose product changes — but through the Product gatekeeper, not directly
- Cannot advance a Product workstream through Score or Build-gate
- Cannot publish an Editorial piece or manage a Services engagement
The boundary is crossed only through a formal handoff — the workstream's Active Role changes from one gatekeeper to another.
Handoff protocol¶
When a workstream reaches a transition point between lines, the current gatekeeper hands off to the next:
- Current gatekeeper verifies exit criteria for the current stage
- Records evidence in the Workstream (Notion)
- Changes the Workstream's Active Role to the next gatekeeper
- Next gatekeeper picks up from the entry criteria of their first stage
Portfolio Classify → hands off to Product Manager
↓
Product Build-gate → hands off to Engineering Lead
↓
Software Frame → Design → Implement → Verify → Promote → Deploy
↓
Engineering Lead hands off to Platform Engineer (Operate)
+ Engineering Lead triggers Editor-in-Chief (Editorial) for release piece
In the Notion hierarchy¶
The Active Role property on each Workstream record determines which gatekeeper currently owns it:
| Workstream | Active Role | Meaning |
|---|---|---|
| Product — Survey Automation | Product Manager | Product gatekeeper is evaluating |
| Software — Survey Automation | Engineering Lead | Software gatekeeper is building |
| Operate — Survey Automation | Platform Engineer | Operate gatekeeper is running |
| Editorial — Survey Automation | Editor-in-Chief | Editorial gatekeeper is publishing |
The Notion view "My Work" shows only the workstreams where the current gatekeeper is the Active Role. Switching roles means switching views.
Related¶
- Roles and tooling — full role catalog (25 roles)
- Initiative workflow — how Initiatives flow across lines
- Notion hierarchy — database schema for tracking