Crear un sistema multiagente ahora es bastante sencillo. Llevarlo a la producción es donde comienzan los verdaderos desafíos. Gracias a los marcos de código abierto y a los servicios en la nube, puede configurar un agente en cuestión de días. Unas cuantas llamadas a las herramientas, unas pocas líneas de aviso y tendrá algo que se ve impresionante. Sin embargo, en el momento en que los equipos intentan ir más allá de un proyecto piloto y pasar a aplicaciones empresariales reales, se topan con un muro conocido. Si alguna vez ha intentado poner a un agente en producción, estas frustraciones le resultarán familiares

¿Por qué el agente no sigue nuestra lógica empresarial, se salta los pasos de validación o no detecta casos extremos?

Modificas el mensaje, agregas más ejemplos y cambias el modelo. Los mismos problemas siguen apareciendo. Esto se debe a que los agentes no siguen una secuencia fija de instrucciones. Emiten sus propios juicios basándose en el contexto. Las instrucciones por sí solas no son suficientes. Debes diseñar cómo piensa el agente, cuándo verifica y qué hace cuando las cosas van mal. Precisamente por eso es fundamental ir más allá de la ingeniería rápida y diseñar toda la arquitectura cognitiva y el flujo de ejecución del agente

Para abordar estos desafíos de manera frontal, el equipo de arquitectura de soluciones de AWS creó Deep Insight, un sistema multiagente de nivel de producción. En esta serie de publicaciones, compartimos lo que el equipo aprendió de primera mano mientras desarrollaba Deep Insight en tres publicaciones. Explicaremos cómo aplicamos las técnicas de ingeniería de contexto propuestas por Anthropic (arquitectura multiagente, toma de notas estructurada, experiencia humana al día, etc.) en un entorno de producción real. También analizaremos las ventajas y desventajas que encontramos a lo largo del proceso (con el código) y los conocimientos operativos que obtuvimos al implementar y ejecutar este agente

Descripción general de la serie de blogs

• Parte 1:5 desafíos de producción en sistemas multiagente y cómo los resolvió Deep Insight.
• Parte 2: Más allá de la ventana contextual: las técnicas de ingeniería de contexto y cómo las aplicó Deep Insight.
• Parte 3: Aprovechar la ingeniería en la práctica: trasladar Deep Insight del desarrollo a la producción.

Esta es la primera parte de una serie de tres partes. Define los cinco desafíos principales que debe resolver cualquier sistema multiagente de producción y muestra cómo los aborda cada capa del conjunto, desde el SDK de Strands Agents y Amazon Bedrock hasta Amazon Bedrock AgentCore, Application Load Balancer y AWS Fargate. Las partes 2 y 3 tratan sobre la ingeniería de contexto y la implementación en producción

Presentamos Deep Insight

Deep Insight es un sistema multiagente que convierte el análisis de datos complejos en información automatizada. Con un archivo CSV y un mensaje en lenguaje natural, una jerarquía de agentes especializados (coordinador, planificador, supervisor, codificador, validador, reportero y rastreador) colabora en el análisis. Juntos cargan los datos, realizan análisis, generan gráficos, validan los cálculos y producen un informe profesional

Exploraremos la arquitectura en detalle más adelante. En primer lugar, veamos cómo funciona. Para la demostración, incluimos los datos publicitarios de una empresa alimentaria ficticia, Yummy Food (yummy-food-market.csv), con un archivo de definiciones de columnas (column_definitions.json) y proporcionamos el siguiente mensaje: analice esto desde una perspectiva de ventas y marketing, genere gráficos e información y elabore un informe en formato.docx. Deep Insight genera un plan de análisis, lo presenta al usuario para su aprobación y, una vez aprobado, ejecuta el

El siguiente vídeo de demostración web de Deep Insight muestra el flujo de trabajo completo, desde la carga de datos y la revisión del plan de análisis hasta la transmisión en tiempo real y la descarga del informe final.

¿Cómo puedo probarlo?

Deep Insight es de código abierto en GitHub con una guía de configuración completa y ofrece tres opciones de implementación que van desde el desarrollo hasta la producción.

La primera es la versión autohospedada, que se ejecuta localmente a través de la CLI. Está optimizada para una iteración rápida con acceso total a nivel de código a todos los agentes, solicitudes y flujos de trabajo. Se configura en unos 10 minutos, lo que lo hace ideal para el desarrollo. (Hay un vídeo de demostración autohospedado disponible en YouTube).

