Specialist Interrogators
Specialist interrogators decompose vague ideas into typed decision briefs so planning can proceed with explicit assumptions and accountable judgement.
The Scenario
An idea enters ideation: 'add single sign-on to the customer portal.' The cell could run one large interrogation that asks every question at once - and either skip half of them or exhaust the human's patience asking all of them. Instead it decomposes ideation into specialist interrogators, one per orthogonal concern, each producing a typed decision-brief that downstream agents read selectively. This example illustrates the decomposition pattern, not a mandatory roster.
The Roster (Example)
| Interrogator | Surfaces |
|---|---|
| idea-interrogator (umbrella) | Turns a raw idea into a spec-writer-ready briefing; invokes the specialists below when their concern is in scope |
| technical-interrogator | Architectural and dialect choices (stack, framework, integration shape) |
| security-interrogator | Data sensitivity, authn/z, compliance obligations |
| infrastructure-interrogator | Deployment, SLOs, disaster recovery, cost shape |
| ux-ui-interrogator | Theming, accessibility, motion, responsive behavior |
The number five is not magic. A payments domain might add a regulatory-interrogator; a data product might drop ux-ui. The pattern is one interrogator per orthogonal concern, not this specific list.
A Sample Brief
Each interrogator writes a typed artifact into the idea's folder. The security-interrogator produces, for the SSO idea, a SecurityDecisionBrief:
brief: SecurityDecisionBrief
idea: IDEA-014-portal-sso
produced_by: security-interrogator
findings:
data_sensitivity: high # customer identity + session tokens
authn:
protocol: OIDC # decided with human; SAML rejected (no legacy IdP)
token_storage: http-only-cookie
authz:
model: role-based
blast_radius: organizational # a flaw exposes every portal account
compliance:
- GDPR (EU customers in scope)
- SOC2 (existing control set applies)
open_questions:
- "Is step-up auth required for profile changes, or only at login?"
trifecta_flags:
untrusted_content: true # user-supplied login parameters
private_data_access: true # customer records
external_communication: true # IdP callback
note: "Lethal-trifecta candidate - see 10.1; force HITL on the auth callback agent."
confidence: 0.78The downstream spec-writer reads this brief plus any others in scope; the technical-interrogator's brief feeds dialect selection, the infrastructure-interrogator's feeds the eventual deploy stage.
What This Illustrates
- One Concern, One Interrogator - the questions for 'is this secure?' are genuinely different from 'is this fast enough?'; splitting by concern keeps each interrogator focused and gives the human meaningful pause points
- Typed Briefs Are the Interface - each output is a structured brief with a declared type, not free prose, which lets the spec-writer consume exactly the briefs in scope
- The Roster Is Cell-Level - the decomposition is the contribution; the specific five are an example, which is why the pattern lives in reference examples rather than the normative body
- It Composes With the Rest of the Model - each brief carries a confidence value, each interrogation is recorded in the decision trace, and a brief that raises a lethal-trifecta flag forces the downstream agent to HITL
Each brief carries a confidence value, each interrogation is recorded in the decision trace, and a brief that raises a lethal-trifecta flag forces the downstream agent to HITL. The specialists are ordinary capabilities; the only new idea is splitting ideation by concern. This pattern correlates to the Interrogatory LLM role described by Martin Fowler - the umbrella idea-interrogator orchestrates the orthogonal specialists, each acting as a focused interrogatory agent over its single concern.