Por qué los agentes más rápidos dejaron al resto del equipo sin contexto

El check-in que llegó sin su contexto

Si cada persona que programa ya es más rápida con un agente, ¿qué tiene que viajar con el trabajo para que la siguiente persona del equipo pueda continuarlo? La respuesta de Kay Malcolm es la sesión misma. En una charla publicada en el canal AI Engineer el 14 de septiembre de 2026, dice que un commit puede dejar el código en su sitio y, aun así, dejar al turno siguiente sin nada desde lo que continuar. Esa fecha de septiembre es el momento en que se publicó la grabación. Ella sitúa la historia de trabajo en 2025.

Dice que dirige la gestión de producto de bases de datos outbound en Oracle y que lleva 20 años en la empresa. La organización que describe tiene cuatro clases de trabajo, y no da plantilla: desarrollo de plataforma, contenido de live lab en una plataforma que dice haber escrito, QA y desarrollo de front-end hecho con IA. Llama a la etapa anterior una era de llevar los tokens al máximo, y dice que el equipo ha pasado después a lo que ella llama IA responsable.

Su juicio sobre ese periodo anterior es que la IA hizo más rápidas a las personas y no dejó al equipo más productivo. No aporta tiempo de ciclo, rendimiento ni gasto en tokens. El ejemplo es un equipo de los Países Bajos. Dice que registraron código a las 4:00 a. m. de ella y dejaron fuera de ese check-in el contexto de Codex. Dice que los equipos de Oracle usan Codex. Describe al equipo más amplio como mitad en EMEA y mitad en Estados Unidos, y así explica esa hora temprana.

En su relato, la mitad de Estados Unidos despertó con el código y sin la sesión que lo produjo. Dice que el equipo usó entonces la IA para reparar una brecha de contexto que había creado la programación asistida por IA. Codex en Oracle sigue siendo su relato de cómo trabajaba ese equipo.

• No Memory, No Harness: Why the Database Is the Last Line of Defense — Kay Malcolm, Oracle

El código entró y el cuello de botella se movió

El diagnóstico de Malcolm de aquella mañana es un problema de control de versiones en su propio flujo de trabajo. Dice que GitHub seguía el código, que los repositorios divergieron y que git registró el código mientras la intención humana se quedó fuera del commit. Ese es su relato de cómo este equipo usaba git.

Dice que el dinero gastado en tokens y en IA dejó en su sitio el tiempo de pruebas y validación, así que ella seguía preguntando a los responsables por qué el equipo no iba más rápido. No nombra ningún gasto, ningún volumen de tokens ni ninguna medición del tiempo de prueba. En su relato, el resultado neto seguía sin alcanzar la aceleración que esperaban los responsables.

Cuando escribir el código dejó de ser el cuello de botella, dice que el equipo necesitaba una capa de colaboración. Esa capa tenía que seguir los pasos siguientes, explicar las decisiones que estaba tomando el agente y resolver preguntas y conflictos. En esta parte de la charla, la IA es el nuevo compañero que la capa tiene que incluir. Dice que algunos miembros de su equipo estaban entre el público.

El arnés alrededor del modelo

Malcolm deja entonces a un lado la historia de la noche y define lo que entiende por un agente empresarial de verdad. Dice que la mayoría trata a ese agente como un modelo más un flujo de trabajo, y rechaza esa pareja como el conjunto entero. En su relato, la sala coincidió en gran parte en que un agente empresarial es más que esas dos piezas.

Su conjunto tiene cinco partes, y ella llama arnés al conjunto. Las herramientas son el modo en que el agente actúa. El contexto es la ventana de contexto, el material que va en el prompt. Nombra la memoria como una parte propia, y más adelante distingue el estado de la sesión de lo que persiste entre sesiones. La recuperación es el modo en que el agente recupera el fragmento pertinente, porque ella no quiere que traiga todo. Los guardarraíles están en la misma capa. Bromea con que a los desarrolladores de la sala no les importa la seguridad, y después dice que los guardarraíles están ahí por su propio papel.

