Ingeniería de contexto: el trabajo antes del aviso

spinny:~/writing $ vim context-engineering-agents.md

1~
2La palabra del momento, en el pequeño mundo de los agentes de IA, es ingeniería de contexto.
3~
4Parece una etiqueta más inventada para vender algo que ya hicimos. En parte lo es. Sin embargo, como suele suceder, la etiqueta prevalece porque da nombre a un dolor real.
5~
6El problema es éste: los modelos no fracasan sólo porque "no piensan". A menudo fallan porque los enviamos a trabajar en la habitación equivocada.
7~
8Les damos viejas instrucciones. Le ocultamos archivos importantes. Les pasamos documentos demasiado largos y no decimos lo que importa. Les mostramos registros sin prioridad. Les damos diez herramientas sin explicarles cuándo usarlas. Entonces nos sorprende que el agente se mueva como una persona despierta en un apartamento desconocido.
9~
10El mensaje es la frase que le dices. El contexto es el mundo que preparas a su alrededor.
11~
12## De la ingeniería rápida a la ingeniería de contexto
13~
14A menudo se pensaba que la ingeniería rápida era escritura. Elija las palabras correctas, pregunte de la manera correcta, agregue ejemplos, especifique el formato.
15~
16La ingeniería de contexto está más cerca de la arquitectura.
17~
18No se pregunta simplemente "¿cómo formulo la solicitud?". Pregunta:
19~
20- ¿Qué información se necesita realmente?
21- ¿Qué son los ruidos?
22- ¿Qué hay que recuperar sobre la marcha?
23- ¿Qué hay que recordar?
24- ¿Qué herramientas deberían exponerse?
25- ¿Qué instrucciones son estables y cuáles dependen de la tarea?
26- ¿Cómo hago para que el agente comprenda qué es la autoridad?
27~
28Es un cambio sutil pero enorme. Porque cuando trabajas con agentes, el contexto no es un bloque estático. Cambia a cada paso.
29~
30El agente abre un archivo, aprende algo, ejecuta una prueba, recibe un error, actualiza el plan, llama a una herramienta, descubre una dependencia. En cada vuelta tiene que decidir qué llevar consigo y qué dejar fuera.
31~
32Esto es ingeniería.
33~
34## El contexto no es un vertedero
35~
36Las plantillas con grandes ventanas contextuales nos dieron la tentación: incluyamos todo.
37~
38Es comprensible. Si tengo un millón de tokens, ¿por qué debería elegir?
39~
40Porque incluso cuando puedes poner todo, eso no significa que todo ayude. De hecho, el ruido tiene un coste. Cuesta tokens, cuesta atención, cuesta latencia, cuesta calidad. Un modelo puede perderse en detalles irrelevantes como nosotros cuando abrimos veinte pestañas y ya no recordamos por qué.
41~
42El buen contexto tiene una jerarquía:
43~
441. instrucciones y políticas del sistema;
452. objetivo específico;
463. situación actual;
474. datos relevantes;
485. limitaciones;
496. herramientas disponibles;
507. realizar un seguimiento de las decisiones ya tomadas.
51~
52No es necesario tratar todo al mismo nivel. Un comando de usuario vale más que una nota antigua. Una prueba fallida vale ahora más que una preferencia estética de hace tres meses. Una política de seguridad vale más que un atajo en la producción.
53~
54La ingeniería de contexto también significa dar ponderaciones, no sólo datos.
55~
56## Memoria: recuerda menos, recuerda mejor
57~
58La memoria en los agentes es uno de los temas más resbaladizos.
59~
60Como usuario, quieres que el agente te conozca. Quieres que recuerde el tono, el plan, las convenciones, las cosas ya decididas. Como ingeniero, usted sabe que cada recuerdo persistente también es un riesgo: puede ser incorrecto, antiguo, demasiado personal, demasiado genérico o no verificable.
61~
62Una memoria útil debe tener al menos tres cualidades:
63~
64- procedencia: ¿de dónde viene esta información?
65- fecha: ¿cuándo fue cierto?
66- finalidad: ¿para qué tipo de tarea debería utilizarse?
67~
68Sin estas tres cosas, la memoria se convierte en superstición.
69~
70Me gusta pensar en la memoria agente como un libro de trabajo, no como una mente mágica. Hay notas temporales, decisiones confirmadas, preferencias de estilo, limitaciones técnicas, enlaces a fuentes. Algunas cosas caducan. Algunos necesitan ser reescritos. Algunos deben ser eliminados porque el agente los malinterpretó.
71~
72Un buen sistema debe hacer que este mantenimiento sea normal. No heroico.
73~
74## Recuperación y herramientas no son lo mismo
75~
76Cuando hablamos de contexto, a menudo terminamos inmediatamente en RAG. Incrustación, base de datos vectorial, fragmentación, reclasificación.
77~
78Todo útil. Pero la recuperación es sólo una manera de llevar información al modelo. Él no es el único.
79~
80Un agente puede obtener contexto leyendo archivos, consultando una API, llamando a un servidor MCP, abriendo un navegador, ejecutando pruebas, buscando en Slack, mirando un panel, preguntando al ser humano.
81~
82Lo interesante es decidir qué ruta utilizar y cuándo.
83~
84Si el agente necesita responder a una pregunta histórica, quizás basta con recuperarla. Si tiene que corregir un error, tiene que leer código real. Si necesita comprender por qué falla una implementación, debe consultar registros nuevos. Si necesita escribirle a un cliente, debe recuperar el tono, el historial y el estado del ticket. Si debe actuar sobre la producción, debe pedir permiso.
85~
86El contexto no es una base de datos. Es un flujo de trabajo.
87~
88## El buen agente también sabe ignorar
89~
90Una señal de madurez en los agentes será la capacidad de decir: no necesito esta información.
91~
92Parece trivial, pero es muy difícil. Se acumulan muchos sistemas agentes. Cada llamada de herramienta agrega texto. Cada error permanece en el búfer. Cada archivo leído se suma a la pila. Al final el modelo tiene una historia muy larga y ningún mapa.
93~
94Se necesita compresión. Se necesita una síntesis intermedia. Necesita estar estructurado.
95~
96No "eso es todo lo que pasó", sino:
97~
98- el objetivo sigue siendo válido;
99- hipótesis actual;
100- archivos ya comprobados;
101- decisiones tomadas;
102- riesgos abiertos;
103- próxima acción.
104~
105Esto hace que el agente sea menos teatral y más útil. No porque parezca más inteligente, sino porque trabaja con un escritorio ordenado.
106~
107## Ingeniería de contexto para equipos, no para artistas rápidos
108~
109La razón por la que este tema me interesa es que transfiere la responsabilidad del individuo al sistema.
110~
111En la ingeniería rápida, a menudo gana el que mejor puede hablar con el modelo. En ingeniería de contexto, gana el equipo que mejor organiza su trabajo: documentación, convenciones, problemas, registros, pruebas, propiedad, nombres, fuentes.
112~
113Un repositorio limpio se convierte en un mejor contexto. Un número bien escrito se convierte en un mejor combustible. Un runbook actualizado ahorra tokens y ansiedad. Un registro de cambios claro reduce las alucinaciones.
114~
115Esta es una noticia buena y algo incómoda. Bello porque premia las buenas prácticas. Es un inconveniente porque no se puede resolver todo con un mensaje inteligente.
116~
117Los agentes amplifican la seguridad del sistema que encuentran.
118~
119##Cómo lo aplicaría mañana
120~
121Si tuviera que introducir la ingeniería de contexto en un proyecto real, empezaría por cosas pequeñas:
122~
123- un archivo de instrucciones del proyecto breve y mantenido;
124- buenos ejemplos de resultados esperados;
125- una lista de herramientas disponibles y casos en los que utilizarlas;
126- decisiones arquitectónicas escritas de manera citable;
127- problema con contexto mínimo obligatorio;
128- fácil de recuperar registros y pruebas;
129- memoria persistente modificable por los humanos.
130~
131Entonces mediría una cosa sencilla: ¿cuántas veces el agente tiene que pedir aclaraciones o va en la dirección equivocada?
132~
133Si sucede con frecuencia, no agregaría un modelo más grande de inmediato. Yo miraría el contexto.
134~
135## Mi lectura
136~
137Ingeniería de contexto es una palabra un poco exagerada, sí. Pero el concepto es sólido.
138~
139Nos recuerda que la inteligencia de un agente no está sólo en el modelo. Está en el entorno que le preparamos: lo que ve, lo que recuerda, lo que puede hacer, lo que tiene prohibido hacer, qué fuentes reconoce como verdaderas.
140~
141La parte humana es ésta: preparar bien el contexto es una forma de cuidar. Le dice al agente, pero también al equipo: "No quiero que adivines, quiero que tengas lo que necesitas".
142~
143Menos magia. Cuarto más limpio. Los agentes lo necesitan tanto como nosotros.
144~
145## Fuentes
146~
147- [Blog de LangChain: El auge de la ingeniería contextual](https://blog.langchain.com/the-rise-of-context-engineering/)
148- [Simon Willison: ingeniería de contexto](https://simonwillison.net/2025/Jun/27/context-engineering/)
149- [Protocolo de contexto modelo: introducción] (https://modelcontextprotocol.io/introduction)
150- [Antrópico: Construyendo agentes efectivos](https://www.anthropic.com/engineering/building- Effective-agents)
151- [OpenAI: Nuevas herramientas para agentes de construcción](https://openai.com/index/new-tools-for-building-agents/)
152~

NORMAL · context-engineering-agents.md [readonly]152 lines · :q to close

2La palabra del momento, en el pequeño mundo de los agentes de IA, es ingeniería de contexto.

4Parece una etiqueta más inventada para vender algo que ya hicimos. En parte lo es. Sin embargo, como suele suceder, la etiqueta prevalece porque da nombre a un dolor real.

6El problema es éste: los modelos no fracasan sólo porque "no piensan". A menudo fallan porque los enviamos a trabajar en la habitación equivocada.

8Les damos viejas instrucciones. Le ocultamos archivos importantes. Les pasamos documentos demasiado largos y no decimos lo que importa. Les mostramos registros sin prioridad. Les damos diez herramientas sin explicarles cuándo usarlas. Entonces nos sorprende que el agente se mueva como una persona despierta en un apartamento desconocido.

10El mensaje es la frase que le dices. El contexto es el mundo que preparas a su alrededor.

11~

12## De la ingeniería rápida a la ingeniería de contexto

13~

14A menudo se pensaba que la ingeniería rápida era escritura. Elija las palabras correctas, pregunte de la manera correcta, agregue ejemplos, especifique el formato.

15~

16La ingeniería de contexto está más cerca de la arquitectura.

17~

18No se pregunta simplemente "¿cómo formulo la solicitud?". Pregunta:

19~

20- ¿Qué información se necesita realmente?

21- ¿Qué son los ruidos?

22- ¿Qué hay que recuperar sobre la marcha?

23- ¿Qué hay que recordar?

24- ¿Qué herramientas deberían exponerse?

25- ¿Qué instrucciones son estables y cuáles dependen de la tarea?

26- ¿Cómo hago para que el agente comprenda qué es la autoridad?

27~

28Es un cambio sutil pero enorme. Porque cuando trabajas con agentes, el contexto no es un bloque estático. Cambia a cada paso.

29~

30El agente abre un archivo, aprende algo, ejecuta una prueba, recibe un error, actualiza el plan, llama a una herramienta, descubre una dependencia. En cada vuelta tiene que decidir qué llevar consigo y qué dejar fuera.

31~

32Esto es ingeniería.

33~

34## El contexto no es un vertedero

35~

36Las plantillas con grandes ventanas contextuales nos dieron la tentación: incluyamos todo.

37~

38Es comprensible. Si tengo un millón de tokens, ¿por qué debería elegir?

39~

40Porque incluso cuando puedes poner todo, eso no significa que todo ayude. De hecho, el ruido tiene un coste. Cuesta tokens, cuesta atención, cuesta latencia, cuesta calidad. Un modelo puede perderse en detalles irrelevantes como nosotros cuando abrimos veinte pestañas y ya no recordamos por qué.

41~

42El buen contexto tiene una jerarquía:

43~

441. instrucciones y políticas del sistema;

452. objetivo específico;

463. situación actual;

474. datos relevantes;

485. limitaciones;

496. herramientas disponibles;

507. realizar un seguimiento de las decisiones ya tomadas.

51~

52No es necesario tratar todo al mismo nivel. Un comando de usuario vale más que una nota antigua. Una prueba fallida vale ahora más que una preferencia estética de hace tres meses. Una política de seguridad vale más que un atajo en la producción.

53~

54La ingeniería de contexto también significa dar ponderaciones, no sólo datos.

55~

56## Memoria: recuerda menos, recuerda mejor

57~

58La memoria en los agentes es uno de los temas más resbaladizos.

59~

60Como usuario, quieres que el agente te conozca. Quieres que recuerde el tono, el plan, las convenciones, las cosas ya decididas. Como ingeniero, usted sabe que cada recuerdo persistente también es un riesgo: puede ser incorrecto, antiguo, demasiado personal, demasiado genérico o no verificable.

61~

62Una memoria útil debe tener al menos tres cualidades:

63~

64- procedencia: ¿de dónde viene esta información?

65- fecha: ¿cuándo fue cierto?

66- finalidad: ¿para qué tipo de tarea debería utilizarse?

67~

68Sin estas tres cosas, la memoria se convierte en superstición.

69~

70Me gusta pensar en la memoria agente como un libro de trabajo, no como una mente mágica. Hay notas temporales, decisiones confirmadas, preferencias de estilo, limitaciones técnicas, enlaces a fuentes. Algunas cosas caducan. Algunos necesitan ser reescritos. Algunos deben ser eliminados porque el agente los malinterpretó.

71~

72Un buen sistema debe hacer que este mantenimiento sea normal. No heroico.

73~

74## Recuperación y herramientas no son lo mismo

75~

76Cuando hablamos de contexto, a menudo terminamos inmediatamente en RAG. Incrustación, base de datos vectorial, fragmentación, reclasificación.

77~

78Todo útil. Pero la recuperación es sólo una manera de llevar información al modelo. Él no es el único.

79~

80Un agente puede obtener contexto leyendo archivos, consultando una API, llamando a un servidor MCP, abriendo un navegador, ejecutando pruebas, buscando en Slack, mirando un panel, preguntando al ser humano.

81~

82Lo interesante es decidir qué ruta utilizar y cuándo.

83~

84Si el agente necesita responder a una pregunta histórica, quizás basta con recuperarla. Si tiene que corregir un error, tiene que leer código real. Si necesita comprender por qué falla una implementación, debe consultar registros nuevos. Si necesita escribirle a un cliente, debe recuperar el tono, el historial y el estado del ticket. Si debe actuar sobre la producción, debe pedir permiso.

85~

86El contexto no es una base de datos. Es un flujo de trabajo.

87~

88## El buen agente también sabe ignorar

89~

90Una señal de madurez en los agentes será la capacidad de decir: no necesito esta información.

91~

92Parece trivial, pero es muy difícil. Se acumulan muchos sistemas agentes. Cada llamada de herramienta agrega texto. Cada error permanece en el búfer. Cada archivo leído se suma a la pila. Al final el modelo tiene una historia muy larga y ningún mapa.

93~

94Se necesita compresión. Se necesita una síntesis intermedia. Necesita estar estructurado.

95~

96No "eso es todo lo que pasó", sino:

97~

98- el objetivo sigue siendo válido;

99- hipótesis actual;

100- archivos ya comprobados;

101- decisiones tomadas;

102- riesgos abiertos;

103- próxima acción.

104~

105Esto hace que el agente sea menos teatral y más útil. No porque parezca más inteligente, sino porque trabaja con un escritorio ordenado.

106~

107## Ingeniería de contexto para equipos, no para artistas rápidos

108~

109La razón por la que este tema me interesa es que transfiere la responsabilidad del individuo al sistema.

110~

111En la ingeniería rápida, a menudo gana el que mejor puede hablar con el modelo. En ingeniería de contexto, gana el equipo que mejor organiza su trabajo: documentación, convenciones, problemas, registros, pruebas, propiedad, nombres, fuentes.

112~

113Un repositorio limpio se convierte en un mejor contexto. Un número bien escrito se convierte en un mejor combustible. Un runbook actualizado ahorra tokens y ansiedad. Un registro de cambios claro reduce las alucinaciones.

114~

115Esta es una noticia buena y algo incómoda. Bello porque premia las buenas prácticas. Es un inconveniente porque no se puede resolver todo con un mensaje inteligente.

116~

117Los agentes amplifican la seguridad del sistema que encuentran.

118~

119##Cómo lo aplicaría mañana

120~

121Si tuviera que introducir la ingeniería de contexto en un proyecto real, empezaría por cosas pequeñas:

122~

123- un archivo de instrucciones del proyecto breve y mantenido;

124- buenos ejemplos de resultados esperados;

125- una lista de herramientas disponibles y casos en los que utilizarlas;

126- decisiones arquitectónicas escritas de manera citable;

127- problema con contexto mínimo obligatorio;

128- fácil de recuperar registros y pruebas;

129- memoria persistente modificable por los humanos.

130~

131Entonces mediría una cosa sencilla: ¿cuántas veces el agente tiene que pedir aclaraciones o va en la dirección equivocada?

132~

133Si sucede con frecuencia, no agregaría un modelo más grande de inmediato. Yo miraría el contexto.

134~

135## Mi lectura

136~

137Ingeniería de contexto es una palabra un poco exagerada, sí. Pero el concepto es sólido.

138~

139Nos recuerda que la inteligencia de un agente no está sólo en el modelo. Está en el entorno que le preparamos: lo que ve, lo que recuerda, lo que puede hacer, lo que tiene prohibido hacer, qué fuentes reconoce como verdaderas.

140~

141La parte humana es ésta: preparar bien el contexto es una forma de cuidar. Le dice al agente, pero también al equipo: "No quiero que adivines, quiero que tengas lo que necesitas".

142~

143Menos magia. Cuarto más limpio. Los agentes lo necesitan tanto como nosotros.

144~

145## Fuentes

146~

147- [Blog de LangChain: El auge de la ingeniería contextual](https://blog.langchain.com/the-rise-of-context-engineering/)

148- [Simon Willison: ingeniería de contexto](https://simonwillison.net/2025/Jun/27/context-engineering/)

149- [Protocolo de contexto modelo: introducción] (https://modelcontextprotocol.io/introduction)

150- [Antrópico: Construyendo agentes efectivos](https://www.anthropic.com/engineering/building- Effective-agents)

151- [OpenAI: Nuevas herramientas para agentes de construcción](https://openai.com/index/new-tools-for-building-agents/)

152~