Bloom-for-Learning: Coaching Multi-Agente Centrado em Autonomia e Interoperabilidade Externa

Da Otimização Prescritiva à Autonomia: Adaptando o Modelo de Coaching de Mindset da Stanford para o Aprendizado Autodirigido

Resumo Executivo

Alunos autodidatas online enfrentam alta evasão por perda de direção, pensamento tudo-ou-nada e autojulgamento. Aplicativos de produtividade tradicionais tratam o coaching como um problema de otimização — coletar dados, prescrever um cronograma rígido, esperar conformidade — mas o comportamento humano não funciona assim.

Inspirado no “Bloom”, o AI health coach da Stanford, que usa Entrevista Motivacional (MI, Motivational Interviewing) para trazer à tona as próprias motivações do usuário em vez de prescrever planos, apresentamos o Bloom-for-Learning: um concierge pessoal de agendamento e aprendizado que co-cria planos de estudo e gerencia a recuperação da agenda. O sistema usa uma arquitetura multi-agente Coordenador-Especialista orientada por LLM, com chamadas de ferramentas em estilo ReAct, o Model Context Protocol (MCP) para sincronização segura de calendário, uma camada de memória de longo prazo apoiada em SQLite, e um protocolo Agent-to-Agent (A2A) para delegação externa. Este relatório analisa como o Bloom-for-Learning apoia o estudo autodirigido mantendo os dados de agenda e metas privados.

1. Introdução & Motivação Teórica

A Falácia da Otimização no Coaching

A maioria dos aplicativos comerciais de coaching falha porque trata hábitos humanos como problemas de otimização. Como observa Matthew Jörke, de Stanford, sobre apps de saúde:

“Com dados suficientes… o chatbot coach vai prescrever um plano de treino e esperar que o usuário o siga… Não é assim que o comportamento humano funciona.”

Um aplicativo prescritivo tira a autonomia do usuário. Uma sessão perdida quebra o cronograma rígido, disparando o pensamento tudo-ou-nada (“perdi um dia, então a semana está arruinada”) e o autojulgamento — o que leva ao abandono.

O Paradigma Bloom da Stanford

A resposta de Stanford, o Bloom, é um AI health coach construído sobre Entrevista Motivacional (MI) — um estilo centrado no cliente que ajuda as pessoas a resolver ambivalências e encontrar sua própria motivação para mudar, fazendo perguntas abertas e co-criando planos em vez de prescrevê-los.

Traduzindo para o Aprendizado Autodirigido

O Bloom-for-Learning adapta esse modelo para o aprendizado autodirigido, direcionado a alunos adultos (25–40 anos) que dominam habilidades fora de estruturas acadêmicas formais, em torno de três hipóteses:

1. A co-criação aumenta a adesão em comparação a cronogramas gerados pelo agente.
2. Recuperação de apoio supera sequências (streaks) — enquadrar interrupções como naturais, não como falhas, evita o abandono por pensamento tudo-ou-nada.
3. Agendamento centrado em autonomia — o aluno detém as edições finais do calendário, reduzindo o atrito.

2. Alinhamento com a Trilha: Concierge Agents

Submetemos à trilha Concierge Agents: o Bloom funciona como um concierge pessoal autônomo que gerencia cronogramas de estudo, negocia datas, lida com interrupções e conduz check-ins reflexivos em nome do aluno.

Os principais desafios do estudo autodirigido são a carga cognitiva do agendamento e o atrito emocional de ficar para trás. O Bloom aborda ambos mantendo privacidade e propriedade de dados rigorosas — camadas de dados localizadas, autorização com escopo restrito e conexões MCP em sandbox, em vez de enviar calendários para um banco de dados centralizado multi-tenant.

3. Arquitetura do Sistema & Fluxo de Diálogo

