DEV Community: Robson Concesso | Engenhoso

Do “200 OK” à entrega real: o que aprendi investigando mensagens no Engenhoso AI

Robson Concesso | Engenhoso — Mon, 17 Aug 2026 20:55:56 +0000

Durante o desenvolvimento do Engenhoso AI, encontrei um daqueles problemas que parecem simples quando descritos em uma frase:

uma mensagem era enviada, o sistema aparentemente funcionava, mas o destinatário nem sempre recebia a resposta como esperado.

À primeira vista, a pergunta parecia óbvia:

onde estava o erro?

Mas sistemas distribuídos raramente respondem bem a perguntas excessivamente simples.

Uma mensagem que atravessa WhatsApp, webhook, aplicação, modelo de inteligência artificial e novamente a infraestrutura de mensageria não percorre um único caminho.

Ela atravessa uma cadeia de acontecimentos.

E foi justamente essa cadeia que precisei aprender a observar.

O primeiro indício: `POST /webhook 200 OK`

Nos logs do serviço que hospeda o webhook do Engenhoso AI, as requisições apareciam normalmente:

POST /webhook HTTP/1.1 200 OK

Em um primeiro momento, isso parecia significar que tudo estava funcionando.

Mas havia um problema conceitual nessa interpretação.

Um 200 OK apenas informava que determinada requisição havia sido recebida e tratada pelo endpoint.

Ele não respondia às perguntas seguintes:

era uma mensagem enviada pelo usuário?
era apenas uma atualização de status da Meta?
a aplicação chamou a OpenAI?
a resposta foi gerada?
a Meta aceitou a resposta para envio?
a mensagem chegou ao telefone do destinatário?
ela foi lida?

Foi então que uma distinção aparentemente simples se tornou central para o diagnóstico:

Webhook recebeu ≠ IA respondeu ≠ Meta aceitou ≠ mensagem foi entregue ≠ mensagem foi lida

Em software, duas etapas consecutivas podem parecer uma coisa só quando não temos instrumentos para observá-las.

O teste com comandos locais

O Engenhoso AI possui alguns comandos locais que não dependem de geração por inteligência artificial.

Um deles é AJUDA.

Durante os testes, esse comando funcionou.

A mensagem chegou ao webhook, foi reconhecida e o menu foi devolvido ao usuário.

Isso permitiu retirar alguns suspeitos da investigação.

Se AJUDA funcionava, então pelo menos parte deste caminho estava operacional:

WhatsApp → Meta → Webhook → Aplicação → Meta → WhatsApp

Mas uma pergunta aberta dependia de uma etapa adicional:

Aplicação → OpenAI → Aplicação

Era necessário investigar essa fronteira separadamente.

O contador da API também pode enganar

Durante parte da investigação, o painel da API permaneceu mostrando o mesmo número de solicitações.

Isso parecia indicar que as perguntas não estavam chegando à OpenAI.

Mais tarde, porém, o contador mudou.

As solicitações estavam sendo contabilizadas.

O que havia ocorrido era uma diferença temporal entre o acontecimento dentro da aplicação e a atualização que eu observava no painel.

Foi um aprendizado importante:

um painel de uso é uma ferramenta de observação, mas não deve ser confundido automaticamente com um log em tempo real da aplicação.

Quando investigamos um sistema distribuído, precisamos saber exatamente o que cada instrumento mede.

Descobrindo a chamada real da OpenAI

Em vez de continuar formulando hipóteses a partir dos painéis, fui ao código.

A aplicação utiliza a Responses API e uma chamada semelhante a:

response = await self._client.responses.create(
    model=self._model,
    instructions=...,
    input=text,
    reasoning={"effort": OPENAI_REASONING_EFFORT},
    max_output_tokens=self._max_output_tokens,
    store=False,
)

Algumas informações começaram então a ficar objetivas.

O projeto estava configurado para utilizar um modelo definido por variável de ambiente.

O esforço adicional de raciocínio estava desativado:

OPENAI_REASONING_EFFORT = "none"

Também encontrei:

max_retries=0

Ou seja, o cliente não estava realizando sucessivas tentativas automáticas capazes de explicar sozinho uma espera de vários minutos.

