Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
Em resumo
A diretoria aprova orçamento para um agente que prepara a renegociação de dívidas de clientes. O time de engenharia diz que monta o agente em poucas semanas, e um fornecedor apresenta uma demonstração que já funciona. A discussão costuma girar em torno da capacidade técnica, a parte menos decisiva da escolha. A decisão de build vs buy em IA depende de onde está a vantagem competitiva, do custo ao longo dos anos, do prazo até o primeiro processo funcionando, de quem mantém o sistema e de quem fica com o contexto. O último ponto passa pelo Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
Construir significa montar internamente as peças que levam um modelo de linguagem a operar dentro de um processo:
Comprar significa contratar uma plataforma, que entrega parte da pilha, ou uma aplicação, que entrega o caso de uso inteiro. Nas duas modalidades, alguém ainda conecta as fontes, configura acessos e acompanha a qualidade.
Uma distribuidora que precifica frete com uma regra própria, refinada ao longo de anos, tem pouco a ganhar com um agente genérico de cotação. No build vs buy dessa empresa, a regra é a vantagem, e entregá-la a um fornecedor do mercado inteiro dilui a diferença.
Construir também faz sentido diante de dado proprietário que nenhum produto pronto interpreta, de exigência regulatória que o fornecedor não cobre ou de volume que torna a cobrança por chamada mais cara que um time dedicado. Nos três casos, a condição é ter pessoas para manter o sistema depois do lançamento.
Transcrever reuniões, classificar chamados e responder questionários de segurança funcionam de forma parecida em quase toda empresa. Nesses casos, o build vs buy pende para a compra: um fornecedor com muitos clientes dilui a manutenção entre eles e entrega o primeiro resultado em semanas.
O orçamento de construção cobre a entrega, e o custo maior aparece depois. Em 1992, Ward Cunningham comparou colocar no ar a primeira versão do código a contrair uma dívida, em que cada minuto gasto em código ainda imperfeito conta como juros até ela ser paga com uma reescrita, ideia que vale para cada integração e filtro que o time constrói e mantém.
Com modelos de linguagem, a lista cresce. Uma versão nova do modelo muda as respostas. Uma fonte altera o schema e a integração quebra. Uma área revê a política de acesso e a cópia no agente fica velha. Comparar licença com custo de projeto deixa de fora o time que cuida disso por anos.
O risco do lado da compra no build vs buy aparece na terceira ou quarta aplicação. Cada uma se conecta ao CRM do próprio jeito, guarda uma cópia das permissões e aprende a própria versão do que é um contrato vigente. O contexto fica espalhado entre fornecedores, e duas aplicações respondem de formas diferentes à mesma pergunta.
Na troca de uma delas, o mapeamento de entidades, as definições ajustadas e o histórico de correções saem junto com o contrato.
Um arranjo frequente de build vs buy é comprar a camada de base e construir os casos de uso que diferenciam. Ele funciona quando a divisão está escrita: a base concentra integração, contexto e permissão, e o time dedica a maior parte das horas aos poucos casos que distinguem a empresa, sem integração própria por caso.
O risco é ficar no meio, com base adotada pela metade e casos sem dono. Um sinal precoce é o time gastar mais horas mantendo conexões do que entregando casos de uso novos.
O Company Brain conecta as fontes uma vez e organiza o contexto em grafo de conhecimento, ontologia do negócio e camada semântica. A permissão é herdada do sistema de origem, e cada resposta aponta a fonte.
Sobre essa base, a escolha de build vs buy passa a ser feita caso a caso. O time constrói os agentes que diferenciam a empresa e conecta os agentes comprados pelo mesmo caminho, via MCP, o protocolo aberto que liga modelos a fontes de contexto. O contexto permanece no perímetro da empresa quando um agente ou modelo é trocado. Cada agente recebe só o recorte que a pergunta exige, o que reduz tokens e permite usar um modelo mais barato.
A camada de base reduz o trabalho repetido e deixa com a empresa as decisões: qual processo diferencia, quem é dono de cada definição e quem opera cada agente. Ela depende de fontes acessíveis e de um responsável pelo contexto compartilhado.
O primeiro passo é listar os casos de uso previstos e marcar, em cada um, se o processo diferencia a empresa e quais fontes consulta. Os casos que repetem as mesmas fontes indicam o que deve ir para a base. Os casos genéricos são candidatos à compra. Os poucos que diferenciam entram na fila de construção, com uma pessoa nomeada para mantê-los.