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.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
