Liderar a integração técnica da API Anthropic: o que aprendi arquitetando sistemas com Claude em produção

Esse é o artigo que eu gostaria de ter lido antes de liderar minha primeira integração séria com Claude. Não é um tutorial de primeiros passos. É um relato técnico denso de como penso a integração quando sou eu quem responde pela arquitetura, pelo custo em produção e pela manutenibilidade do sistema daqui a dois anos, com os apontamentos práticos que uso para justificar cada decisão perante o time e perante o cliente.

O erro que vejo repetido: tratar a API como um endpoint de chat

A maioria dos times que integra a API da Anthropic pela primeira vez comete o mesmo erro estrutural. Trata o modelo como se fosse um substituto de uma chamada de chat, envia uma mensagem, recebe uma resposta, imprime na tela. Funciona no protótipo e quebra na primeira semana de produção real, porque produção exige coisas que um chat não exige: contexto que persiste entre chamadas, ferramentas que o modelo pode invocar, controle de custo por requisição, previsibilidade de formato de saída e um plano de contenção para quando o modelo erra.

Minha primeira decisão como líder técnico em qualquer integração é separar claramente duas camadas. A camada de decisão, onde o modelo raciocina, escolhe ferramentas e produz linguagem, e a camada de execução, onde o sistema determinístico valida, persiste e aplica regras de negócio que não podem depender de inferência estatística. Essa separação parece óbvia escrita assim, mas na prática é a linha que a maioria dos times borra sob pressão de prazo, e é exatamente essa linha borrada que depois vira dívida técnica impossível de pagar.

A Messages API, que é o núcleo da API da Anthropic, foi desenhada justamente para suportar essa separação. Cada chamada recebe uma lista de mensagens, um modelo, um limite de tokens de saída e, opcionalmente, um conjunto de ferramentas e um prompt de sistema. O que o time decide fazer em torno desse contrato determina se a arquitetura vai escalar ou vai virar um emaranhado de prompts gigantes tentando fazer o trabalho que deveria estar no código.

Um ponto que muitos times esquecem logo no início: a Messages API é stateless. Não existe sessão persistida do lado da Anthropic entre uma chamada e outra, quem monta, resume e reenvia o histórico a cada requisição é a minha aplicação. Isso significa que o estado conversacional, o histórico resumido, os eventos de ferramenta já executados e a política de retenção de dado são responsabilidade inteiramente minha, não do modelo. Claude recebe o contexto que eu decido enviar, ele não é o dono desse contexto, e tratar essa fronteira com clareza evita um erro comum, que é depositar no modelo uma expectativa de memória que ele simplesmente não tem por contrato.

Foi exatamente esse princípio que apliquei em SIA. O núcleo de domínio, escrito em arquitetura hexagonal, nunca conhece detalhes de como o modelo é chamado. O Claude ocupa uma porta específica do hexágono, a porta de raciocínio e geração de linguagem, e nunca tem acesso direto ao banco de dados nem decide sozinho se uma reserva pode ser cancelada. Toda ação com efeito colateral real passa por uma camada de validação determinística antes de virar operação no sistema. O modelo sugere, o código decide.

Escolher o modelo certo não é escolher o mais forte

Uma decisão que recorrentemente cai sobre quem lidera a integração é qual modelo usar em cada ponto do sistema. Em vez de amarrar a arquitetura ao nome comercial do modelo, o que envelhece rápido porque a Anthropic lança e aposenta versões com frequência, trato cada modelo como um perfil operacional. Existe o perfil de baixo custo e baixa latência, hoje ocupado por Haiku, o perfil de equilíbrio para a maior parte da carga de produção, hoje ocupado por Sonnet, o perfil de raciocínio profundo para decisões caras de errar, hoje ocupado por Opus, e o perfil de capacidade de fronteira com restrições de acesso mais estritas, hoje ocupado por modelos de nível Mythos. Essa camada de abstração, que mantenho na configuração do sistema e não espalhada pelo código, é o que permite trocar de versão de modelo sem reescrever a lógica de roteamento inteira.