O Bloom-for-Learning usa um design modular multi-agente, governado por um coordenador central orientado por LLM, que roteia turnos dinamicamente via chamadas de ferramentas, enquanto cada especialista opera sem estado (stateless).

                          Usuário (Vite + React UI)
                                    │
                                    ▼
                         ┌─────────────────────┐
                         │     Coordenador     │◄── Memória de Longo Prazo
                         │  (Roteador LLM de   │    (SQLite + Resumos)
                         │     Ferramentas)     │
                         └──────────┬──────────┘
                                    │ ferramentas delegate / respond
         ┌──────────────────┼──────────────────┬──────────────────┐
         ▼                  ▼                  ▼                  ▼
   ┌───────────┐      ┌───────────┐      ┌───────────┐      ┌───────────┐
   │Onboarding │      │Planejamento│      │Recuperação│      │Reflexão   │
   │Especialista│      │(Loop ReAct│      │Especialista│      │Especialista│
   └───────────┘      │+ Calendário)│     └───────────┘      └───────────┘
                      └───────────┘

3.1. O Padrão Coordenador-Especialista Orientado por LLM

Em vez de uma máquina de estados if/else fixa, o Coordenador chama generateWithTools a cada turno com duas ferramentas — delegate(agent, reason) e respond(message, new_state) — deixando o LLM decidir o roteamento:

1. O Coordenador constrói o contexto (estado, últimas 15 mensagens, memória) e executa um loop de ferramentas com no máximo 3 iterações, delegando ou respondendo a cada iteração. Ele usa diretamente o suggestedNextState do próprio especialista, em vez de deixar o LLM sobrescrevê-lo, mantendo as transições determinísticas. Uma proteção de roteamento pós-submissão agora também corrige delegações incorretas para qualquer estado com um único especialista obrigatório inequívoco (§9).
2. Os Especialistas são agentes de prompt sem estado (Onboarding, Planejamento, Recuperação, Reflexão), cada um recebendo um bloco {learner_context} injetado, para que mantenham consciência contextual sem reproduzir o histórico completo.

3.2. Agente de Planejamento: Loop de Ferramentas ReAct

O Especialista de Planejamento substitui heurísticas baseadas em regex por um loop ReAct sobre quatro ferramentas de calendário (máximo de 5 iterações por turno):

Após a concordância do aluno, o agente executa get_free_busy → propose_sessions → confirm_plan em um único turno, criando eventos no Google Calendar e retornando os IDs de sessão confirmados.

3.3. Estados Detalhados de Diálogo

Quatro fluxos estruturados guiam o aluno:

1. Onboarding (S1–S6), um fluxo baseado em MI: S1 Boas-vindas (define o tom); S2 Descoberta de Meta (a categoria da meta é inferida apenas a partir de sinais explícitos, nunca forçada); S3 Histórico & Barreiras (capturado literalmente); S4 Contexto & Recursos (horas semanais + janela de foco, horas só são capturadas com unidade explícita); S5 Verificação de Prontidão (confiança de 1 a 10, protegida contra confusão entre respostas de horário e de confiança); S6 Resumo & Confirmação (o LLM resume nas palavras do aluno; após confirmação, persiste e avança para PLANNING). Cada estado agora só avança mediante uma resposta genuína, em vez de sempre progredir (§9).
2. Planejamento Semanal: fundamentado na disponibilidade real do calendário, dentro de ±10% do orçamento, confirmado apenas após concordância explícita.
3. Recuperação de Apoio: acionada 2 horas após uma sessão perdida; explora o que aconteceu e co-cria um reagendamento.
4. Reflexão Metacognitiva: acionada na conclusão ou na revisão semanal, reforçando ciclos positivos de feedback.

4. Memória de Longo Prazo do Aluno

Para evitar que o coach comece do zero a cada conversa, o Bloom executa um pipeline de extração de memória fire-and-forget apoiado em SQLite:

Após cada turno de especialista (fora do onboarding):
  → o LLM extrai fatos da conversa (assíncrono, sem impacto na latência de resposta)
  → Armazenados em learner_memories: {preference, barrier, progress, insight}