Mais importante ainda: a aplicação possuía limites explícitos de tempo.

Timeout não era apenas uma hipótese

O projeto já possuía uma arquitetura de deadlines.

Na configuração de referência apareciam, entre outros, estes valores:

OPENAI_TIMEOUT_SECONDS=12
OPENAI_WEBHOOK_TOTAL_TIMEOUT_SECONDS=15

E o código realmente propagava um prazo para a geração.

De maneira simplificada:

generation_task = asyncio.create_task(
    _run_openai_generation(...)
)

generation_timed_out = not await _wait_for_openai_task(
    generation_task,
    deadline=openai_deadline,
)

Quando o limite era ultrapassado, o Engenhoso AI selecionava uma resposta de fallback.

Isso explicava uma mensagem que apareceu em um dos testes:

Desculpe, não consegui gerar uma resposta agora. Tente novamente em alguns instantes.

Poucos minutos depois, a mesma pergunta recebeu uma resposta normal.

O problema era, portanto, intermitente.

E já não fazia sentido atribuir automaticamente vários minutos de espera a uma única chamada indefinida para o modelo.

O envio à Meta também tinha prazo

Continuei seguindo o código.

A própria etapa de envio da resposta possuía um deadline:

remaining_delivery_seconds = delivery_deadline - loop.time()

if remaining_delivery_seconds <= 0:
    return

E a chamada era executada dentro de uma janela controlada:

async with asyncio.timeout_at(meta_deadline):
    await _send_started_reply(...)

Isso trouxe outra conclusão importante.

O projeto já havia sido construído para tentar impedir que uma operação permanecesse indefinidamente presa em uma etapa externa.

Mas ainda faltava uma informação fundamental:

o que acontecia depois que a Meta aceitava uma mensagem?

O ponto cego: `statuses`

A API do WhatsApp envia callbacks relacionados ao estado das mensagens.

Entre eles podem aparecer estados como:

sent
delivered
read
failed

O Engenhoso AI já possuía um teste que verificava que uma atualização de status deveria ser ignorada como mensagem de usuário:

def test_atualizacao_de_status_e_ignorada() -> None:
    ...
    assert response.status_code == 200
    assert fake.sent == []

Isso estava correto.

Um callback de status não deve provocar uma nova resposta automática.

O problema era outro:

ele também desaparecia do ponto de vista da observabilidade.

O código extraía:

messages = _extract_messages(payload, settings)

Mas um callback poderia conter, por exemplo:

{
  "statuses": [
    {
      "status": "delivered"
    }
  ]
}

em vez de uma nova mensagem.

Nesse caso, o webhook respondia 200 OK, mas eu não conseguia saber pelo log se aquele evento representava sent, delivered, read ou até failed.

Foi aí que percebi que o problema não era apenas corrigir alguma coisa.

Era tornar o sistema capaz de explicar o que estava acontecendo.

Criando observabilidade sem registrar a conversa

Foi criada uma função independente para extrair apenas os estados técnicos:

def _extract_status_updates(payload):
    ...

Conceitualmente, ela percorre:

entry → changes → field = messages → value → statuses

e identifica estados como sent, delivered, read e failed.

Mas havia outra preocupação.

Observabilidade não deveria significar registrar indiscriminadamente informações dos usuários.

Por isso, o message_id original não precisava aparecer nos logs.

Foi utilizada uma referência derivada:

message_ref = (
    hashlib.sha256(message_id.encode("utf-8")).hexdigest()[:12]
    if message_id
    else "unknown"
)

Os registros podem então assumir formas semelhantes a:

whatsapp_status status=sent ref=8a92e740fb21 timestamp=...

whatsapp_status status=delivered ref=8a92e740fb21 timestamp=...

whatsapp_status status=read ref=8a92e740fb21 timestamp=...

A mesma referência permite correlacionar os eventos sem registrar:

o texto da conversa;
o telefone;
o nome do usuário;
o identificador original da mensagem.

Para mim, esse ponto é particularmente importante.

Observabilidade não precisa significar abandono da privacidade.

Testar antes de integrar

