5 desafíos de producción en sistemas multiagente y cómo Deep Insight los resolvió

Construir un sistema multiagente ahora es bastante sencillo. Llevarlo a producción es donde comienzan los verdaderos desafíos. Gracias a los frameworks de código abierto y los servicios en la nube, puedes configurar un agente en cuestión de días. Algunas llamadas a herramientas, algunas líneas de prompt, y tienes algo que impresiona. Pero en el momento en que los equipos intentan pasar de un piloto a aplicaciones empresariales reales, chocan con un muro familiar. Si alguna vez has intentado poner un agente en producción, estas frustraciones te sonarán:

¿Por qué el agente no sigue nuestra lógica de negocio, omite pasos de validación o no detecta casos extremos?

Ajustas el prompt, agregas más ejemplos, cambias de modelo. Los mismos problemas siguen apareciendo. Esto se debe a que los agentes no siguen una secuencia fija de instrucciones. Emiten sus propios juicios según el contexto. Las instrucciones por sí solas no son suficientes. Necesitas diseñar cómo piensa el agente, cuándo verifica y qué hace cuando algo sale mal. Esto es exactamente por lo que se ha vuelto crítico ir más allá de la ingeniería de prompts y diseñar toda la arquitectura cognitiva y el flujo de ejecución del agente.

Para enfrentar estos desafíos de frente, el equipo de Arquitectura de Soluciones de AWS construyó Deep Insight, un sistema multiagente de calidad de producción. En esta serie de publicaciones, compartimos lo que el equipo aprendió de primera mano al construir Deep Insight en tres publicaciones. Recorreremos cómo aplicamos las técnicas de Context Engineering propuestas por Anthropic (arquitectura multiagente, toma de notas estructurada, human-in-the-loop y más) en un entorno de producción real. También cubrimos las compensaciones que encontramos en el camino (con código) y las ideas operativas que obtuvimos al implementar y ejecutar este agente en AWS.

Resumen de la serie de blogs

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

Esta es la Parte 1 de una serie de tres partes. Define los cinco desafíos centrales que cualquier sistema multiagente de producción debe resolver y muestra cómo cada capa del stack los aborda, desde Strands Agents SDK y Amazon Bedrock hasta Amazon Bedrock AgentCore, Application Load Balancer, y AWS Fargate. Las Partes 2 y 3 cubren Context Engineering y el despliegue en producción.

Presentamos Deep Insight

Deep Insight es un sistema multiagente que convierte análisis de datos complejos en perspectivas automatizadas. Dado un archivo CSV y un prompt en lenguaje natural, una jerarquía de agentes especializados (Coordinator, Planner, Supervisor, Coder, Validator, Reporter y Tracker) colabora en el análisis. Juntos cargan los datos, ejecutan análisis, generan gráficos, validan cálculos y producen un informe profesional (.docx) con citas.

Exploraremos la arquitectura en detalle más adelante. Primero, veámoslo en acción. Para la demo, suministramos datos de publicidad de una empresa de alimentos ficticia, Yummy Food (yummy-food-market.csv) con un archivo de definiciones de columnas (column_definitions.json), y proporcionamos el prompt: Analiza esto desde una perspectiva de ventas y marketing, genera gráficos e ideas y produce un informe .docx. Deep Insight genera un plan de análisis, lo presenta al usuario para su aprobación y, una vez aprobado, ejecuta el análisis.

El video de demostración de Deep Insight que sigue muestra el flujo de trabajo completo, desde la carga de datos y la revisión del plan de análisis hasta el streaming en tiempo real y la descarga del informe terminado.

¿Cómo puedo probarlo?

Deep Insight está publicado como código abierto en GitHub con una guía completa de configuración, y ofrece tres opciones de despliegue que abarcan desde el desarrollo hasta la producción.

La primera es la versión Self-Hosted, que se ejecuta localmente a través de la CLI. Está optimizada para la iteración rápida con acceso a nivel de código a cada agente, prompt y flujo de trabajo. Se configura en unos 10 minutos, lo que la hace muy adecuada para el desarrollo. (Hay un video de demostración de la versión Self-Hosted disponible en YouTube.)

El segundo es la versión Web, una interfaz basada en navegador para cargar datos, revisar planes de análisis (Human-in-the-Loop, o HITL) y descargar informes, todo sin escribir código, lo que la hace accesible para no desarrolladores. (El video de demostración anterior muestra la versión Web en acción.)

