Em 2012 escrevi um [postmortem para Plancast](https://markmhendrickson.com/posts/a-postmortem-for-plancast/), uma startup na qual passei três anos. A premissa era simples: as pessoas fazem planos, vale a pena compartilhar planos e um feed de eventos futuros de pessoas em quem você confia traria à tona coisas que você não sabia que queria fazer. Não funcionou. A peça explicou o porquê.

Relendo-o doze anos depois, os diagnósticos superficiais ainda se mantêm. Os planos são feitos com pouca frequência para manter o hábito alimentar diário. Compartilhar planos futuros gera ciclos de vaidade fracos em comparação com o compartilhamento de fotos. Os planos expiram, portanto, qualquer conteúdo tem horas de validade. A maioria dos planos são geograficamente locais, portanto, a maioria dos planos da sua rede são irrelevantes na maior parte do tempo. E o problema mais profundo: as pessoas não querem ter consciência ambiental de eventos para os quais não foram convidadas pessoalmente. Consciência sem convite parece exclusão. A maioria das pessoas também não deseja compartilhar todos os planos com toda a rede. As pessoas erradas podem aparecer ou a sala deixa de parecer controlável.

O que perdi em 2012 foi que nenhum desses problemas eram realmente problemas de mecânica do produto. Eles eram problemas de substrato. O substrato disponível na época, um feed dentro de uma rede social centralizada, tinha formato errado para qualquer um deles. Tentei projetar em torno do substrato com recursos. O substrato ainda era um teto baixo em todas as métricas.

## O que realmente estava errado

Um feed é o primitivo errado para compartilhamento de planos porque:

- Um feed pressupõe um fluxo constante de conteúdo. Os planos não chegam como um fluxo.
- Uma transmissão de recompensas de feed. Os planos precisam de audiências dirigidas.
- Um feed tem uma função de recolhimento. O Plancast escolheu “mais cedo primeiro” por data do evento, os feeds sociais escolheram “mais novo primeiro” por hora de postagem. De qualquer forma, é um tipo cronológico. Os planos se beneficiam de muitas funções de consulta, e as úteis (quem está indo em seu gráfico de confiança, o que cabe nesta quinta-feira, quem está na cidade) raramente são de ordem cronológica.
- Um feed torna cada conteúdo visível para todos que seguem você. Os planos precisam de escopos.
- Um feed trata o consumo como uma superfície voltada para o usuário. Os planos precisam ser combinados com outros sistemas (calendários, RSVPs, trânsito, clima).
- Um feed centraliza a mediação. Os planos são inerentemente entre as pessoas.

Uma vez que essa lista esteja na mesa, cada falha do Plancast que mencionei em 2012 é um sintoma posterior. O substrato não conseguiu expressar o que a partilha de planos realmente quer ser.

## O substrato que eu precisava

O substrato sobre o qual eu construiria agora tem duas peças, nenhuma das quais existia em forma utilizável em 2012.

**Estado durável e somente anexado para agentes pessoais de IA.** Isso é o que estou construindo como [Neotoma](https://neotoma.io). Cada observação que um agente faz (um contato adicionado, um evento confirmado, um convite emitido, uma presença confirmada) torna-se uma entidade digitada com proveniência, restrições de esquema e um histórico imutável. O próprio agente de IA do usuário lê e grava nele. Não existe um gráfico social centralizado. O usuário possui o estado.

**Uma malha soberana de catálogos de endereços e escopos de confiança.** É para isso que serve o [Darkmesh](https://github.com/markmhendrickson/darkmesh) (meu fork do original de [Anand Iyer](https://www.anandiyer.com/). Darkmesh permite que uma pessoa publique fatias endereçáveis ​​de seu contexto (contatos específicos, grupos específicos, escopos específicos) em nós de malha de outras pessoas sob consentimento explícito. O consentimento é mantido na borda da rede. O agente do remetente não pode colocar uma mensagem no estado do destinatário, a menos que o nó mesh do destinatário tenha admitido o escopo do remetente.

Agentes pessoais de IA conversam entre si através da malha. Afirme que eles se preocupam com vidas duradouras no Neotoma de cada usuário. Não existe um servidor central que mantenha os planos de todos.

## Como a missão original se torna tratável

A proposta original do Plancast era: encontros fortuitos a partir da consciência compartilhada dos planos. O erro foi pensar que a consciência compartilhada tinha que vir de um feed.

Neste novo substrato, o mesmo tom se decompõe em trabalhos diferentes.

1. **A ingestão de eventos é automática.** Meu agente já sabe sobre eventos para os quais confirmei presença no Luma, eventos em minha agenda, eventos em e-mails de confirmação da Eventbrite ou Meetup. Ele os escreve em meu Neotoma como entidades de “evento” com proveniência. Eu nunca os digito em lugar nenhum.

2. **O compartilhamento é controlado e endereçado por consentimento.** Quando eu confirmo algo, meu agente pode sinalizar escopos que devem saber que estou indo. Estas não são postagens de feed. São observações dirigidas que viajam pela malha apenas para pessoas cujos nós admitiram meu escopo.

3. **A descoberta é uma consulta, não um feed.** A superfície mais natural para "o que está acontecendo no meu mundo" não é um fluxo. É uma pergunta que faço ao meu próprio agente. *Quem na minha rede de confiança irá para onde nas próximas duas semanas. Qual desses eventos se encaixa na minha noite desta quinta-feira. Quem está na cidade e que eu não vejo há um ano.* Cada consulta é computada no momento da recuperação em meu Neotoma, além de quaisquer escopos que minha malha tenha admitido. Não há alimentação.

4. **Os convites são de primeira classe.** Esta é a parte em que a peça de 2012 insistiu, e a parte que a maioria das tentativas de produtos foram ignoradas.

## Como os convites devem funcionar

O Plancast tinha convites explícitos, mas eram manuais. Eles seguiram um plano que seus assinantes já podiam ver. A alimentação ainda era a primeira superfície. Uma tag, uma menção ou metadados que sinalizassem você tinham o mesmo formato: a visibilidade do ambiente vinha em primeiro lugar, o toque pessoal em segundo. Supõe-se que um convite real inverta essa ordem.

Neste substrato, um convite é uma entidade digitada no próprio estado do destinatário. Aproximadamente:

```
convite
  remetente: contact_id
  destinatário: contact_id
  ref_evento: id_do_evento
  escopo: "1:1" | "grupo_pequeno" | "co_attending_set"
  note_to_recipient: string (obrigatório, não vazio)
  relacionamento_basis: string (por que essa pessoa, por que esse evento)
  slot_budget_used: inteiro (orçamento por evento)
  expira_at: carimbo de data/hora
  condicional_on: predicado de quorum opcional
  proveniência: agente/fonte/timestamp
```

Algumas coisas decorrem dessa forma.

**O substrato se recusa a entregar se a malha não tiver admitido o escopo do remetente.** Isso elimina os convites em massa frios na velocidade da máquina na única camada onde eles podem ser eliminados: a borda da rede.

**Orçamentos de convite por evento forçam a seletividade.** Cada evento tem um número pequeno e configurável de espaços para convites que um remetente pode gastar. O substrato, e não a força de vontade, impõe "não destrua sua agenda de endereços". A tensão vaidade versus seletividade de 2012 torna-se um parâmetro de substrato.

**Pull com pré-liberação é o padrão dominante.** Quando meu agente executa sua consulta permanente, ele vê apenas pessoas cujos próprios agentes me sinalizaram como alguém que eles gostariam de receber neste evento específico. A intersecção de “quem na minha rede vai” e “quem me receberia lá” é muito menor do que “quem na minha rede postou”. Não é uma alimentação. É um índice com permissão controlada.

**O contexto pessoal é obrigatório no nível do tipo.** `note_to_recipient` e `relationship_basis` são campos obrigatórios. Vazio não é um estado válido. Meu agente pode esboçá-los a partir do meu gráfico Neotoma (última sobreposição, contexto compartilhado, contatos comuns), mas uma linha confirmada por humanos é o padrão. Era para isso que o artigo de 2012 apontava quando insistia que as pessoas queriam se sentir pessoalmente convidadas. O substrato faz da nota pessoal um requisito estrutural e não uma cortesia opcional.

**A recusa é silenciosa e não atribuída.** Os destinatários respondem com `accept`, `pass` ou `pencil`. Apenas `accept` é visível para o remetente. `pass` resolve "sem resposta" sem confirmação de leitura e sem motivo. O destinatário mantém a proveniência privada. Você pode auditar sua própria carga social sem expô-la.

**Quorum é um primitivo de primeira classe.** O artigo de 2012 nomeou a procrastinação como um dos principais fracassos: as pessoas mantêm opções abertas e se recusam a se comprometer antecipadamente. O substrato aborda isso diretamente com `conditional_on`: "Irei para X se Aaron e Diwaker também se comprometerem." O substrato observa o predicado e o resolve. Sem função de coordenador, sem tópico de bate-papo em grupo, sem problemas.

**Composibilidade com o gráfico de eventos existente.** Quando um convite é aceito, o agente acessa a plataforma que possui o RSVP canônico (Luma, Eventbrite, calendário) e escreve a reserva real. A entidade Neotoma `attendance_commitment` permanece canônica para quem confia em quem está indo para onde. O RSVP de terceiros permanece canônico para o local e a porta. Dois registros, uma fonte de verdade por preocupação, vinculados.

## O que os agentes estão realmente decidindo

O sistema acima só funciona se os agentes realizarem trabalho não trivial localmente. As duas questões, em ambas as direções do circuito, são concretas.

**Outbound, quem aceitaria este plano.** Quando meu agente vê que confirmei presença em algo, ele avalia meus contatos em relação ao evento, não em relação a mim. Sinais locais úteis:

- contatos cujo Neotoma carrega temas compartilhados ou eventos co-participados com este,
- contatos com os quais estive em coisas semelhantes no ano passado,
- contatos que optaram explicitamente por uma categoria (sinalize-me sobre música ao vivo nesta cidade),
- contatos cuja programação ou localização observada se sobrepõe à janela do evento.

O agente produz uma lista de candidatos classificados, nunca um disparo automático. Os orçamentos de slots são gastos por mim ou com minha confirmação, e o campo `relationship_basis` é preenchido a partir da mesma pontuação para que eu possa ver porque uma pessoa foi sugerida antes de enviar.

**Inbound, quais planos que passam pela malha valem a pena serem revelados.** Meu agente executa a consulta simétrica em relação aos convites recebidos e às observações de presença no ambiente admitidas pelo meu escopo. Sinais locais:

- há quanto tempo e com que frequência estive presente com as pessoas envolvidas,
- se o tópico corresponde a uma categoria com a qual continuei envolvido,
- se minha própria agenda tem espaço,
- se um quórum que me interessa está se formando.

A maioria dos pings recebidos é arquivada, e não exibida. Os que surgem vêm com um pequeno parágrafo do próprio agente explicando por que este e não os outros.

Ambas as direções são pesadas e permanecem locais. Não existe um classificador central. O agente de cada usuário calcula em relação ao estado de propriedade do usuário e a pontuação pode ser inspecionada por esse usuário. É isso que faz com que a experiência passe a parecer uma infraestrutura que pode atuar em seu nome sem se tornar uma plataforma.

## Como os relacionamentos evoluem conforme observado

Em um feed, seu gráfico de relacionamento fica praticamente estático depois de formado. Você segue pessoas, raramente deixa de segui-las e todo o resto é ruído de sinal que a plataforma interpreta para você. Neste substrato o gráfico é moldado por observações.

Cada escrita digitada move ligeiramente um relacionamento. Um convite enviado move a borda em uma direção. Um convite aceito vai além. A sobreposição de atendimento registrada por ambos os agentes avança novamente. Uma conversa gravada, uma nota compartilhada ou uma entidade de projeto que ambos os nós tocam deixam uma observação na borda entre dois contatos, com proveniência e um carimbo de data/hora.

O inverso também é verdadeiro. As bordas decaem quando nada acontece. Um contato que você não convidou, com quem não participou ou sobre o qual não escreveu há um ano é um tipo de vantagem diferente do contato que você viu no fim de semana passado. A decadência não é exclusão. A história ainda está lá para recuperação. Mas a pontuação de relevância do agente amanhã utiliza o peso atualizado, portanto, um ano de silêncio custa visibilidade antes de custar o próprio relacionamento.

Isso inverte o modelo de feed da maneira que importa. Os feeds tornam o gráfico a entrada e a atividade a saída. Este substrato faz da atividade a entrada e do gráfico a saída. Os relacionamentos evoluem porque o comportamento é um estado estruturado, não porque alguém clicou em “Seguir” uma vez em 2014 e a plataforma tem fingido que a vantagem ainda significa alguma coisa desde então.

## O que isso não é

Esta não é uma tentativa de substituir convites de autoria humana. A função do substrato é tornar um convite escrito à mão mais barato para ser bem enviado, mais certo de chegar e mais difícil de enviar spam. Cada camada acima tem como objetivo levar a experiência de volta ao que 2012 identificou corretamente como a moeda social real: alguém em quem você confia pensou especificamente em você. O substrato não pode fabricar esse pensamento. Pode recusar-se a fornecer substitutos.

## O que ainda está aberto

Algumas coisas para as quais ainda não tenho boas respostas.

- Como os orçamentos convidados devem ser denominados e renovados. Por evento, por semana, por malha? Vinculado à taxa de aceitação?
- Como as alterações no escopo da malha se propagam quando os relacionamentos mudam. Como é revogar um escopo sem destruir um relacionamento?
- Interoperabilidade entre malhas quando os participantes executam diferentes implementações de malha. Requer uma camada de protocolo fina?
- Tratamento de abuso quando um remetente previamente admitido começa a enviar spam. Quem aplica a penalidade, o nó da malha do destinatário ou o substrato como um todo?
- História de migração para eventos cujo RSVP canônico reside atrás de um acesso pago ou login.

Estas são questões reais, mas são questões de produto e protocolo em cima de um substrato que já funciona. Eles não são incógnitas arquitetônicas.

## Por que estou escrevendo isso agora

Algumas semanas atrás, Oo Nwoye deixou um comentário público sobre um [artigo recente](https://markmhendrickson.com/posts/) sobre a memória do agente e perguntou, em muitas palavras, se o Plancast deveria ser ressuscitado para a era da IA. A resposta é a mesma acima. A missão original estava certa. O substrato estava errado. O substrato agora existe.

Não creio que a resposta seja reconstruir o Plancast como um aplicativo. A resposta é construir escopos de convites, presença e confiança como primitivos em uma camada soberana de estado pessoal, deixar os agentes fazerem o trabalho de ingestão e roteamento e deixar a mecânica social emergir do fato de que um convite é uma gravação digitada para um estado durável em vez de um evento de alimentação ambiental.

Se você construiu ou está construindo alguma coisa nesse bairro, eu gostaria de conversar.