95%
dos pilotos enterprise de ia não geram impacto mensurável em p&l, segundo estudo da mit nanda initiative sobre cerca de 300 projetos.
mit nanda initiative, via the new stack · 2026um especialista sênior em operação ai-first, embedded no modelo forward deployed, pela fração de tempo que o diagnóstico definir. constrói e versiona o harness que faz a ia funcionar no trabalho real (agentes, skills, protocols, evals, automações), na sua infraestrutura. o que exigir código custom é especificado com o seu time de engenharia, que constrói. instala harness e autonomia, não software e dependência.
os modelos melhoram todo mês, sozinhos. o que separa piloto de resultado é o resto: fazer a ia funcionar dentro da infraestrutura real, com sistemas legados, regras de segurança, dados bagunçados e o jeito particular como o seu time trabalha. é nesse last mile que a maioria dos projetos morre.
dos pilotos enterprise de ia não geram impacto mensurável em p&l, segundo estudo da mit nanda initiative sobre cerca de 300 projetos.
mit nanda initiative, via the new stack · 2026é a distância entre a demo e a operação: contexto que não está escrito em lugar nenhum, processo que só existe na cabeça de alguém, integração que ninguém quer encostar, e nenhum dono claro do resultado. resolver isso não é comprar ferramenta: é trabalho de engenharia dentro de casa, com quem opera.
forward deployed engineer: o engenheiro sênior que trabalha dentro do cliente, alternando entre escrever código de produção e definir escopo com quem opera. a palantir criou o papel; em 2026 ele virou padrão dos maiores players de ia.
a palantir divide a engenharia em "devs" (uma capacidade, muitos clientes) e "deltas", os fdes: um cliente, muitas capacidades, dentro do ambiente do cliente.
blog.palantir.com · dev versus deltaunidade dedicada, com mais de us$ 4 bilhões de investimento inicial, pra colocar fdes dentro de organizações e fazer a ia gerar valor na operação.
openai.com · anúncio oficiala anthropic contrata fdes pra construir aplicações de produção dentro dos sistemas do cliente, entregando "mcp servers, sub-agents, and agent skills".
greenhouse oficial · job descriptiona ey formalizou a função fde no reino unido e irlanda. quando a big four cria o cargo, a função deixou de ser nicho.
ey.com · newsroomtodo mundo agora vende "ia na sua operação". a diferença aparece quando você pergunta a quem o trabalho responde no fim: ao roadmap do vendor, ao relatório, ao contrato de horas, ou à autonomia do seu time.
| /dimensão | fde de vendor | consultoria tradicional | bodyshop | residência rabbity |
|---|---|---|---|---|
| /o que entrega | sistema do vendor rodando no cliente | recomendação (slides) | horas de engenheiro | harness instalado + time operando |
| /lealdade | ao roadmap do vendor | ao relatório | ao contrato de horas | à autonomia do seu time |
| /código e setup | sim, no stack do vendor | raramente | sim, sem transferência | sim: memory, skills, protocols, gates, evals no seu repositório · código custom especificado com o seu time |
| /critério de fim | renovação (stickiness) | entrega do relatório | renovação | critérios de saída explícitos: o time dirige sozinho |
| /lock-in | alto, por design | n/a | n/a | nenhum · neutro de ferramenta |
a residência constrói e versiona o harness da sua operação: agentes, skills, protocols, evals e automações de workflow, montados com as ferramentas que o seu time já usa e conectados via mcp, no seu repositório, na sua infraestrutura. o que exigir código custom é especificado com o seu time de engenharia (spec executável, protocols, gates) e construído por ele: o código do produto core continua com quem sempre foi dono dele. esse recorte é a promessa: nada de virar bodyshop, nada de dependência.
seis dimensões de runtime governam a operação: é o rigor que separa harness de "chatbot instalado". riscos reais (memory poisoning, injeção via skills) são nomeados e mitigados por design, não descobertos em produção.
cada workflow entra na escada no degrau certo. subir de degrau é decisão de governança, com gate e critério, não acidente de entusiasmo.
quem faz separado de quem julga, inclusive na arquitetura dos agentes instalados. é o que mantém qualidade quando a velocidade sobe.
o harness instalado é organizacional: "o que nós sabemos", versionado e compartilhado. não é a ferramenta pessoal de um entusiasta.
o entregável não é um conjunto de automações. é a fundação pra loops.escalar vira repetição sobre a mesma base, não reinício
as tentativas famosas de operar com menos hierarquia (haier, zappos, valve, spotify) não quebraram por falta de informação circulando. quebraram por falta de accountability: quem decide, quem responde, quem é dono do resultado. a ia resolve bem o roteamento de informação; não resolve, por natureza, a responsabilização. por isso o harness rabbity a instala por design.
autonomia sobe degrau por degrau, e cada degrau passa por um gate com dono humano definido. quem aprova o quê fica escrito, não subentendido.
a interação entre agentes, ferramentas e pessoas é contrato explícito e auditável. quando algo dá errado, dá pra reconstruir o que aconteceu e por quê.
quem faz separado de quem julga, na arquitetura dos agentes e no desenho da operação. crítica independente embutida, não opcional.
não vendemos "elimine seus gerentes". vendemos a infraestrutura de coordenação que deixa claro quem responde pelo quê em cada degrau da escada de autonomia.
o esqueleto é fixo: um diagnóstico que desenha o formato, uma residência embedded com tempo definido, e um loop mensal que mantém tudo vivo. fração de tempo, duração e presença são calibrados caso a caso, no diagnóstico.
quem vem de um workshop rabbity já chega com ele pronto: canvas de dores, mapa de squads, maturidade. quem entra direto começa por aqui. é o diagnóstico que desenha o formato da residência: fração, duração, presencial e remoto.
1 a 2 squads por vez, sessões de trabalho no ambiente real: trava e conserto no mesmo bloco, sem aula. você sai com o harness versionado no seu repositório, 2 a 3 workflows rodando na escada com gates, evals dos fluxos críticos e um playbook escrito com o time, não para o time.
cadência de sessões de trabalho + canal assíncrono com sla definido. a fronteira de modelos, ferramentas e processos se move todo mês; acompanhar isso sozinho é um trabalho em si. o loop existe pra digerir essa mudança com critério.
harness sem manutenção apodrecetelemetria do harness revisada, evals rodando, o que quebrou consertado. o harness continua confiável conforme a operação muda.
workflows promovidos de degrau com gate e critério, gente nova treinada, squads novos entrando (cada expansão pode ser uma mini-residência).
o que saiu de novo em tecnologia e processo, filtrado com critério: o que entra no seu caminho, o que espera, o que se ignora. e o caminho atualizado conforme necessário.
quem faz um workshop rabbity (produto ou marketing) sai com 2 semanas de acompanhamento assíncrono incluídas. elas mostram em miniatura o que a residência aprofunda: o time tenta no ambiente real e o especialista destrava. foi assim que esta oferta nasceu, com o case-zero de produto pedindo exatamente esse formato de trabalho.
sem workshop antes? a residência começa por um diagnóstico dedicado: mapa de squads, dores, maturidade. o formato sai desenhado dele, e a conversa de escopo acontece com a operação mapeada, não no achismo.
operação construída em cima de hype apodrece rápido e cobra caro. a rabbity trabalha com números com fonte primária, trade-offs declarados e autonomia que sobe por decisão de governança, não por empolgação. é isso que produz operações sólidas e perenes: a solidez não é o freio da velocidade, é o que permite sustentar velocidade.
todo número citado tem fonte e contexto. quando uma história tem leitura dupla, as duas aparecem no material, não só a conveniente.
o que a ia não resolve entra no material: custo de supervisão, limites dos agentes, risco real. promessa sem trade-off é sinal de alerta, inclusive a nossa.
nenhum workflow sobe de degrau sem gate, eval e dono. rápido de verdade é o que não precisa voltar atrás em produção.
"o que a sua empresa entende que é genuinamente difícil de entender, e esse entendimento está ficando mais profundo a cada dia?"
jack dorsey e roelof botha · sequoia capital · 2026
o mercado montou o fde sobre um perfil de engenharia. a rabbity monta a residência sobre outro perfil, de propósito: método de produto e de marketing + implementação de ia em alta maturidade. porque o gargalo desta página não é escrever código, é fazer a operação funcionar; e o código que precisar existir já tem dono, o seu time de engenharia.
fundador da rabbity. mais de quinze anos em produto, marketing e estratégia digital, com passagens por times em escala e consultoria de transformação. opera ai-first no próprio trabalho todos os dias (memory · skills · protocols em loop) e conduz a residência com o mesmo método que instala: implementa ia madura dentro de times de produto e de marketing, especifica com a engenharia o que exigir código, e forma o time pra dirigir sozinho.
a regra que o próprio dorsey usa: as ferramentas constroem cerca de 80% do caminho; os últimos 20% são criatividade, gosto e julgamento. a residência é o profissional dos 20%, dentro da sua operação.
jack dorsey · entrevista oficial sequoia capital · 2026
manda uma mensagem no whatsapp. resposta no mesmo dia útil. a conversa começa por contexto: a sua operação, onde a ia empaca hoje, o que já foi tentado. se fizer sentido, o próximo passo é o diagnóstico que desenha o formato da residência.