O Espelho — Tony's Narrative × Sistema T&C

SOPs Ativos

Tony Judgments

Rubrics Calibradas

Cron Jobs

Clients Ativos

Route Files

O Arco Narrativo é Idêntico

Sistema T&C (Arquitetura)

EBITDA Bridge

⟷

Evals + Reliability Hierarchy

Revenue Split

⟷

Pipeline Stages (Triage → Verified)

Mythos: Dual Revenue

⟷

Internal Repos → Client Repos

Blue Ocean Territory

⟷

Client Registry em Expansão

Agent Packages (3 Tiers)

⟷

SOP Architecture (3 Tiers)

IK Flywheel

⟷

Self-Improvement Loop

T&C Team + Warren

⟷

15 Crons × 7 Pessoas

The Ask

⟷

Pipeline como Produto (AIPMO)

Card 1 — Tony Vende

📊 EBITDA Bridge: 40% → 80%

Sistema T&C — Nós Operamos

Reliability Hierarchy + Evals

Tony decompõe o EBITDA em 3 fontes com perfis diferentes de IK-dependência:

Cost elimination (~25-35%): Eliminar Swimlane, CrowdStrike, Jira → $5.5-11.5M/yr. Baixa dependência de IK.
Scale efficiency (~25-30%): Automação operacional → mais clients por analyst. Média dependência de IK.
Net new revenue (~35-45%): Agents novos, service lines novos → receita que não existia. Alta dependência de IK.

No sistema T&C, o mesmo padrão aparece como Reliability Hierarchy:

Regras comportamentais (AGENTS.md/BOOTSTRAP.md) = cost elimination. Custo zero, impacto imediato, low-IK.
Crons e event-driven services (15 crons ativos) = scale efficiency. Precisa entender timing/contexto, med-IK.
Evals + Product Judgment Gate = net new revenue. Gera capacidade nova. 6 rubrics, 95 judgments calibrados, high-IK.

Nuance: Tony decompõe EBITDA por IK-dependência porque a sequência de execução importa — low-IK primeiro (rápido), high-IK depois (compound). Nossa reliability hierarchy segue a mesma lógica: regras (least reliable, fastest to deploy) → crons → services (most reliable, slowest to build). A failure migration é para CIMA no stack — mesma direção que o IK compound.

Card 2 — Tony Vende

💰 Revenue Split: Contracted vs Alliance

Sistema T&C — Nós Operamos

Pipeline Stages: Triage → Verified

Tony separa: A.1-A.5 = $5.5M contratado (table stakes). A.6-A.13 = alliance revenue. 250-550 agents = total opportunity.

O pipeline faz a mesma divisão:

Stages iniciais (triage → estimated) = contratado. Todo issue recebe. São table stakes.
Product Judgment Gate → sprint = alliance. Só trabalho qualificado avança. É onde valor novo é criado.

Evidência: 55 SOPs processando issues pelos mesmos stages. Labels funcionais — cada label trigger uma route ou bloqueia. Product Judgment Gate filtra escopo contra "realidade do cliente a 90 dias" antes de permitir sprint planning.

Nuance: Tony separa contracted vs alliance porque o modelo de receita é diferente. Nosso pipeline separa early vs late stages pela mesma razão — custo de execução escala exponencialmente, então só trabalho com product judgment positivo passa pro sprint. O gate É o filtro contracted→alliance.

Card 3 — Tony Vende

🎯 Mythos: Deloitte Builds, Market Sells

Sistema T&C — Nós Operamos

Internal Repos → Client Repos

"Deloitte builds the arsenal. Mythos creates the market. Every production agent = a product Kindo sells."

No sistema T&C:

Arsenal = repos internos: ops (docs + evals + SOPs), orgloop (engine), template (starter kit)
Mercado = repos de client: client-kindo, client-grant-intelligence, client-maris-garden, client-t-and-c
Mecanismo de conversão: O template repo é o "arsenal → market" converter.

Nuance: O multiplicador 2-5× do Mythos tem equivalente direto. A product-judgment-gate.md foi criada para Kindo mas já roda em GI e Mari's Garden. Build once, deploy many — mesma lógica do Tier 2 agent packaging. Cada SOP escrito para um client beneficia todos os outros.

Card 4 — Tony Vende

🗺️ 6 Portfolios × 6 Service Lines

Sistema T&C — Nós Operamos

Client Registry em Expansão

Tony: 36 células de oportunidade. Só D&RaaS (Krishna) está parcialmente coberto. 95% é whitespace.

Nós: Começamos com 1 client (Kindo) → 4 ativos, cada um com pipeline completo. Cada novo client = nova "service line."

Evidência: Tony mede em agents por service line (12-15 × 6 lines). Nós medimos em SOPs por client. A métrica é a mesma — density of automation per domain. O nosso está mais avançado em ratio: 55 SOPs vs 5 agents em produção na Kindo.

Card 5 — Tony Vende

📦 Agent Packages: 3 Tiers

Sistema T&C — Nós Operamos

SOP Architecture: 3 Tiers

Tier 1 — Core

