Agente de trading IA con Claude Code: lo que este sistema 24/7 hace bien
He visto muchas demos de agentes de IA que se derrumban en cuanto tocan el mundo real.
Lucen impecables hasta que entran en juego el dinero, los tiempos, la ambigüedad o el fallo. Entonces todo se convierte en un prompt pulido encadenado a un mal criterio.
Por eso este recorrido por un agente de trading IA 24/7 me llamó la atención.
No porque prometiera una máquina mágica de imprimir dinero. No porque usara un modelo más grande. Y desde luego no porque "bot de trading IA" sea una frase que suela atraer a ingenieros prudentes. Me llamó la atención porque el sistema estaba planteado de la forma correcta: rutinas, archivos de memoria, guardarraíles, paper trading, autonomía acotada y una estrategia construida en torno a decisiones más lentas y guiadas por fundamentos, en lugar de intentar hacer scalping de velas cada tres minutos.
Ese es un diseño mucho más serio.
Este artículo se basa en un recorrido en vídeo que analicé y en los detalles del sistema presentados allí, no en un agente de trading que yo mismo haya desplegado en vivo con capital real.
El montaje del recorrido usa Claude Opus dentro de Claude Code, con el proyecto actualizado de Opus 4.6 a Opus 4.7 para un comportamiento agéntico más sólido. Alrededor de ese modelo se sitúa un sistema operativo práctico: Alpaca como bróker, Perplexity para investigación de mercado, ClickUp para notificaciones, GitHub para persistencia del estado y rutinas programadas que mantienen al agente en marcha incluso cuando nadie está sentado frente al teclado.
Si le quitas el bombo del "trader de IA", lo que realmente tienes delante es una pipeline de decisión en ejecución continua con memoria, herramientas y restricciones de riesgo.
Esa distinción importa.
Porque la pregunta interesante no es "¿Puede Claude comprar acciones?".
Claro que puede, si lo conectas a una API de bróker.
La pregunta de verdad es esta: ¿puedes construir un sistema que siga tomando decisiones sensatas cuando el mercado está ruidoso, la ventana de contexto es finita, los supuestos de ayer están a medias mal y no hay nadie cerca para vigilar cada movimiento?
Esa es la parte que este recorrido se toma en serio. Y por eso creo que merece la pena estudiarlo aunque nunca dejes que una IA toque una cuenta de bróker en vivo.
Esto no es un bot de day trading, y eso es una fortaleza
La decisión más inteligente de toda la arquitectura es la que la mayoría pasará por alto.
Este agente no se posiciona como un monstruo de alta frecuencia cazando operaciones por debajo del segundo. No intenta ganarle a los creadores de mercado. No pretende que Claude sea de pronto una mesa cuant con infraestructura colocada y un equipo de investigación con doctorados.
Está construido para un estilo más lento: swing trades, periodos de tenencia más largos, fundamentos, investigación de catalizadores, revisiones de cartera y ventanas de ejecución disciplinadas.
Esa elección hace que todo el proyecto sea inmediatamente más creíble.
Los modelos de lenguaje grandes son buenos en síntesis. Pueden leer entradas desordenadas, ponderar señales contradictorias, producir razonamiento escrito, comparar narrativas y mantener un marco estratégico en mente cuando la tarea está bien acotada. Eso encaja mucho mejor con "investiga una empresa, examina catalizadores, compara convicción, dimensiona el riesgo, registra la decisión" que con "predice el próximo movimiento de cinco minutos en SPY".
El recorrido refuerza esto con un benchmark que creo que la gente suele malinterpretar: el análisis financiero agéntico. Ese tipo de evaluación no va realmente de convertirse en una máquina de scalping. Va de si el modelo puede estudiar negocios, razonar a través de fundamentos y producir tesis de inversión coherentes.
Ese es un caso de uso completamente distinto al day trading técnico.
Y si yo estuviera construyendo algo en esta categoría, haría exactamente la misma apuesta: dejar que el modelo opere donde el lenguaje, la investigación y el encuadre de decisiones realmente importan.
El verdadero producto aquí es el sistema de rutinas
La mayoría de quienes ven un vídeo así se centran en la integración con el bróker porque es la parte vistosa. Comprar. Vender. Posición abierta. Operación ejecutada.
Creo que eso pasa por alto la verdadera victoria de ingeniería.
El producto real es la capa de rutinas.
El recorrido divide al agente en trabajos programados a lo largo de la semana de trading:
- Investigación previa a la apertura
- Ejecución en la apertura del mercado
- Gestión de riesgo a media sesión
- Revisión al cierre del mercado
- Calificación semanal del rendimiento
Esa programación es lo que convierte un prompt puntual en un sistema operativo.
Sin rutinas no tienes un agente autónomo. Tienes una sesión de chat ingeniosa que olvida todo en cuanto se cierra la ventana.
Con rutinas obtienes comportamiento repetido bajo condiciones predecibles. El agente despierta, lee memoria, comprueba el entorno, ejecuta un trabajo definido, actualiza registros y entrega mejor estado a la siguiente ejecución. Ese patrón es mucho más valioso que el nicho del trading en sí. Podrías reutilizar el mismo diseño para prospección de ventas, monitorización de seguridad, triaje de soporte, investigación de contenido o mantenimiento de infraestructura. Es la misma razón por la que me entusiasmaron las tareas y la ejecución paralela en Claude Code: el apalancamiento viene de la orquestación repetible, no de un único prompt impresionante.
Este es uno de los mayores cambios de mentalidad que he tenido trabajando con sistemas de IA: el foso casi nunca es el prompt. Es el bucle.
Un buen sistema de rutinas hace tres cosas a la vez:
- Acota el trabajo de cada ejecución.
- Hace más fácil inspeccionar los fallos.
- Capitaliza el aprendizaje a lo largo del tiempo a través de archivos, registros y revisiones.
Eso es exactamente lo que está haciendo este proyecto.
Ejecuciones sin estado, memoria con estado
Esta es la parte que más me gustó.
Cada ejecución de rutina se trata como sin estado en tiempo de ejecución, pero el sistema más amplio mantiene el estado mediante archivos. Es un patrón muy práctico para trabajar con Claude Code.
En lugar de fingir que el modelo "simplemente recordará", el agente lee y escribe explícitamente su memoria:
- archivos de estrategia
- notas de investigación
- historial de operaciones
- registros diarios
- resúmenes
- snapshots de cartera
Eso le da a cada ejecución una capa de continuidad sin obligar a que todo el conocimiento viva dentro de una única conversación inflada.
He visto demasiados flujos de IA fallar porque quien los construye asume que una ventana de contexto grande resuelve la persistencia. No lo hace. Más contexto ayuda, pero también tienta a meter todo en un mismo sitio hasta que la señal se enturbia. El recorrido incluso lo señala con la preocupación por el presupuesto de tokens: aproximadamente 200.000 tokens suena enorme hasta que mezclas instrucciones de sistema, registros, investigación previa, respuestas de API y contexto de mercado en vivo en la misma ejecución.
Entonces empieza la putrefacción.
No un fallo dramático. Peor. Degradación suave.
El modelo sigue produciendo texto fluido, pero el criterio se vuelve menos nítido. Los supuestos viejos se quedan demasiado tiempo. La nueva evidencia recibe muy poco peso. Los compromisos se aplanan en resúmenes genéricos. Eso es peligroso en cualquier flujo autónomo, y especialmente peligroso en algo que toca dinero.
Los archivos de memoria externa son la contramedida correcta.
Te obligan a estructurar el estado a propósito. ¿Qué es estrategia duradera? ¿Qué es investigación temporal? ¿Qué pertenece al diario de operaciones? ¿Qué debería resumirse en lugar de copiarse en bruto? Una vez que piensas así, el agente se vuelve más fácil de escalar y mucho más fácil de depurar. He visto el mismo principio aparecer en los sistemas Claude Code que se mejoran a sí mismos, donde las ganancias reales vienen de lo que el agente preserva, audita y refina con el tiempo.
Por qué Opus 4.7 encaja mejor con este tipo de trabajo
El recorrido enmarca el paso de Opus 4.6 a Opus 4.7 alrededor de un mejor desempeño agéntico: mejor criterio en situaciones ambiguas y mejor autoverificación. Desempaqué ese ángulo del cambio de modelo de forma más directa en mi análisis de Opus 4.7, pero en este montaje de trading la pregunta práctica es más sencilla: ¿se comporta el modelo como un mejor operador a lo largo de ejecuciones programadas repetidas?
Eso importa más aquí que la elocuencia bruta.
Una rutina de trading está llena de preguntas turbias que no tienen etiquetas limpias:
- ¿Esta noticia es relevante o solo ruido?
- ¿La tesis de la posición está rota o simplemente incómoda?
- ¿Debería el agente esperar confirmación o actuar ya?
- ¿La nota anterior sigue aplicando tras el catalizador de hoy?
- ¿La convicción es lo bastante alta para abrir riesgo o es solo una idea interesante?
Esos son problemas de criterio.
Por mi experiencia, los sistemas de IA que sobreviven más tiempo en producción no son los que suenan más listos en una demo. Son los que dudan correctamente, verifican antes de actuar y se mantienen coherentes cuando la entrada está incompleta.
Por eso importa el encuadre de "flujo agéntico". Si un modelo es mejor revisando su propio razonamiento, contrastando archivos y resistiendo el impulso de improvisar más allá de la evidencia, esa es exactamente la mejora que quieres en un sistema autónomo programado.
Aun así nunca confiaría en eso a ciegas. Pero preferiría sin duda ese perfil antes que un modelo optimizado sobre todo para prosa bonita o velocidad de codificación de un solo intento.
Lo mejor de la estrategia es el diseño del riesgo
El recorrido menciona un reto de 30 días en el que el sistema anterior superó al S&P 500 por un 8%.
Es un resultado divertido. Tampoco debería ser la conclusión principal.
Las ventanas cortas pueden favorecer casi a cualquiera. Un buen mes no es una ventaja duradera. Hay un montón de sistemas temerarios que parecen brillantes justo antes de explotar.
Lo que más me importa es el diseño de los guardarraíles:
- tamaño máximo de posición en torno al 5% por posición
- límites en posiciones nuevas
- límites de pérdida diaria
- gestión de stops
- paper trading primero
Eso es comportamiento adulto.
Si vas a automatizar algo con consecuencias financieras, la primera capa de diseño no debería ser "¿Cómo lo hago más agresivo?". Debería ser "¿Cómo evito que haga algo estúpido a las 9:47 de un martes raro?".
La programación de rutinas refleja bien esa mentalidad.
La fase previa a la apertura es para investigación y generación de ideas.
La apertura del mercado es para ejecutar operaciones planificadas, no para improvisar desde cero.
La media sesión es para cortar las perdedoras y apretar el control sobre las ganadoras.
La revisión semanal es para calificar el sistema y ajustar la metacapa.
Ese ritmo aleja al agente del comportamiento impulsivo y lo acerca a la disciplina de proceso. Incluso el uso de trailing stops y umbrales de pérdida muestra conciencia de que la confianza de la IA no es lo mismo que el control de riesgo.
Si yo adaptara esta arquitectura, trataría esos guardarraíles como el verdadero núcleo del producto y la generación de señales como la capa secundaria. Las señales van y vienen. La arquitectura de riesgo es lo que mantiene vivo el experimento el tiempo suficiente para aprender.
GitHub como capa de persistencia es una elección lista y aburrida
Lo digo como un cumplido.
Una de las señales más fuertes de que un sistema lo construyó alguien práctico es cuando la capa de persistencia es aburrida a propósito.
Este proyecto guarda su estado de trabajo en un repositorio privado de GitHub. Las rutinas en la nube clonan el repo, ejecutan el trabajo, actualizan archivos y vuelven a hacer commit de los cambios. Eso significa que la memoria del agente, los registros, los documentos de estrategia y el historial operativo viven todos en una línea de tiempo versionada e inspeccionable.
Eso es dramáticamente mejor que esconder todo dentro de un historial de chat efímero.
También te da unas cuantas ventajas concretas:
- puedes inspeccionar cómo evolucionó la estrategia
- puedes comparar cambios semanales en prompts o archivos de memoria
- puedes recuperarte de ediciones malas
- puedes auditar por qué ocurrió una decisión
- puedes migrar el sistema entre entornos sin reconstruir el estado a mano
Aquí también hay una lección más profunda.
Cuando la gente habla de "agentes de IA", a menudo se obsesiona con el modelo y subinvierte en la higiene de software circundante. Pero autonomía sin auditabilidad es solo caos con buena marca.
Un sistema de memoria respaldado por Git no es glamuroso. Es exactamente el tipo de infraestructura aburrida que hace que los flujos autónomos sean sobrevivibles.
La capa de notificaciones dice mucho sobre quien construye
El recorrido usa ClickUp para resúmenes y alertas en lugar de tirar por defecto a Telegram o algún canal de notificación más ruidoso.
Es una decisión pequeña, pero revela algo útil: el sistema no intenta convertir cada cambio de estado en un drama.
Los buenos flujos autónomos deberían estar dirigidos por interrupciones, no por ruido.
La fase previa a la apertura solo envía mensajes urgentes.
La apertura de mercado solo notifica cuando ocurre realmente una operación.
La media sesión registra actividad sin spam.
La revisión semanal produce un resumen digerible.
Ese es el patrón correcto. Si cada rutina grita pidiendo atención, el operador humano acaba ignorándolo todo. Una capa de notificaciones útil solo escala cuando una persona realmente necesita saber algo.
Esto importa incluso fuera del trading. Uso el mismo principio en el diseño de automatización en general: si un flujo me pinga cada vez que respira, he construido un robot necesitado, no un sistema fiable.
La lección más grande: enseña al agente como a un principiante, no como a un genio
Mi analogía favorita del recorrido es la de aprender a montar en bici.
No tiras a alguien al tráfico el primer día y lo llamas estrategia de aprendizaje.
Empiezas con ruedines. Luego una calle tranquila. Luego una carretera de verdad.
Así es exactamente como deberían construirse estos sistemas.
Empieza con paper trading.
Escribe la estrategia con claridad.
Define qué cuenta como una señal válida.
Registra cada acción.
Revisa los errores.
Aprieta los prompts.
Aumenta la autonomía despacio.
Esa progresión es mucho más sana que el típico enfoque de "conecta el modelo a la API y reza". Respeta el hecho de que los agentes de IA no se vuelven fiables porque les des permiso. Se vuelven fiables porque creas un entorno donde el buen comportamiento es más fácil que el malo.
Ese es el verdadero oficio.
No los teatrillos de prompt. No la captura de pantalla de una confirmación de operación. El oficio está en las restricciones operativas.
Por dónde creo que esto puede romperse
Me gusta la arquitectura, pero también creo que cualquiera que intente esto debería ser brutalmente honesto sobre los modos de fallo.
Primero, el modelo todavía puede sobreajustarse a lo que sea más legible en el contexto. Si una nota de investigación fuerte está escrita de forma más persuasiva que las demás, el agente puede sobreponderar la calidad de la narrativa en lugar de la evidencia real.
Segundo, la memoria rancia es peligrosa. Un archivo de estrategia que tenía sentido hace tres semanas puede convertirse silenciosamente en mala guía si las condiciones del mercado cambian y nadie actualiza el documento.
Tercero, los sistemas integrados con APIs heredan las debilidades de cada dependencia externa. Bróker, investigación, notificaciones, sincronización del repo, ejecución de schedules, variables de entorno, permisos de ramas, rate limit. Cada pieza móvil añade otra forma de que el flujo falle en el momento exacto equivocado.
Cuarto, los registros pueden volverse desorden en lugar de memoria si no se resumen agresivamente. Un diario largo no es automáticamente un diario útil.
Y quinto, el riesgo psicológico es real. Si el agente tiene un estilo de escritura fuerte, puede sonar más seguro de lo que merece. Eso puede seducir al operador a confiar en la calidad de la explicación en lugar de en la calidad del resultado.
Solo ejecutaría un sistema así si tuviera una rutina para revisar al revisor: no solo "qué operaciones hizo", sino "qué supuestos siguen apareciendo, qué archivos están demasiado pesados y dónde está el sistema racionalizando en lugar de razonando".
Lo que robaría de esta arquitectura ahora mismo
Aunque tuviera cero interés en el trading automatizado, robaría varias ideas de este montaje ahora mismo.
La primera es el modelo de rutinas programadas para dividir el trabajo a lo largo del día.
La segunda es la arquitectura de memoria basada en archivos para mantener al agente anclado entre ejecuciones.
La tercera es la capa de persistencia respaldada por GitHub con historial de versiones como log de auditoría.
La cuarta es el sesgo hacia notificaciones escasas y de alta señal.
Y la quinta es la insistencia en el modo paper antes que el modo en vivo.
Esa última aplica casi en todas partes. Antes de que un agente toque infraestructura de producción, datos de cliente, facturas, acciones de seguridad o capital real, deja que opere primero en modo sombra. Míralo pensar. Míralo registrar. Míralo equivocarse en un entorno seguro.
Esa disciplina es lo que separa un sistema autónomo útil de una historia cara.
Lo que exigiría antes de dejar que esto toque dinero real
Si alguien me preguntara dónde trazo la línea entre "prototipo chulo" y "sistema en el que confiaría con una cuenta en vivo", mi respuesta sería bastante estricta.
Querría al menos cuatro cosas en su sitio.
La primera es un periodo en sombra lo bastante largo para exponer la deriva de patrones. No dos días. No una semana de suerte. Querría que el agente corriera en modo paper el tiempo suficiente para ver cómo se comporta en sesiones aburridas, sesiones volátiles, sesiones cargadas de noticias y días en los que no hacer nada es la decisión correcta.
La segunda es revisión de decisiones a nivel de tesis, no solo a nivel de operación. Mucha gente que construye estos sistemas solo revisa si la operación ganó o perdió dinero. Eso no basta. Quiero saber si el razonamiento era internamente consistente, si los catalizadores citados eran reales, si el dimensionamiento encajaba con la convicción declarada y si la lógica de salida siguió las reglas escritas.
La tercera es un fallback operativo duro. Si la sincronización con GitHub falla, si la API del bróker no está disponible, si una llamada de investigación devuelve basura o si faltan variables de entorno, el comportamiento más seguro debería ser parar y registrar el fallo, no improvisar alrededor. Los sistemas autónomos se ganan la confianza en parte por lo que se niegan a hacer.
La cuarta es un ritual regular de poda de estrategia. Un riesgo subestimado en los sistemas de memoria basada en archivos es la acumulación. Cada semana añades más notas, más lecciones, más opiniones, más excepciones. Con el tiempo, el agente puede acabar leyendo un museo de creencias medio muertas. Querría una pasada de limpieza semanal o mensual donde se eliminen los supuestos rancios, se reescriban limpiamente las reglas vivas y la estrategia central se mantenga lo bastante compacta para seguir afilada.
Esa es la pieza que mucha gente que construye con IA subestima. El sistema no solo necesita inteligencia en tiempo de ejecución. Necesita disciplina de mantenimiento entre ejecuciones.
Y honestamente, esa podría ser la verdadera ventaja en proyectos como este. No la actualización del modelo. No el stack de APIs. No la redacción del prompt. La ventaja está en si el operador humano mantiene el entorno lo bastante limpio para que el agente siga tomando decisiones sensatas.
Mi opinión
Este recorrido es interesante porque trata la autonomía de la IA como ingeniería de sistemas en vez de como pensamiento mágico.
Sí, el titular es un agente de trading IA 24/7 en Claude Code.
Pero la lección real es más amplia: si quieres que un agente de IA haga trabajo serio de forma continua, dale rutinas, memoria, límites de riesgo, estado versionado, notificaciones selectivas y un trabajo lo bastante acotado para que el criterio realmente importe.
¿Confiaría a ciegas en algún agente de trading IA con dinero real? No.
¿Estudiaría esta arquitectura como plantilla para construir agentes de larga duración que operen con más disciplina que el típico cebo de demo? Por supuesto.
Esa es la parte a la que merece la pena prestar atención.
Porque el futuro de los agentes de IA útiles probablemente no será un único bot omnisciente gigante haciendo todo a la vez. Serán sistemas como este: programados, restringidos, registrados, revisados y construidos para mejorar con el tiempo.
Y honestamente, ese es un futuro mucho mejor que el que venden los mercaderes del bombo.
Trabajemos juntos
¿Quieres construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (desarrollos a medida e integraciones): fiverr.com/s/EgxYmWD
- Portafolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