Antes de conectar essa informação ao fluxo real, acrescentei um teste específico para os estados sent, delivered, read e failed.

A sequência de desenvolvimento foi deliberadamente simples:

criar extrator → criar teste → ligar ao log → Pull Request → Merge → Deploy

A alteração foi desenvolvida em uma branch separada:

fix/whatsapp-status-observability

Depois passou por Pull Request antes de chegar à main.

Esse processo pode parecer mais trabalhoso do que editar diretamente a produção.

Mas existe uma diferença entre fazer uma mudança e construir um histórico compreensível de mudanças.

Quanto mais o projeto cresce, mais essa diferença importa.

A infraestrutura também entrou no experimento

Durante a investigação, o webhook ainda estava executando em uma instância gratuita do serviço de hospedagem.

Decidi migrá-lo para uma instância paga de entrada.

No momento da mudança, a configuração selecionada foi:

Starter
0,5 CPU
512 MB de RAM

A decisão não foi tomada porque eu tivesse demonstrado que a hospedagem era a causa de todas as falhas.

Essa distinção é importante.

A migração foi uma forma de retirar uma variável da investigação e dar ao webhook uma infraestrutura mais adequada ao seu papel atual.

Depois do deploy, o serviço voltou ao estado Live, enquanto o health check continuou respondendo 200 OK.

A partir desse momento, o comportamento posterior poderia ser comparado com os registros anteriores à migração.

Não é correto afirmar:

“o plano pago resolveu o problema”

apenas porque uma mensagem posterior funcionou.

É necessário observar uma série de interações.

Essa diferença entre coincidência temporal e evidência causal é um aprendizado que considero importante também fora da programação.

O que mudou na maneira de diagnosticar

Antes dessa investigação, uma pergunta poderia ser formulada assim:

Por que a pessoa não recebeu a mensagem?

Agora ela pode ser dividida em perguntas melhores:

O webhook recebeu o evento?
Era uma mensagem ou um callback de status?
A aplicação decidiu chamar a IA?
A geração terminou ou ocorreu timeout?
Foi utilizado fallback?
A resposta foi enviada para a Meta?
A Meta marcou como sent?
Foi marcada como delivered?
Foi marcada como read?
Houve failed?

Quanto melhor a pergunta técnica, menor a necessidade de adivinhar.

Uma arquitetura que começou a se tornar observável

Hoje consigo representar o fluxo de forma mais clara:

Usuário → WhatsApp → Meta → Webhook Engenhoso AI

A partir do webhook, a aplicação pode seguir por um comando local ou por geração de IA.

Quando existe geração:

Webhook → OpenAI → resposta gerada → Meta

Depois disso, os callbacks ajudam a observar o que ocorreu com a mensagem:

Meta → sent → delivered → read

ou, quando algo não ocorre como esperado:

Meta → failed

O sistema não ficou apenas mais fácil de depurar.

Ele ficou mais capaz de contar a própria história operacional.

O aprendizado maior

Quando comecei essa investigação, eu procurava um erro.

No decorrer do processo, percebi que havia uma questão anterior ao erro:

eu possuía instrumentos suficientes para saber onde ele estava?

Nem sempre a próxima melhoria de um sistema é uma nova funcionalidade.

Às vezes, o que falta é capacidade de observação.

Um 200 OK pode ser verdadeiro e, ao mesmo tempo, insuficiente.

A chamada da IA pode ter acontecido e o painel ainda não ter atualizado.

A Meta pode ter aceitado uma mensagem sem que isso signifique que ela já chegou ao destinatário.

São estados diferentes.

E aprender a respeitar essas diferenças talvez seja uma das mudanças mais importantes quando um projeto deixa de ser apenas um experimento e começa a se comportar como um sistema real.

O Engenhoso AI continua sendo, para mim, um ambiente de aprendizagem.

Cada dificuldade técnica revela não apenas alguma coisa sobre Python, APIs, webhooks ou inteligência artificial.

Ela revela também uma forma de pensar:

antes de corrigir aquilo que não compreendemos, precisamos construir meios para enxergá-lo.

Transparência sobre o processo

