OpFarma, una compañía de agentes que coloca lotes por vencer

Mi resolución del desafío técnico de Paperclip.

Desarrollé esta solución con Claude Code, que usé como herramienta para el código, la plataforma y la documentación, y que además ejecuta a los agentes de OpFarma. Estuvieron a mi cargo la definición del problema, las decisiones de diseño y toda la operación con sistemas reales. Di de alta y configuré la cuenta de WhatsApp Business de OpFarma cuando Meta bloqueó la primera, cargué las credenciales, aprobé cada tarjeta en Paperclip, ejecuté el circuito completo en macOS y en Windows, recibí las ofertas en un celular real y verifiqué los servidores en producción.

OpFarma es una distribuidora de insumos médicos armada como compañía de agentes. Los agentes detectan los lotes que se van a vencer en el depósito, buscan qué cliente puede consumir cada uno antes de la fecha según lo que realmente compra, y le mandan la oferta por WhatsApp. El lote que ninguna cuenta absorbe se ofrece a clínicas nuevas con un posteo en LinkedIn, y ese posteo queda listo para que Grok Bot lo publique. Una persona aprueba el margen, cada mensaje y cada posteo.

Cubre las tres vías del desafío. B2 (WhatsApp) con envío real, B3 (LinkedIn) con un dry-run del pedido exacto, y B1 (Grokbot) con el traspaso listo en la tarea.

La entrega

• Video del flujo (Loom, menos de 2 minutos), en https://www.loom.com/share/1bd98da03eb24adc9ae1734368438296. Va de la aprobación del margen al posteo de LinkedIn en dry-run, el traspaso a Grok Bot, la aprobación del WhatsApp, el mensaje que llega y el aviso de Meta en la plataforma. Es otra corrida del mismo circuito, en una Mac, así que las tareas tienen otros números que en la página de evidencia.
• Plataforma deployada en Vercel, en https://opfarma-paperclip-challenge.vercel.app. Tiene un explorador que corre el mismo motor que usan los agentes. Se elige un lote y se ve qué cuenta lo consume a tiempo, por qué las demás quedan afuera, el precio y el mensaje que saldría. Una barra adelanta el reloj para ver qué pasa si nadie hace nada. También expone los dos servidores MCP en /api/mcp/inventory y /api/mcp/whatsapp, protegidos con clave.
• La compañía en Paperclip, tal como trabajó, en https://opfarma-paperclip-challenge.vercel.app/paperclip. Paperclip corre en la máquina de cada persona, así que ahí está el historial real de siete tareas, con cada tarjeta de aprobación, exportado con scripts/export-evidence.mjs y sin datos personales.
• Research de Paperclip, de una página, en research/RESEARCH.md. La versión extendida está en research/PAPERCLIP.md.
• Decisiones, de media página, en DECISIONS.md. El detalle técnico de cada obstáculo está en docs/BITACORA.md.
• Cómo lo verifiqué, en VERIFICATION.md.
• Cada decisión con sus alternativas, en el registro de decisiones.
• Por qué tres canales y por qué LinkedIn, con fuentes, en research/CANALES.md.
• Cómo pasar LinkedIn de la simulación a publicar de verdad, en docs/LINKEDIN.md.
• El problema y sus fuentes, en research/EXPIRY.md.
• Cómo pasar WhatsApp a producción, en docs/PRODUCCION.md.

Por qué este problema

El enunciado deja libre el objetivo de la compañía. No quería una demo en la que el agente manda un WhatsApp que una persona podría mandar igual. Busqué una tarea que a mano no se llega a hacer.

En un distribuidor de insumos médicos, un lote que vence en depósito no reduce el margen. Se pierde el 100% del costo. Saber qué se vence es fácil, porque cualquier sistema lo avisa. Lo difícil es saber a quién vendérselo antes de la fecha, y eso exige cruzar cada lote con la rotación de cada cuenta. Con cientos de cuentas, esa tarea simplemente no se hace. El software del rubro avisa pero no coloca; los proyectos de redistribución la resuelven dentro de una red hospitalaria, y los marketplaces de excedentes publican el stock y esperan a un comprador. No encontré herramientas que, del lado del distribuidor, busquen activamente al cliente que va a consumir cada lote a tiempo. Las auditorías, normas, estudios y entrevistas que respaldan el problema están en research/EXPIRY.md.

Cómo está armado

   Paperclip  (el molde)                    platform/  (las manos, en Vercel)
   ┌───────────────────────────┐            ┌──────────────────────────────┐
   │ OpFarma                   │            │  /api/mcp/inventory          │
   │                           │   MCP      │    escanear, colocar, ofertar│
   │  MarginReviewer  (qa)     │◀──────────▶│    margen: aprobación humana │
   │        ▲                  │            │  /api/mcp/whatsapp           │
   │        │ reportan         │            │    envío: aprobación humana  │
   │  StockScout     (general) │            │  /api/mcp/social             │
   │  GrowthScout    (cmo)     │            │                              │
   │                           │            │    posteo: aprobación humana │
   │  detectar                 │            └──────────────────────────────┘
   │  ofertar  ◀── revisor     │                 │               │
   │  aprobar y enviar         │                 ▼               ▼
   │  postear en LinkedIn      │        WhatsApp Cloud API   LinkedIn (dry-run)
   │  traspaso a Grok Bot ─────┼──MCP──▶ mcp.grokbot.dev ──▶ una persona lo pega en Grok
   └───────────────────────────┘

Separé las "manos" a propósito. El servidor de inventario no puede contactar a nadie; el de WhatsApp y el de redes son los únicos que salen hacia afuera. Son riesgos distintos, así que tienen conexiones y políticas distintas. Grokbot es de terceros y de sólo lectura, así que entra sin clave y sin permisos especiales.

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