Essa é uma das mudanças mais importantes recentes da Lovable porque transforma apps reativos em ferramentas que também podem executar trabalho em segundo plano. O Google Calendar é um exemplo fácil de visualizar, mas o mesmo modelo pode ser aplicado a outros conectores compatíveis.
O que significa criar um agente na Lovable
Neste contexto, agente não significa apenas um chatbot. É um app que recebe acesso autorizado a ferramentas do usuário, executa uma regra ou objetivo e pode agir em nome dele dentro dos limites concedidos. Com offline access habilitado, essas ações podem acontecer sem uma sessão ativa no navegador.
- Ler a agenda e verificar disponibilidade.
- Criar, atualizar ou cancelar eventos no Google Calendar.
- Executar uma tarefa programada durante a madrugada.
- Reagendar uma reunião perdida.
- Gerar um resumo diário antes do expediente.
- Combinar Calendar com Gmail, CRM ou outra ferramenta para executar um fluxo completo.
Como funciona a arquitetura
- Você habilita o conector necessário no workspace.
- Configura o acesso do app à conta do usuário por OAuth.
- Cada usuário conecta a própria conta e concede as permissões solicitadas.
- A Lovable mantém as credenciais no connector gateway, sem expô-las ao app ou navegador.
- Seu app pede uma ação ao conector, como consultar disponibilidade ou criar um evento.
- Com offline access autorizado, a ação também pode acontecer em background ou por agendamento.
Passo a passo: agente com Google Calendar
Um bom primeiro projeto é um agente de agendamento. O objetivo: consultar a disponibilidade real do usuário e criar um evento automaticamente quando uma condição for atendida.
- Crie um projeto Lovable com autenticação para os usuários do app.
- No catálogo de conectores, adicione Google Calendar ao fluxo.
- Defina as permissões mínimas necessárias: leitura da disponibilidade e criação de eventos, por exemplo.
- Configure o app OAuth quando o fluxo exigir client ID e secret próprios.
- Permita que cada usuário conecte a própria conta Google.
- Habilite offline access somente se o agente realmente precisar agir quando o usuário não estiver presente.
- Crie a regra de negócio: por exemplo, buscar uma janela livre e agendar somente dentro do horário comercial.
- Adicione um job agendado ou fluxo em background para executar a rotina.
- Teste primeiro com uma conta controlada e revise os eventos criados.
- Publique e monitore as conexões, permissões e falhas de execução.
Exemplo real de fluxo
Quando chegar um novo pedido de agendamento, verifique o Google Calendar do usuário, encontre o primeiro horário livre de 45 minutos entre 9h e 17h nos próximos 5 dias úteis e crie o evento. Se não houver horário disponível, registre o pedido como pendente e não crie nada.
A força está nos limites. Um agente bom não recebe uma instrução vaga para fazer qualquer coisa. Ele recebe contexto, regras, escopo de permissão e critérios claros para agir ou parar.
Por que cada usuário conecta a própria conta
Nos app user connectors, a conexão pertence à pessoa que usa o app. Isso permite vender ou distribuir um mesmo produto para várias pessoas sem compartilhar uma única conta Google do criador. Cada usuário trabalha com seus próprios dados e permissões.
A Lovable informa que as credenciais ficam armazenadas de forma protegida no gateway e não chegam ao app nem ao navegador. O app atua com as permissões que aquela pessoa concedeu.
Cuidados de segurança antes de liberar offline access
- Solicite apenas os scopes realmente necessários.
- Prefira acesso somente durante a sessão quando background não for indispensável.
- Defina limites claros para criação, edição e exclusão de eventos.
- Registre o que o agente fez para facilitar auditoria.
- Não copie dados sensíveis para seu banco sem necessidade.
- Teste comportamentos inesperados antes de disponibilizar o app para clientes.
Aplicativo interno ou produto para clientes?
Para apps internos, alguns provedores simplificam o processo de aprovação. Quando o produto será usado por clientes externos, o provedor pode exigir revisão do OAuth e das permissões solicitadas. Google é um caso em que scopes mais sensíveis podem exigir etapas adicionais de verificação.