Na prática, uso Haiku para classificação, extração estruturada e qualquer etapa de alto volume onde a margem de erro tolerável é maior, como o roteamento inicial de intenção em SIA, que decide se a mensagem do usuário é uma consulta simples de disponibilidade ou algo que exige raciocínio mais profundo. Uso Sonnet como cavalo de batalha para a maior parte da lógica de agente, geração de respostas e orquestração de ferramentas, porque é onde a relação custo benefício fica mais favorável para carga de produção real. Reservo Opus para os pontos do sistema onde o raciocínio profundo realmente muda o resultado, análise jurídica complexa em Kazo.ai, arquitetura de código, decisões que exigem cadeias longas de inferência.

Apontamento técnico: esse roteamento por complexidade não precisa ser feito por outro modelo separado. É possível usar o próprio Haiku como classificador de complexidade na entrada do grafo de decisão, com latência baixa o suficiente para não impactar a experiência, e só escalar para Sonnet ou Opus quando a classificação indicar necessidade real. Isso evita o erro mais comum, que é escolher o modelo mais capaz para tudo, achando que assim se elimina risco. Isso apenas transfere o risco de qualidade para risco de custo e de latência, e em sistemas com volume real esse segundo risco costuma doer mais rápido que o primeiro.

Tool use é onde a arquitetura realmente acontece

Se existe um único recurso da API que separa uma integração amadora de uma integração de nível staff, é o uso correto de tool use. A ideia central é simples, você declara ferramentas com nome, descrição e schema de parâmetros, o modelo decide quando invocá-las e o seu código executa a lógica real e devolve o resultado na próxima chamada.

O ponto que a maioria subestima é que a descrição da ferramenta é, na prática, uma peça de engenharia de prompt tão importante quanto o próprio prompt de sistema. Ferramentas mal descritas geram chamadas erradas, parâmetros incompletos, e decisões de quando usar a ferramenta que não fazem sentido para o seu domínio. Trato o design de cada ferramenta como trato o design de um endpoint de API pública, com contrato claro, exemplos de uso corretos e incorretos documentados na própria descrição, e validação rígida do lado do meu código, nunca confiando cegamente no que o modelo retorna.

Em SIA, a ferramenta mais crítica não era genérica, era de domínio, consulta de disponibilidade de frota, criação e cancelamento de reserva, verificação de política de cada locadora. Declarei cada uma com o mesmo rigor que aplico a um endpoint público:

tools = [
    {
        "name": "cancelar_reserva",
        "description": (
            "Cancela uma reserva existente, identificada pelo id da reserva. "
            "Use apenas quando o usuário confirmar explicitamente a intenção "
            "de cancelamento. Não use para consultar política de cancelamento, "
            "use a ferramenta consultar_politica_tenant para isso. Retorna erro "
            "se a reserva já estiver cancelada ou fora da janela permitida."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "reserva_id": {"type": "string"},
                "motivo": {"type": "string"}
            },
            "required": ["reserva_id"]
        }
    }
]

Esse nível de descrição, incluindo o que a ferramenta não deve fazer e para onde redirecionar a intenção quando o caso não se aplica, reduziu de forma mensurável a taxa de chamadas incorretas nos primeiros testes de SIA. A ferramenta é chamada pelo modelo, mas o cancelamento real só acontece depois que o meu código confere se aquela reserva pertence ao tenant correto, se está dentro da janela de cancelamento e se o usuário autenticado tem permissão sobre ela.