A cada novo turno:
  → buildContext() carrega fatos recentes (últimos 14 dias, máximo 10)
                  + o resumo periódico mais recente
                  + perfil do aluno
  → Injetado como {learner_context} no prompt de sistema de cada especialista

Cron semanal (summarizeActiveUsers):
  → Quando ≥5 novos fatos se acumulam, o LLM os comprime em uma narrativa
  → Fatos antigos são arquivados; o resumo é persistido em memory_summaries

Fatos recentes fornecem contexto de alta resolução; resumos periódicos cobrem o histórico mais antigo — sem necessidade de banco de dados vetorial, e nenhum dado sai da implantação SQLite local do usuário.

5. Segurança, Privacidade e Gestão Segura de Contexto

Um concierge pessoal precisa acessar dados sensíveis: metas, agendas, dificuldades, calendários externos. O Bloom implementa um modelo de segurança em múltiplas camadas:

  ┌──────────────────────────────────────────────────────────┐
  │              LIMITES DOS DADOS DO USUÁRIO                │
  └────────────────────────────┬─────────────────────────────┘
                               ▼
  ┌──────────────────────────────────────────────────────────┐
  │ 1. Banco de Dados Local-First & Fallback em Memória       │
  │    SQLite/PostgreSQL; sem necessidade de persistência     │
  │    remota.                                                │
  └────────────────────────────┬─────────────────────────────┘
                               ▼
  ┌──────────────────────────────────────────────────────────┐
  │ 2. OAuth com Escopo Restrito & Servidor MCP em Sandbox    │
  │    Acesso ao calendário restrito a calendar.events;       │
  │    contatos, e-mails ou arquivos do Drive não acessíveis. │
  └────────────────────────────┬─────────────────────────────┘
                               ▼
  ┌──────────────────────────────────────────────────────────┐
  │ 3. Contexto de LLM Limitado + Compressão de Memória       │
  │    Últimas 15 mensagens enviadas à API do LLM; histórico  │
  │    mais antigo comprimido em resumos locais, nunca        │
  │    reproduzido em massa.                                  │
  └──────────────────────────────────────────────────────────┘

5.1. Acesso ao Calendário com Escopo Restrito via MCP

O Bloom se conecta ao Google Calendar via MCP em vez de conceder chaves de API amplas na nuvem:

• Consentimento OAuth 2.0, realizado localmente; o refresh token é armazenado no lado do cliente.
• Escopo Limitado — apenas calendar.events, nunca e-mail/contatos/Drive.
• Conexão em Modo Duplo — primeiro SSE do MCP SDK (timeout de 2s), com fallback para HTTP POST direto usando o campo summary correto e capturando o ID do evento do Google para futuras exclusões/reagendamentos.

5.2. Banco de Dados Local-First

Um conector dinâmico recorre a um mock em memória caso o PostgreSQL esteja indisponível, permitindo que o concierge rode totalmente local, sem transmissão de dados a terceiros.

6. Integração Técnica: Model Context Protocol (MCP)

sequenceDiagram
    participant Usuário
    participant Backend
    participant Servidor MCP Calendário
    participant API do Google Calendar

    Usuário->>Backend: "Ficou bom, pode confirmar."
    Note over Backend: Loop ReAct do agente de planejamento: get_free_busy → propose_sessions → confirm_plan
    Backend->>Servidor MCP Calendário: HTTP POST { name: create_event, parameters: { summary, start, end } }
    Servidor MCP Calendário->>API do Google Calendar: Gravação autenticada via OAuth 2.0
    API do Google Calendar-->>Servidor MCP Calendário: Evento criado (ID do evento do Google retornado)
    Servidor MCP Calendário-->>Backend: { value: { event: { id: "google_event_id" } } }
    Note over Backend: Armazena o ID do evento do Google como calendar_event_id para futuras exclusões
    Backend->>Usuário: "Plano confirmado — sessões adicionadas ao seu calendário!"

