Cómo construimos un sistema operativo agéntico para una firma de private markets

Qué construimos para una firma de private markets

Una firma de private markets — que administra una cartera de inversiones directas, fondos de fondos y posiciones de tesorería — reemplazó su forma cotidiana de operar (planillas y correo) por una plataforma agéntica que su equipo ahora usa todos los días a través de los canales que ya usaba a diario. Greelow diseñó y entregó la plataforma de principio a fin.

El equipo ahora puede:

• Hacer preguntas sobre cartera, pipeline y contactos desde el chat o desde un dashboard web, y recibir respuestas basadas en las propias herramientas y documentos de la firma.
• Delegar trabajo programado y recurrente al agente — recordatorios, briefings, detección de respuestas de seguimiento — sin que esos flujos dependan del calendario de una sola persona.
• Compartir accesos de forma selectiva, de modo que el asistente de un socio pueda operar sobre el buzón del fondo de ese socio sin obtener acceso más amplio, y de modo que revocar a un usuario que se va elimine todo rastro de sus sesiones en una sola operación.
• Hacer preguntas que atraviesen fuentes distintas — una empresa que aparece en un chat, en un pitch deck y en una factura — y obtener una sola respuesta en lugar de tres parciales.

Cada afirmación arquitectónica que sigue se corresponde con código que hoy ejecutamos para este cliente. Los sistemas agénticos empresariales tienden a fallar en los mismos tres lugares: identidad, memoria y permisos. La plataforma fue diseñada en torno a esos tres desde el primer día, y el resto de la arquitectura se derivó de ellos.

El desafío

Un equipo de mercados privados de menos de veinte personas operaba una cartera con algunos cientos de posiciones entre inversiones directas y fondos. Sus datos canónicos vivían donde siempre habían vivido: una planilla maestra, un workspace para pipeline y contactos, y sus casillas de correo.

Nada en ese sistema estaba tan roto como para justificar un rediseño. Todo estaba tan lento como para forzar una solución de compromiso. Actualizar la cartera significaba abrir la planilla, revisar el workspace, buscar en el correo la última nota de un fundador y reconciliar a mano. La información nueva se quedaba a menudo en la casilla de una persona hasta que otra preguntaba por ella.

Querían conservar la planilla como fuente de verdad. Años de metodología estaban dentro de sus fórmulas. Pero querían que la superficie diaria fuera una ventana de chat. Querían que el sistema supiera quién era cada usuario y lo recordara entre sesiones. Querían límites por usuario que satisficieran su propia postura de gobernanza. Y no tenían un equipo interno de ingeniería para construir nada de eso.

Agentes en los que el equipo confía para trabajo real

El planteo era específico. La plataforma tenía que llegar a un estado funcional rápidamente, pero cada decisión arquitectónica tenía que sobrevivir años, porque la firma no tiene planes de formar un equipo interno de ingeniería.

Tres restricciones dieron forma a cada decisión de diseño.

La superficie diaria es el chat. No otra interfaz SaaS. Cada capacidad tenía que ser accesible desde las mismas plataformas de mensajería que el equipo ya usaba, con un dashboard web para las superficies que realmente se benefician de tablas y gráficos.

El agente opera con credenciales reales. No con una cuenta de servicio compartida. Las trazas de auditoría, la atribución individual y la revocación por usuario tenían que ser consecuencias naturales del diseño, no funcionalidades agregadas después.

El agente tiene que recordar quién es cada usuario. No solo el último mensaje. Quién es, cómo trabaja y en qué está enfocado — de forma persistente, por usuario, a lo largo de conversaciones y de canales.

La solución

Identidad por usuario, credenciales por usuario

Cada usuario aporta sus propias credenciales a la plataforma, y el sistema las mantiene separadas. El agente, cuando actúa en nombre de un usuario, actúa con la autoridad de ese usuario y de ningún otro. Dos usuarios hablando con el agente al mismo tiempo alcanzan conjuntos de credenciales completamente disjuntos.

El acceso compartido entre usuarios es un concepto de primera clase, no un parche. Un socio puede compartir el buzón de su fondo con un asistente, y el agente del asistente hereda ese acceso acotado por el mismo camino de código que el propio. Un usuario que se va se desaprovisiona en una sola operación que recorre las dos direcciones de cada acceso compartido en el que participaba, de modo que ningún acceso residual sobrevive de ningún lado.

Nada de este estado se guarda en disco. Los sistemas multi-tenant que guardan información crítica del usuario ahí tienden a perderla. La plataforma se negó a heredar esa fragilidad. El estado dinámico vive en la base de datos. El almacenamiento local se trata estrictamente como una caché que se puede reconstruir en cualquier momento. Un ingeniero nuevo que se suma al proyecto hereda esa disciplina como el patrón por defecto, no como el antipatrón.

La capa de credenciales es donde mueren muchos pilotos empresariales. Los equipos esperan salir al aire antes de que alguien de seguridad pida ver el diseño. Resolver primero la respuesta de seguridad hizo que cada decisión posterior fuera más económica.

