Arquitectura de referencia para sistemas de IA agente empresarial de nivel profesional
Aprenda las capas fundamentales, las estrategias de memoria, los principios para la recuperación de información y las medidas de seguridad necesarias para pasar de un prototipo de IA agente a sistemas empresariales fiables en producción.
Resumen ejecutivo
Pasar de las aplicaciones de modelos de lenguaje grande sin estado (LLM) a la IA agente de nivel profesional representa un cambio significativo en la forma en que las empresas desarrollan software. Los primeros esfuerzos de IA empresarial se basaron en gran medida en la generación mejorada por recuperación de información (RAG): se extraían documentos para convertirlos en representaciones vectoriales y se incluían en la ventana de contexto de las solicitudes. Este enfoque funciona bien para responder preguntas sencillas, pero falla en la toma de decisiones autónomas, la planificación multietapa con estado, la invocación fiable de herramientas y la capacidad de autocorregirse a lo largo de un flujo de trabajo.
Enterprise Agentic AI cierra esa brecha al reposicionar los modelos base: en lugar de actuar como la interfaz directa con el usuario, el modelo se convierte en un componente de razonamiento integrado dentro de un entorno de software determinista. Dichos sistemas pueden percibir su entorno, dividir objetivos grandes en pasos más pequeños, llamar a servicios internos de la empresa y mantener el estado de ejecución a lo largo de transacciones multi-paso. Sin embargo, pasar de un prototipo funcional a algo que se pueda ejecutar en producción implica resolver problemas como bucles de control no deterministas inestables, degradación del contexto durante sesiones prolongadas, riesgos de escalada de privilegios y un gasto excesivo de tokens.
Este documento presenta una arquitectura de referencia integral dirigida a arquitectos y líderes de ingeniería en IA responsables de los sistemas de agentes empresariales. Aborda las capas fundamentales que necesita cualquier agente, compara topologías multiagente, profundiza en patrones de integración para búsquedas de nivel empresarial —con especial atención a Amazon Kendra— e incluye ejemplos en Python listos para su uso en producción.
Sección 1: La arquitectura canónica de agentes empresariales
Capas básicas: Percepción, razonamiento, planificación, memoria y ejecución de herramientas
Un sistema de agentes listo para producción mantiene el modelo base probabilístico separado del entorno de ejecución determinista que lo rodea. Normalmente, esta arquitectura está compuesta por cinco capas básicas, todas ejecutadas dentro de un contenedor de entorno gestionado:
- Capa de percepción: Convierte las señales brutas de la empresa — telemetría, mensajes de usuarios, cargas útiles de webhook, respuestas de API — en entradas limpias y tipadas que el resto del sistema puede utilizar. Esto incluye la sanitización de entradas, la limitación de frecuencia y las verificaciones tempranas del esquema, todo ello realizado antes incluso de que se invoque al LLM.
- Motor de razonamiento: El centro cognitivo, impulsado por un LLM subyacente (por ejemplo, los modelos Anthropic Claude 3.5 Sonnet o AWS Bedrock). En lugar de tomar medidas por sí mismo, este motor interpreta el contexto actual, evalúa las posibles opciones y emite declaraciones estructuradas de intención.
Patrones de orquestación: bucles de agente único vs. topologías de múltiples agentes
Elegir el patrón de orquestación adecuado depende en gran medida de cuán complejo sea el dominio objetivo:
- Bucles ReAct de agente único: Un bucle de razonamiento que recorre las fases de Pensamiento, Acción y Observación. Esto es adecuado para flujos de trabajo lineales y limitados que utilizan menos de 5 a 8 herramientas distintas. Más allá de eso, un agente único tiende a enfrentarse a ventanas de contexto excesivamente grandes, instrucciones poco claras y confusión sobre qué herramienta elegir.
Para su uso en entornos empresariales de producción, la Topología de Supervisor Multi-Agentes es la opción predeterminada recomendada, gracias a sus claros límites de estado, mayor facilidad para realizar auditorías y costos de contexto más predecibles.
Sección 2: Gestión de memoria empresarial y higiene del contexto
Jerarquía de memoria: Memoria de trabajo, trayectoria a corto plazo y memoria a largo plazo
Considere la gestión de la memoria de los agentes como un problema de presupuestación de recursos. Permitir que la memoria crezca sin control aumenta el costo de inferencia, genera latencia y hace que el modelo pierda el hilo de razonamiento a medida que el contexto se degrada. Un agente empresarial bien diseñado necesita una estructura de memoria en capas:
- Memoria de trabajo (Pizarra): La ventana de contexto en tiempo real: instrucciones del sistema actualmente en vigor, el estado de la tarea activa y los resultados más recientes de las herramientas.
Estrategias para la compresión del contexto, el recorte y la aislación del estado
Para evitar que el contexto se deteriore, el entorno de ejecución debe aplicar activamente reglas de higiene:
- Truncamiento de observaciones: Las respuestas en bruto de las herramientas —como un payload JSON con 500 registros— nunca deben pasar directamente a la memoria de trabajo. El entorno de ejecución debe limpiar, truncar o resumir lo que devuelve una herramienta antes de que llegue al motor de razonamiento.
- Compresión de ventana móvil: Una vez que el área temporal provisional supera un umbral presupuestario establecido (por ejemplo, el 20% del límite total de contexto del modelo), un paso de compresión condensa las interacciones anteriores de la conversación en resúmenes semánticos compactos y descarta los intercambios originales sin procesar.
- Aislamiento del estado de las subtareas: Cuando el supervisor asigna una tarea a un subagente, este recibe un contexto nuevo que contiene únicamente el objetivo y los parámetros específicos que necesita; no se filtra ningún dato del historial de razonamiento del supervisor.
Sección 3: Análisis en profundidad: Anclaje de recuperación empresarial mediante Amazon Kendra
Amazon Kendra como capa de recuperación en producción
Construir una pipeline de recuperación en una base de datos vectorial genérica generalmente implica diseñar desde cero la propia lógica de ingestión de documentos, fragmentación, generación de embeddings y una capa de fusión de búsquedas híbridas. Amazon Kendra, por su parte, ofrece un motor de búsqueda empresarial completamente gestionado que se encarga de todo esto de forma predeterminada. Incluye una comprensión del lenguaje natural en múltiples etapas, un análisis estructural que respeta tablas, encabezados y pies de página, además de un modelo de clasificación híbrido que combina señales léxicas y semánticas.
Dentro de una pila de agentes empresariales, Kendra suele funcionar como el Subsistema de Anclaje de Conocimiento central: el componente encargado de permitir que los agentes obtengan contexto factual verificado de diversas fuentes de datos internas, sin el riesgo de fragmentación que surge al dividir los datos de forma simplista en bases de datos vectoriales.
Ajuste avanzado de relevancia y recorte dinámico de metadatos
Para respaldar la toma de decisiones autónomas de manera segura, la recuperación a nivel empresarial requiere un manejo preciso de permisos y controles de relevancia ajustables:
- Listas de control de acceso nativas (ACL): Kendra extrae y mapea automáticamente las ACL a nivel de documento definidas en los sistemas originales, ya sea SharePoint, Confluence o S3. Cuando un agente realiza una consulta, envía la identidad del usuario autenticado como un token
UserContext, y Kendra aplica recortes de seguridad a nivel de índice para que ningún fragmento al que el usuario solicitante no tenga autorización para ver llegue al agente.
_last_updated_at, por categoría empresarial, o mediante coincidencias exactas en campos personalizados como Department o ProjectCode.Retrieve en lugar de la API general Query. La API Retrieve omite por completo los metadatos de búsqueda orientados a la interfaz de usuario y, en su lugar, devuelve extractos detallados a nivel de párrafo, diseñados específicamente para introducirse directamente en la ventana de contexto de un LLM.Sección 4: Límites deterministas, validación de herramientas y disyuntores
Controles previos a la ejecución (feedforward) y posteriores a la ejecución (feedback)
Los agentes autónomos necesitan límites claros a nivel de software para evitar la escalada de privilegios, las invocaciones de herramientas mal formadas o los bucles de ejecución infinitos:
- Validación feedforward (pre-ejecución): Antes de que una llamada a una herramienta llegue a un sistema empresarial, el entorno en tiempo de ejecución verifica sus argumentos contra esquemas estrictos de Pydantic, asegurándose de que existan los campos requeridos, que los valores numéricos o de tipo enum estén dentro de los rangos permitidos, y que el token de autorización del llamante realmente permita esa acción.
Error: La tabla de la base de datos ‘users_v2’ no se encontró. Tablas disponibles: ['users', 'orders'] — lo que proporciona al agente información útil para ajustar su siguiente acción.Sandboxing, presupuestos por paso y disyuntores automáticos
- Sandboxing aislado: Cualquier código generado dinámicamente — como el Python producido por un agente de análisis de datos — debe ejecutarse dentro de sandbox aislados y desechables, como contenedores Docker o micro-MVMs gVisor, con un acceso a la red de salida estrictamente restringido.
- Presupuestos de pasos y costos: Cada tarea del agente debe tener un límite estricto en las iteraciones de llamadas a herramientas (por ejemplo, no más de 10) así como un gasto máximo en tokens. Al superarse cualquiera de estos límites, el sistema debe detener la ejecución y transferir la tarea a un operador humano.
- Disyuntores de herramientas: Si una API o base de datos backend sigue fallando en los intentos sucesivos de reintentar, el sistema debe activar un disyuntor, marcando dicha herramienta como
UNAVAILABLEen el catálogo de herramientas del agente, de modo que la capa de planificación opte por rutas alternativas en lugar de seguir intentando utilizar una dependencia defectuosa.
Sección 5: Plan maestro de implementación en producción
El ejemplo a continuación es una aplicación Python completa y ejecutable que ilustra una Arquitectura de Supervisor Multi-Agentes de nivel producción. Combina validación de herramientas basada en Pydantic, presupuestación por pasos, manejo determinista de errores y una herramienta de envoltura para la recuperación de información mediante Amazon Kendra.
import os
import json
import time
from typing import List, Dict, Any, Optional
from pydantic import BaseModel, Field, ValidationError
# =====================================================================
# 1. TOOL SCHEMAS & ENTERPRISE INTEGRATION CONTRACTS
# =====================================================================
class KendraRetrieveInput(BaseModel):
"""Input contract for the Amazon Kendra retrieval tool."""
query_text: str = Field(..., description="The natural language query string to search across corporate documentation.")
department_filter: Optional[str] = Field(None, description="Optional department metadata filter (e.g., 'Engineering', 'HR').")
user_id: str = Field(..., description="Authenticated user ID used for native Kendra ACL security trimming.")
class DatabaseQueryInput(BaseModel):
"""Input contract for enterprise relational database lookups."""
query_type: str = Field(..., description="Must be 'SELECT'. Data mutation operations are strictly prohibited.")
table_name: str = Field(..., description="Target database table name.")
limit: int = Field(default=5, ge=1, le=20, description="Number of records to return.")
# =====================================================================
# 2. MOCK ENTERPRISE SERVICES & KENDRA TOOL ENGINE
# =====================================================================
class MockAmazonKendraClient:
"""Simulates Amazon Kendra's high-density Retrieve API with ACL security trimming."""
def __init__(self):
self._mock_index = [
{
"doc_id": "KENDRA-DOC-001",
"content": "Production deployment requires dual sign-off from Engineering and Security leads.",
"department": "Engineering",
"acl_users": ["user_eng_101", "admin_007"]
},
{
"doc_id": "KENDRA-DOC-002",
"content": "Standard employee travel stipend is capped at $150/day for domestic lodging.",
"department": "HR",
"acl_users": ["user_hr_201", "user_eng_101", "admin_007"]
}
]
def retrieve(self, query_text: str, user_id: str, department_filter: Optional[str] = None) -> List[Dict[str, Any]]:
results = []
for doc in self._mock_index:
# Enforce Document-Level ACL Security Trimming
if user_id not in doc["acl_users"]:
continue
# Apply Optional Metadata Department Filtering
if department_filter and doc["department"].lower() != department_filter.lower():
continue
results.append({
"DocumentId": doc["doc_id"],
"ContentSnippet": doc["content"],
"Department": doc["department"]
})
return results
class MockEnterpriseDatabase:
"""Simulates a secure internal enterprise database."""
def __init__(self):
self._tables = {
"deployments": [
{"id": 1, "service": "auth-service", "status": "COMPLETED", "env": "prod"},
{"id": 2, "service": "payment-api", "status": "PENDING_APPROVAL", "env": "prod"}
]
}
def execute_select(self, query_type: str, table_name: str, limit: int) -> List[Dict[str, Any]]:
if query_type.upper() != "SELECT":
raise ValueError(f"Security Alert: Unauthorized operation '{query_type}'. Only 'SELECT' is permitted.")
if table_name not in self._tables:
raise KeyError(f"Database Error: Table '{table_name}' does not exist. Available tables: {list(self._tables.keys())}")
return self._tables[table_name][:limit]
# =====================================================================
# 3. PRODUCTION AGENT HARNESS & RUNTIME ENGINE
# =====================================================================
class ProductionAgentRuntime:
"""
Deterministic software harness surrounding probabilistic reasoning models.
Enforces budgets, schema validation, sandboxing, and error recovery loops.
"""
def __init__(self, user_id: str, max_step_budget: int = 4):
self.user_id = user_id
self.max_step_budget = max_step_budget
self.kendra_service = MockAmazonKendraClient()
self.db_service = MockEnterpriseDatabase()
def execute_task(self, task_goal: str) -> Dict[str, Any]:
print(f"=== [Harness Started] Initiating Task: '{task_goal}' for User: '{self.user_id}' ===")
step_count = 0
scratchpad_history: List[str] = []
# Simulated dynamic model trajectory outputs (demonstrating multi-step execution & self-correction)
simulated_llm_turns = [
# Turn 1: Attempt invalid database deletion (Caught by Feedforward Schema/Guardrail)
{
"thought": "I will clean up old deployment logs before checking security compliance.",
"action": "execute_db_query",
"args": {"query_type": "DELETE", "table_name": "deployments", "limit": 5}
},
# Turn 2: Corrected database lookup
{
"thought": "I will check active deployment statuses in the enterprise database.",
"action": "execute_db_query",
"args": {"query_type": "SELECT", "table_name": "deployments", "limit": 2}
},
# Turn 3: Ground task using Amazon Kendra Retrieve API
{
"thought": "Now I need to query enterprise policies regarding production deployment sign-off.",
"action": "kendra_retrieve",
"args": {"query_text": "production deployment sign-off rules", "department_filter": "Engineering"}
}
]
while step_count < self.max_step_budget:
step_count += 1
print(f"\n--- [Step {step_count}/{self.max_step_budget}] ---")
# Fetch current simulated model decision turn
turn_data = simulated_llm_turns[min(step_count - 1, len(simulated_llm_turns) - 1)]
print(f"Agent Thought: {turn_data['thought']}")
action = turn_data.get("action")
args = turn_data.get("args", {})
# --- TOOL EXECUTION BRANCH: DATABASE ---
if action == "execute_db_query":
try:
# 1. Pre-execution Feedforward Schema Validation
validated_args = DatabaseQueryInput(**args)
# 2. Tool Execution
db_results = self.db_service.execute_select(
query_type=validated_args.query_type,
table_name=validated_args.table_name,
limit=validated_args.limit
)
observation = f"Database Query Success: {json.dumps(db_results)}"
print(f"[Observation]: {observation}")
scratchpad_history.append(observation)
except ValidationError as ve:
error_msg = f"Schema Validation Blocked Action: {ve.errors()[0]['msg']}"
print(f"[Harness Feedforward Intercept]: {error_msg}")
scratchpad_history.append(error_msg)
except (ValueError, KeyError) as exec_err:
error_msg = f"Tool Execution Failure: {str(exec_err)}"
print(f"[Harness Feedback Sensor Catch]: {error_msg}")
scratchpad_history.append(error_msg)
# --- TOOL EXECUTION BRANCH: AMAZON KENDRA RETRIEVE ---
elif action == "kendra_retrieve":
try:
# Inject authenticated context
args["user_id"] = self.user_id
# 1. Pre-execution Schema Validation
validated_kendra_args = KendraRetrieveInput(**args)
# 2. Execute Kendra Retrieve Call
kendra_passages = self.kendra_service.retrieve(
query_text=validated_kendra_args.query_text,
user_id=validated_kendra_args.user_id,
department_filter=validated_kendra_args.department_filter
)
observation = f"Amazon Kendra Retrieved {len(kendra_passages)} Grounding Snippets: {json.dumps(kendra_passages)}"
print(f"[Observation]: {observation}")
scratchpad_history.append(observation)
# Successful multi-step completion condition reached
return {
"status": "SUCCESS",
"completed_in_steps": step_count,
"trajectory": scratchpad_history
}
except ValidationError as ve:
error_msg = f"Kendra Schema Error: {ve.errors()[0]['msg']}"
print(f"[Harness Intercept]: {error_msg}")
scratchpad_history.append(error_msg)
return {"status": "FAILED", "reason": "Step budget exhausted without completing task goals."}
# =====================================================================
# 4. EXECUTION DRIVER
# =====================================================================
if __name__ == "__main__":
# Instantiate runtime for an authorized engineering user
agent_runtime = ProductionAgentRuntime(user_id="user_eng_101", max_step_budget=4)
# Run Agentic Workflow
final_execution_summary = agent_runtime.execute_task(
task_goal="Verify pending production deployments and confirm authorization policies."
)
print("\n================ FINAL SYSTEM SUMMARY ================")
print(json.dumps(final_execution_summary, indent=2))
Sección 6: Operaciones en producción, telemetría y gobernanza
Observabilidad: Rastreo de trayectorias con OpenTelemetry
Ejecutar sistemas basados en agentes en entornos de producción exige un nivel de rastreo que los paneles APM habituales no pueden ofrecer. Dado que los agentes siguen rutas de ejecución variables y no deterministas, su stack de telemetría debe reconstruir todo el árbol de trayectorias que recorrió un agente, y no solo una pareja de solicitud-respuesta:
- Granularidad de los spans: Cada turno del agente debe generar un conjunto de spans anidados de OpenTelemetry, donde cada span esté dedicado a crear la prompt del sistema, medir el tiempo que tarda el modelo en responder, verificar que los argumentos de la herramienta coincidan con su esquema esperado, cronometrar la llamada real a la herramienta y ejecutar cualquier operación de compactación de memoria que ocurra durante ese turno.
- Registro del estado de la trayectoria: Los spans deben registrar las cantidades de tokens en el contexto de entrada, las cantidades de tokens en la salida, los esquemas utilizados para los parámetros de la herramienta y la longitud bruta de las observaciones devueltas. Este nivel de detalle permite realizar una atribución precisa de costos y determinar con exactitud qué paso dentro de la trayectoria se convirtió en un cuello de botella.
Lineamientos operativos y evaluación (La tríada agente)
Mantener un agente saludable en producción implica realizar evaluaciones automatizadas de forma continua en tres dimensiones clave:
- Tasa de cumplimiento de objetivos: la proporción de ejecuciones del agente que alcanzan un estado final exitoso sin agotar su presupuesto de pasos ni generar excepciones de herramientas no manejadas.
- Gravedad del contexto, o índice de alucinaciones: esto verifica si la respuesta resumida final del agente está realmente respaldada por hechos extraídos de sus herramientas de recuperación (como los fragmentos devueltos por Amazon Kendra), en lugar de generarse a partir de la memoria paramétrica del propio modelo.
Conclusión con recomendaciones prácticas
Desarrollar sistemas de IA agentes de nivel empresarial implica tratar al modelo base subyacente como un componente de razonamiento probabilístico que opera dentro de un marco software determinista y estrictamente regulado. Las organizaciones que logran pasar los agentes de la fase de prototipo a producción son aquellas que establecen límites arquitectónicos claros entre la percepción, la planificación, la memoria y la ejecución de herramientas, en lugar de permitir que el modelo controle todo esto libremente al mismo tiempo.
Plan de acción para los equipos de arquitectura
- Separar el razonamiento de la ejecución: cada llamada a una herramienta iniciada por un LLM debe pasar por un mecanismo determinista que valide los argumentos contra un esquema Pydantic antes de ejecutarse y detecte errores de manera clara posteriormente.
- Utilizar Amazon Kendra para obtener contexto: llame a la API
Retrievede Kendra para proporcionar al agente un contexto detallado a nivel de párrafo, confiando al mismo tiempo en su funcionalidad de ajuste automático de permisos a nivel de documento para mantener la aplicación de medidas de seguridad de forma automática. - Limitar explícitamente el uso de memoria: aplique la compactación progresiva del contexto e isole el contexto de las subtareas para evitar que se produzca envejecimiento del contexto, desviación de instrucciones o consumo excesivo de tokens durante sesiones prolongadas.
Lecturas relacionadas
- Por qué el costo de la IA agente explota: un modelo de costos basado en la arquitectura — Explica por qué los costos de los agentes basados en LLM deben medirse por tarea completada y no por llamada, y describe mecanismos arquitectónicos como el enrutamiento de modelos, los presupuestos de contexto y el caché para controlar los gastos.
- Nueve pilares arquitectónicos para sistemas de IA agente de grado productivo — Conozca un plano arquitectónico basado en nueve pilares que abarca redes de confianza cero, niveles de datos y vinculación de evidencias, para crear sistemas de IA agente de nivel empresarial que sean auditables.
- Diseñando espacios de trabajo de IA agente que se adaptan a la forma en la que trabajan realmente los equipos — Explica diez principios fundamentales para desarrollar espacios de trabajo de IA agente que integren contexto, conocimiento, autonomía, acceso a herramientas y automatización de flujos de trabajo en un sistema unificado.
- Elegir y ajustar modelos de embedding para sistemas RAG en producción — Aprenda cómo los modelos de embedding convierten el texto en vectores buscables, por qué el vocabulario del dominio daña la búsqueda semántica, y cómo seleccionar, comprimir y ajustar finamente modelos para RAG en producción.