Explica el conjunto con una imagen al estilo Marvel. El modelo es un cerebro flotando en un frasco de vidrio. El arnés es el cuerpo que hace el trabajo. La memoria es el sistema nervioso central que lleva el contexto del cerebro al resto del cuerpo. Vuelve a señalar la brecha de Git y dice que la pieza que faltaba era ese sistema nervioso.

• Herramientas: cómo actúa el agente sobre el mundo.
• Contexto: la ventana de contexto, el material que va en el prompt.
• Memoria: una parte aparte del arnés. Más adelante distingue el estado de la sesión de lo que persiste entre sesiones.
• Recuperación: traer de vuelta el fragmento pertinente de lo que se guardó.
• Guardarraíles: los límites que ella pone en la misma capa que el resto del arnés.

Cinco clases de memoria que quiere que se recuerden

Malcolm dice que hay muchos tipos de memoria y que eligió cinco comunes que quiere que la sala recuerde. Es un conjunto didáctico, la lista que escogió para la charla. Aquí separa el estado de la sesión de lo que persiste entre sesiones, la distinción que aplazó cuando nombró la memoria dentro del arnés. Después de las definiciones, dice que la pregunta abierta es dónde se sitúa esa memoria.

Menciona un agente personal jefe de gabinete al que llamó Sasha Fierce solo para dejarlo a un lado. La charla, dice, trata de la memoria semántica para agentes empresariales.

• La memoria a corto plazo es el estado de la sesión. Sus ejemplos son el chat, Claude Code y Codex.
• La memoria a largo plazo es lo que persiste entre sesiones.
• La memoria episódica es lo que ocurrió la última vez que el agente interactuó con alguien o con algo.
• La memoria procedimental son las herramientas usadas y los pasos dados.
• La memoria semántica es el conocimiento empresarial del que, según ella, trata esta charla.

Por qué otro almacén especializado le pareció caro

El argumento del almacenamiento llega como una historia anterior a Oracle. Malcolm dice que llegó a Oracle desde Southern Company, a la que llama una compañía eléctrica. Dice que está basada en Atlanta. En Southern Company trabajó como afinadora del rendimiento de SQL. Dice que conocía los parámetros de init.ora, los parámetros de arranque de Oracle, incluidos unos que soporte le dijo que no anotara. En ese mundo, dice, los datos eran filas y columnas.

Un desarrollador le pidió entonces que almacenara datos no estructurados. Dice que le contestó que lo resolvería y volvería con él, y que nunca lo hizo. En Southern Company, según su recuerdo, cada base de datos que administraba un DBA significaba dos reuniones semanales, una de seguridad y otra de parches, bajo la ley Sarbanes-Oxley, la ley estadounidense de cumplimiento corporativo que ella sigue asociando con esas reuniones. Cuando ese desarrollador instaló una base de datos aparte para los datos no estructurados, dice que su carga pasó de dos reuniones a cuatro. Esos recuentos son su memoria del puesto.

Después describe un flujo de trabajo de seguridad vital para personas que suben a torres a restablecer la electricidad. Dice que el sistema producía falsos positivos y falsos negativos, y que el grupo quería que se comprobaran los postes cercanos antes de enviar a quienes subían. Respondió a la pregunta de la relación con un UNION ALL anidado de cinco niveles. Dice que pudo tardar unos 20 minutos, y llama a esa consulta un antecedente del grafo. Los 20 minutos son su cifra para esa consulta en un flujo de trabajo que recuerda.

Dice que el grupo instaló después Neo4j, una base de datos de grafos, y que sus reuniones recurrentes pasaron a seis. Dice que dejó el puesto y se fue a Oracle para ayudar a resolver la expansión de las bases de datos especializadas. Ese es su relato de por qué se marchó.

Cuatro almacenes y ningún lugar en el que el agente pueda confiar

Ya en Oracle, Malcolm dice que una persona que llamó, a la que nombra como Joe Mundy, le dijo que la empresa llegaba tarde, que estaba instalando Redis y que tenía una base de datos vectorial. El nombre, la instalación de Redis y la sensación de que Oracle llegaba tarde forman parte de la llamada tal como ella la recuerda.