El tercero es la versión Managed AgentCore, una opción de despliegue en producción impulsada por Amazon Bedrock AgentCore, una plataforma para construir, conectar y optimizar agentes a escala, con cualquier framework o modelo. Esta versión despliega los agentes en el runtime de AgentCore, una capacidad de Amazon Bedrock AgentCore. El sistema se ejecuta completamente dentro de una nube privada virtual (VPC), con un Code Interpreter 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 necesitas aislamiento de sesiones y despliegue en una VPC privada. La Parte 3 cubre su despliegue y operaciones en detalle.

Las tres comparten la misma arquitectura multiagente, por lo que un agente validado en desarrollo se despliega a producción tal cual.

Descripción general de la solución

Construir un sistema multiagente de producción requiere más que buenos prompts. Necesitas la pila tecnológica y la infraestructura adecuadas para abordar cómo colaboran los agentes, cómo razonan, cómo los despliegas, dónde ejecutan código de forma segura y cómo monitoreas la salud operativa. Deep Insight resuelve problemas en estas cinco áreas clave. Debido a que los agentes generan tanto código como contenido de informes, también cubrimos los controles de IA responsable para producción en Detalle de la solución 2.

El siguiente diagrama de arquitectura (Figura 1) ilustra esto de un vistazo. Los cuadros verdes representan la estructura multiagente de Strands Agents, que aborda los desafíos 1 y 2 de la tabla anterior. Lo cubriremos en detalle en la próxima sección Detalle de la solución 1: Diseño del sistema multiagente. Los componentes de infraestructura restantes que se muestran en el diagrama abordan los desafíos 3, 4 y 5, que recorreremos en Detalle de la solución 2: Despliegue y operaciones en producción.

Figura 1: Arquitectura de la solución

Detalle de la solución 1: Diseño del sistema multiagente

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

Figura 2: Estructura multiagente

El Coordinador enruta las solicitudes de los usuarios, el Planificador divide las tareas en pasos discretos, el Revisor de Planes recopila los comentarios de los usuarios y el Supervisor invoca a los agentes especializados apropiados según el plan. El Codificador escribe y ejecuta código de análisis de datos, el Validador verifica los cálculos, el Reportero genera el informe final y el Rastreador sigue el progreso. Explicaremos esto en tres capas:

• [1.ª Capa] Coordinador a Planificador a Revisor de Planes: análisis de solicitudes y creación del plan de ejecución.
• [2.ª Capa] Supervisor: orquestación de agentes especializados.
• [3.ª Capa] Codificador, Validador, Reportero, Rastreador: ejecución de tareas especializadas.

Se combinan dos patrones clave del Strands Agents SDK para controlar el flujo de ejecución entre estos agentes. Primero, el patrón Graph define el orden y flujo de ejecución de los agentes como un grafo dirigido. Las solicitudes fluyen del Coordinator, Planner, Plan Reviewer y luego Supervisor, con una rama condicional que regresa al Planner ante solicitudes de revisión. Determinar el siguiente paso por condición hace que flujos de trabajo complejos como HITL y el manejo de errores sean sencillos. Segundo, el patrón Agents-as-Tools permite que el Supervisor invoque agentes especializados (Coder, Validator, Reporter, Tracker) como herramientas solo cuando sea necesario. Cada uno trabaja en un contexto independiente y devuelve únicamente resultados, minimizando el uso de contexto al tiempo que preserva la experiencia del dominio.

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

[1.ª Capa] Coordinator a Planner a Plan Reviewer

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

1.1 Coordinator (enrutamiento): No todas las solicitudes necesitan una orquestación costosa

El Coordinator es el punto de entrada de las solicitudes de los usuarios. Maneja los saludos básicos directamente y enruta tareas complejas como el análisis de datos al Planner con un marcador handoff_to_planner.

La decisión clave de diseño es la selección del modelo: como el Coordinator solo clasifica, usa el ligero Claude Haiku, evitando costos de nivel Opus en saludos básicos y entregando respuestas rápidas.

# builder.py: conditional edges for routing decisions
builder.set_entry_point("coordinator")
builder.add_edge("coordinator", "planner", condition=should_handoff_to_planner)

Las condiciones de enrutamiento provienen del prompt del Coordinator: cualquier solicitud que requiera herramientas, razonamiento o pensamiento de varios pasos va al Planner.