La segunda es la versión web, una interfaz de usuario basada en un navegador para cargar datos, revisar los planes de análisis (Human-in-the-Loop o HITL) y descargar informes, todo ello sin necesidad de escribir código, por lo que es accesible para quienes no son desarrolladores. (El vídeo de demostración anterior muestra la

La tercera es la versión Managed AgentCore, una opción de implementación en producción impulsada por Amazon Bedrock AgentCore, una plataforma para crear, conectar y optimizar agentes a escala, con cualquier marco o modelo. Esta versión implementa los agentes en AgentCore Runtime, una funcionalidad de Amazon Bedrock AgentCore. El sistema se ejecuta en su totalidad en una nube privada virtual (VPC) privada, con un intérprete de código personalizado alojado por separado en AWS Fargate, y los agentes se ejecutan simultáneamente en entornos aislados por usuario. Es la elección correcta cuando necesita aislar la sesión e implementar una VPC privada. La parte 3 describe en detalle su implementación y sus operaciones

Los tres comparten la misma arquitectura multiagente, por lo que un agente validado durante el desarrollo se implementa en la producción tal cual.

Descripción general de la solución

creación de un sistema multiagente de producción requiere más que buenas indicaciones. Necesita la infraestructura y la tecnología adecuadas para abordar la forma en que los agentes colaboran, cómo razonan, cómo los implementan, dónde ejecutan el código de forma segura y cómo se monitorea el estado operativo. Deep Insight resuelve problemas en estas cinco áreas clave. Como los agentes generan tanto el código como el contenido de los informes, también abordamos los controles de IA responsables para la producción en el detalle de la solución 2.

El siguiente diagrama de arquitectura (figura 1) ilustra esto de un vistazo. Los recuadros verdes representan la estructura multiagente de Strands Agents, que aborda los desafíos 1 y 2 de la tabla anterior. Trataremos este tema en detalle en la próxima sección Detalle de la solución 1: Diseño de sistemas multiagente. Los demás componentes de la infraestructura que se muestran en el diagrama abordan los desafíos 3, 4 y 5, que analizaremos en el detalle 2 de la solución: implementación y operaciones de producción

Figura 1: Arquitectura de la solución

Detalle de la solución 1: Diseño del sistema con múltiples agentes

Deep Insight utiliza una arquitectura multiagente en la que ocho agentes colaboran para producir un producto de alta calidad. Cada agente trabaja en su propio contexto independiente, solo realiza sus tareas especializadas y solo transmite los resultados comprimidos

Figura 2: Estructura multiagente

El coordinador canaliza las solicitudes de los usuarios, el planificador divide las tareas en pasos discretos, el revisor del plan recopila los comentarios de los usuarios y el supervisor invoca a los agentes especializados apropiados de acuerdo con el plan. El codificador escribe y ejecuta el código de análisis de datos, el validador verifica los cálculos, el informador genera el informe final y el rastreador hace un seguimiento del progreso. Vamos a explicar esto en tres niveles

• [Primera capa] Del coordinador al planificador y al revisor del plan: solicite el análisis y la creación del plan de ejecución.
• [Segunda capa] Supervisor: orquestación de agentes especializados.
• [Tercera capa] Codificador, validador, reportero, rastreador: ejecución de tareas especializadas.

combinan dos patrones clave del SDK de Strands Agents para controlar el flujo de ejecución entre estos agentes. En primer lugar, el patrón Graph define el orden de ejecución y el flujo de los agentes como un gráfico dirigido. El coordinador del flujo de solicitudes, el planificador, el revisor del plan y luego el supervisor, con una rama condicional que regresa al planificador en caso de solicitudes de revisión. Determinar el siguiente paso por condición facilita los flujos de trabajo complejos, como el HITL, y la gestión de errores. En segundo lugar, el patrón de agentes como herramientas permite al supervisor invocar a agentes especializados (codificadores, validadores, reporteros, rastreadores) como herramientas solo cuando es necesario. Cada uno funciona en un contexto independiente y solo arroja resultados, lo que minimiza el uso del contexto y preserva la experiencia en el campo

En esta sección se muestra cómo la arquitectura resuelve el enrutamiento, la planificación y la orquestación.

[Primera capa] Del coordinador al planificador y al revisor de la planificación

Esta capa convierte la solicitud de un usuario en un plan de ejecución aprobado.

1.1 Coordinador (enrutamiento): no todas las solicitudes necesitan una organización costosa

El coordinador es el punto de entrada para las solicitudes de los usuarios. Gestiona directamente los saludos básicos y dirige las tareas complejas, como el análisis de datos, al planificador con un marcador handoff_to_planner

La decisión clave en cuanto al diseño es la selección del modelo: dado que el coordinador solo clasifica, utiliza el ligero Claude Haiku, lo que evita los costes del Opus en saludos básicos y ofrece respuestas rápidas.

# builder.py: bordes condicionales para las decisiones de enrutamiento
builder.set_entry_point («coordinador»)
builder.add_edge

Las condiciones de enrutamiento provienen del aviso del coordinador: cualquier solicitud que necesite herramientas, razonamiento o ideas en varios pasos va dirigida al planificador.

1.2 Planificador (creación del plan): los análisis complejos deben descomponerse antes de ejecutarse

En la estructura multiagente de Deep Insight, el agente Planner desempeña el papel fundamental de distribuir las tareas entre los agentes. Antes de comenzar el trabajo sustantivo, divide las tareas grandes en pasos más pequeños y cada agente especializado las ejecuta de una en una, manteniendo el contexto de cada agente

El planificador utiliza un modelo de Claude Opus con el pensamiento extendido activado para desarrollar el plan de análisis. Organiza el plan en un formato de lista de verificación [] que especifica las tareas concretas asignadas a cada agente, almacenadas en una variable full_plan. Divide la solicitud en 5 a 10 pasos claros, como se muestra en el siguiente ejemplo:

## título
Informe de análisis de los patrones de compra de los consumidores de Yummy Food y la eficacia de la publicidad

## pasos

### 1. Coder: análisis integral de datos y generación de información
- [] Cargue todos los archivos de datos desde '. /data/ *' ruta y comprensión de la estructura
- [] Analice el historial de compras de los consumidores (patrones, preferencias, segmentos de clientes)
- [] Analice los datos publicitarios por canal (costo, efectividad, comparación de canales)
- [] Análisis a nivel de categoría (alimentos frescos, alimentos precocinados, alimentos saludables y eficacia)
- [] Calcule las métricas empresariales clave (tasa de conversión, CPA, ROAS, etc.)
- [] Genere visualizaciones (más de 5 gráficos, gráficos de segmentos de consumidores)
- [] Obtenga información estratégica de marketing
- [] Generar metadatos de cálculo (para su validación)

### 2. Validador: verificación de cálculos y generación de metadatos de citas
- [] Identifique los objetivos de verificación y extraiga los cálculos de los filtros
- [] Cargue los archivos de datos directamente y realice nuevos cálculos
- [] Verifique la precisión de las métricas de rendimiento por canal
- [] Valide la coherencia de los datos de las imágenes y los gráficos
- [] Genere metadatos de citas (números de referencia para elementos verificados)

### 3. Reportero: Generación de informes de análisis de marketing
- [] Escriba la descripción general del informe
- [] Cree un informe estructurado utilizando resultados de análisis verificados
- [] Inserte secciones de visualización y análisis
- [] Presente recomendaciones de estrategias de marketing y propuestas de mejora
- [] Genere un informe de marketing profesional en formato DOCX

1.3 Revisor del plan

El revisor del plan es un nodo de HITL que presenta el plan al usuario y recopila los comentarios sobre la aprobación o la revisión. Si hay comentarios, se envían al planificador para revisar el plan. Si se aprueba, transfiere la tarea al supervisor. Se establece un recuento máximo de revisiones (MAX_PLAN_REVISIONS) para evitar bucles

# builder.py: Planifique los bordes condicionales bidireccionales del revisor
builder.add_edge («plan_reviewer», «planner», condition=should_revise_plan)
builder.add_edge («plan_reviewer», «supervisor», condition=should_proceed_to_supervisor)
builder.set_max_node_executions (

En la versión web, el revisor del plan muestra un modo de navegador en el que el usuario lee el plan y lo aprueba o introduce comentarios sobre la revisión. Una cuenta regresiva de 300 segundos aprueba automáticamente el plan si no recibe respuesta

Figura 3: Planear la ejecución del agente Reviewer en la interfaz de usuario web

Si no se planifica, el agente decide todo en tiempo de ejecución, una corrección intermedia invalida el trabajo anterior y los usuarios no pueden ver el progreso. Con el planificador y el revisor del plan, el usuario puede revisar y revisar el plan, supervisar el progreso en tiempo real y volver a ejecutar solo un

Supervisor (orquestador) [de segunda capa]: Los agentes especializados necesitan un director

El supervisor ejecuta el plan completo del planificador en orden e invoca a los agentes de la capa 3 (Coder, Validator, Reporter, Tracker) como herramientas registradas en él mediante Tool Use.

# nodes.py: registro de subagentes como herramientas en el Supervisor
agent = strands_utils.get_agent (
 agent_name="supervisor»,
 system_prompts=apply_prompt_template (prompt_name="supervisor», prompt_context= {}),
 model_id=os.getenv («SUPERVISOR_MODEL_ID», os.getenv («DEFAULT_MODEL_ID»)),
 prompt_cache_info =( Verdadero, «predeterminado»),
 tool_cache=verdadero,
 tools= [coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
 Streaming=verdadero,

El indicador del sistema del supervisor define reglas estrictas de flujo de trabajo:

• Orden de ejecución obligatoria: Coder, Tracker, Validator, Tracker, Reporter, Tracker: después de ejecutar cada agente, se invoca a Tracker para rastrear el progreso, lo que permite al supervisor administrar el estado general de la tarea.
• Regla de finalización de secciones: el supervisor no pasa al siguiente agente hasta que todos los elementos de la lista de verificación del agente actual estén marcados con [x].
• Preservación del contexto: el supervisor envía las pistas y las variables del plan completo a cada agente de la herramienta, manteniendo el contexto completo y evitando la pérdida de información.

[Tercera capa] Codificador, validador, reportero, rastreador: la división del trabajo impulsa la calidad

Cada agente de capa 3 (Coder, Validator, Reporter, Tracker) está empaquetado como una PythonAgentTool y recibe las llamadas del supervisor para usar la herramienta. Cada uno se crea como una instancia independiente de Agent () en el SDK de Strands con su propia

El supervisor invoca las llamadas de uso de herramientas en este orden, según la lista de verificación del planificador:

1. Codificador: carga datos, escribe y ejecuta código de análisis, produce gráficos PNG, acumula los resultados en all_results.txt y deja calculation_metadata.json para su verificación.
2. Rastreador (primera pasada): actualiza los elementos completados de la lista de verificación de [] a [x], y el supervisor los utiliza para decidir si continuar o no.
3. Validador: vuelve a realizar cada cálculo en calculation_metadata.json a partir de los datos de origen. Las coincidencias no superan los 0,01 pases y se marcan las discrepancias. Los cálculos verificados van a citations.json para
que el reportero los cite.
4. Rastreador (segunda pasada): refleja el estado de finalización del validador en la lista de verificación.
5. Reporter: lee all_results.txt y citations.json para generar el informe DOCX final en dos versiones, con y sin citas.
6. Rastreador (tercera pasada): refleja el estado final de finalización de todas las tareas.

rastreador se ejecuta detrás de cada agente para que el supervisor pueda hacer un seguimiento del progreso y hacer cumplir la regla de finalización (no continuar hasta que todos los elementos estén [x]). Como actualiza la lista de verificación con el razonamiento del LLM y sin herramientas, supone pocos gastos generales

Configuración del modelo LLM por agente

Deep Insight adapta el modelo y la configuración a la función de cada agente. No se trata de una selección de modelos. Es una decisión arquitectónica para optimizar el costo y la calidad.

Los agentes de Supervisor, Coder y Reporter utilizan Prompt Caching para almacenar en caché las indicaciones del sistema y las definiciones de las herramientas, lo que reduce los costos de los tokens de entrada hasta en un 90 por ciento en las llamadas repetidas. El coordinador se ejecuta solo una vez, y el validador y el rastreador se ejecutan en contextos diferentes cada vez, por lo que el almacenamiento en caché no es efectivo para ellos y permanece desactivado. Esta estrategia de almacenamiento en caché selectivo es una

Detalle de la solución 2: implementación y operaciones de producción

Si el detalle de la solución 1 definió lo que hace el sistema, en esta sección se define dónde y cómo se ejecuta de forma segura. A partir de ahora, todo abarca las decisiones de infraestructura para las operaciones de producción. En concreto, en esta sección se aborda el entorno de ejecución seguro del código generado por el LLM y la visibilidad operativa del equipo

1. Ejecución de código: el código generado por LLM necesita un entorno de ejecución seguro

El agente Coder escribe y ejecuta Python para el análisis de datos. En la versión autohospedada, se ejecuta localmente a través de subprocess.run (), pero en producción (AgentCore) la seguridad y el aislamiento son esenciales. Ejecutar código generado por LLM directamente en un servidor de producción es arriesgado: el modelo puede eliminar los archivos del sistema, agotar los recursos en un bucle infinito o acceder a los datos de análisis de otros usuarios. Deep Insight resuelve este problema con contenedores efímeros por sesión en AWS Fargate y ALB. Estos componentes no se ejecutan de forma aislada. Como se muestra en la figura 1, las tareas de AgentCore Runtime, ALB y Fargate se ejecutan todas dentro de la misma VPC privada. Los puntos de enlace de la VPC las conectan a Amazon Simple Storage Service (Amazon S3), Amazon Bedrock y Amazon Elastic Container Registry (Amazon ECR) sin tener que pasar por la Internet pública. Los grupos de seguridad restringen los componentes que pueden llegar a los contenedores del intérprete de código. Las funciones de AWS Identity and Access Management (IAM) limitan cada componente a los recursos de AWS que necesita. Amazon CloudWatch recopila los registros de contenedores y los datos de observabilidad de AgentCore Observability, una funcionalidad de Amazon Bedrock AgentCore

• Imagen de Docker de contenedor personalizada: un entorno limitado preoptimizado con fuentes, bibliotecas del sistema y paquetes de Python para el sistema multiagente.
• Aislamiento de contenedores: cada sesión de análisis obtiene un contenedor de Fargate independiente en una subred de VPC privada sin acceso directo a Internet.
• Ejecución en dos pasos: el código generado por LLM se codifica en base64, se envía a través de HTTP, se escribe en un archivo (paso 1) y luego se ejecuta mediante un subproceso (paso 2).
• Afinidad de sesión: las cookies de sesión fijas de ALB devuelven a un agente al mismo contenedor, incluso cuando ejecuta código varias veces.
• Gestión de artefactos: los gráficos, los informes y los registros se cargan en Amazon S3 cuando finaliza el análisis. Los contenedores finalizan automáticamente al cabo de una hora.

aislamiento de contenedores protege la infraestructura, pero no controla lo que generan los agentes. El agente validador vuelve a verificar los cálculos. No detecta las instrucciones de inserción rápida ocultas en los datos cargados ni filtra el texto generado por LLM en busca de contenido dañino o infundado. En el caso de las implementaciones de producción, recomendamos añadir Amazon Bedrock Guardrails como control de inteligencia artificial responsable: aplicar filtros de contenido y detectar rápidamente los ataques a las solicitudes de los usuarios y a los datos cargados, y aplicar comprobaciones contextuales a los resultados de los agentes para que el texto del informe se mantenga centrado en los datos de origen y en los cálculos

2. Operaciones y monitoreo: los equipos necesitan visibilidad

Un sistema de producción no está completo solo con código. El equipo debe evaluar el estado del sistema, diagnosticar los problemas y revisar los resultados, por lo que Deep Insight proporciona una interfaz de usuario web y un panel de operaciones.

Interfaz de usuario web (deep insight-web)

Una interfaz web basada en FastAPI que se comunica con el backend a través del protocolo nativo de AgentCore (boto3.invoke_agent_runtime ()). Los usuarios cargan datos e introducen un mensaje y, a continuación, supervisan el progreso mediante la transmisión de eventos enviados por el servidor (SSE). Cuando se genera el plan, un modal permite al usuario aprobarlo o enviar comentarios sobre la revisión (HITL). El informe terminado se puede descargar directamente. Se admiten tanto el coreano como el inglés.

Figura 4: Captura de pantalla de la versión web de Deep Insight

Panel de operaciones (deep-insight-web/ops)

El panel de operaciones es opcional. Deep Insight funciona bien sin él, pero añade estas funciones para los equipos que las necesitan:

• Seguimiento de tareas: todas las métricas de las tareas de análisis, incluidos el estado, el uso de los tokens y el tiempo transcurrido, se registran en Amazon DynamoDB.
• Alerta de errores: cuando se produce un error en un análisis, se envía inmediatamente un correo electrónico a los administradores a través de Amazon SNS.
• Panel de administración: un panel de administración dedicado está protegido mediante la autenticación JSON Web Token (JWT) a través de Amazon Cognito para una supervisión segura de las tareas.

Figura 5: Captura de pantalla del panel de Deep Insight Ops

Figura 6: Vista detallada del panel de Deep Insight Ops

Ampliación de la arquitectura de Deep Insight

arquitectura multiagente de Deep Insight no se limita al dominio único de la generación de informes de análisis de datos. Los dos ejemplos siguientes demuestran que los principios de diseño de la orquestación jerárquica siguen siendo efectivos en ámbitos completamente diferentes

Caso 1: LG Electronics: sistema de extracción de información de marketing impulsado por la inteligencia artificial de Agentic

división de ventas de LG Electronics en Corea creó ChatInsight con la misma arquitectura multiagente que Deep Insight, en la que las solicitudes de análisis de datos tardaban entre 2 y 3 semanas y perdían el interés entre los especialistas en marketing y los científicos de datos. El coordinador clasifica según su complejidad, el planificador hace un seguimiento de las tareas y el supervisor organiza el codificador y el reportero. El estado entre los agentes se transfiere de forma acumulativa a través de un archivo all_results.txt. Los análisis que tardaban 3 días ahora tardan 30 minutos, lo que supone una mejora de la productividad 288 veces mayor. Los profesionales del marketing que no conozcan SQL pueden dejar que el agente explore los datos y proponga estrategias (consulte el sistema de extracción de información mediante IA de LG Electronics Agentic en el blog técnico de AWS

Figura 7: Arquitectura del sistema de información de marketing de IA de LG Electronics Agentic

Caso 2: TechRecon: agente de reconocimiento tecnológico impulsado por inteligencia artificial (re:Invent 2025)

Presentado en AWS re:Invent 2025 (sesión SNR203), TechRecon aplica la arquitectura de Deep Insight a la estrategia tecnológica. Para una empresa y un sector, el investigador recopila las tendencias tecnológicas, el programador las analiza, el validador las verifica y el reportero elabora un análisis del panorama y un documento de posición técnica. La arquitectura es prácticamente idéntica a la de Deep Insight, creada con el patrón Graph del SDK de Strands Agents y con Extended Thinking y Prompt Caching, y Researcher sustituyó a Coder como principal agente de ejecución. Esto demuestra que el diseño sigue un patrón de uso general: si se intercambian las funciones y las instrucciones de los agentes, la misma estructura de orquestación resuelve problemas completamente diferentes

Figura 8: Resultados de TechRecon

(Más información: Vídeo de la sesión TechRecon GitHub | AWS re:Invent)

Conclusión

Crear un agente que funcione en la producción no es una cuestión de capacidad del modelo. Es una cuestión de arquitectura. Deep Insight ofrece una respuesta comprobada:

• Gestión del flujo de trabajo: el patrón gráfico del Strands Agents SDK define el orden de ejecución entre los agentes e implementa la bifurcación de HITL, mientras que el patrón Agents-as-Tools permite al supervisor invocar agentes especializados solo cuando es necesario.
• Motor de razonamiento: asignamos los modelos Claude de Amazon Bedrock por rol (Haiku, luego Opus y luego Sonnet) para optimizar los costos y la calidad.
• Implementación: Amazon Bedrock AgentCore proporciona un tiempo de ejecución administrado con aislamiento de sesiones, implementación de VPC privadas y capacidad de observación de OpenTelemetry.
• Ejecución de código: Application Load Balancer y Amazon Elastic Container Service (Amazon ECS) en Fargate aíslan la ejecución del código generado por LLM en contenedores aislados efímeros por sesión, lo que evita problemas de seguridad como el acceso a los archivos del sistema, el agotamiento de los recursos y la divulgación no intencionada de datos.
• Operaciones: la transmisión de SSE de la interfaz de usuario web y el panel de operaciones (DynamoDB, Cognito y SNS) proporcionan visibilidad a todo el equipo.

El sistema de información de marketing de LG Electronics y el caso TechRecon en re:Invent 2025 validaron estos principios de diseño.

En la parte 2, examinamos cuatro niveles de técnicas de ingeniería de contexto para superar los límites de las ventanas contextuales en esta arquitectura, desde el aislamiento a nivel de arquitectura hasta el diseño rápido, la optimización de las herramientas y las salvaguardias de verificación, comparando nuestro enfoque con la investigación de ingeniería de Anthropic.

Deep Insight es de código abierto. Explore el código y amplíelo para su propio dominio.

• GitHub
• Taller: Deep Insight Workshop (inglés | coreano)

Acerca de los autores