Un catálogo de servidores de herramientas pequeños, con alcance por dominio

El agente alcanza los sistemas operativos de la firma a través del Model Context Protocol. En lugar de un solo servidor de herramientas amplio, la plataforma expone un catálogo de servidores acotados, cada uno con alcance a un solo dominio: finanzas, cartera, recuperación de documentos, facturación, y así.

La elección fue deliberada. Los servidores acotados siguen siendo auditables. Cada uno recibe únicamente las credenciales que su dominio requiere, así que una inyección de prompt que llega a un servidor no puede cruzar a otro. Los servidores acotados evolucionan de forma independiente, sin arrastrar al resto de los dominios en su ciclo de versiones. Y los servidores acotados mantienen barata la inyección de credenciales por usuario: el constructor para un servidor pequeño es pequeño.

Una capa de grafo se ubica encima de los servidores de herramientas y resuelve entidades a lo largo de fuentes distintas. Cuando una empresa de la cartera aparece en un hilo de chat, en un pitch deck y en una factura, las tres referencias se resuelven al mismo nodo. El equipo puede entonces hacer preguntas que la base de datos subyacente no podría responder a bajo costo — "qué personas aparecen en materiales vinculados a empresas de la cartera de un fondo determinado" — sin que esas preguntas se transformen en queries escritas a mano.

La base de datos sigue siendo la fuente de verdad. El grafo es una capa derivada que puede reconstruirse desde la fuente en cualquier momento.

Dos formas de programar trabajo

Los sistemas agénticos que solo responden a mensajes desaprovechan la mitad de su valor. La plataforma programa trabajo de dos formas.

El trabajo regular de la plataforma se ejecuta en una cadencia programada. Scoring de cartera, actualizaciones de foco, briefs diarios y semanales, sincronizaciones incrementales desde correo y drive, correspondencia entre personas y empresas a lo largo de fuentes distintas — cada uno tiene una frecuencia definida y un alcance definido. El alcance es explícito: si una tarea aplica a todos los usuarios, a un subconjunto específico, o a la plataforma en su conjunto. Hay un solo lugar donde mirar para saber qué se ejecuta cuándo.

Junto a la programación de la plataforma, los usuarios pueden pedirle al agente que haga cosas más tarde. En lenguaje natural, sin necesidad de interfaz. Recuérdame mañana a las nueve que llame a X. Cada lunes, envíame un resumen de mi bandeja. Cada pedido se convierte en un compromiso duradero que el sistema honra cuando llega el momento, y el sistema está diseñado para que dos agentes nunca toquen la sesión del mismo usuario al mismo tiempo.

Un motor dedicado, no una colección suelta de scripts

El motor que hace funcionar al agente — eligiendo a qué modelo llamar, alimentándolo con las credenciales correctas, siguiéndole el rastro a lo que hizo y dando forma a sus resultados en algo utilizable — es un sistema coherente, no un surtido de scripts. Todo lo demás en la plataforma delega en él. Tres de sus partes son las que verdaderamente importan.

La elección de proveedor de modelo está separada del resto del sistema. Cuando la plataforma necesita que el agente piense, pregunta. La capa de abajo se encarga de decidir a qué proveedor llamar. Cambiar de proveedor por usuario o por carga de trabajo es un cambio acotado, no una reescritura.

Una memoria de dos niveles por usuario resuelve el modo de falla en el que el agente se olvida de quién eres entre conversaciones. Una memoria episódica con ventana corta carga el pasado reciente. Una capa semántica duradera carga quién es cada usuario y cómo opera. La capa semántica está siempre presente en el prompt del agente. El usuario no tiene que volver a explicarse.

Una biblioteca de skills específica del dominio le da al agente el vocabulario y los flujos de trabajo de las finanzas de mercados privados. Administración de fondos, operaciones de cartera, análisis de inversiones. El agente razona en el lenguaje propio de la firma, no en uno genérico.

El resultado

La firma ahora vive su día a día a través de esta plataforma. Cartera, pipeline, contactos y documentos son alcanzables desde una sola conversación, desde el canal que cada usuario prefiere, con el agente operando con las credenciales reales de ese usuario y recordando quién es entre sesiones. La compartición selectiva permite a los socios dar acceso acotado a asistentes sin abrir permisos más amplios. Cada desaprovisionamiento elimina todo rastro de un usuario que se va en una sola operación.

El sistema es lo que la firma llama suyo. No porque lo hayan escrito, sino porque opera sobre sus datos canónicos, respeta su postura de gobernanza y habla su vocabulario.

Los resultados cuantitativos para las operaciones de la firma siguen bajo observación. El sistema es lo suficientemente reciente como para que el equipo aún esté midiendo qué cambió. Cuando los números lleguen, los publicaremos en sus propios términos.

La plataforma es lo suficientemente pequeña como para que un ingeniero nuevo pueda tenerla en la cabeza tras una semana. Eso no es un accidente. Es una restricción de diseño. Lo que un equipo no puede sostener en una sola cabeza, ese equipo no puede desarrollar con seguridad.