Este texto nasceu de uma experiência real de desenvolvimento do projeto Engenhoso AI.

Ferramentas de inteligência artificial foram utilizadas como apoio na investigação técnica, organização das hipóteses, leitura do código e revisão do texto.

As decisões sobre arquitetura, testes, alterações no projeto, interpretação dos resultados e publicação permanecem sob responsabilidade do autor.

Engenhoso AI
Aprender, construir, observar e compreender.

Minha jornada entre Inteligência Artificial, Artes Visuais e experiência industrial

Robson Concesso | Engenhoso — Fri, 07 Aug 2026 19:16:31 +0000

Durante muito tempo, tecnologia, arte e experiência industrial pareceram ocupar espaços diferentes em minha trajetória. De um lado, o trabalho prático, cercado por processos, equipamentos, riscos e problemas que exigem soluções concretas. De outro, a música e as artes visuais, que me ensinaram a observar, interpretar e criar. Mais recentemente, a Inteligência Artificial passou a ocupar um terceiro espaço — e, aos poucos, percebi que esses caminhos não precisavam permanecer separados.

Atualmente estudo Tecnologia em Inteligência Artificial e Licenciatura em Artes Visuais. Ao mesmo tempo, continuo trazendo comigo uma experiência construída no ambiente industrial e uma relação constante com a música e a criação. Foi justamente desse encontro entre áreas aparentemente distintas que surgiu uma pergunta que hoje orienta boa parte dos meus estudos: o que podemos criar quando conhecimento técnico, criatividade e experiência prática deixam de competir entre si e começam a dialogar?

Este espaço no DEV Community nasce como uma tentativa de registrar essa busca. Não pretendo escrever como alguém que já possui todas as respostas, mas como estudante e criador que deseja compreender melhor aquilo que aprende, aplicar conceitos em projetos reais e compartilhar o percurso com outras pessoas.

De onde venho

Minha trajetória profissional foi construída, em grande parte, dentro do ambiente industrial. Trabalho com solda cerâmica, uma atividade em que conhecimento técnico, atenção aos procedimentos, segurança e capacidade de resolver problemas fazem parte da rotina.

A indústria me ensinou algo que hoje reconheço como importante também para o estudo da tecnologia: uma solução não é valiosa apenas porque parece interessante em teoria. Ela precisa funcionar diante das condições reais, respeitar limites, reduzir riscos e produzir um resultado que possa ser compreendido e repetido.

Foi nesse ambiente que desenvolvi boa parte da minha maneira de observar problemas. Antes de pensar em ferramentas sofisticadas, procuro compreender o processo, identificar suas variáveis e perguntar o que realmente precisa ser resolvido.

Com o tempo, percebi que essa forma de pensar poderia dialogar com outras áreas que sempre fizeram parte da minha vida. A arte trouxe sensibilidade e interpretação; a música, estrutura e expressão; e a tecnologia passou a oferecer novas possibilidades para transformar ideias em sistemas e experiências concretas.

Por que comecei a estudar Inteligência Artificial

Meu interesse pela Inteligência Artificial não surgiu apenas pela novidade da tecnologia, mas principalmente pelas perguntas que ela começou a despertar em mim. Percebi que não se tratava somente de máquinas capazes de gerar textos, imagens ou respostas, mas de um campo muito mais amplo, envolvendo conhecimento, linguagem, tomada de decisão, automação e formas diferentes de representar problemas.

Essa percepção despertou em mim o desejo de compreender o que existe por trás das ferramentas que utilizamos. Em vez de permanecer apenas como usuário de sistemas de inteligência artificial, comecei a buscar uma formação que me permitisse entender seus fundamentos, suas possibilidades e também seus limites.

Ao ingressar no curso de Tecnologia em Inteligência Artificial, comecei a entrar em contato com temas como algoritmos, aprendizado de máquina, IA simbólica, engenharia do conhecimento, sistemas baseados em regras e desenvolvimento de soluções inteligentes. Cada novo conceito passou a modificar também a maneira como eu observava problemas que já conhecia em outros contextos.

