> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apollospace.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Digital Twin

> A modalidade per-user da Athena — representa a voz, decisões e contexto de uma pessoa específica da sua org.

## O que é

Um **Digital Twin** é a persona [Athena](/agents/athena) **configurada
para representar uma pessoa específica**. Tecnicamente é a mesma
`slug='athena'` da família `cos`, só que com voz, exemplos e
contexto vinculados a um humano da org.

> Pense no Twin como **"a Athena DE alguém"**:
> *"o Twin do CEO"*, *"o Twin da diretora comercial"*,
> *"o Twin do head de produto"*.

Por isso o Digital Twin **não aparece** como agente separado na lista
de personas — porque ele não é. É um modo de uso da Athena.

<Info>
  **O que NÃO é um Digital Twin:**

  * Não é avatar de vídeo / face-swap / clone visual
  * Não é réplica de personalidade — é uma representação operacional
  * Não substitui a pessoa em decisões irreversíveis (assinatura,
    aprovação financeira, fechamento contratual)
</Info>

## Quando faz sentido criar um Twin

<CardGroup cols={2}>
  <Card title="Você não escala mais" icon="hourglass-half">
    Líder com 80+ pings/dia em WhatsApp + Slack — o Twin responde o
    que é repetitivo (status, links, follow-ups simples) com a voz
    correta.
  </Card>

  <Card title="Decisão precisa do seu jeito" icon="comments">
    "Como X líder responderia este e-mail?" — o Twin tem o histórico

    * voice\_md certo pra produzir uma versão alinhada.
  </Card>

  <Card title="Continuidade quando você não está" icon="moon">
    Fim de semana, viagem, foco-mode. O Twin mantém follow-ups
    rolando sem interromper a vida do humano.
  </Card>

  <Card title="Onboarding de novo líder" icon="user-plus">
    Líder novo começa, demora a ganhar contexto da empresa. O Twin
    dele acelera — herda o knowledge da org de saída.
  </Card>
</CardGroup>

## Como o Twin aprende a voz

A configuração é incremental:

<Steps>
  <Step title="Voice_md inicial">
    Você cria um documento de voz (markdown) com **3-5 exemplos** de
    como o líder responde tipicamente: um e-mail de cobrança, um
    "obrigado, vou olhar", um corte ríspido em algo fora de escopo,
    um pedido de informação extra.
  </Step>

  <Step title="Contexto da empresa">
    O Twin herda o knowledge da org (documentos, capturas no Brain) +
    histórico de pipelines + traces de conversas anteriores onde o
    líder participou.
  </Step>

  <Step title="Ajuste iterativo">
    Nas primeiras semanas, você revisa rascunhos do Twin antes de
    enviar. Cada correção (que tom, que assinatura, que cumprimento)
    realimenta o `voice_md`.
  </Step>

  <Step title="Operação autônoma para casos simples">
    Em um ponto o Twin acerta consistentemente em **casos baixo-risco**
    (responder horário, mandar link, dizer "amanhã eu vejo"). Aí você
    pode liberar HITL nesses casos e manter aprovação só em casos
    sensíveis.
  </Step>
</Steps>

## Limites — onde o Twin **nunca** opera sozinho

Como o Twin decide se age sozinho ou propõe pra você aprovar:

```mermaid theme={null}
flowchart TD
    A[Twin recebe pedido] --> B{Categoria do pedido?}
    B -->|Resposta simples / link / cumprimento| C[Age autônomo]
    B -->|Follow-up de proposta enviada| C
    B -->|Comunicação regulatória / legal| D[Propõe + aguarda humano]
    B -->|Proposta comercial ao cliente| D
    B -->|Assinatura de contrato| D
    B -->|Pagamento / refund| D
    B -->|Decisão de governança| D
    C --> E[Mensagem segue]
    D --> F{Líder aprova?}
    F -->|Sim| E
    F -->|Não| G[Descarta + registra no histórico]
```

Estes limites são **invariantes** do produto, não opção configurável:

| Ação                                        | Twin pode?                  |
| ------------------------------------------- | --------------------------- |
| Responder "obrigado, vou olhar"             | ✓ sim, autônomo             |
| Mandar link de calendário                   | ✓ sim, autônomo             |
| Fazer follow-up de proposta enviada         | ✓ sim, autônomo             |
| Aprovar **proposta comercial** ao cliente   | ✗ não — exige HITL          |
| Aprovar **assinatura de contrato**          | ✗ não — exige HITL          |
| Confirmar **pagamento / refund**            | ✗ não — exige HITL          |
| Falar em **eventos públicos** como o líder  | ✗ não — produto não suporta |
| Editar **decisão de governança** da empresa | ✗ não — exige HITL          |

Quando uma ação cai num desses casos, o Twin **propõe** + espera
confirmação humana do líder antes de executar.

## Quando aparece publicamente — e quando NÃO deve

**Aparece publicamente** (com a voz do líder):

* Em respostas de WhatsApp / e-mail no inbox dele
* Em rascunhos de campanhas outbound assinadas por ele
* Em respostas de chat interno do time onde o líder geralmente fala

**NÃO aparece** (Twin não é apropriado):

* Em comunicações regulatórias / legais (sempre humano)
* Em mídias públicas (LinkedIn post, Twitter) — sem opt-in explícito
* Em primeiro contato com investidor / parceiro estratégico
* Em qualquer comunicação onde o destinatário razoavelmente espera
  falar com o ser humano em pessoa

## Próximos passos

<CardGroup cols={2}>
  <Card title="Athena (modo org)" icon="user-tie" href="/agents/athena">
    A modalidade default da Athena — Chief of Staff genérico da org.
  </Card>

  <Card title="Faturamento dos Twins" icon="star" href="/billing/stars">
    Cada chamada do Twin debita Stars do mesmo saldo — mesma proteção
    de orçamento que a Athena normal.
  </Card>

  <Card title="Convidar o time" icon="users" href="/guides/invite-team">
    Pra criar Twins, primeiro os humanos precisam estar na org.
  </Card>
</CardGroup>