Conexão em Modo Duplo & Fallback

• O Servidor MCP (mcp-google-calendar): um servidor TypeScript independente que lida com OAuth 2.0 e mapeia chamadas JSON-RPC para a API do Google Calendar.
• O Serviço de Calendário do Backend: SSE primeiro, com fallback para HTTP POST em até 2s; captura o ID do evento do Google para reagendamentos/exclusões futuras.
• Proteção de Resiliência: um servidor de calendário offline recorre a um armazenamento mock local, mantendo a conversa fluida.

7. Proteções de Segurança & Moderação de Distorções Cognitivas

7.1. Proteção Contra Distorções Cognitivas

O filtro de segurança bloqueia e redireciona respostas que demonstram pensamento tudo-ou-nada (“perdi uma aula, fracassei no curso”), rotulação/autoculpa (“eu sou simplesmente preguiçoso”) ou supergeneralização (“eu nunca consigo seguir cronogramas”).

7.2. Limites Saudáveis de Agendamento

O planejamento impõe proteção do sono (≥6h/noite), prevenção de sobrecarga (sinaliza mais de 30h de estudo/semana) e orçamentos flexíveis (±10% da meta semanal).

7.3. Neutralidade de Categoria de Meta

O onboarding nunca força um enquadramento profissional — uma categoria de meta só é registrada quando as próprias palavras do aluno a tornam inequívoca; caso contrário, permanece indefinida em vez de ser presumida.

8. Resultados Experimentais & Validação

A suíte de testes executa 88 testes automatizados em Jest, distribuídos em 19 suítes, cobrindo testes unitários (serviço de LLM, memória, roteamento do coordenador, cada especialista) e fluxos ponta a ponta (onboarding, confirmação de planejamento, reagendamento de recuperação, reflexão, extração/sumarização de memória).

8.1. Desempenho de Latência

O loop ReAct adiciona de 1 a 2 chamadas de LLM em turnos de confirmação, trocando latência por precisão de agendamento fundamentada na disponibilidade real do calendário, em vez de adivinhação.

8.2. Telemetria Armazenada & Rastreamento de Custo de Tokens

Latência, status, provedor e contagens de tokens são persistidos em telemetry_events (extraídos do usageMetadata do Gemini / usage da OpenAI em cada chamada, incluindo iterações de chamadas de ferramentas); GET/DELETE /api/telemetry permitem inspeção e reset.

8.3. Teste Qualitativo de Resiliência (Simulação de Recuperação)

• Rastreador Prescritivo: “Alerta: você perdeu sua sessão das 14h. Sua sequência de 12 dias foi quebrada. Reagende agora.” → Provoca culpa, soa punitivo, incentiva o abandono.
• Chat de Recuperação do Bloom: “Notei que você perdeu a sessão desta tarde. A vida acontece — foi falta de energia, trabalho inesperado ou questão de horário?” → Valida o aluno, reduz a ansiedade, mantém o engajamento na co-criação de um novo cronograma.

9. A Jornada do Projeto & Narrativa de Construção

O desenvolvimento seguiu uma refatoração sistemática, em etapas:

1. Etapa 0 — Camada de Prompt: Reescrita de todos os prompts dos especialistas com regras comportamentais explícitas, comportamentos proibidos e exemplos few-shot fundamentados em MI; extração de um prompt coordinator.md com regras explícitas de roteamento e transições de estado válidas.

2. Etapa 1 — Loop Agentivo de Ferramentas: Substituição do roteador if/else do coordenador por um loop de chamada de ferramentas via LLM (delegate/respond), e das heurísticas baseadas em regex do agente de planejamento por um loop ReAct limitado sobre quatro ferramentas de calendário. Correção de um bug crítico em que voltar ao LLM após a delegação permitia que ele sobrescrevesse o suggestedNextState correto do especialista — resolvido interrompendo o loop imediatamente após a delegação, mantendo as transições sob responsabilidade do especialista.