Foi nesse processo que compreendi uma diferença importante entre simplesmente utilizar uma tecnologia e procurar entender como ela pode ser estruturada para resolver um problema real. Essa mudança de perspectiva passou a orientar meus estudos e, posteriormente, também o desenvolvimento dos meus próprios projetos.

Quanto mais estudo Inteligência Artificial, mais percebo que aprender essa área não significa apenas conhecer modelos ou ferramentas. Significa aprender a formular melhores perguntas, representar conhecimento, reconhecer limites e decidir em quais situações a automação realmente acrescenta valor.

Arte, música e tecnologia não precisam estar separadas

Durante muito tempo, arte, música e tecnologia foram tratadas por mim como caminhos diferentes. Com o avanço dos meus estudos, porém, tornou-se mais claro para mim que todas essas áreas lidam, de alguma forma, com criação, linguagem, estrutura e interpretação.

Nas Artes Visuais, aprendo a observar formas, relações, composição, símbolos e maneiras diferentes de comunicar uma ideia. Na música, encontro ritmo, organização, emoção e construção de sentido. Na Inteligência Artificial, encontro sistemas capazes de representar informações, reconhecer padrões e apoiar processos de criação e decisão.

Essa aproximação me fez compreender que tecnologia não precisa ocupar o lugar da criatividade humana. Ela pode funcionar como ferramenta, meio de experimentação e até como espaço de diálogo entre diferentes formas de conhecimento.

Essa percepção também influenciou a maneira como venho desenvolvendo meus próprios projetos. Em vez de pensar a Inteligência Artificial apenas como código ou automação, comecei a considerar também identidade visual, linguagem, experiência de interação e a forma como uma pessoa se sente ao utilizar um sistema.

Talvez seja justamente nessa interseção que eu encontre meu maior interesse: investigar o que acontece quando pensamento técnico, sensibilidade artística e experiência prática deixam de caminhar separados e passam a contribuir para uma mesma construção.

Quando o estudo começou a se transformar em projeto

Em determinado momento, percebi que apenas estudar os conceitos não era suficiente para mim. Eu precisava experimentar, testar, errar, corrigir e observar como aquelas ideias se comportavam quando colocadas diante de um problema real.

Foi assim que comecei a transformar parte do conhecimento adquirido nos estudos em pequenos projetos e, gradualmente, em sistemas mais estruturados. Conceitos como automação, APIs, regras determinísticas, persistência de dados, interação com usuários e organização do conhecimento deixaram de ser apenas assuntos estudados e passaram a fazer parte de decisões concretas de desenvolvimento.

Esse processo também modificou minha forma de aprender. Quando um conceito precisa funcionar dentro de um projeto, surgem perguntas que muitas vezes não aparecem durante uma leitura ou uma aula. É necessário pensar em falhas, segurança, comportamento inesperado, experiência do usuário e manutenção.

A prática começou, então, a funcionar como uma extensão do estudo. Cada problema encontrado no desenvolvimento me levava novamente à teoria, e cada novo conceito estudado abria possibilidades para melhorar aquilo que eu estava construindo.

Foi nesse movimento entre teoria e experimentação que começou a surgir o Engenhoso AI.

O nascimento do Engenhoso AI

O Engenhoso AI começou como uma forma de reunir, em um mesmo projeto, diferentes conhecimentos que eu vinha estudando e experimentando. A proposta não era criar apenas um chatbot, mas construir um ambiente em que inteligência artificial, automação, regras explícitas, interação humana e identidade visual pudessem funcionar de maneira integrada.

Ao longo do desenvolvimento, o projeto passou a incorporar elementos como integração com o WhatsApp, comandos locais, persistência de dados, mecanismos de atendimento humano, organização de respostas, segurança e uma identidade visual própria.

Cada nova funcionalidade trouxe também novas perguntas. Quando uma resposta deve ser automatizada? Em quais situações uma regra explícita é mais adequada do que uma resposta generativa? Como preservar a privacidade? Como permitir que uma pessoa assuma a conversa quando necessário? Como tornar a interação mais clara e menos impessoal?

Essas questões fizeram com que o Engenhoso AI se tornasse, para mim, mais do que um projeto técnico. Ele passou a funcionar como um laboratório de aprendizagem, no qual conceitos estudados na faculdade podem ser confrontados com decisões reais de desenvolvimento.