Su tesis sigue de inmediato. Un agente que tiene que leer una copia relacional, una copia JSON, una copia de grafo y una copia vectorial tiene que inventar una única fuente de verdad. Dice que a veces acertará, que la mayoría de las veces se equivocará y que una adivinación errónea quema tokens. “Most times” (la mayoría de las veces) es su estimación. No da ninguna tasa de error ni ningún recuento de tokens.

Dice que la memoria también puede residir en un sistema de archivos, o en un archivo de asistente como memory.md para Claude o ChatGPT. En su argumento, un archivo que una persona puede leer sigue sin resolver el problema de coordinación que está a punto de poner en escena.

Para mostrar el fallo, sienta a cuatro voluntarios como una base de datos relacional, una base de datos no estructurada, una base de datos de grafos y una base de datos vectorial. Tienen que guardar una frase, “The cow jumped over the moon” (la vaca saltó sobre la luna). Les dice que sigan sentados y que susurren. Hablar en voz alta, dice, significaría cinco veces los tokens, una regla que dio a los voluntarios. Trata su incapacidad para acordar una única fuente de verdad como la demostración.

Su mapa de los tipos de memoria hacia una sola base de datos

La frase que Malcolm pide a la sala que conserve es una afirmación de producto. Dice que Oracle puede almacenar de forma nativa JSON, grafo, vector, datos espaciales y datos inmutables al estilo de una cadena de bloques en una sola base de datos, hasta la misma tabla o la misma partición. Los tipos nativos, el alcance de la partición y la inmutabilidad al estilo de una cadena de bloques siguen siendo su afirmación desde el escenario.

Dice que cualquier tipo de dato y cualquier carga de trabajo pueden ejecutarse en lo que ella llama una base de datos 26AI en AWS, Google Cloud, Azure, OCI y en instalaciones propias, y lee la sorpresa de la sala como un problema de marketing de Oracle. 26AI es el nombre que pronuncia para esa frase de cualquier carga de trabajo. La disponibilidad en esas nubes sigue sin verificarse.

Después bosqueja dónde se situarían sus tipos de memoria. La formulación en el escenario está comprimida, y algunos tipos caen en más de una representación. La tabla sigue la asignación que ella pronuncia. Es su sugerencia.

Dice que cuatro bases de datos separadas no pueden hablar entre sí, que es lo que entiende que mostraron los voluntarios, y llama a Oracle AI Database el mejor lugar para guardar la memoria del agente que impulsa un arnés. El punto de la coordinación es su argumento. “El mejor” no tiene ninguna comparación al lado en la charla. Vuelve a la imagen: el arnés es el cuerpo y la memoria es el sistema nervioso.

Lo que el bróker interno guardó con el commit

Malcolm dice que su equipo respondió a la brecha de la noche con un bróker interno de memoria. La charla lo llama Py y, más tarde, Polly. Esas son las dos formulaciones del escenario. No presenta ninguna de las dos grafías como nombre de un producto que se distribuya.

En su relato, el bróker guardó contexto procedimental, episódico y de largo plazo para que los compañeros humanos compartieran código y contexto a través de forks, ramas y commits. Dice que el equipo abandonó la continuidad automática. Los desarrolladores siguieron al mando mientras Polly creaba el contexto y resolvía a qué fork, rama y commit pertenecía ese contexto. La historia del bróker muestra el contexto atado a un fork, una rama y un commit, con una persona todavía a cargo.

Llama simplista al ejemplo. A escala empresarial, dice, la memoria se vuelve innegociable dentro de un arnés. Deja esa ampliación como su juicio.

Los artículos y el límite de memoria para un solo usuario

Malcolm dice que leyó tres artículos en el avión. Parafrasea un artículo de OpenAI y una frase de Harrison Chase, y nunca nombra un tercer título. El apunte sobre Claude que sigue es su propia comparación, después de esas dos lecturas.

En su paráfrasis de un artículo de OpenAI que no nombra, un agente de datos interno necesitaba memoria para filtrar correctamente en lugar de emparejar cadenas. Esa formulación es su lectura de avión. No da ningún título.