A API também oferece um conjunto de ferramentas de servidor prontas, busca na web, busca sobre arquivos, execução de código em sandbox, edição de texto, um shell controlado e até uma ferramenta de busca sobre o próprio catálogo de ferramentas disponíveis, útil quando o agente tem acesso a um número grande demais de ferramentas para caber inteiro no prompt. Existe também um recurso de memória do lado do agente, pensado para persistir aprendizados entre sessões sem depender inteiramente do histórico de conversa. Uso as ferramentas de servidor quando o ganho de manutenção compensa a perda de controle fino, e escrevo minhas próprias ferramentas de domínio quando a lógica de negócio é específica demais para depender de um componente genérico da plataforma, que foi o caso em praticamente todas as ferramentas críticas de SIA e de Kazo.ai.

Apontamento técnico: para agentes que fazem várias chamadas de ferramenta em sequência, vale a pena revisar como o modelo lida com chamadas paralelas de ferramenta e como o fluxo de streaming intercala blocos de texto com blocos de chamada de ferramenta. O código consumidor precisa remontar corretamente esse estado antes de decidir se e quando executar uma ação real, e esse é um dos pontos onde mais vejo bugs sutis em implementações de primeira viagem.

Ferramentas com efeito colateral exigem idempotência

Validar a chamada antes de executar resolve parte do problema, mas não resolve tudo. A pergunta que faço em toda revisão de arquitetura é o que acontece se a mesma ferramenta for chamada duas vezes. E se houver retry de rede depois que a operação já foi executada do lado do meu sistema. E se o usuário confirmar o cancelamento e a conexão cair antes da resposta chegar de volta, levando o cliente a tentar de novo. E se o mesmo evento de fila for reprocessado por engano.

Em SIA, toda ação de negócio com efeito colateral carrega um identificador de operação próprio, derivado do tenant, do usuário e da intenção, não apenas do id técnico da chamada de ferramenta. Esse identificador funciona como chave de idempotência, o que significa que executar a mesma operação duas vezes com a mesma chave produz o mesmo resultado final, sem duplicar o efeito. Modelei o ciclo de vida de cada ação como uma máquina de estados explícita, solicitada, validada, confirmada, executada, falha, em vez de tratar a execução como um evento binário de sucesso ou erro. Isso me permite auditar exatamente em qual etapa uma operação ficou presa quando algo dá errado, reprocessar com segurança a partir do último estado consistente, e manter uma fila de mensagens mortas para os casos que exigem intervenção humana em vez de retry automático. Para ações irreversíveis, como o cancelamento definitivo de uma reserva fora da janela de tolerância, exijo uma confirmação explícita adicional antes de mover o estado para executado, mesmo que o modelo já tenha interpretado a intenção do usuário com clareza.

Esse nível de rigor parece exagero em um protótipo, mas é exatamente o que separa um agente que funciona bem em demonstração de um agente que sobrevive a rede instável, retry de cliente e reprocessamento de fila em produção real.

Saída estruturada como contrato, não como sugestão

Sistemas em produção raramente consomem texto livre. Consomem JSON que alimenta outro serviço, popula um banco de dados ou dispara um workflow. A API da Anthropic oferece suporte nativo a saída estruturada, o que elimina boa parte do trabalho frágil de parsing de texto que dominava as primeiras gerações de integrações com LLM.

Como líder técnico, insisto que qualquer ponto do sistema que precise de dado estruturado use esse recurso desde o primeiro dia, em vez de pedir no prompt para o modelo responder em JSON e torcer para o formato se manter estável. A diferença entre as duas abordagens é a diferença entre um contrato de API e uma promessa verbal. Um schema validado no lado do servidor, com o tipo de dado, os campos obrigatórios e os valores permitidos definidos explicitamente, é o que permite tratar a saída do modelo como qualquer outra fronteira de sistema, com testes automatizados de contrato, incluindo casos de borda que o schema deve rejeitar.