O projeto ainda está em evolução, e talvez essa seja justamente uma de suas maiores contribuições para minha formação: ele me obriga a aprender continuamente, revisar decisões, reconhecer erros e transformar problemas encontrados no caminho em novas oportunidades de estudo.

Por que decidi compartilhar o que estou aprendendo

Ao longo dos meus estudos, comecei a perceber que aprender não significa apenas acumular informações. Quando tento explicar um conceito com minhas próprias palavras, organizar uma ideia ou relacionar teoria e prática, sou obrigado a compreender melhor aquilo que estou estudando.

Compartilhar esse processo passou, então, a fazer sentido como parte da própria formação. Escrever sobre Inteligência Artificial, engenharia do conhecimento, sistemas baseados em regras, automação ou desenvolvimento de projetos não é apenas registrar resultados; é também revisar conceitos, identificar dúvidas e perceber pontos que ainda precisam ser aprofundados.

Foi por isso que decidi criar este espaço no DEV Community. Quero utilizá-lo como um caderno público de aprendizagem, no qual conteúdos acadêmicos possam dialogar com experiências práticas, projetos pessoais e reflexões sobre tecnologia.

Também espero que esses registros possam ser úteis para outras pessoas que estejam estudando temas semelhantes. Não necessariamente porque eu tenha respostas definitivas, mas porque dúvidas, erros, testes e descobertas também fazem parte da construção do conhecimento.

Minha intenção é manter uma postura de transparência: distinguir aquilo que já compreendo com segurança daquilo que ainda estou investigando, citar as fontes utilizadas e revisar criticamente os conteúdos antes de publicá-los.

O que pretendo publicar por aqui

Pretendo utilizar este espaço para registrar temas que façam parte dos meus estudos e dos projetos que estiver desenvolvendo. Entre eles estarão Inteligência Artificial simbólica, engenharia do conhecimento, sistemas baseados em regras, automação, integração por APIs, agentes de inteligência artificial e desenvolvimento de soluções aplicadas.

Também quero explorar as relações entre Inteligência Artificial, Artes Visuais e música. Tenho interesse especial em compreender como tecnologia, criação e linguagem podem dialogar sem que a ferramenta substitua aquilo que continua pertencendo à experiência e à intenção humanas.

Parte das publicações também deverá nascer dos desafios encontrados durante o desenvolvimento do Engenhoso AI. Problemas de arquitetura, segurança, persistência, interação, atendimento humano e identidade visual podem se transformar em oportunidades para estudar conceitos com mais profundidade e compartilhar aquilo que foi aprendido durante o processo.

Sempre que possível, quero partir de uma pergunta, apresentar aquilo que compreendi, relacionar a teoria a uma experiência prática e registrar também os limites ou dúvidas que permanecerem. Dessa forma, cada publicação poderá funcionar não apenas como resultado de um estudo, mas como parte dele.

Uma jornada que está apenas começando

Este primeiro texto não pretende apresentar conclusões definitivas. Ele representa apenas o ponto de partida de um percurso que ainda está sendo construído.

Tenho aprendido que diferentes experiências não precisam competir para definir quem somos. O conhecimento desenvolvido na indústria, a sensibilidade encontrada na arte e na música e os novos caminhos abertos pela Inteligência Artificial podem coexistir e contribuir uns com os outros.

Talvez aprender seja justamente isso: ampliar aquilo que já somos sem precisar apagar aquilo que nos trouxe até aqui.

Ao registrar esse percurso, espero compreender melhor minhas próprias ideias, desenvolver uma linguagem técnica cada vez mais clara e, ao mesmo tempo, contribuir com outras pessoas que também estejam buscando transformar estudo em experiência e conhecimento em criação.

Seguimos aprendendo.

Transparência sobre o uso de IA

Este artigo foi escrito por Robson Concesso com apoio de inteligência artificial na organização das ideias, estruturação do texto e revisão da linguagem. As experiências, interpretações, decisões editoriais e a validação do conteúdo permanecem sob responsabilidade do autor.