1.2 Planner (creación del plan): Los análisis complejos necesitan descomposición antes de la ejecución

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

El Planner usa un modelo Claude Opus con Extended Thinking 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, almacenado en una full_plan variable. Divide la solicitud en 5–10 pasos claros, como se muestra en el siguiente ejemplo:

## title
Yummy Food Consumer Purchase Patterns and Advertising Effectiveness Analysis Report

## steps

### 1. Coder: Comprehensive Data Analysis and Insight Generation
- [ ] Load all data files from './data/*' path and understand structure
- [ ] Analyze consumer purchase history (patterns, preferences, customer segments)
- [ ] Analyze advertising data by channel (cost, effectiveness, channel comparison)
- [ ] Category-level analysis (fresh food, convenience food, health food ad effectiveness)
- [ ] Calculate key business metrics (conversion rate, CPA, ROAS, etc.)
- [ ] Generate visualizations (5+ charts, consumer segment charts)
- [ ] Derive strategic marketing insights
- [ ] Generate calculation metadata (for validation)

### 2. Validator: Calculation Verification and Citation Metadata Generation
- [ ] Identify verification targets and extract filter calculations
- [ ] Load data files directly and perform recalculations
- [ ] Verify accuracy of per-channel performance metrics
- [ ] Validate data consistency of visuals and graphs
- [ ] Generate citation metadata (reference numbers for verified items)

### 3. Reporter: Marketing Analysis Report Generation
- [ ] Write report overview
- [ ] Create structured report using verified analysis results
- [ ] Insert visualizations and analysis sections
- [ ] Present marketing strategy recommendations and improvement proposals
- [ ] Generate professional marketing report in DOCX format

1.3 Plan Reviewer

El Plan Reviewer es un nodo HITL que presenta el plan al usuario y recoge comentarios de aprobación o revisión. Si hay comentarios, regresa al Planner para revisar el plan. Si se aprueba, transfiere la tarea al Supervisor. Se establece un número máximo de revisiones (MAX_PLAN_REVISIONS) para evitar bucles infinitos.

# builder.py: Plan Reviewer's bidirectional conditional edges
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(25)

En la versión web, el Plan Reviewer muestra un modal en el navegador donde el usuario lee el plan y lo aprueba o introduce comentarios de revisión. Una cuenta regresiva de 300 segundos aprueba automáticamente el plan si no llega ninguna respuesta.

Figura 3: Ejecución del agente Plan Reviewer en la interfaz web

Sin planificación, el agente decide todo en tiempo de ejecución, una corrección a mitad de camino invalida el trabajo previo y los usuarios no tienen visibilidad del progreso. Con el Planner y el Plan Reviewer, el usuario puede revisar y modificar el plan, monitorear el progreso en tiempo real y reejecutar solo el paso fallido.

[2.ª Capa] Supervisor (orquestador): Los agentes especializados necesitan un director

El Supervisor ejecuta el full_plan del Planner en orden, invocando a los agentes de la Capa 3 (Coder, Validator, Reporter, Tracker) como herramientas registradas en él mediante Tool Use.

# nodes.py: registering sub-agents as tools on the 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=(True, "default"),
    tool_cache=True,
    tools=[coder_agent_tool, reporter_agent_tool, tracker_agent_tool, validator_agent_tool],
    streaming=True,
)

El prompt del sistema del Supervisor define reglas estrictas de flujo de trabajo:

• Orden de ejecución obligatorio: Coder, Tracker, Validator, Tracker, Reporter, Tracker: después de que se ejecuta cada agente, se invoca a Tracker para registrar el progreso, permitiendo al Supervisor gestionar el estado general de la tarea.
• Regla de finalización de sección: 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 pasa las variables clues y full_plan a cada agente de herramienta, manteniendo el contexto completo y evitando la pérdida de información.

[3.ª Capa] Coder, Validator, Reporter, Tracker: la división del trabajo impulsa la calidad

Cada agente de la Capa 3 (Coder, Validator, Reporter, Tracker) está envuelto como un PythonAgentTool y recibe llamadas de Tool Use del Supervisor. Cada uno se crea como una instancia Agent() independiente en el Strands SDK con su propio system prompt, ID de modelo y conjunto de herramientas.

El Supervisor invoca las llamadas de Tool Use en este orden, según la lista de verificación del Planner:

1. Coder – Carga los datos, escribe y ejecuta código de análisis, produce gráficos PNG, acumula resultados en all_results.txt, y deja calculation_metadata.json para su verificación.
2. Tracker (1.ª pasada) – Actualiza los elementos completados de la lista de verificación de [ ] a [x], lo que el Supervisor usa para decidir si continuar.
3. Validator – Vuelve a realizar cada cálculo en calculation_metadata.json a partir de los datos de origen. Las coincidencias dentro de 0.01 pasan; las discrepancias se marcan. Los cálculos verificados pasan a citations.json para que el Reporter los cite.
4. Tracker (2.ª pasada) – Refleja el estado de finalización del Validator 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. Tracker (3.ª pasada) – Refleja el estado de finalización final de todas las tareas.

El Tracker se ejecuta después de cada agente para que el Supervisor pueda seguir el progreso y hacer cumplir la regla de finalización (no se avanza hasta que todos los elementos estén en [x]). Como actualiza la lista de verificación con razonamiento del LLM y sin herramientas, añade poca sobrecarga.

Configuración del modelo LLM por agente

Deep Insight adapta el modelo y la configuración al rol de cada agente. Esto no es una selección de modelo. Es una decisión arquitectónica para optimizar el costo y la calidad.

Los agentes Supervisor, Codificador y Reportero usan Prompt Caching para almacenar en caché sus prompts de sistema y definiciones de herramientas, reduciendo los costos de tokens de entrada hasta en un 90 por ciento en llamadas repetidas. El Coordinador se ejecuta solo una vez, y el Validador y el Rastreador se ejecutan con contextos diferentes cada vez, por lo que la caché es ineficaz para ellos y permanece deshabilitada. Esta estrategia de almacenamiento en caché selectiva es un compromiso deliberado entre costo y rendimiento.

Detalle de la solución 2: Despliegue y operaciones en producción

Si Solution detail 1 definía lo que hace el sistema, esta sección define dónde y cómo se ejecuta de forma segura. Todo lo que sigue abarca las decisiones de infraestructura para operaciones de producción. Específicamente, esta sección cubre el entorno de ejecución seguro para el código generado por LLM, y la visibilidad operativa para el 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 Self-Hosted 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 podría eliminar archivos del sistema, agotar recursos en un bucle infinito o acceder a los datos de análisis de otros usuarios. Deep Insight resuelve esto 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, el runtime de AgentCore, el ALB y las tareas de Fargate se ejecutan todos dentro de la misma VPC privada. Los VPC endpoints los conectan con Amazon Simple Storage Service (Amazon S3), Amazon Bedrock y Amazon Elastic Container Registry (Amazon ECR) sin atravesar la internet pública. Los security groups restringen qué componentes pueden llegar a los contenedores de Code Interpreter. Los roles de AWS Identity and Access Management (IAM) delimitan cada componente a solo los recursos de AWS que necesita. Amazon CloudWatch recopila los registros de los contenedores y los datos de observabilidad de AgentCore Observability, una capacidad de Amazon Bedrock AgentCore.

• Imagen de Docker de contenedor personalizada: un sandbox 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 2 pasos: el código generado por LLM se codifica en base64, se envía por HTTP, se escribe en un archivo (Paso 1) y luego se ejecuta mediante subprocess (Paso 2).
• Afinidad de sesión: las cookies de sticky session del ALB enrutan a un agente de vuelta al mismo contenedor incluso cuando ejecuta código varias veces.
• Gestión de artefactos: los gráficos, informes y registros se cargan en Amazon S3 cuando el análisis se completa. Los contenedores terminan automáticamente después de una hora.

El aislamiento de contenedores protege la infraestructura, pero no gobierna lo que los agentes generan. El agente Validator reverifica los cálculos. No detecta instrucciones de inyección de prompts ocultas en los datos cargados ni examina el texto generado por LLM en busca de contenido dañino o sin fundamento. Para implementaciones de producción, recomendamos añadir Amazon Bedrock Guardrails como un control de IA responsable: aplique filtros de contenido y detección de ataques de prompt a los prompts de los usuarios y a los datos cargados, y aplique comprobaciones de fundamentación contextual a las salidas de los agentes para que el texto del informe permanezca fundamentado en los datos de origen y en los cálculos verificados.

2. Operaciones y monitoreo: los equipos necesitan visibilidad

Un sistema de producción no está completo solo con el código. El equipo debe evaluar la salud del sistema, diagnosticar problemas y revisar resultados, por lo que Deep Insight proporciona una Web UI y un panel de Ops.