Mas é importante não confundir conformidade de schema com correção de domínio. Schema garante forma, não garante verdade. Um JSON perfeitamente válido, com todos os campos obrigatórios preenchidos e todos os enums dentro do conjunto permitido, ainda pode carregar uma decisão de negócio errada, uma data interpretada de forma incorreta, um valor monetário fora da realidade da operação. Trato o schema como a primeira barreira de qualidade, não como autorização final, e mantenho validação de domínio separada, no código, para as regras que nenhum schema genérico consegue expressar. Também trato o schema em si como um contrato versionado, qualquer mudança de campo obrigatório ou de enum é uma mudança de breaking change para quem consome essa saída, com o mesmo cuidado que teria ao alterar um contrato de API pública.

Extended thinking e o controle fino de esforço de raciocínio

O modo de raciocínio estendido permite que o modelo trabalhe um problema em etapas antes de produzir a resposta final, o que costuma melhorar sensivelmente a qualidade em tarefas de múltiplos passos, matemática, planejamento e depuração de lógica complexa. A plataforma também expõe controles mais finos sobre esse comportamento, incluindo ajuste de esforço de raciocínio e orçamento de tarefa, o que permite calibrar o quanto o modelo pode gastar pensando antes de responder, em vez de tratar o raciocínio estendido como liga ou desliga.

A decisão de onde ativar esse modo é uma decisão de produto tanto quanto técnica. Em uma etapa de triagem que precisa responder em menos de um segundo, como o roteamento inicial em SIA, o custo do raciocínio estendido não se paga. Em uma etapa de análise que só roda algumas vezes por dia e cujo erro custa caro, como uma revisão de contrato em Kazo.ai ou uma decisão de arquitetura assistida, o ganho de qualidade compensa cada token adicional. Parte do meu trabalho ao liderar essas integrações é mapear, tarefa por tarefa, onde o raciocínio estendido paga aluguel e onde é só gordura de latência.

Cache de prompt, janela de contexto e o custo real em multi tenant

Depois que a arquitetura funciona, a próxima batalha é o custo por requisição em escala, e é aqui que a maioria das integrações amadoras quebra o orçamento sem perceber. O cache de prompt permite marcar blocos estáveis do contexto, como instruções de sistema longas, documentação de domínio ou exemplos few shot, para que não sejam reprocessados do zero em cada chamada.

Em SIA, com múltiplos tenants e cada um com seu próprio conjunto de políticas, o prompt de sistema cresceu rápido. Segmentei esse prompt em blocos estáveis, instrução geral do agente, política do tenant, poucos exemplos few shot, marcados como pontos de cache, e blocos variáveis, o histórico recente da conversa, que ficam fora do cache. Essa decisão não foi uma otimização de última hora, foi tomada junto com o desenho inicial da arquitetura, porque adicionar cache depois que o sistema já está em produção sempre custa mais caro do que desenhar certo desde o início.

Para conversas longas ou agentes que acumulam muito histórico de ferramenta, a plataforma também oferece mecanismos de edição de contexto e compactação, que permitem podar ou resumir partes antigas da janela de contexto sem perder a coerência da conversa, além de ferramentas de diagnóstico de cache para entender onde o aproveitamento de cache está de fato acontecendo e onde está sendo invalidado por uma mudança inesperada no início do prompt. Esse tipo de diagnóstico é o primeiro lugar que olho quando o custo por conversa sobe sem uma razão aparente de produto.

A API de processamento em lote resolve a outra ponta, cargas assíncronas de alto volume, com redução de custo de cinquenta por cento em relação ao processamento síncrono. Uso batch para qualquer pipeline que não precise de resposta em tempo real, reprocessamento de base histórica, geração de relatórios noturnos, classificação massiva de documentos. Um erro comum de quem lidera a integração pela primeira vez é rodar esse tipo de carga na API síncrona só porque é o caminho que já está implementado, pagando o dobro sem necessidade nenhuma.

Limites de taxa não são um detalhe de infraestrutura, são uma decisão de arquitetura

