O mesmo botão, duas respostas diferentes
O produto em questão é um app para organizadores de eventos — casamento, festa, corporativo — onde cada evento vira um registro próprio: agenda, orçamento, contatos e financeiro. Um botão de assistente fica sempre visível, mas responde de dois jeitos diferentes dependendo de onde foi acionado. Chamado a partir da lista geral de eventos, ele enxerga tudo o que o usuário tem em andamento — "quais pagamentos tenho pendente?" soma o que está em aberto em todos os eventos. Chamado de dentro de um evento específico, a mesma pergunta já vem filtrada — "quanto falta pagar do buffet?" sabe, sem precisar perguntar, que o buffet é o daquele evento.
Parece um detalhe pequeno, mas é a diferença entre um agente que ajuda e um que obriga o usuário a fazer o trabalho de dar contexto toda vez que pergunta algo. Definir o escopo pela tela onde o botão vive — em vez de exigir que o usuário escolha um evento antes de poder perguntar — é decisão de produto, não só de prompt.
Sugestão é rascunho, nunca ação automática
O mesmo agente também gera uma agenda inicial a partir do tipo e da data do evento, aponta itens de orçamento que costumam faltar para aquele porte de evento, e rascunha uma mensagem de cobrança para um fornecedor a partir do contato e da pendência financeira. Em nenhum desses casos o agente age sozinho: a agenda sugerida precisa ser confirmada item a item, e a mensagem de cobrança fica pronta para revisão — quem manda é o usuário, sempre. Um agente que executa direto o que "acha" que deveria fazer erra rápido e caro demais para operar sem essa trava.
Quando o produto tem um parceiro comercial embutido, o limite tem que estar no desenho
Esse app específico é patrocinado: uma empresa parceira integra seu catálogo de produtos dentro do fluxo do organizador, e em troca recebe leads e métricas de uso. O ponto que importa aqui não é o modelo de patrocínio em si — é onde a fronteira de privacidade fica desenhada. O parceiro só recebe um lead quando o próprio usuário clica em "pedir cotação", e só enxerga métricas agregadas (categoria mais buscada, cidade, mês), nunca dado individual de orçamento, contato ou anotação de ninguém. Isso não é uma política escrita à parte — é uma regra que vive no modelo de dados e na API: a rota que devolve métricas simplesmente não responde abaixo de uma contagem mínima, para não deixar reidentificar ninguém por exclusão. Em qualquer produto com um terceiro embutido — patrocínio, marketplace, catálogo de parceiro — esse limite precisa estar na arquitetura, não na boa vontade de quem opera o painel do parceiro depois.
Por onde começar
O erro mais comum ao colocar um agente de IA num produto é tratá-lo como uma tela a mais — um chat genérico jogado num canto, sem saber de onde veio a pergunta nem o que pode fazer sozinho. O caminho que funciona é desenhar o escopo antes do prompt: onde o botão vive em cada tela, o que o agente pode responder ali, e o que precisa sempre passar pela revisão do usuário antes de virar ação. Só depois disso faz sentido discutir modelo, custo por chamada e latência.