En 2012 escribí una [autopsia para Plancast](https://markmhendrickson.com/posts/a-postmortem-for-plancast/), una startup en la que había pasado tres años. La premisa era simple: las personas hacen planes, vale la pena compartirlos y una información de los próximos eventos de personas en las que confías sacaría a la luz cosas que no sabías que querías hacer. No funcionó. El artículo explica por qué.

Al releerlo doce años después, los diagnósticos superficiales siguen siendo válidos. Los planes se hacen con muy poca frecuencia como para mantener un hábito de alimentación diario. Compartir planes futuros genera bucles de vanidad débiles en comparación con compartir fotos. Los planes caducan, por lo que cualquier contenido tiene horas de vida útil. La mayoría de los planes son geográficamente locales, por lo que la mayoría de los planes de su red son irrelevantes la mayor parte del tiempo. Y el problema más profundo: la gente no quiere estar ambientalmente consciente de eventos a los que no fueron invitados personalmente. La conciencia sin invitación se siente como exclusión. La mayoría de las personas tampoco quieren compartir todos los planes con toda su red. Pueden aparecer las personas equivocadas o la sala deja de parecer controlable.

Lo que me perdí en 2012 fue que ninguno de estos eran realmente problemas mecánicos del producto. Eran problemas de sustrato. El sustrato disponible en ese momento, un feed dentro de una red social centralizada, no tenía la forma adecuada para ninguno de ellos. Intenté diseñar el sustrato con características. El sustrato todavía era un techo bajo en todos los aspectos.

## ¿Qué estaba realmente mal?

Un feed es la primitiva incorrecta para compartir planes porque:

- Un feed supone un flujo constante de contenido. Los planes no llegan como un torrente.
- Una transmisión de recompensas en el feed. Los planes necesitan audiencias dirigidas.
- Un feed tiene una función de colapso. Plancast eligió "lo más pronto primero" según la fecha del evento, las redes sociales eligen "lo más nuevo primero" según la hora de publicación. De cualquier manera, es de tipo cronológico. Los planes se benefician de muchas funciones de consulta, y las útiles (quién irá en su gráfico de confianza, qué encaja este jueves, quién está en la ciudad) rara vez son de tipo cronológico.
- Un feed hace que cada contenido sea visible para todos los que te siguen. Los planes necesitan alcances.
- Un feed trata el consumo como la superficie de cara al usuario. Los planes necesitan composición con otros sistemas (calendarios, confirmaciones de asistencia, tránsito, clima).
- Un feed centraliza la mediación. Los planes son inherentemente entre personas.

Una vez que esa lista esté sobre la mesa, cada falla de Plancast que mencioné en 2012 será un síntoma posterior. El sustrato no podía expresar lo que realmente quiere ser el plan compartido.

## El sustrato que necesitaba

El sustrato sobre el que ahora construiría tiene dos piezas, ninguna de las cuales existía en forma utilizable en 2012.

**Estado duradero de solo agregar para agentes personales de IA.** Esto es lo que estoy creando como [Neotoma](https://neotoma.io). Cada observación que hace un agente (un contacto agregado, un evento confirmado, una invitación emitida, una asistencia confirmada) se convierte en una entidad tipificada con procedencia, restricciones de esquema y un historial inmutable. El propio agente de IA del usuario lee y escribe en él. No existe un gráfico social centralizado. El usuario es dueño del estado.

**Una malla soberana de libretas de direcciones y ámbitos de confianza.** Para esto es [Darkmesh](https://github.com/markmhendrickson/darkmesh) (mi bifurcación del original de [Anand Iyer](https://www.anandiyer.com/)). Darkmesh permite a una persona publicar porciones direccionables de su contexto (contactos específicos, grupos específicos, ámbitos específicos) en los nodos de malla de otras personas bajo consentimiento explícito. El consentimiento se mantiene en el borde de la red. El agente de un remitente no puede poner un mensaje en el estado de un destinatario a menos que el nodo de malla del destinatario haya admitido el alcance del remitente.

Los agentes personales de IA hablan entre sí a través de la red. Indique que se preocupan por la vida de forma duradera en el propio Neotoma de cada usuario. No existe un servidor central que contenga los planes de todos.

## Cómo la misión original se vuelve manejable

El discurso original de Plancast era: reuniones fortuitas a partir del conocimiento compartido de los planes. El error fue pensar que la conciencia compartida tenía que surgir de un feed.

Sobre este nuevo sustrato, la misma brea se descompone en diferentes obras.

1. **La ingesta de eventos es automática.** Mi agente ya conoce los eventos a los que he confirmado su asistencia en Luma, los eventos en mi calendario, los eventos en los correos electrónicos de confirmación de Eventbrite o Meetup. Los escribe en mi Neotoma como entidades de "evento" con procedencia. Nunca los escribo en ningún lado.

2. **El uso compartido está controlado y dirigido al consentimiento.** Cuando confirmo mi asistencia a algo, mi agente puede marcar ámbitos que deberían saber que voy a asistir. Estas no son publicaciones de noticias. Son observaciones dirigidas que viajan a través de la malla sólo a personas cuyos nodos han admitido mi alcance.

3. **El descubrimiento es una consulta, no un feed.** La superficie más natural para "lo que está sucediendo en mi mundo" no es un flujo. Es una pregunta que le hago a mi propio agente. *¿Quién, en mi confianza, irá la malla a dónde en las próximas dos semanas? ¿Cuál de esos eventos se adapta a mi velada de este jueves? ¿Quién está en la ciudad que no he visto en un año?* Cada consulta se calcula en el momento de la recuperación de mi Neotoma más cualquier alcance que mi malla haya admitido. No hay pienso.

4. **Las invitaciones son de primera clase.** Esta es la parte en la que insistió el artículo de 2012 y la parte que la mayoría de los intentos de producto se han saltado.

## Cómo deberían funcionar realmente las invitaciones

Plancast sí tenía invitaciones explícitas, pero eran manuales. Se ubicaron encima de un plan que sus suscriptores ya podían ver. La alimentación seguía siendo la primera superficie. Una etiqueta, una mención o metadatos que te señalaban tenían la misma forma: la visibilidad ambiental era lo primero, el toque personal en segundo lugar. Se supone que una invitación real invierte ese orden.

En este sustrato, una invitación es una entidad tipificada en el propio estado del destinatario. Aproximadamente:

```
invitación
  remitente: contact_id
  destinatario: contact_id
  event_ref: evento_id
  alcance: "1:1" | "grupo_pequeño" | "co_asistente_set"
  note_to_recipient: cadena (obligatoria, no vacía)
  Relationship_basis: cadena (por qué esta persona, por qué este evento)
  slot_budget_used: número entero (presupuesto por evento)
  expires_at: marca de tiempo
  conditional_on: predicado de quórum opcional
  procedencia: agente / fuente / marca de tiempo
```

Algunas cosas se derivan de esta forma.

**El sustrato se niega a entregarse si la malla no ha admitido el alcance del remitente.** Eso mata las invitaciones de masa fría a la velocidad de la máquina en la única capa donde se pueden matar: el borde de la red.

**Los presupuestos de invitación por evento obligan a la selectividad.** Cada evento tiene una cantidad pequeña y configurable de espacios para invitaciones que un remitente puede gastar. El sustrato, no la fuerza de voluntad, obliga a "no arruinar tu libreta de direcciones". La tensión entre vanidad y selectividad de 2012 se convierte en un parámetro de sustrato.

**El patrón dominante es retirar con autorización previa.** Cuando mi agente ejecuta su consulta permanente, solo ve las personas cuyos propios agentes me han marcado como alguien a quien darían la bienvenida en este evento específico. La intersección entre "quién en mi red irá" y "quién me daría la bienvenida allí" es mucho más pequeña que "quién en mi red publicó". No es una alimentación. Es un índice controlado por permisos.

**El contexto personal es obligatorio a nivel de tipo.** `note_to_recipient` y `relationship_basis` son campos obligatorios. Vacío no es un estado válido. Mi agente puede redactarlos desde mi gráfico de Neotoma (última superposición, contexto compartido, contactos comunes), pero la línea predeterminada es una línea confirmada por humanos. Esto es a lo que apuntaba el artículo de 2012 cuando insistía en que la gente quiere sentirse personalmente invitada. El sustrato hace de la nota personal un requisito estructural, no una cortesía opcional.

**El rechazo es silencioso y no está atribuido.** Los destinatarios responden con "aceptar", "aprobar" o "lápiz". Sólo "aceptar" es visible para el remitente. `pass` se resuelve como "sin respuesta" sin confirmación de lectura y sin motivo. El destinatario conserva su procedencia privada. Puedes auditar tu propia carga social sin exponerla.

**El quórum es un elemento primitivo de primera clase.** El artículo de 2012 mencionaba la procrastinación como uno de los principales fracasos: las personas mantienen abiertas las opciones y se niegan a comprometerse temprano. El sustrato aborda esto directamente con `condicional_on`: "Iré a X si Aaron y Diwaker también se comprometen". El sustrato observa el predicado y lo resuelve. Sin rol de coordinador, sin hilo de chat grupal, sin problemas.

**Componibilidad con el gráfico de eventos existente.** Cuando se acepta una invitación, el agente accede a la plataforma propietaria del RSVP canónico (Luma, Eventbrite, calendario) y escribe la reserva real. La entidad Neotoma `attendance_commitment` sigue siendo canónica para quién-confía-quién-va-dónde. La confirmación de asistencia de terceros sigue siendo canónica para el lugar y la puerta. Dos registros, una fuente de verdad por inquietud, vinculados.

## Lo que realmente están decidiendo los agentes

El sistema anterior sólo funciona si los agentes realizan un trabajo no trivial a nivel local. Las dos preguntas, en ambas direcciones del bucle, son concretas.

**Saliente, ¿quién agradecería este plan?** Cuando mi agente ve que he confirmado su asistencia a algo, califica mis contactos según el evento, no contra mí. Señales locales útiles:

- contactos cuyo Neotoma comparte temas compartidos o eventos a los que ha asistido,
- contactos con los que he estado en cosas similares en el último año,
- contactos que han optado explícitamente por una categoría (avisarme sobre música en vivo en esta ciudad),
- contactos cuyo propio horario o ubicación observada se superpone con la ventana del evento.

El agente produce una lista de candidatos clasificados, nunca un disparo automático. Los presupuestos de espacios los gasto yo o con mi confirmación, y el campo `relationship_basis` se completa con la misma puntuación para que pueda ver por qué se sugirió a una persona antes de enviarla.

**Entrante, qué planes que pasan a través de la malla valen la pena sacar a la luz.** Mi agente ejecuta la consulta simétrica contra las invitaciones entrantes y las observaciones de asistencia ambiental admitidas por mi alcance. Señales locales:

- cuán recientemente y con qué frecuencia he asistido con las personas involucradas,
- si el tema coincide con una categoría con la que me he mantenido comprometido,
- si mi propio calendario tiene espacio,
- si se está formando un quórum que me interesa.

La mayoría de los pings entrantes se archivan, no aparecen. Los que aparecen vienen con un breve párrafo del propio agente explicando por qué éste y no los demás.

Ambas direcciones son un trabajo pesado y ambas permanecen locales. No hay un clasificador central. El agente de cada usuario calcula en función del estado que posee el usuario y ese usuario puede inspeccionar la puntuación. Eso es lo que hace que la experiencia empiece a parecer una infraestructura que puede actuar en tu nombre sin convertirse en una plataforma.

## Cómo evolucionan las relaciones según lo observado

En un feed, su gráfico de relaciones es mayoritariamente estático una vez formado. Sigues a personas, rara vez las dejas de seguir y todo lo demás es ruido de señal que la plataforma interpreta por ti. En este sustrato, la gráfica está formada por observaciones.

Cada escritura escrita mueve ligeramente una relación. Una invitación enviada mueve el borde en una dirección. Una invitación aceptada lo lleva más lejos. La superposición de asistencia registrada por ambos agentes la lleva aún más lejos. Una conversación grabada, una nota compartida o una entidad de proyecto en la que ambos nodos se tocan dejan una observación en el borde entre dos contactos, con procedencia y una marca de tiempo.

Lo inverso también es cierto. Los bordes se deterioran cuando no pasa nada. Un contacto al que no has invitado, al que no has asistido o sobre el que no has escrito en un año es un tipo de ventaja diferente al contacto que viste el fin de semana pasado. La decadencia no es la eliminación. La historia todavía está ahí para ser recuperada. Pero la puntuación de relevancia del agente mañana utiliza el peso actualizado, por lo que un año de silencio cuesta visibilidad antes de que le cueste a la relación misma.

Esto invierte el modelo de alimentación en la forma que importa. Las fuentes hacen que el gráfico sea la entrada y la actividad la salida. Este sustrato hace que la actividad sea la entrada y el gráfico la salida. Las relaciones evolucionan porque el comportamiento es un estado estructurado, no porque alguien hizo clic en "Seguir" una vez en 2014 y la plataforma ha estado fingiendo que la ventaja todavía significa algo desde entonces.

## ¿Qué no es esto?

Este no es un intento de reemplazar las invitaciones escritas por humanos. El trabajo del sustrato es hacer que una invitación escrita a mano sea más barata de enviar, más segura de recibir y más difícil de enviar spam. Cada capa anterior está destinada a impulsar la experiencia hacia lo que en 2012 identifiqué correctamente como la moneda social real: alguien en quien confías pensó en ti específicamente. El sustrato no puede fabricar ese pensamiento. Puede negarse a entregar sustitutos.

## ¿Qué sigue abierto?

Algunas cosas para las que todavía no tengo buenas respuestas.

- Cómo deben denominarse y renovarse los presupuestos de invitación. ¿Por evento, por semana, por malla? ¿Vinculado a la tasa de aceptación?
- Cómo se propagan los cambios en el alcance de la malla cuando cambian las relaciones. ¿Cómo se ve revocar un alcance sin quemar una relación?
- Interoperabilidad entre mallas cuando los participantes ejecutan diferentes implementaciones de malla. ¿Requiere una capa de protocolo delgada?
- Manejo de abuso cuando un remitente previamente admitido comienza a enviar spam. ¿Quién aplica la penalización, el nodo de malla del receptor o el sustrato en su conjunto?
- Historia de migración para eventos cuya confirmación de asistencia canónica se encuentra detrás de un muro de pago o inicio de sesión.

Estas son preguntas reales, pero son preguntas sobre productos y protocolos además de un sustrato que ya funciona. No son incógnitas arquitectónicas.

## ¿Por qué estoy escribiendo esto ahora?

Hace unas semanas, Oo Nwoye dejó un comentario público sobre un [artículo reciente](https://markmhendrickson.com/posts/) sobre la memoria del agente y preguntó, en pocas palabras, si Plancast debería resucitar para la era de la IA. La respuesta es la misma que la anterior. La misión original era correcta. El sustrato estaba mal. El sustrato ya existe.

No creo que la respuesta sea reconstruir Plancast como aplicación. La respuesta es construir ámbitos de invitaciones, asistencia y confianza como primitivos en una capa de estado personal soberano, dejar que los agentes hagan el trabajo de ingesta y enrutamiento, y dejar que la mecánica social surja del hecho de que una invitación es una escritura mecanografiada en un estado duradero en lugar de un evento de transmisión ambiental.

Si ha construido o está construyendo algo en este vecindario, me gustaría hablar.