A API organiza limites de taxa e de gasto em níveis de uso, com um algoritmo de balde de token controlando o consumo permitido ao longo do tempo. Isso parece um detalhe operacional até o dia em que o sistema atinge escala real e começa a receber erros de limite excedido no meio de um fluxo crítico.

Trato o dimensionamento de limites como parte do desenho da arquitetura, não como um ajuste de última hora. Isso significa desenhar filas e backoff exponencial desde a primeira versão do sistema, mesmo quando o volume inicial não justificaria essa complexidade, porque migrar de uma chamada síncrona ingênua para um sistema de filas resiliente depois que o produto já está em produção é sempre mais caro do que desenhar certo desde o início. Também significa que, ao liderar tecnicamente esse tipo de projeto, sou eu quem negocia com antecedência o aumento de tier de uso junto à Anthropic, em vez de descobrir o limite no meio de um pico de tráfego.

Apontamento técnico: a API de contagem de tokens permite estimar o custo de uma chamada antes de enviá-la, o que uso em SIA para decidir dinamicamente se uma conversa muito longa precisa passar por compactação de contexto antes da próxima chamada ao modelo, em vez de simplesmente deixar a janela de contexto estourar e receber um erro em produção.

MCP e a integração com sistemas externos

O Model Context Protocol mudou a forma como conecto Claude a sistemas externos, bancos de dados internos, ferramentas de terceiros, APIs corporativas. Em vez de escrever uma ferramenta customizada para cada integração, o MCP padroniza a exposição de ferramentas e recursos externos ao modelo através de um protocolo comum.

Do ponto de vista de liderança técnica, o valor real do MCP não é a conveniência de não escrever código de integração do zero. É a possibilidade de tratar cada fonte de dado externa como um componente desacoplado, testável isoladamente, com seu próprio ciclo de vida, em vez de acoplar tudo dentro do prompt ou do orquestrador principal do agente. Uso isso deliberadamente para manter a mesma arquitetura hexagonal que apliquei em SIA, o núcleo de domínio não conhece os detalhes de cada integração externa, apenas a interface que o protocolo expõe.

Segurança: prompt injection não é bug de prompt, é problema de arquitetura

Todo agente com acesso a ferramentas, busca na web, leitura de arquivo ou conexão MCP com sistema interno carrega uma superfície de ataque que não existia em um chatbot de texto simples. Conteúdo recuperado de um documento, de uma página web ou de um sistema externo pode conter instruções disfarçadas de dado, escritas para manipular o próximo raciocínio do modelo. Tratar isso como um problema de prompt, tentando blindar com mais uma instrução de sistema pedindo para o modelo ignorar instruções maliciosas, não resolve o problema pela raiz. A solução real está na arquitetura em volta do modelo, não dentro dele.

O princípio que aplico é o de menor privilégio possível para cada ferramenta. Nenhuma ferramenta crítica fica acessível sem uma camada de autorização determinística, escopada por tenant e por usuário autenticado, independente do que o modelo decidiu chamar. Separo com rigor o dado que foi recuperado de uma fonte externa da instrução que o sistema realmente deve executar, tratando todo conteúdo vindo de documento, página web ou integração externa como dado não confiável, nunca como comando. Mantenho uma lista de permissão explícita de quais ferramentas cada fluxo de conversa pode acessar, em vez de expor o catálogo inteiro para todo tipo de interação, e bloqueio deliberadamente encadeamentos de ferramenta que poderiam levar de uma leitura aparentemente inofensiva a uma ação sensível sem confirmação intermediária. Segredo, token de acesso, connection string e política interna sensível nunca entram no contexto que vai para o modelo, porque qualquer coisa que chega até o contexto pode, em tese, ser refletida de volta em uma resposta. O MCP, nesse desenho, é uma fronteira de confiança que preciso proteger com a mesma seriedade de qualquer integração externa, não um atalho mágico que resolve integração sem exigir essa disciplina.

Streaming e experiência do usuário

