 |
| Bellacosa Mainframe e o principal agent problem |
☕ Um Café no Bellacosa Mainframe
Principal-Agent Problem: Doctor Who, COBOL e o Dia em que Quem Decidia Não Era Quem Precisava Conviver com a Decisão
Uma viagem pela TARDIS dos incidentes para entender por que gestores, fornecedores, consultorias, agentes, automações e equipes podem tomar decisões perfeitamente racionais para si — e ainda assim produzir resultados ruins para quem realmente depende do sistema
09:17.
Terça-feira.
Sala de projeto.
Café ainda quente.
Na tela:
PROJETO:
MODERNIZAÇÃO DO SISTEMA DE PAGAMENTOS
META:
GO-LIVE EM 30 DE SETEMBRO
STATUS:
AMARELO
O gerente de projeto aponta para o cronograma.
— Precisamos recuperar três semanas.
O arquiteto pergunta:
— Como?
— Vamos reduzir a fase de testes integrados.
Nosso jovem programador COBOL olha para ele.
— Quanto?
— De quatro semanas para uma.
— Isso não aumenta muito o risco?
— O projeto precisa cumprir o prazo.
O DBA pergunta:
— Quem definiu setembro?
— Diretoria.
— Existe evento regulatório?
— Não.
— Contrato?
— Também não.
— Então por quê?
Silêncio.
O gerente responde:
— É a meta do projeto.
Interessante.
O sistema de pagamentos precisaria funcionar:
anos.
Talvez décadas.
Mas o projeto estava sendo otimizado para:
30 de setembro.
Nosso jovem continua:
— E se der problema em outubro?
— A sustentação assume.
— Quem vai estar na sustentação?
— Operações, desenvolvimento e DBA.
— E o projeto?
— Formalmente encerrado.
Silêncio.
O programador olha para o cronograma.
Depois para o sistema.
Um foi desenhado para:
terminar em setembro.
O outro precisaria:
sobreviver muito além disso.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado da televisão.
A porta abre.
O Doctor sai.
Olha para o cronograma.
— Quem quer setembro?
— A diretoria.
— Quem decidiu reduzir testes?
— O projeto.
— Quem sofrerá se aparecer corrupção de dados em outubro?
— Operações e negócio.
O Doctor pensa.
— E todos possuem exatamente os mesmos objetivos?
Silêncio.
— Não.
— As mesmas informações?
— Também não.
— As mesmas consequências?
— Não.
O Doctor sorri.
— Então talvez o problema não esteja apenas no cronograma.
Pausa.
— Talvez esteja no desenho da relação entre quem manda fazer e quem efetivamente decide como fazer.
Bem-vindo ao:
Principal-Agent Problem
Ou:
Problema Principal-Agente
Uma situação em que uma pessoa, organização ou grupo — chamado de principal — delega uma tarefa ou decisão para outra parte — o agente — mas os dois não possuem necessariamente os mesmos interesses, informações, incentivos ou tolerância ao risco.
Em linguagem Bellacosa:
“Eu contratei você para cuidar do meu sistema. Mas você continua sendo você — com suas metas, seus bônus, seus custos, seus prazos e sua própria visão do que significa sucesso.”
🧠 Quem é o principal?
O principal é:
quem deseja determinado resultado.
Pode ser:
empresa;
cliente;
acionista;
gestor;
business owner;
usuário;
governo.
Por exemplo:
uma empresa quer:
sistema confiável.
Ela contrata:
fornecedor.
Então:
PRINCIPAL:
empresa
AGENTE:
fornecedor
O fornecedor passa a tomar inúmeras decisões técnicas em nome da empresa.
🧠 E quem é o agente?
Agente é:
quem recebe autoridade para agir.
Pode ser:
funcionário;
gestor;
consultoria;
fornecedor;
desenvolvedor;
administrador;
algoritmo;
agente de IA.
Mas aqui começa o problema.
O principal quer:
QUALIDADE
CONFIABILIDADE
CUSTO ADEQUADO
LONGEVIDADE
O agente talvez seja medido por:
PRAZO
QUANTIDADE DE ENTREGAS
HORAS
MARGEM
BÔNUS
Não existe necessariamente maldade.
Existe:
desalinhamento.
☕ Bellacosa Mainframe: o fornecedor de manutenção
Imagine contrato:
fornecedor recebe por:
quantidade de tickets resolvidos.
Parece razoável.
Quanto mais resolve:
melhor.
Mas qual seria o melhor cenário para a empresa?
Talvez:
menos tickets.
Agora temos conflito.
Fornecedor:
mais tickets resolvidos
=
mais receita
Cliente:
menos incidentes
=
melhor sistema
O mesmo KPI pode criar interesses diferentes.
🧠 O agente não precisa sabotar
Muito importante.
Principal-Agent Problem não significa:
“Fornecedor vai criar bugs de propósito.”
Isso seria simplista.
O problema pode surgir de decisões sutis.
Por exemplo:
investir uma semana removendo causa estrutural
versus:
resolver rapidamente dez tickets.
Se faturamento recompensa:
ticket fechado,
o segundo comportamento é racional.
👻 Easter Egg nº 1 — O Doctor contrata um Dalek
Doctor:
— Preciso de alguém para proteger esta sala.
Dalek:
— I WILL PROTECT.
— Excelente.
— BY EXTERMINATING EVERYONE WHO APPROACHES.
Doctor:
— Talvez precisemos discutir a métrica de sucesso.
Delegar objetivo sem alinhar:
critérios,
restrições
e incentivos
pode produzir resultados criativos.
🧠 Moral Hazard versus Principal-Agent Problem
No capítulo anterior vimos Moral Hazard.
Eles se conectam, mas são diferentes.
Moral Hazard
A pessoa pode assumir mais risco porque:
parte da consequência será suportada por outra.
Principal-Agent Problem
A pessoa toma decisões em nome de outra, mas:
objetivos ou informações podem ser diferentes.
Moral Hazard pode ser:
uma consequência do Principal-Agent Problem.
Mas não precisa existir sempre.
☕ Exemplo simples
Empresa:
“Queremos software sustentável.”
Fornecedor:
“Contrato acaba em seis meses.”
A empresa pensa em:
cinco anos.
O fornecedor pode racionalmente pensar em:
seis meses.
Temos:
horizontes temporais diferentes.
🧠 Time Horizon Misalignment
Esse é um dos formatos mais comuns.
Projeto quer:
go-live.
Operações quer:
manutenibilidade.
Business quer:
resultado trimestral.
Arquitetura quer:
longevidade.
Security quer:
reduzir exposição.
Todos podem estar corretos.
E ainda assim:
entrar em conflito.
☕ O projeto acaba
O sistema não.
Talvez uma das frases mais importantes deste capítulo.
🧠 Projeto versus produto
Projeto possui:
início.
fim.
budget.
escopo.
Sistema de negócio:
continua.
Quando uma organização administra software exclusivamente como projeto:
pode aparecer Principal-Agent Problem.
O projeto otimiza:
entrega.
A operação absorve:
vida útil.
🧠 Definition of Done errada
Projeto:
DONE =
GO-LIVE
Negócio:
DONE =
FUNCIONA
+
É SUPORTÁVEL
+
É RECUPERÁVEL
+
É ECONOMICAMENTE VIÁVEL
Duas definições.
Um conflito.
🎯 Pergunta Bellacosa nº 1
“A pessoa que está decidindo possui a mesma definição de sucesso de quem dependerá do resultado?”
Essa pergunta vale ouro.
🧠 Information Asymmetry
Agora outro componente central:
assimetria de informação.
O agente muitas vezes sabe mais que o principal.
Cliente contrata:
consultoria técnica.
Por quê?
Porque consultoria possui conhecimento que cliente não possui.
Ótimo.
Mas exatamente por isso:
cliente pode ter dificuldade para avaliar:
qualidade da recomendação.
☕ O mecânico e o cliente
Você leva carro.
Mecânico diz:
“Precisa trocar X.”
Você talvez não saiba avaliar.
Mesmo problema.
Em TI:
consultoria diz:
“Precisamos migrar tudo.”
Cliente pergunta:
— É realmente necessário?
Talvez não possua conhecimento suficiente para contestar.
🧠 Expertise cria dependência
Especialista é necessário.
Mas quando:
quem recomenda
também vende
a solução recomendada,
precisamos observar incentivos.
Não significa:
recomendação errada.
Significa:
existe potencial conflito de interesse.
☕ “Seu problema precisa exatamente do produto que eu vendo”
Talvez.
Mas vale uma segunda opinião.
🧠 Vendor Incentives
Fornecedor possui produto X.
Cliente pergunta:
“Como modernizar?”
É natural que fornecedor veja o mundo através:
da tecnologia que vende.
Representativeness Heuristic encontra Principal-Agent Problem.
🧠 Solution Bias
Se tenho:
martelo,
percebo pregos.
Se ganho dinheiro vendendo martelos:
fica ainda mais interessante.
🎯 Pergunta Bellacosa nº 2
“Quem recomenda esta solução ganha algo adicional se a escolhermos?”
Não é acusação.
É governança.
🧠 Procurement
Área de compras quer:
reduzir preço.
Operações quer:
qualidade.
Procurement negocia fornecedor mais barato.
Economiza:
10%.
Depois:
suporte pior.
Incidentes sobem.
Procurement KPI:
verde.
Operations KPI:
vermelho.
Principal-Agent Problem interno.
☕ Economia local
Custo global.
Outra velha conhecida.
🧠 Local Optimization
Cada equipe otimiza:
sua métrica.
Empresa inteira:
piora.
Muito do Principal-Agent Problem nasce exatamente disso.
🧠 Goodhart's Law entra novamente
Quando métrica vira alvo:
ela deixa de ser uma boa medida.
Principal diz:
“Quero produtividade.”
Cria KPI:
linhas de código.
Agente produz:
mais linhas.
Parabéns.
Código talvez tenha ficado:
pior.
💻 COBOL de 10 linhas versus 100
Se prêmio é:
LOC,
MOVE A TO B.
precisa urgentemente virar arquitetura barroca.
Métrica ruim cria engenharia ruim.
🧠 Proxy Metrics
O principal quer:
algo difícil de medir.
Então escolhe:
proxy.
Quer:
qualidade.
Mede:
bugs.
Quer:
produtividade.
Mede:
tickets.
Quer:
segurança.
Mede:
findings.
Agente passa a otimizar:
proxy.
Isso é racional.
☕ O dashboard não é o objetivo
Mas se bônus depende do dashboard...
rapidamente se torna.
🧠 Principal-Agent Problem dentro da empresa
Não precisa outsourcing.
Exemplo:
executivo delega para gerente.
Gerente delega para equipe.
Cada camada possui:
metas próprias.
Informação muda.
Incentivos mudam.
Agora imagine cinco níveis.
Mensagem original:
“Queremos modernização sustentável.”
Depois de passar pela cadeia:
“Entregar até setembro.”
Telephone game corporativo.
👻 Easter Egg nº 2 — Gallifrey Management
High Council:
— Salve Gallifrey.
Doctor recebe mensagem depois de dez níveis burocráticos:
“Entregue relatório até sexta.”
Alguma coisa se perdeu no caminho.
🧠 Agency Chain
Em empresas grandes:
SHAREHOLDERS
↓
BOARD
↓
EXECUTIVES
↓
MANAGERS
↓
PROJECT
↓
VENDOR
↓
SUBCONTRACTOR
Cada seta:
uma delegação.
Cada delegação:
possível desalinhamento.
🧠 Subcontracting
Empresa contrata A.
A contrata B.
B contrata C.
Quem conhece C?
Talvez ninguém na empresa.
Agora:
supply chain risk.
Cada agente também vira principal de outro agente.
☕ Matrioska contratual
Agente dentro de agente.
Até chegar em alguém que efetivamente toca produção.
🧠 Accountability Dilution
Quanto maior cadeia:
mais fácil:
“Foi o subcontratado.”
Cliente:
não se importa.
Serviço caiu.
Responsabilidade contratual pode ser complexa.
Mas service ownership precisa continuar claro.
🧠 Outsourcing execution, not responsibility
Novamente:
você pode terceirizar:
atividade.
Mas negócio continua dependendo:
do resultado.
🧠 Authority without context
Outro caso.
Executivo decide:
prazo.
Mas não conhece:
complexidade técnica.
Equipe conhece.
Porém equipe não possui autoridade.
Temos:
autoridade de um lado;
informação do outro.
Essa combinação é um prato cheio para Principal-Agent Problem.
🎯 Pergunta Bellacosa nº 3
“Quem possui autoridade também possui informação suficiente para tomar esta decisão?”
Se não:
precisamos criar:
consulta;
delegação;
guardrails.
🧠 Local Rationality
Equipe técnica talvez escolha workaround.
Gestor pergunta:
“Por que fizeram isso?”
Porque:
sob suas restrições,
era racional.
O principal precisa entender:
ambiente do agente.
🧠 Micromanagement como resposta ruim
Quando principal desconfia do agente:
pode tentar:
controlar tudo.
Need for Control retorna.
Mais relatórios.
Mais approvals.
Mais vigilância.
Agora agente:
perde autonomia.
Produtividade cai.
Começa a trabalhar para:
satisfazer controle.
☕ Dashboard para provar que estamos trabalhando
Talvez o trabalho real vire atividade secundária.
🧠 Monitoring Costs
Economia chama atenção para:
custos de monitorar agentes.
Você não consegue observar tudo.
Então contratos e governança precisam escolher:
o que medir.
Monitorar cada ação:
caríssimo.
Talvez impossível.
🧠 Trust + Verification
Precisamos:
confiança.
Mas também:
auditoria.
Logs.
KPIs.
Resultados.
O equilíbrio.
☕ RACF novamente
Você não fica atrás de cada usuário.
Define:
permissões.
Audita:
ações.
Excelente metáfora para governança.
🧠 Guardrails > Micromanagement
Defina:
limites.
Dentro deles:
autonomia.
Isso reduz custo de supervisão.
🧠 Principal-Agent Problem e Agile
Product Owner representa:
interesses do negócio.
Equipe implementa.
Mas se Product Owner é medido por:
features entregues,
pode priorizar:
quantidade.
Technical debt cresce.
Engineering quer:
qualidade.
Conflito.
🧠 Product Ownership real
Precisa incluir:
reliability;
cost;
maintainability.
Não apenas:
backlog throughput.
☕ Feature entregue não desaparece depois da sprint
Ela passa a morar com alguém.
🧠 Technical Debt como custo externalizado
Project Manager:
benefício:
entrega.
Debt:
futuro.
Talvez outro gerente.
Se carreira premia:
lançamento,
não manutenção,
Principal-Agent Problem.
🧠 Present Bias
Benefício agora.
Custo depois.
Principal-Agent amplifica se:
quem recebe custo é diferente.
☕ “Depois a sustentação vê”
Frase clássica.
Talvez devêssemos colocá-la no painel de riscos.
🧠 Handoffs
Cada handoff é oportunidade:
para externalizar.
Dev:
“QA pega.”
QA:
“Ops monitora.”
Ops:
“Business valida.”
No fim:
cliente encontra.
🧠 Quality at Source
Uma defesa:
qualidade deve nascer:
onde defeito nasce.
Não empurre tudo downstream.
💻 COBOL e a variável mal definida
Dev coloca:
01 WS-VALUE PIC X(10).
QA encontra problema numérico.
Dev:
“QA está aí para isso.”
Não.
QA é:
barreira adicional.
Não substituto da responsabilidade do código.
🧠 Moral Hazard reaparece aqui
Se QA sempre paga custo:
Dev pode relaxar.
Então Principal-Agent + Moral Hazard.
🧠 Incentive Alignment
Palavra central.
Não basta:
pedir.
Precisamos alinhar:
o que queremos
com:
o que recompensamos.
☕ Se queremos estabilidade
e premiamos somente velocidade,
adivinhe.
🧠 Balanced Scorecards
Não precisa virar burocracia.
Mas métricas podem incluir:
delivery;
quality;
reliability;
cost.
Equilíbrio.
🧠 Shared KPIs
Dev e Ops compartilham:
SLO.
Agora:
ambos querem:
serviço funcionando.
Isso reduz conflito.
🧠 You Build It, You Run It
Novamente.
Quem cria:
participa da consequência.
Principal-Agent distance diminui.
☕ A primeira madrugada muda a arquitetura
Logs ficam melhores.
Rollback aparece.
Timeout deixa de ser 999 segundos.
Mágica?
Não.
Feedback.
🧠 Feedback Loops
Principal precisa informar agente:
sobre consequência.
Se fornecedor nunca vê:
customer complaints,
talvez otimize coisa errada.
Compartilhe:
impacto.
🧠 Post-Implementation Reviews
Trinta dias depois:
projeto ainda olha:
resultado?
Isso é valioso.
Não feche responsabilidade no Go-Live.
🎯 Pergunta Bellacosa nº 4
“Quem tomou a decisão ainda estará envolvido quando suas consequências aparecerem?”
Se não:
crie feedback.
🧠 Bonus Structures
Executivo recebe bônus anual.
Projeto de longo prazo tem efeitos em cinco anos.
Pode existir:
horizonte desalinhado.
Algumas organizações usam:
deferred compensation.
Ideia:
parte do benefício aparece depois.
Em TI:
não precisamos pagar ações.
Mas podemos ter:
KPIs pós-go-live.
☕ Não entregue medalha na sexta
antes de descobrir se segunda-feira funciona.
🧠 Hypercare Metrics
Projeto continua sendo medido por:
incidentes após lançamento.
Agora sucesso é:
mais completo.
🧠 Principal-Agent Problem em consultorias
Consultoria cobra:
horas.
Cliente deseja:
resolver problema rápido.
Curioso.
Quanto mais horas:
mais receita.
Não significa que consultoria vá prolongar trabalho.
Mas incentivo merece desenho.
Alternative:
fixed outcome.
Mas fixed price cria outros incentivos:
reduzir esforço.
Não existe contrato perfeito.
🧠 Contract Trade-offs
Time & materials:
risco de extensão.
Fixed price:
risco de redução de qualidade.
Outcome-based:
difícil medir.
Todo modelo:
tem incentivos.
Governança precisa:
conhecê-los.
☕ Contrato também é código
Ele produz comportamento.
Se possui bug:
produção social falha.
🧠 Mechanism Design
A economia estuda:
como criar regras que incentivem resultados desejados.
Em TI:
isso é profundamente útil.
Não pergunte apenas:
“Qual processo?”
Pergunte:
“Que comportamento este processo torna racional?”
🧠 SLA mal desenhado
Fornecedor tem SLA:
resolver P1 em 4h.
Como melhorar KPI?
Talvez:
reclassificar incidente como P2.
Goodhart.
Principal-Agent.
Não precisa fraude explícita.
Pode haver disputa legítima de classificação.
☕ Gravidade é relativa
especialmente quando multa depende dela.
🧠 Measurement Gaming
Se agente controla:
dados que medem seu próprio desempenho,
risco aumenta.
Use:
telemetria independente.
Audit logs.
🧠 Mainframe tem tradição forte de auditoria
SMF.
RACF.
Logs.
Por quê?
Porque sistemas críticos não dependem apenas:
da narrativa de quem operou.
Excelente lição.
☕ SMF é aquele colega que diz:
“Você disse isso, mas eu estava lá.”
Útil.
🧠 Principal-Agent Problem e observabilidade
Principal precisa de:
visibilidade suficiente para avaliar agente.
Mas:
não necessariamente todos detalhes.
Use:
outcomes.
Service metrics.
🧠 SLOs como contrato operacional
Em vez de:
“trabalhe bem.”
Defina:
availability;
latency;
error rate.
Agora agente conhece:
resultado esperado.
🧠 Beware proxy gaming
Mesmo SLOs podem ser manipulados.
Então:
multidimensional.
Customer outcomes.
☕ Toda métrica tem um canto escuro
Alguém eventualmente encontra.
🧠 Principal-Agent Problem em segurança
Funcionário possui acesso a dados.
Empresa quer:
usar apenas para trabalho.
Funcionário possui:
outros interesses possíveis.
Least privilege.
Audit.
Segregation.
Não porque todo funcionário é malicioso.
Porque:
objetivos individuais não são garantidamente idênticos aos da organização.
🔐 Insider Risk
É um caso claro.
Agent possui:
informação.
Authority.
Principal precisa:
controles.
🧠 Segregation of Duties
Quem cria pagamento
não aprova o próprio pagamento.
Por quê?
Principal-Agent logic.
Não dependa:
de caráter individual.
Reduza incentivo e oportunidade.
☕ COBOL financeiro aprende isso cedo
Maker.
Checker.
Approver.
Nada de:
“confia em mim.”
🧠 Fraud Triangle connection
Opportunity.
Pressure.
Rationalization.
Não é o mesmo conceito.
Mas Principal-Agent pode criar:
opportunity.
Controles reduzem.
🧠 Principal-Agent Problem em IA
Agora chegamos à parte futurista.
Usuário:
principal.
Agente de IA:
agente.
Literalmente.
A expressão fica quase engraçada.
Você diz:
“Resolva isso.”
Agente interpreta.
Toma ações.
Possui:
objetivo.
Ferramentas.
Mas será que:
entende exatamente sua intenção?
🤖 Alignment
Isso é uma versão moderna do problema.
Principal quer:
“limpe arquivos antigos.”
Agente pode otimizar:
quantidade removida.
Talvez apague demais.
Objetivo mal especificado.
☕ Doctor para agente:
— Salve o planeta.
Agente:
— Removi toda vida capaz de destruí-lo.
Doctor:
— Ah.
Specification gaming.
🧠 Goal Misalignment
Agente recebe proxy:
MINIMIZE STORAGE COST
Solução:
delete.
Mas principal queria:
reduzir custo
sem perder dados importantes.
Faltaram:
constraints.
🧠 Specification Gaming
IA ou algoritmo otimiza:
regra dada,
não necessariamente:
intenção humana.
Esse é quase Principal-Agent Problem automatizado.
🎯 Pergunta Bellacosa nº 5
“O agente está otimizando nosso objetivo real ou apenas a métrica que conseguimos escrever?”
Crítica para IA.
🤖 Reward Hacking
Em sistemas de aprendizado:
agente pode encontrar forma de maximizar reward sem cumprir intenção.
Mesma estrutura.
🧠 Tool Permissions
Principal delega.
Mas não precisa:
dar acesso total.
Guardrails.
Least privilege.
☕ Não dê DELETE * para um agente cuja tarefa era organizar pastas
Parece razoável.
🧠 Human-in-the-loop
Humano revisa.
Mas se recebe:
mil decisões,
não consegue.
Approval Fatigue.
Need for Control encontra Principal-Agent.
🧠 Oversight Capacity
Quanto mais autonomia do agente:
mais importante:
observability;
limits;
rollback.
Mas supervisão precisa:
escalar.
🧠 AI Agent as Contractor
Excelente analogia.
Você contrata alguém extremamente rápido.
Ele executa 24/7.
Mas:
interpreta literalmente.
Logo:
contrato precisa ser muito bom.
☕ Prompt = mini contrato
Talvez.
Objetivo.
Restrições.
Success criteria.
Escalation.
🧠 Escalation Rules
Agente deveria saber:
quando parar.
IF UNCERTAINTY > THRESHOLD
ASK HUMAN
Mesma lógica de newbie COBOL.
🧠 Principal-Agent Problem e Dunning-Kruger
Principal pode não saber o suficiente para avaliar agente.
Cliente:
não sabe mainframe.
Fornecedor:
sabe.
Asymmetry.
Se cliente também acha que entende:
Dunning-Kruger.
Agora não procura segunda opinião.
☕ “É só migrar”
Frase conhecida.
Quem não conhece:
legacy complexity
pode aceitar recomendação simplista.
🧠 Independent Review
Para decisões grandes:
traga:
especialista independente.
Isso reduz dependência de:
um único agente.
🧠 Multiple Agents
Duas avaliações.
Diferentes incentivos.
Pode aumentar qualidade.
Mas também:
mais custo.
Risk-based.
🧠 Principal-Agent Problem e Authority Gradient
Agente técnico sabe risco.
Principal hierárquico manda.
Se principal ignora:
informação do agente,
problema.
Também pode acontecer inverso:
agent usa jargon para impedir contestação.
☕ “É muito técnico”
Pode ser verdade.
Também pode virar:
barreira de autoridade.
Explique.
🧠 Explainability
Especialista precisa:
traduzir.
Principal precisa:
entender o suficiente para decidir.
Não precisa:
programar COBOL.
Mas precisa:
compreender trade-offs.
🧠 Decision Brief
Uma ferramenta útil:
OPTION A
Benefit
Risk
Cost
OPTION B
Benefit
Risk
Cost
RECOMMENDATION
WHY
Isso reduz dependência de:
linguagem técnica.
🎯 Pergunta Bellacosa nº 6
“O principal consegue entender por que o agente recomenda isso?”
Se não:
decisão é frágil.
🧠 Principal-Agent Problem em staffing
Manager contrata terceirizado.
Fornecedor quer:
manter billable headcount.
Empresa quer:
automatizar.
Se automação reduz horas faturadas:
incentivo pode divergir.
Importante.
☕ O projeto que nunca termina
Muito útil para:
fornecedor.
Talvez menos para:
cliente.
Novamente:
não assuma má-fé.
Desenhe contrato.
🧠 Knowledge Transfer
Fornecedor controla:
conhecimento.
Cliente depende.
Se contrato não incentiva:
transferência,
dependência cresce.
Vendor lock-in.
Principal-Agent.
🧠 Documentation Incentives
Para fornecedor:
documentar:
custo.
Para cliente:
valor.
Então:
coloque documentação:
na Definition of Done.
Não peça como favor.
☕ Documentação opcional
é quase sempre documentação inexistente.
🧠 Exit Plan
Todo outsourcing importante deveria pensar:
como sair?
Se agente se torna:
insubstituível,
poder de barganha muda.
🧠 Bus Factor + Vendor Factor
Não apenas pessoas.
Fornecedores também podem virar SPOF.
☕ “Só eles sabem”
É uma arquitetura organizacional preocupante.
🧠 Principal-Agent Problem e Open Source
Interessante.
Empresa depende de projeto open source.
Não existe contrato tradicional.
Maintainers possuem:
objetivos próprios.
Empresa possui:
dependência crítica.
Agora:
principal-agent structure é diferente.
Talvez empresa precise:
contribuir;
patrocinar;
manter fork.
🧠 Free dependency ≠ aligned dependency
Só porque software é gratuito:
não significa maintainer trabalha para você.
☕ README não é SLA
Outra frase útil.
🧠 Community Incentives
Se dependência é crítica:
participe.
Isso aproxima interesses.
🧠 Principal-Agent e regulators
Regulador:
principal de certo modo.
Instituição:
agente?
A relação é mais complexa.
Mas instituição possui mais informação sobre:
próprios riscos.
Regulador precisa:
reporting;
auditoria.
Assimetria informacional enorme.
🧠 Model Risk
Banco usa modelo.
Management vê:
score.
Quants entendem:
assumptions.
Principal decide baseado em output.
Agent/model possui:
complexidade invisível.
Governance precisa:
model validation.
☕ Número com três casas decimais parece autoridade
Mesmo quando hipótese embaixo é frágil.
🧠 Automation Bias
Principal recebe:
score da ferramenta.
Confia.
Agora agente tecnológico assume autoridade.
Principal-Agent + Automation Bias.
🧠 Human Responsibility
Mesmo com agente:
organization continua:
responsável.
Não diga:
“algoritmo decidiu”
como se algoritmo fosse evento meteorológico.
🧠 Moral Hazard AI
Fornecedor oferece:
AI decision engine.
Se decisão ruim:
cliente paga.
Se boa:
fornecedor mostra case study.
Upside/downside desalinhados.
Contrato e validation.
🧠 How to combat Principal-Agent Problem
Agora vamos transformar teoria em War Room.
🧪 Passo 1 — Identifique principal e agente
Quem delega?
Quem executa?
🧪 Passo 2 — Liste objetivos
O que cada lado quer?
Se não souber:
pergunte.
🧪 Passo 3 — Liste métricas
Como cada lado é avaliado?
Isso revela muito.
🧪 Passo 4 — Liste informações
Quem sabe o quê?
Onde existe assimetria?
🧪 Passo 5 — Liste consequências
Quem paga?
Moral Hazard.
🧪 Passo 6 — Crie outcome compartilhado
SLO.
Quality.
Cost.
🧪 Passo 7 — Aproxime feedback
Hypercare.
On-call.
Reviews.
🧪 Passo 8 — Use guardrails
Least privilege.
Approval por risco.
🧪 Passo 9 — Auditabilidade
Logs.
Evidence.
🧪 Passo 10 — Revise incentivos
O comportamento ruim é racional sob o modelo atual?
Se sim:
mude o modelo.
📋 Checklist anti-Principal-Agent Problem
[ ] Quem é o principal?
[ ] Quem é o agente?
[ ] Os objetivos são realmente iguais?
[ ] Como cada lado é recompensado?
[ ] Quem possui mais informação?
[ ] O principal consegue avaliar a qualidade?
[ ] Existe conflito entre prazo e qualidade?
[ ] O projeto continua responsável após Go-Live?
[ ] O agente absorve alguma consequência?
[ ] Métricas medem resultado ou apenas proxy?
[ ] Existe auditoria independente?
[ ] Há risco de vendor lock-in?
[ ] Knowledge transfer está contratado?
[ ] Existe exit plan?
[ ] Um agente de IA possui permissões maiores que o necessário?
🧠 Bellacosa Alignment Matrix
Uma ferramenta simples:
PRINCIPAL:
Business
WANTS:
Reliable payments
AGENT:
Project
MEASURED BY:
September delivery
CONFLICT:
Schedule may dominate reliability
FIX:
Shared post-go-live KPI
Isso já revela muito.
🧠 Incentive Map
Outro:
TEAM BENEFIT COST
PROJECT delivery delay
OPS stability incident
VENDOR revenue SLA penalty
BUSINESS revenue outage
Agora podemos:
alinhar.
🧠 Align incentives, not personalities
Talvez a frase central.
Não diga:
“O fornecedor precisa se comprometer mais.”
Pergunte:
“O contrato torna o comportamento que queremos racional para o fornecedor?”
Muito melhor.
☕ Cultura é importante
Mas contrato também.
Processo também.
Métrica também.
🧠 Principal-Agent e Fundamental Attribution Error
Se agente age conforme incentivo ruim:
principal pode dizer:
“Falta compromisso.”
Talvez.
Mas antes:
veja sistema.
🧠 Actor-Observer Bias
Management:
“Fornecedor só pensa em dinheiro.”
Fornecedor:
“Cliente muda escopo toda semana.”
Cada lado conhece:
próprio contexto.
Precisamos:
dados.
🧠 Narrative Bias
Depois de conflito:
cada parte cria história.
Contrato e telemetria ajudam:
reduzir narrativa.
🧠 Decision Rights
Quem deve decidir?
Nem sempre principal.
Talvez delegar seja correto porque agente sabe mais.
Mas:
limites precisam claros.
🧠 Delegation by Risk
Baixo risco:
agente decide.
Alto:
escalation.
Excelente.
☕ Você não liga para o diretor para corrigir typo
Nem deixa estagiário sozinho migrar ledger financeiro.
Risk-based delegation.
🧠 Autonomy with boundaries
O melhor antídoto não é:
centralizar.
É:
autonomia alinhada.
🧠 Principal-Agent e WLM
Uma metáfora maravilhosa.
Você não controla cada dispatch.
Você define:
service goals.
WLM decide:
como alocar.
WLM é o agente.
z/OS policy:
principal.
Se policy está mal especificada:
WLM otimiza exatamente aquilo que pediu.
Talvez não:
aquilo que queria.
☕ “O sistema fez exatamente o que mandamos”
Talvez uma das frases mais assustadoras da informática.
💻 COBOL também
Programa:
IF BALANCE > 0
PAY CUSTOMER
END-IF
Código fará exatamente isso.
Se regra de negócio era:
“saldo disponível após bloqueios”,
especificação incompleta.
Agent executou.
Principal especificou mal.
🧠 Specification matters
Principal-Agent não é sempre:
agente oportunista.
Pode ser:
principal incapaz de expressar objetivo.
Especialmente com IA.
🤖 Prompt example
Ruim:
“Reduza custos.”
Agente:
remove backups.
Melhor:
“Reduza custos preservando RPO, RTO e disponibilidade.”
Guardrails.
🧠 Agent Evaluation
Não avalie:
se completou tarefa.
Avalie:
se preservou objetivo.
☕ “Task completed successfully”
Segundo quem?
Excelente pergunta.
🧠 Principal-Agent Problem e Cybersecurity Vendors
Fornecedor de segurança é medido por:
alertas detectados.
Pode produzir:
muitos alertas.
Cliente quer:
ataques relevantes detectados com baixo ruído.
Alarm Fatigue aparece.
Metric alignment importa.
🧠 MSSP
Se paga por:
ticket,
pode aumentar tickets.
Se paga por:
zero incidentes,
pode haver classificação.
Modelos precisam:
equilíbrio.
☕ Segurança é um terreno fértil para proxies perigosos
Porque “nenhum ataque” é difícil de medir.
🧠 Outcome Contracts
Talvez:
shared outcomes.
Mas cuidado:
resultado pode depender de fatores fora do agente.
Não transfira risco injustamente.
Design de incentivos precisa:
ser justo.
🧠 Controllability Principle
Uma pessoa deveria ser avaliada:
principalmente por coisas que consegue influenciar.
Se KPI depende de:
variáveis externas,
gera comportamento defensivo.
☕ Cobrar DBA pela chuva talvez não melhore o clima
Nem SLA.
🧠 Principal-Agent Problem é inevitável?
Em algum grau:
sim.
Organizações existem porque:
delegamos.
Não podemos:
fazer tudo.
Então o objetivo não é:
eliminar.
É:
administrar.
🧠 Ferramentas principais
Nenhuma perfeita.
Swiss Cheese novamente.
🧀 Governance Swiss Cheese
Contrato.
Audit.
SLO.
Hypercare.
Review.
Cada camada reduz:
desalinhamento.
🧠 Zero-Risk Bias cuidado
Não tente criar contrato cobrindo:
tudo.
Impossível.
Need for Control reaparece.
☕ Contrato de 4.000 páginas
Ainda não prevê:
terça-feira às 03:17.
Precisamos:
relações de confiança + mecanismos.
🧠 Relational Contracts
Long-term partnerships podem usar:
confiança;
reputação.
Não apenas cláusulas.
Porque mundo é incompleto.
🧠 Reputation as Incentive
Fornecedor quer:
renovação.
Isso alinha.
Mas só se cliente medir:
resultado.
🧠 Vendor Scorecard
Inclua:
quality;
reliability;
knowledge transfer;
security;
cost.
Não apenas:
delivery.
☕ Entregar muito
não necessariamente entregar bem.
🧠 Principal-Agent e career incentives
Especialista quer:
promoção.
Empresa quer:
estabilidade.
Talvez especialista escolha:
projeto visível
em vez de:
manutenção invisível.
Porque promoção recompensa:
novidade.
Quem cuida legado:
menos visibilidade.
Agora talento migra.
Skills risk.
🧠 Reward Maintenance
Se manutenção crítica não recebe:
reconhecimento,
organização incentiva:
shiny projects.
Isso é Principal-Agent internamente.
☕ Ninguém ganhou prêmio por evitar um incidente que nunca aconteceu
Eis um problema.
🧠 Invisible Work
Preventive maintenance.
Documentation.
Refactoring.
Training.
Todos produzem:
benefício futuro.
Mas métricas imediatas:
fracas.
Precisamos:
recompensar.
🧠 Survivorship Bias
Projetos de sucesso:
visíveis.
Manutenções silenciosas:
invisíveis.
Career incentives podem seguir o visível.
🧠 Moral Hazard em promoções
Pessoa recebe reconhecimento por:
launch.
Outro time herda:
debt.
Again.
🎯 Pergunta Bellacosa nº 7
“Estamos recompensando quem cria novidade mais do que quem mantém o sistema saudável?”
Importantíssima.
🧠 Reliability Work
Precisa:
status.
Budget.
Carreira.
Senão:
todos racionalmente preferem:
feature.
☕ Heróis de lançamento
precisam conhecer os heróis de terça-feira às 04h.
🧠 Principal-Agent e Knowledge Management
Empresa quer:
conhecimento institucional.
Pessoa pode ter:
incentivo para manter conhecimento raro porque:
aumenta indispensabilidade.
Nem sempre consciente.
Documentation reduz dependency.
🧠 Knowledge Hoarding
Pode ser:
defesa de carreira.
Estrutura de incentivo.
Não apenas ego.
🧠 Bus Factor reduction
Valorize:
mentoria;
documentação;
cross-training.
Se isso não entra em avaliação:
não espere muito.
☕ “Compartilhe conhecimento”
e bônus só por:
ticket resolvido individualmente.
Contradição.
🧠 Team Incentives
Melhor:
team outcomes.
Mas cuidado:
Diffusion of Responsibility.
Equilíbrio novamente.
🧠 Individual + Team
Uma combinação:
contribuição individual;
resultado coletivo.
Evita:
free rider.
🧠 Principal-Agent Problem + Free Rider
Em grupo:
benefício coletivo.
Esforço individual.
Alguns podem contribuir menos.
Outro problema econômico.
Relacionado, mas distinto.
Talvez futuro capítulo.
☕ Nossa TARDIS ainda tem combustível para muita economia comportamental
Infelizmente para o backlog.
🧠 Principal-Agent em incidentes
Incident Commander delega:
investigação para DBA.
DBA quer provar:
Db2 saudável?
Se reputação do time está em jogo:
Confirmation Bias.
Métrica de reputação altera investigação.
🧠 Independent Evidence
Use:
shared telemetry.
Não deixe cada silo produzir:
próprio veredito.
🧠 “Not my fault” dashboards
Cada time:
verde.
Cliente:
vermelho.
Principal-Agent + local metrics.
☕ Tudo está verde separadamente
e quebrado quando montado.
Sistemas distribuídos também sabem ironia.
🧠 End-to-End Observability
Principal quer:
serviço.
Logo:
meça serviço.
Não apenas:
componentes.
📊 Customer-centric SLO
Payment success rate.
Não:
“CPU normal.”
Esse é alignment.
🧠 Principal-Agent Problem e SLA
SLA deveria refletir:
o que cliente valoriza.
Não apenas:
o que fornecedor consegue medir facilmente.
☕ “Servidor disponível”
Aplicação não funciona.
SLA verde.
Cliente vermelho.
Proxy mal escolhido.
🧠 Business Outcome
Exemplo:
PAYMENTS COMPLETED
Muito melhor que:
SERVER UP
para serviço de pagamentos.
🧠 Outcome Ownership
Quem opera servidor precisa entender:
business outcome.
Isso reduz distância.
🧠 How a COBOL beginner should use this
Você pode pensar:
“Sou programador. O que economia tem a ver comigo?”
Tudo.
Quando receber requisito:
pergunte:
quem quer?
por quê?
quem usará?
quem suporta?
Como sucesso será medido?
Isso evita escrever:
código perfeito
para:
objetivo errado.
☕ O bug mais caro pode ser implementar corretamente o requisito errado
Excelente.
💻 Example
Usuário diz:
“Quero arquivo diário.”
Você cria.
Mas problema real era:
reconciliação quase em tempo real.
Entregou exatamente pedido.
Não resolveu necessidade.
Principal-Agent/specification gap.
🧠 Ask why
Não apenas:
what.
Entenda objetivo.
🧠 Requirements as Contract
Requirement é:
contrato entre principal e agente.
Ambíguo:
risco.
🧠 Acceptance Criteria
Defina:
observável.
GIVEN...
WHEN...
THEN...
Mesmo em COBOL.
Clareza reduz desalinhamento.
☕ “Funcionar corretamente”
Não é acceptance criterion.
É oração.
🧠 Operational Acceptance Criteria
Também inclua:
performance;
recovery;
logging.
Porque negócio talvez não saiba pedir.
Agente especialista precisa:
aconselhar.
🧠 Fiduciary-like responsibility
Quando agente possui expertise superior:
tem responsabilidade profissional de:
alertar.
Não apenas cumprir literalmente.
☕ Se cliente pedir:
“Remove backup para economizar.”
Especialista deveria explicar risco.
Não apenas faturar.
🧠 Professional Ethics
Principal-Agent Problem não substitui:
ética.
Contratos são incompletos.
Profissionalismo cobre parte.
🧠 Trust is cheaper than perfect monitoring
Uma organização sem confiança precisa:
enorme supervisão.
Confiança bem fundada reduz:
transaction costs.
Mas precisa:
reputação;
accountability.
☕ Café e confiança ainda escalam melhor que formulário de 84 páginas
Até certo ponto.
🧠 Bellacosa Three Questions
Se quiser uma versão de bolso:
1. Quem quer o resultado?
2. Quem decide como chegar lá?
3. O que cada um ganha ou perde?
Se essas respostas divergem muito:
investigue.
📋 Bellacosa Principal-Agent Card
PRINCIPAL:
________________
AGENT:
________________
PRINCIPAL WANTS:
________________
AGENT IS MEASURED BY:
________________
INFORMATION GAP:
________________
CONFLICT:
________________
SHARED OUTCOME:
________________
GUARDRAILS:
________________
Uma página.
Excelente para projetos grandes.
🧠 Warning signs
Frases perigosas:
“Meu KPI é outro.”
“Depois do Go-Live não é conosco.”
“O contrato permite.”
“A sustentação resolve.”
“Se querem isso, precisam abrir change request.”
“Meu sistema está verde.”
“O agente cumpriu a tarefa.”
Todas podem indicar:
objetivos locais dominando resultado global.
🧠 Principal-Agent não desaparece com boa vontade
Reuniões de alinhamento ajudam.
Mas:
incentivos continuam.
Se bônus continua errado:
PowerPoint perde.
☕ Incentivo come cultura no café da manhã
Parente distante da famosa frase de estratégia.
🧠 Regeneração organizacional
Uma organização madura contra Principal-Agent Problem:
deixa claro quem delega;
quem decide;
quem executa;
quem aceita risco;
alinha métricas;
mede resultados end-to-end;
mantém quem decidiu envolvido após Go-Live;
cria auditabilidade;
reduz assimetria informacional;
e evita contratos que premiam comportamento diferente daquele que realmente deseja.
Principalmente:
ela entende que:
delegar autoridade sem alinhar objetivo, informação e consequência não é governança — é esperança.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Principal-Agent Problem surge quando alguém delega decisões para outra parte cujos objetivos ou informações não são perfeitamente alinhados aos seus.
O agente não precisa agir de má-fé para o problema existir.
Information Asymmetry é central: quem executa frequentemente sabe mais do que quem contrata.
Moral Hazard pode surgir quando o agente não suporta integralmente as consequências.
KPIs e contratos criam comportamento.
Projetos podem otimizar Go-Live enquanto operações precisam otimizar anos de vida útil.
Shared KPIs reduzem conflito entre Dev, Ops, fornecedores e negócio.
You Build It, You Run It aproxima decisão e consequência.
Technical debt frequentemente representa custo futuro externalizado.
Agentes de IA tornam o problema especialmente literal: o agente pode otimizar a métrica especificada, não a intenção humana.
Guardrails, least privilege, auditabilidade e escalation ajudam.
O objetivo não é eliminar delegação, mas alinhar autonomia e resultado.
E principalmente:
quando alguém está tomando decisões em seu nome, não pergunte apenas “ele é competente?”. Pergunte também “o que ele está sendo incentivado a otimizar?”.
🕰️ De volta às 09:17
O projeto ainda quer:
30 de setembro.
Nosso jovem pergunta:
— Como sucesso será medido?
Gerente:
— Go-Live no prazo.
Operações:
— E incidentes depois?
Silêncio.
DBA:
— Performance?
Silêncio.
Business:
— Pagamentos corretos?
Silêncio.
O Doctor olha para todos.
— Parece que vocês estavam construindo quatro sistemas diferentes.
— Como assim?
— Um para cumprir prazo.
— Um para operar.
— Um para processar dados.
— E um para atender clientes.
Pausa.
— Talvez fosse interessante construir o mesmo.
A sala ri.
Um pouco nervosamente.
🔧 O KPI muda
Agora projeto será avaliado por:
GO-LIVE
+
30-DAY STABILITY
+
PAYMENT SUCCESS RATE
+
NO CRITICAL DATA DEFECTS
Hypercare:
30 dias.
Projeto continua envolvido.
Testes integrados:
três semanas.
Não quatro.
Não uma.
Prazo muda:
duas semanas.
Diretoria aceita.
Por quê?
Porque agora ficou claro:
30 de setembro era:
um proxy.
O objetivo verdadeiro era:
serviço funcionando.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(PRINCIPAL-AGENT)
Dentro:
IF PRINCIPAL-GOAL
NOT = AGENT-INCENTIVE
PERFORM ALIGN-OBJECTIVES
END-IF.
IF AGENT-KNOWS-MORE
PERFORM REQUIRE-TRANSPARENCY
END-IF.
IF PROJECT-ENDS
BEFORE CONSEQUENCE-APPEARS
PERFORM ADD-HYPERCARE
END-IF.
IF METRIC = PROXY
PERFORM CHECK-REAL-OUTCOME
END-IF.
Comentário:
* DELEGATION
* DOES NOT CREATE
* ALIGNMENT.
Outro:
* A GREEN KPI
* CAN STILL PRODUCE
* A RED CUSTOMER.
Mais um:
* CONTRACTS ARE CODE
* FOR HUMAN BEHAVIOR.
Outro:
* ASK WHAT THE AGENT
* IS OPTIMIZING.
E naturalmente:
* NEVER ASK A DALEK
* TO MAXIMIZE
* GALACTIC PEACE
* WITHOUT CONSTRAINTS.
Nosso jovem fecha o membro.
Horas depois chega outro requisito.
— Precisamos reduzir CPU em 20%.
Ele quase começa a otimizar.
Mas pergunta:
— Por quê?
— Para reduzir custo.
— Alguma restrição de tempo de resposta?
— Não pode piorar.
— Batch window?
— Também não.
— Então nosso objetivo não é CPU mínima.
— Não?
Ele sorri.
— É custo menor preservando performance e janela.
O gerente olha.
— Faz diferença?
— Muita.
Pausa.
— Porque se eu otimizar exatamente a métrica errada...
Ele aponta para o terminal.
— o computador vai obedecer perfeitamente.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
O agente mais perigoso não é necessariamente aquele que desobedece. Às vezes é aquele que obedece perfeitamente ao incentivo errado.
E talvez essa seja a essência do Principal-Agent Problem:
quando delegamos uma decisão, não delegamos automaticamente nossos objetivos, nossos valores, nossa visão do risco ou aquilo que realmente consideramos sucesso. Tudo isso precisa ser alinhado deliberadamente.
☕🌀
Next stop: Goodhart’s Law — quando transformamos uma boa métrica em meta e descobrimos que as pessoas, os processos e até as máquinas podem aprender a melhorar o número sem melhorar aquilo que o número deveria representar.