Tony: A.1-A.5 + A.6 Vitals. Ships com cada MXDR deploy.

Sistema: merge.md, deployment.md, patrol.md, triage.md, dependabot-triage.md

Tier 2 — Domain

Tony: A.7-A.10, A.12-A.13. Built from IK, deployed many.

Sistema: 7 AIPMO SOPs, product-judgment-gate, sprint-planning, bd-daily-alert

Tier 3 — Bespoke

Tony: Custom agents per F50. Highest margin.

Sistema: cos-*.md, video-ingestion.md, corpus-ingest.md, kimi-quality-audit.md

Nuance: Krishna disse: "Out of the box you get these 6 agents. But every client — 'Build custom agents for me.'" É literalmente o que acontece quando abrimos um repo: Tier 1 vem grátis (template), Tier 2 configurado por domínio, Tier 3 construído sob demanda. A progressão é idêntica.

Card 6 — Tony Vende

🔄 IK Flywheel: Compound Learning

Sistema T&C — Nós Operamos

Self-Improvement Loop

Tony: ~70% do EBITDA gain flui pelo compound learning. Só gira quando agents estão live. Kush: 3 níveis (User → Agent → Org).

O flywheel T&C já está girando:

Nível 1 — User (sessão individual)

MEMORY.md + daily memory files. Cada sessão deposita conhecimento. 15+ memory files ativos.

Nível 2 — Agent (cross-session learning)

95 Tony judgments no calibration corpus. 6 rubrics calibradas. Shadow review automático. Self-improvement loop: 9 failure classes, 24 instâncias, 5 fixes implementados aguardando verificação.

Nível 3 — Organizational

Ops repo docs, 15+ standing rules (acumuladas de Charlie, Tony, Victor, Joana), pipeline principles #9-#16, Koan 1.

Nuance crucial: Kush definiu IK como "compound learning through use, not static knowledge extraction" e deu o exemplo: "antes auditávamos por sample, agora 100% com AI." O shadow review faz EXATAMENTE isso — audita 100% das outputs do Warren ao invés de sample-based review. O autodream cron (sábados 03:00 PT) é o equivalente técnico do Quality Audit Package de 5 agents do Tony.

Card 7 — Tony Vende

👥 T&C Team: 7 + Warren

Sistema T&C — Nós Operamos

15 Crons × 7 Pessoas

Tony: 60% Agent Designers, 25% Engineers, 15% Program. Porque agents são configs not code.

15 cron jobs multiplicam o time:

Victor: daily briefing (7am BRT)
Joana: daily briefing (8am BRT)
Tony: daily dossier (8:30am HST) + stale-item patrol (seg)
Charlie: daily dossier (5:07am PT)
#sales: sales-ops daily (seg-sex) + digest
#client-kindo: deloitte program status (seg)
Sistema: autodream, memory consolidation, event monitor, public-exposure audit, workspace distill

Evidência: Ratio config vs code nos SOPs: 55 SOPs (.md) vs 1 transform + 5 route files (.yaml) = ~90:10. Ainda mais agressivo que o 60/25 que Tony projeta. Confirma: agents are configs not code.

Card 8 — Tony Vende

🎯 The Ask: Resources + Comp Share

Sistema T&C — Nós Operamos

Pipeline como Produto (AIPMO)

Tony: resources + comp share on net new revenue. Fase: 3 engineers → 5 + delivery lead → 10 + team.

O AIPMO como GTM é literalmente este pipeline empacotado como produto:

Product Planning → Architecture → Estimation → Sprint → Implementation → Delivery
Human gates nos pontos certos
Autonomous execution entre os gates
Evals que provam qualidade
IK flywheel que demonstra compound value

Nuance: Tony precisa provar que "comp share on net new revenue" é justificado. O pipeline fornece a evidence trail: issues processados → quality metrics → deployment velocity → client outcomes. O evals system não é só quality control — é a prova documental de que o flywheel funciona.

O Meta-Insight

O storyboard segue exatamente o mesmo arco narrativo do nosso pipeline. Tony vê estratégia — "como convencer o Ron a investir?" Nós vemos arquitetura — "como o sistema funciona?" A resposta é a mesma coisa.

O sistema T&C é a prova de conceito viva do que Tony propõe para a Deloitte.

Se o Ron perguntar "how do I know this works?" — a resposta é: porque a equipe que vai entregar já opera exatamente este modelo para si mesma.

Perguntas para a Sessão de Amanhã

Onde o mapeamento quebra? Onde o paralelo Tony→Sistema não se sustenta? Isso revela blind spots em ambos.
O que estamos sub-comunicando? O evals system (95 judgments + shadow review automático) é provavelmente o asset mais sub-vendido. É demonstração concreta do flywheel.
O que falta no sistema para sustentar a narrativa? Se Tony vende 250-550 agents, nosso pipeline precisa escalar de 55 SOPs para centenas. Qual é o bottleneck?
O IK flywheel nosso é transferível? A lógica MEMORY.md → calibration → shadow review funciona para Kindo's agents? Se sim, é um deliverable adicional vendável.