Para qualquer interface voltada a usuário final, o streaming de resposta deixou de ser opcional. A percepção de velocidade de um sistema conversacional depende mais de quando o primeiro token aparece do que do tempo total de geração. Implemento streaming como padrão em toda interface interativa e reservo chamadas não streaming para processamento em background, onde ninguém está olhando a tela esperando o token seguinte.

Avaliação contínua, não teste único

Um sistema baseado em modelo de linguagem não passa em um teste e fica aprovado para sempre. O comportamento pode variar entre versões de modelo, entre mudanças sutis no prompt, entre diferentes distribuições de entrada do usuário real. Como líder técnico, o compromisso que assumo desde o primeiro sprint é construir um conjunto de avaliações automatizadas que rode continuamente, não apenas na primeira entrega.

Em SIA, a validação do primeiro tenant, a locadora de veículos, só foi exposta a tráfego real depois que o conjunto de avaliação cobrindo os fluxos mais críticos, criação de reserva, cancelamento, consulta de disponibilidade, estava estável. A expansão para novos tenants seguiu o mesmo padrão, nunca configuração solta em produção sem passar antes pelo mesmo conjunto de avaliação, adaptado às políticas específicas daquele cliente, o que tornou a incorporação de um novo tenant um processo medido em dias e não em semanas. Trato mudança de modelo, mudança de prompt e mudança de ferramenta exatamente como trato uma mudança de schema de banco de dados, nada entra em produção sem passar pelo conjunto de avaliação primeiro.

Versionamento e rollout como disciplina de produção

Avaliação contínua só funciona de verdade se cada peça do sistema for versionada como um artefato de produção, não como um detalhe implícito de configuração. Trato o prompt de sistema, o schema de cada ferramenta, a versão do modelo e a política de autorização aplicada em cada fluxo como artefatos com número de versão, changelog e histórico, exatamente como trato uma migração de banco de dados. A Anthropic aposenta versões de modelo com um cronograma de depreciação, e sistemas que amarram lógica de negócio implicitamente ao comportamento de uma versão específica sofrem quando essa migração chega sem aviso na camada de código.

O processo que sigo para qualquer mudança nessa camada é o mesmo que aplicaria a uma mudança de infraestrutura crítica. Libero a nova versão de prompt, de schema ou de modelo primeiro para uma fatia pequena de tráfego, um tenant piloto ou uma porcentagem controlada de conversas, comparo métricas de qualidade e de custo contra a baseline anterior, e só então amplio o rollout depois de confiança suficiente nos números. Mantenho a capacidade de reverter para a versão anterior em minutos, não em um novo deploy, porque parte da premissa de que uma mudança de prompt ou de modelo pode se comportar de forma sutilmente diferente em produção do que se comportou no conjunto de avaliação, por maior que esse conjunto seja. Registrar, em cada resposta gerada, qual versão de modelo, de prompt, de schema de ferramenta e de política foi aplicada é o que transforma uma regressão de qualidade de mistério em investigação com dado concreto.

Observabilidade: o que realmente meço em sistemas com Claude

Custo total e taxa de acerto do conjunto de avaliação são o começo, não o fim, da observabilidade de um sistema com modelo de linguagem em produção. Em uma resposta ruim sem rastreabilidade, o time só enxerga o sintoma, nunca a causa. Sem rastro por tenant, por versão de prompt, por chamada de ferramenta, por custo e por latência, não existe operação real do sistema, existe apenas observação de sintoma.

As métricas que acompanho de perto em qualquer sistema que lidero incluem custo por conversa e por tenant, taxa de aproveitamento de cache, volume de token de entrada e de saída por tipo de fluxo, latência nos percentis mais altos e não apenas na média, taxa de chamada de ferramenta e taxa de erro dentro dessas chamadas, taxa de violação de schema na saída estruturada, taxa de fallback acionado, taxa de retry e, por fim, taxa de escalonamento para atendimento humano quando o agente não consegue resolver a solicitação sozinho. Acompanho também a variação dessas métricas entre versões de prompt e de modelo, porque uma regressão de qualidade raramente aparece como um erro explícito, ela aparece primeiro como uma variação sutil nesses números.

