Funcionário Digital
Funcionário digital é a camada agentiva do sistema operacional empresarial que opera com contexto do negócio — histórico, regras e base de conhecimento — não depende de prompts genéricos como um chatbot.
O que é
O funcionário digital é a camada agentiva do sistema operacional empresarial — um agente que opera sobre contexto do negócio e executa ações em nome da empresa em canais de atendimento, cobrança, reativação e marketing. Não é um chatbot generalista, nem um assistente de produtividade acoplado a LLM: é um colaborador digital com papel operacional.
A diferença prática: um chatbot responde perguntas dentro de um script. O funcionário digital participa do fluxo operacional — agenda, cobra, reativa, qualifica leads, confirma entregas, pesquisa satisfação, escalonamento. Ele lê o tálamo antes de cada ação para saber tom, regras, histórico e guardrails; executa; registra a ação em log auditável.
Essa diferença importa porque resolve um problema estrutural de PME: a execução depende da memória do dono ou de poucos gerentes. Quando o funcionário digital assume fluxos repetitivos com contexto, o negócio deixa de parar quando o dono dorme, viaja ou fica doente.
Como funciona
O funcionário digital opera sobre três camadas: base de conhecimento viva, memória transversal e guardrails explícitos. A base de conhecimento é onde o negócio registra tom, regras, glossário e políticas — editada em texto plano por quem conhece a operação. A memória transversal é o histórico de cada cliente, paciente, fornecedor — disponível para consulta entre canais sem reiniciar conversa. Os guardrails definem o que o funcionário digital pode e não pode fazer sem aprovação humana.
O loop de execução é o seguinte: evento chega (mensagem no WhatsApp, lead no formulário, prazo de cobrança vencido); funcionário digital lê o contexto relevante no tálamo; verifica se a ação está dentro do guardrail; executa; registra. Se a ação sai do guardrail (desconto além do permitido, agendamento em horário bloqueado, exceção ao tom), o funcionário digital escalona para humano com contexto completo — o operador não precisa ler 20 mensagens para entender o caso.
Essa arquitetura permite ajustar o comportamento em velocidade operacional: mudar uma regra na base de conhecimento propaga para todos os disparos subsequentes sem deploy, sem retreinamento.
Diferença entre funcionário digital e chatbot
Três diferenças estruturais: contexto, ação e aprendizado. No contexto, o chatbot clássico é estático — conhece o fluxo conversacional configurado e nada mais; o funcionário digital lê histórico transversal do cliente, prontuário, OS aberta, última cobrança paga. A cada interação ele sabe com quem está falando.
Na ação, o chatbot responde. O funcionário digital executa: agenda a consulta, dispara o boleto, atualiza a OS, aciona o entregador. Ele participa do fluxo operacional, não apenas representa um front de atendimento.
No aprendizado, o chatbot exige retreinamento ou reprogramação para mudar comportamento. O funcionário digital lê a base de conhecimento na hora da ação — uma regra nova aparece no próximo disparo. Isso permite governança operacional em ritmo de negócio, não em ritmo de ciclo de desenvolvimento.
Exemplos práticos
Os exemplos do frontmatter cobrem o padrão: em todos, o funcionário digital consulta contexto antes de agir. É essa consulta que diferencia execução com contexto de disparo em massa.
Na clínica, o atendente não precisa verificar prontuário + convênio + agenda do profissional antes de propor um retorno — o funcionário digital faz isso em milissegundos e sugere horários que respeitam as três restrições simultaneamente. Na reativação de vendas, a diferença entre “Oi João, volte a comprar!” (disparo em massa) e “Oi João, notei que seu último pedido foi de tênis de corrida há 90 dias — temos sua numeração em meia compressão” é a consulta de contexto. Na cobrança humanizada, a diferença entre “você está inadimplente” e “tudo certo com seu último pedido? Consigo te ajudar com as opções de pagamento” é o tom lido da base de conhecimento aplicado por cliente.
Em cada caso, a arquitetura é a mesma: consulta contextual → ação dentro do guardrail → registro auditável.