Cita a Harrison Chase por una frase que ella formula como “Your harness, your memory” (tu arnés, tu memoria) y después: si no eres dueño de tu arnés, no eres dueño de tu memoria. Esa es su cita desde el escenario, y la formulación no está comprobada.

Después dice que la memoria de Claude se comporta como una memoria de sistema de archivos que funciona para un usuario y crea un problema cuando el uso empresarial escala más allá de una persona. Ese límite de un usuario es su comparación. No muestra en el escenario la implementación de la memoria de Claude, ni un fallo multiusuario.

El traspaso que bosqueja para Kevin y Linda

Desde el escenario, Malcolm señala un paquete que, según dice, se instala con pip, el instalador de paquetes de Python, bajo un nombre que la charla formula como Oracle agent memory. Dice que el SDK guarda conversaciones en curso, memorias y hechos, y que decide qué merece conservarse. El nombre del paquete, la línea de instalación y ese comportamiento de retención siguen siendo un señalamiento que ella hizo desde el escenario.

El recorrido que ilustra usa a dos compañeros, Kevin y Linda. Dice que Linda está sentada en la sala. Kevin comparte contexto con el bróker a través de ese SDK. Dice que el almacenamiento es Oracle Autonomous Database y que el modelo puede ser un LLM que elija el equipo o un modelo local en lo que ella llama el Oracle private AI services container. Autonomous Database y el contenedor privado siguen siendo afirmaciones de producto sin verificar. Kevin y Linda son sus nombres de ejemplo para el traspaso.

Su cierre repite el juicio inicial y añade un resultado de producto. La IA, dice, hace más rápidas a las personas, y la memoria compartida en una Oracle AI Database hace más rápidos a los equipos. El resultado de velocidad del equipo es suyo. No aporta ninguna métrica de equipo. También dice que 26AI permite a un equipo elegir almacenamiento en el sistema de archivos, archivos guardados en la base de datos, o modelado JSON y relacional dentro de la base de datos. Esa elección sigue siendo su descripción del producto.

Qué puede llevarse un equipo de la charla

El argumento utilizable es la separación entre una sesión individual rápida y un equipo que hereda solo el diff. Los pasos siguientes, la razón de las decisiones del agente y la historia de preguntas y conflictos tienen que residir en algún lugar que la siguiente persona pueda leer. La historia nocturna de Malcolm es una forma en que aparece esa separación: un equipo de los Países Bajos registró código de Codex a las 4:00 a. m. de ella y dejó atrás la sesión. Cualquier sesión de agente que termine en un commit puede producir la misma brecha.

Sus cinco tipos son una lista práctica de comprobación para ese almacén: estado de la sesión, memoria que dura entre sesiones, la última interacción, herramientas y pasos, y el conocimiento empresarial del que dependía el cambio. La recuperación y los guardarraíles siguen formando parte del arnés alrededor de ese almacén. Los cinco tipos son el conjunto que ella eligió para enseñar.

Los almacenes separados recrean el fallo de coordinación que ella puso en escena, ya sean una base de datos relacional, una base de datos JSON, una base de datos de grafos, una base de datos vectorial o un archivo personal de memoria que un usuario puede leer. Poner varias representaciones en un solo sistema es el remedio que ella propone. Las capacidades de Oracle que nombra siguen siendo afirmaciones de quien habla. Oracle AI Database es el nombre que está en su frase del mejor lugar. 26AI es el nombre que usa para cualquier tipo de dato, cualquier carga de trabajo, las nubes que enumera y la elección final de almacenamiento.

Un equipo puede copiar la elección de control que ella describe para el bróker. Adjuntar el contexto a un fork, una rama y un commit, y dejar que una persona decida qué puede continuar la sesión siguiente. Dice que Polly creó ese contexto mientras los desarrolladores seguían al mando, y que abandonó la continuidad automática a propósito. La charla muestra ese diseño como una historia interna a la que ella llama simplista.

• El paso siguiente hacia el que iba la sesión.
• Por qué el agente tomó la decisión que tomó.
• Preguntas y conflictos, y cómo se resolvieron.
• El fork, la rama y el commit a los que pertenece ese contexto, con una persona que sigue eligiendo qué continúa.