Web UI (deep-insight-web)

Una interfaz web basada en FastAPI que se comunica con el backend a través del AgentCore Native Protocol (boto3.invoke_agent_runtime()). Los usuarios cargan datos e introducen un prompt, luego monitorean el progreso a través de streaming con Server-Sent Events (SSE). Cuando se genera el plan, una ventana modal permite al usuario aprobarlo o dar retroalimentación de revisión (HITL). El informe terminado se puede descargar directamente. Se admiten tanto coreano como inglés.

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

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

El panel de Ops es opcional. Deep Insight funciona perfectamente sin él, pero añade estas características 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 tokens y el tiempo transcurrido, se registran en Amazon DynamoDB.
• Alertas de fallos: cuando falla un análisis, se envía de inmediato 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 por autenticación JSON Web Token (JWT) a través de Amazon Cognito para un monitoreo seguro de las tareas.

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

Figura 6: vista de detalle del panel de Ops de Deep Insight

Extensión de la arquitectura de Deep Insight

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

Caso 1: LG Electronics: sistema de extracción de información de marketing impulsado por IA agéntica

La División de Ventas de Corea de LG Electronics construyó ChatInsight sobre la misma arquitectura multiagente que Deep Insight, donde las solicitudes de análisis de datos tardaban 2–3 semanas y perdían la intención entre los especialistas de marketing y los científicos de datos. El Coordinator enruta por complejidad, el Planner realiza el seguimiento de las tareas y el Supervisor orquesta al Coder y al Reporter, con el estado entre agentes pasado de forma acumulativa a través de un archivo all_results.txt. Un análisis que tomaba 3 días ahora toma 30 minutos, una mejora de productividad de 288x. Los especialistas de marketing que no conocen SQL pueden dejar que el agente explore los datos y proponga estrategias (consulte el Sistema de extracción de información agéntica de IA de LG Electronics en el AWS Tech Blog).

Figura 7: arquitectura del sistema de información de marketing agéntica de IA de LG Electronics

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

Presentado en AWS re:Invent 2025 (sesión SNR203), TechRecon aplica la arquitectura de Deep Insight a la estrategia tecnológica. Dada una empresa y un sector, un Researcher recopila tendencias tecnológicas, el Coder analiza, el Validator verifica y el Reporter produce un Landscape Analysis y un Technical Position Paper. La arquitectura es casi idéntica a la de Deep Insight, construida con el patrón Graph de Strands Agents SDK y Extended Thinking y Prompt Caching, con el Researcher reemplazando al Coder como agente de ejecución principal. Demuestra que el diseño es un patrón de propósito general: se intercambian los roles y los prompts de los agentes, y la misma estructura de orquestación resuelve problemas completamente diferentes.

Figura 8: Resultados de TechRecon

(Lea más: TechRecon GitHub | Video de la sesión de AWS re:Invent)

Conclusión

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

• Gestión del flujo de trabajo: el patrón Graph de Strands Agents SDK define el orden de ejecución entre agentes e implementa ramificación HITL, mientras que el patrón Agents-as-Tools permite al Supervisor invocar agentes especializados solo cuando es necesario.
• Motor de razonamiento: asignamos modelos Claude de Amazon Bedrock por rol (Haiku, luego Opus, luego Sonnet) para optimizar costo y calidad.
• Despliegue: Amazon Bedrock AgentCore proporciona un runtime gestionado con aislamiento de sesiones, despliegue en VPC privada y observabilidad con OpenTelemetry.
• Ejecución de código: un Application Load Balancer más Amazon Elastic Container Service (Amazon ECS) en Fargate aísla la ejecución de código generado por LLM en contenedores sandbox efímeros por sesión, evitando problemas de seguridad como el acceso a archivos del sistema, el agotamiento de recursos y la divulgación no intencionada de datos.
• Operaciones: el streaming SSE de la Web UI y el panel de Ops (DynamoDB + Cognito + SNS) proporcionan visibilidad para todo el equipo.

El sistema de insight 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 capas de técnicas de Context Engineering para superar los límites de la ventana de contexto sobre esta arquitectura, desde el aislamiento a nivel de arquitectura hasta el diseño de prompts, la optimización de herramientas y las salvaguardas 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 extiéndalo para su propio dominio.

• GitHub
• Taller: Deep Insight Workshop (Inglés | Coreano)

Sobre los autores