Pattern Composition Playbook

Los patterns se vuelven útiles cuando se componen en un sistema que alguien puede operar. El objetivo no es usar la mayor cantidad posible de patterns. El objetivo es poner cada responsabilidad en el lugar correcto: el workflow controla el flujo, la policy controla los permisos, los tools controlan los efectos secundarios, retrieval controla la evidencia, el loop controla la incertidumbre acotada, los evals controlan la prueba y observability controla el aprendizaje a partir de fallas.

La forma más fácil de dañar un agentic system es componer patterns por intuición. Agregar memory porque el agent olvidó algo. Agregar un segundo agent porque el task parece grande. Agregar reflection porque la respuesta fue débil. Agregar tools porque el model necesita datos. Cada decisión puede sonar razonable, pero el resultado puede ser un sistema sin dueño, sin condición de parada, sin límite de evidencia y sin forma de replay de fallas.

La composición debe empezar por la propiedad.

La Pregunta de Composición

Antes de agregar un pattern, pregunta qué problema le pertenece.

Si ningún pattern controla un problema concreto, no lo agregues.

Para ejemplos concretos de extremo a extremo, lee Vertical Slice Examples después de este capítulo. Los slices muestran la misma regla de composición aplicada a workflows de soporte, código e investigación.

Una Composición Predeterminada

Para muchos sistemas en producción, la composición predeterminada es:

1. enrutar la solicitud por tipo de task, riesgo y capability;
2. cargar el durable state, policy context e identidad del solicitante;
3. armar un pequeño conjunto de trabajo con evidencia aprobada;
4. ejecutar un agent loop acotado solo donde exista incertidumbre;
5. ejecutar tools mediante schemas tipados y verificaciones de permisos;
6. aplicar policy antes de efectos secundarios o escrituras en memory;
7. pausar para aprobación cuando el riesgo lo requiera;
8. evaluar trayectoria, evidencia, output y comportamiento de policy;
9. registrar traces, costos, decisiones, llamadas a tools y razones de parada;
10. convertir fallas de producción en regression evals.

Esa secuencia no es un framework. Es un mapa de responsabilidades. Un sistema simple puede omitir varios pasos. Un sistema de alto riesgo puede necesitar todos.

Scorecard de Composición

Antes de aceptar una composición, califica cada pattern agregado según la responsabilidad que afirma controlar.

Si un pattern falla job, owner o boundary, elimínalo de la composición. Si falla eval o trace, no lo lleves a producción hasta que exista la prueba.

Composición 1: Investigación de Reembolsos en Soporte

Usa esto cuando el agent investiga un reembolso pero no debe emitir dinero directamente.

El límite importante es la autoridad financiera. El agent puede investigar, citar policy y redactar una solicitud de reembolso. No debe emitir el reembolso. La acción de reembolso pertenece a un workflow respaldado por policy, usualmente con aprobación.

async function handleRefundCase(input: RefundCase) {
  const route = routeSupportCase(input);
  const evidence = await collectRefundEvidence(input.orderId, route.region);

  const investigation = await refundAgent.investigate({
    caseId: input.caseId,
    evidenceRefs: evidence.refs,
    budget: { maxSteps: 6, maxToolCalls: 8, timeoutMs: 45000 }
  });

  const policy = enforcePolicy({
    actorRole: input.agentRole,
    capability: 'refund',
    riskLevel: investigation.riskLevel
  });

  if (policy.decision === 'require_approval') {
    return approvals.request({
      proposedAction: investigation.proposedRefund,
      evidenceRefs: investigation.evidenceRefs,
      policyRefs: investigation.policyRefs
    });
  }

  if (policy.decision !== 'allow') return policy;
  return refunds.draftRefundRequest(investigation);
}

Esto es agentic, pero solo en la investigación. El workflow controla enrutamiento, policy, aprobación y efectos secundarios.

Composición 2: Asistente de Policy con Evidencia

Usa esto cuando el assistant responde a partir de policy aprobada, documentación o fuentes de compliance.

El límite crítico es la evidencia. El assistant no debe responder porque el model “sabe” algo. Debe responder porque el sistema recuperó fuentes elegibles y la respuesta las cita.

{
  "answer_status": "answered",
  "answer": "The request can be approved only if damage evidence is attached.",
  "citations": ["refund_policy.v3#damaged-items"],
  "evidence_refs": ["src_refund_policy_2026_04"],
  "missing_evidence": []
}

Cuando falta evidencia, la salida correcta no es una respuesta más débil. Es missing_evidence, conflicting_evidence, refused o needs_human.

Composición 3: Investigación y Revisión Multi-Agent

Usa esto cuando un task se beneficia de flujos de trabajo separados y revisión independiente.

El límite crítico es la propiedad final. Varios agents pueden producir evidencia, borradores o críticas. Un componente debe controlar la síntesis final.

type ResearchAssignment = {
  workerRole: 'source_finder' | 'technical_reviewer' | 'risk_reviewer';
  objective: string;
  scopedContextRefs: string[];
  allowedTools: string[];
  expectedOutputSchema: string;
  acceptanceCriteria: string[];
};

Si cada worker ve el mismo context y tools, probablemente no tienes un multi-agent system útil. Solo tienes llamadas duplicadas al model.

Qué No Componer

Algunas combinaciones son riesgosas a menos que exista un límite claro:

Componer no se trata de más partes. Se trata de mejores límites.

Revisión de Diseño

Antes de aprobar un sistema compuesto, pregunta:

1. ¿Quién es dueño del goal?
2. ¿Quién es dueño del state?
3. ¿Quién es dueño de la evidencia?
4. ¿Quién es dueño de los permisos de tool?
5. ¿Quién es dueño de la policy?
6. ¿Quién es dueño de la aprobación?
7. ¿Quién es dueño de la evaluación?
8. ¿Quién es dueño de la respuesta o acción final?
9. ¿Quién es dueño del replay y rollback?
10. ¿Qué falla en producción se convierte en un nuevo eval?

Si la respuesta es “el prompt” para cualquier responsabilidad de alto riesgo, la arquitectura no está lista.

Regla de Diseño

Compón patterns solo cuando cada pattern agregado tenga una función, un límite, un responsable y un eval que pueda fallar.

Capítulos Relacionados

• Architecture Before Autonomy
• From Patterns To Systems
• Pattern Evaluation Checklist
• Agents As Services
• Tool Use
• Agent Loop
• Policy Enforcement
• Human Approval Gates
• Production Evaluation Feedback Loops
• Vertical Slice Examples