3. Etapa 2 — Camada de Memória: Introdução de um pipeline de memória fire-and-forget: uma chamada assíncrona de LLM extrai fatos estruturados (preference, barrier, progress, insight) para learner_memories após cada turno; um cron semanal comprime ≥5 fatos acumulados em resumos narrativos; cada turno injeta um bloco {learner_context} para que o coach mantenha a consciência do contexto sem reproduzir o histórico.

4. Contínuo — Correções de Bugs & Robustez: Correção de incompatibilidades de parâmetros do MCP (title→summary, {id}→{eventId}); captura dos IDs de evento do Google para exclusões corretas; refinamento do parsing de slots do onboarding (horas condicionadas à unidade, desambiguação entre horário e confiança, sem categoria de meta forçada).

5. Etapa 3 — Revisão de Confiabilidade Pós-Submissão: Uma revisão estruturada do uso real identificou quatro defeitos que compartilhavam um mesmo padrão: fabricar ou ignorar informações passadas em vez de fundamentar as respostas no que era conhecido. Corrigidos, cada um verificado contra o LLM real: datas/preferências de agenda são fundamentadas no fuso horário do aluno e perguntadas em vez de presumidas; a sincronização do calendário é exibida com honestidade; o onboarding só avança mediante respostas genuínas (campos relevantes migrados para nullable, para que “desconhecido” seja armazenado com honestidade); e a proteção de roteamento do Coordenador (§3.1).

10. Demonstração dos Principais Conceitos do Curso

11. Discussão & Escopo Futuro

Principais Aprendizados

1. Psicologia Comportamental é o Núcleo: o sucesso em software educacional é um problema psicológico de motivação, resiliência e autonomia — não apenas de otimização da entrega de conteúdo.
2. Roteamento por LLM Precisa de Contratos de Estado Determinísticos: um roteador orientado por LLM com transições de estado sob responsabilidade do especialista, somado a uma proteção determinística para estados inequívocos (§9), mantém a conversa focada sem sacrificar a flexibilidade.
3. Compressão de Memória em vez de Busca Vetorial: para um concierge com um único aluno por implantação, SQLite mais sumarização periódica via LLM lida com interações em escala de anos sem o custo operacional de um banco de dados vetorial.
4. Integrações Desacopladas: o MCP torna a camada de calendário substituível de forma independente — Google Calendar hoje, qualquer servidor CalDAV amanhã.

Trabalhos Futuros

• Estudos Longitudinais de Adesão: um estudo de 12 semanas medindo a adesão em comparação a um rastreamento baseado apenas em calendário.
• Modelos On-Device: modelos menores executados localmente (ex.: Gemma 2B) para privacidade total e menor custo.
• Suporte Expandido a MCP: gerenciadores de tarefas (Todoist, Jira) e repositórios de documentos (Notion).

12. Conclusão

O Bloom-for-Learning mostra como construir uma plataforma de coaching com IA que respeita a autonomia do usuário e apoia a mudança comportamental — combinando coaching centrado em autonomia, uma arquitetura multi-agente orientada por LLM, um loop de ferramentas ReAct para agendamento fundamentado, memória de longo prazo e MCP para integração privada de calendário, em um ambiente de aprendizado de apoio e resiliente.

Projeto no Github

https://github.com/cacaprog/bloom-learning-app/tree/main

Vídeo do MVP

https://www.youtube.com/watch?v=-ydFvpgAg_8&t=70s

Referências

• Jörke, M., & Ju, W. (2025). An AI Health Coach Could Change Your Mindset. Stanford Institute for Human-Centered Artificial Intelligence (HAI).
• Miller, W. R., & Rollnick, S. (2012). Motivational Interviewing: Helping People Change. Guilford Press.
• Model Context Protocol (MCP) Specification. Anthropic PBC. https://modelcontextprotocol.io