Onde rodar: API direta, Bedrock, Vertex ou Foundry

A Anthropic disponibiliza o mesmo modelo através de múltiplas superfícies, a API direta, o Amazon Bedrock, o Google Cloud Vertex AI e o Microsoft Foundry. A escolha entre elas raramente é uma questão técnica pura, é uma questão de onde o resto da infraestrutura do cliente já vive, de requisitos de conformidade e de compromissos de nuvem já assumidos.

Quando lidero essa decisão para um cliente que já opera inteiramente dentro de um ecossistema de nuvem específico, geralmente recomendo manter a integração dentro desse mesmo ecossistema, para simplificar faturamento consolidado e governança de identidade. Quando o cliente não tem esse compromisso prévio, prefiro a API direta pela previsibilidade de lançamento de novos recursos, que costuma chegar primeiro por esse canal antes de se propagar para as plataformas parceiras.

Checklist que uso antes de colocar Claude em produção

Antes de qualquer sistema com Claude sair de homologação, passo por uma lista curta de perguntas que aprendi a fazer da forma mais difícil, revisando incidentes e retrabalho de projetos anteriores. Qual parte da decisão é responsabilidade do modelo e qual é responsabilidade do código. Onde entram as ferramentas e qual delas tem efeito colateral real sobre dado do cliente. Existe schema de saída validado do lado do servidor, não apenas uma instrução de formato no prompt. Existe um conjunto de avaliação automatizada cobrindo os fluxos críticos, e ele roda a cada mudança de modelo, prompt ou ferramenta. Existe um caminho de fallback para quando o modelo se recusa, erra o formato ou estoura o limite de tokens. Existe controle de custo por chamada e por conversa, não apenas um teto mensal descoberto no fim do mês. Existe estratégia de cache de prompt desenhada junto com a arquitetura, não encaixada depois. Existe tratamento de limite de taxa com fila e backoff, não apenas uma chamada síncrona torcendo para não estourar. Existe observabilidade por tenant, permitindo isolar o comportamento e o custo de cada cliente dentro do mesmo sistema.

Uso essa lista como critério de saída de qualquer sprint que toque a camada de integração com o modelo. Se alguma dessas respostas ainda é não, o sistema não está pronto para tráfego real, por melhor que o protótipo pareça em uma demonstração controlada.

O papel do líder técnico nessa integração

Depois de liderar várias dessas integrações, incluindo o desenho completo de SIA do zero, cheguei a uma conclusão que hoje guia como estruturo qualquer projeto novo com a API da Anthropic. O trabalho de maior alavancagem não é escrever a chamada de API, isso qualquer desenvolvedor pleno aprende em uma tarde. É decidir, antes de qualquer linha de código, onde termina a responsabilidade do modelo e onde começa a responsabilidade do sistema determinístico. É escolher o modelo certo para cada etapa em vez do modelo mais impressionante para tudo. É desenhar o contrato de saída como um contrato de API de verdade. É tratar cache, custo e limite de taxa como parte da arquitetura, não como um problema de operação para resolver depois que o incêndio já começou.

No fundo, a frase que resume minha filosofia evoluiu ao longo desses projetos. O modelo sugere, o código decide, a política autoriza, a observabilidade mede, o versionamento controla, e o sistema consegue falhar sem corromper o domínio. Modelo de linguagem fino, modelo de domínio espesso continua sendo o resumo mais compacto dessa ideia, validado em cenários reais de produção dentro de SIA, e é também o critério mais confiável que uso para avaliar se uma integração técnica com a API Anthropic vai envelhecer bem ou vai virar um sistema impossível de manter no ano seguinte.