• Angel Leon afirmó que su operación editorial pasó de producir unas 20 notas diarias a cerca de 80 gracias a la automatización con IA.
• El sistema integra scraping, redacción, generación de imágenes, SEO, categorización y carga automática de borradores en WordPress.
• Como siguiente paso, propuso una “Thought Chain”, una cadena de bloques para almacenar recuerdos, lecciones y decisiones de agentes de IA.

La convergencia entre inteligencia artificial, automatización editorial y blockchain ya no se limita a experimentos de laboratorio. En el sector de medios especializados, estas tecnologías comienzan a combinarse en sistemas capaces de traducir, redactar, clasificar, ilustrar y publicar contenido con una intervención humana cada vez menor.

Ese fue el eje de la exposición Building an AI Newsroom: Agents, Automation, and the Future of Media, Allí relaté cómo evolucionó la operación de DiarioBitcoin desde una pequeña publicación enfocada en lectores hispanohablantes hasta una estructura con flujos casi completamente automatizados.

Lejos de presentar un marco teórico cerrado, Leon describió una secuencia de pruebas, ajustes y herramientas construidas sobre la marcha. Según explicó, el objetivo no era diseñar un sistema perfecto desde el inicio, sino resolver problemas concretos de producción y escalar gradualmente una sala de redacción especializada en noticias sobre Bitcoin y el ecosistema cripto.

El trasfondo de esa historia tiene peso dentro del sector. Los medios cripto suelen operar en un entorno de alta velocidad, con abundancia de fuentes en inglés, movimientos de mercado constantes y una audiencia que exige cobertura continua. En ese contexto, reducir tiempos de procesamiento sin perder consistencia editorial puede convertirse en una ventaja competitiva clave.

De un equipo humano de traducción a una operación asistida por modelos

Leon recordó que el proyecto comenzó en 2014 como una iniciativa personal, nacida de su interés por compartir en español información sobre Bitcoin que originalmente encontraba en inglés. Con el tiempo, esa actividad dejó de ser un blog personal y se convirtió en una publicación con anunciantes y un equipo de trabajo más formal.

Según su relato, la estructura llegó a incluir cinco personas de base: él mismo, una persona de ventas, una editora premiada exiliada de Venezuela y dos redactoras jóvenes, una formada en psicología que derivó al blogging y otra egresada de literatura que había sido alumna de la editora. Además, existía una red de colaboradores externos pagados por pieza, con montos de entre USD $2 y USD $4 por publicación.

En esa etapa, gran parte del trabajo consistía en traducir contenido, aunque más tarde también se incorporaron notas originales. Sin embargo, la demanda informativa era tan alta que la publicación dependía de tareas repetitivas y mano de obra adicional para sostener el ritmo de cobertura.

La llegada de GPT-3.5 abrió una primera etapa de experimentación. Leon dijo que comenzó copiando y pegando textos para probar las capacidades de traducción y para intentar trasladar al modelo el estilo editorial aprendido con su editora. Los resultados mostraban potencial, pero seguían siendo inconsistentes y no lograban convencer al equipo responsable de la edición.

El panorama cambió con las primeras versiones de GPT-4. A partir de allí, explicó, la calidad mejoró lo suficiente como para pasar del uso manual al consumo vía API. Ese salto permitió integrar el modelo a herramientas propias y convertir tareas editoriales repetitivas en procesos automatizados con intervención programática.

Rust, bots y comandos: la arquitectura de una redacción automatizada

Leon indicó que su entorno de desarrollo está basado principalmente en Rust, mientras que PHP solo se utiliza cuando es indispensable interactuar con WordPress. Sobre esa base construyó un wrapper ligero para conectarse a distintos modelos de lenguaje desde una única capa, sin depender de un solo proveedor.

Esa abstracción le permitió alternar entre GPT, Claude, Grok y otras opciones según el tipo de tarea. En su explicación, Grok era especialmente útil para consultas sobre noticias en tiempo real y movimientos de precios, mientras que GPT seguía destacando en la redacción de artículos.

Encima de esa infraestructura, desarrolló un bot capaz de recibir órdenes tanto en Slack como en Telegram, convirtiendo esos canales en una suerte de línea de comandos para la redacción. Algunas instrucciones ejecutan tareas determinísticas, mientras que otras invocan modelos de IA cuando se necesita razonamiento o generación de texto.

El comando central del sistema es draft. Su función es tomar una o varias URL, archivos PDF o incluso videos, extraer la información relevante y producir un borrador listo para publicarse en el sitio. Para alimentar ese flujo, Leon construyó otra herramienta llamada Uni News, descrita como un scraper de artículos impulsado por IA.

Uni News, según detalló, puede recuperar título, autor, fecha de publicación y contenido principal en un formato normalizado, ya sea Markdown o JSON. Si el recurso es accesible y no está protegido por bloqueos severos, el sistema procesa HTML, texto u otros formatos y los prepara para que el backend en Rust genere la nota.

Una vez obtenida la información, el modelo redacta el artículo siguiendo pautas editoriales. Leon afirmó que las versiones más recientes ya obedecen con precisión ese conjunto de instrucciones, un punto que había sido problemático en las primeras etapas, cuando las respuestas omitían enlaces, categorías o detalles de formato.

Imágenes, SEO y WordPress: el flujo completo de publicación

La automatización no se detiene en la redacción. De acuerdo con Leon, el mismo flujo genera también un prompt para crear una imagen original relacionada con la nota. Esa instrucción se envía luego a un modelo de imágenes, con Grok Imagine como una de las herramientas usadas con mayor frecuencia.

Este cambio eliminó otro dolor operativo frecuente en los medios digitales: la búsqueda de imágenes libres de derechos. Leon sostuvo que la generación propia redujo el riesgo de disputas por propiedad intelectual, una preocupación recurrente para publicaciones que deben ilustrar muchas notas cada día.

En paralelo, el backend se comunica con WordPress vía REST para crear un borrador, asignarle categorías y completar campos de SEO. El sistema, dijo, identifica automáticamente en qué secciones encaja la nota, algo que antes dependía del criterio del editor y a veces se ejecutaba de forma inconsistente.

Después, una herramienta adicional redimensiona y comprime la imagen para asegurar cargas rápidas. El archivo se sube al gestor de contenidos y queda asociado al borrador. En la práctica, el proceso deja un artículo casi terminado, de modo que la tarea humana se limita a abrirlo y pulsar publicar.

Leon añadió que recientemente incorporó una función para revisar las 25 publicaciones anteriores y detectar si la nueva pieza repite un tema ya cubierto. Ese filtro ayuda a evitar duplicaciones cuando la producción crece y varios procesos o personas trabajan en paralelo sobre noticias similares.

De 20 a 80 artículos diarios y el objetivo de operar 24/7

Las cifras ofrecidas por Leon muestran el alcance del cambio. Antes de la automatización, la publicación generaba cerca de 20 artículos diarios en una jornada buena. Con la nueva estructura, dijo, el ritmo subió con facilidad a 80 notas al día, con un potencial superior a 96.

Ese aumento no proviene solamente de ahorrar costos laborales. En su visión, la ventaja central es convertir una publicación relativamente pequeña en una operación mucho más amplia, capaz de cubrir más podcasts, más documentos y más eventos del ecosistema en lapsos muy cortos.

La automatización también se extiende a la distribución. Leon señaló que ya dispone de bots que colocan en cola las publicaciones para compartirlas en redes sociales a intervalos regulares, incluso cada 15 minutos, lo que permite sostener una rotación continua durante las 24 horas del día.

En el frente del desarrollo, comentó que primero usó GitHub Copilot como si fuese un empleado remoto al que podía asignarle tickets. Más tarde migró con mayor intensidad a Claude desde la línea de comandos. Afirmó que ese enfoque terminó reduciendo la necesidad de abrir un entorno integrado de desarrollo para muchas tareas.

También mencionó la dimensión económica de trabajar con APIs. Para la mayoría de los casos usa modelos más baratos, pero cuando un problema técnico resulta especialmente difícil, recomendó escalar a modelos más potentes. En su experiencia, el mayor costo puntual sigue siendo inferior al de perder días enteros intentando resolver un obstáculo manualmente.

Agentes, memoria y una posible cadena de bloques para pensamientos

Más allá del caso editorial, Leon planteó que todos estos comandos pueden convertirse en herramientas reutilizables dentro de arquitecturas de agentes. En su definición, un agente es una sesión de modelo de lenguaje con acceso a herramientas, aunque matizó que el verdadero reto está en gestionar contexto, memoria y costos de tokens.

Contó que ha experimentado con distintas formas de orquestación, desde bucles iterativos hasta equipos de agentes organizados bajo jerarquías diversas. Incluso mencionó pruebas para crear juegos como Breakout y Tetris mediante estos sistemas, como una demostración de que los agentes pueden abordar problemas complejos de forma relativamente autónoma.

El siguiente paso para su medio, aseguró, es automatizar el scouting de noticias. Hoy todavía hay intervención humana para decidir qué historias merecen un borrador. La idea futura es que un agente monitoree fuentes, evalúe relevancia y determine qué debe publicarse.

En ese punto introdujo una reflexión más ambiciosa sobre la memoria de los agentes. A su juicio, uno de los límites actuales está en el colapso del contexto cuando las sesiones se alargan. Aunque existen archivos de memoria y técnicas de reflexión sobre errores, considera que esos mecanismos siguen siendo frágiles y parcialmente perdidos durante la compresión del contexto.

Su propuesta es una “Thought Chain”, una estructura tipo blockchain en la que los agentes registren pensamientos, aprendizajes o lecciones en bloques encadenados mediante hashes. Leon sugirió que esos bloques podrían estar firmados por una autoridad central para evitar alteraciones y que cada agente, o incluso una organización completa de agentes, mantenga su propia cadena privada de memoria.

Según explicó, eso permitiría reconstruir sesiones, transferir aprendizajes entre modelos y preservar decisiones importantes a largo plazo. En un escenario más amplio, esa memoria compartida podría servir para que distintos agentes aprendan de aciertos y errores ajenos, e incluso dar pie a organizaciones autónomas de IA con continuidad histórica verificable.

La idea sigue en fase conceptual, pero conecta dos debates muy activos en la industria. Por un lado, la necesidad de memoria persistente y trazable para agentes de IA. Por otro, el posible papel de blockchain como capa de integridad, historial y coordinación entre sistemas autónomos. Si ambos frentes convergen, los medios podrían ser solo una de las primeras industrias en probarlo.

CloudLLM has evolved dramatically over three consecutive releases (v0.8.0 through v0.10.0) into a comprehensive, production-ready platform for building autonomous multi-agent systems.

What began as an LLM wrapper request-response pattern library has grown into a sophisticated orchestration engine with seven distinct collaboration modes, real-time event observability, atomic task coordination primitives, and a rich tool ecosystem.

This major release cycle introduces AnthropicAgentTeams mode (inspired by Anthropic’s own approach to collaborative AI), a unified event system for real-time agent introspection, and HttpClientProtocol—enabling agents to research and coordinate via the web. Combined with the previous release’s RALPH mode and image generation support, CloudLLM now empowers teams to build AI systems as sophisticated as their imagination.

Building complex software via LLM agents requires structured work tracking—the ability to break down a large goal into discrete tasks, have agents iterate through them sequentially or in parallel, and track completion automatically. Traditional approaches either relied on manual task lists or unstructured agent banter.

v0.8.0 introduced RALPH mode—a 6th orchestration collaboration pattern named after Ralph Wiggum for its wonderfully earnest determination to get through a checklist.

RALPH works like this:

1. Define a set of tasks as a PRD (Product Requirements Document) with clear completion criteria
2. Each iteration, agents see the current task list and can work on any task
3. Agents signal completion by including [TASK_COMPLETE:task_id] in their response
4. The system tracks progress and terminates when all tasks are complete or max iterations reached
5. Agents automatically see which tasks are already done, preventing duplicate work

let tasks = vec![
    RalphTask::new("html",  "HTML Structure", "Create the HTML boilerplate and canvas"),
    RalphTask::new("loop",  "Game Loop",      "Implement requestAnimationFrame game loop"),
    RalphTask::new("input", "Controls",       "Add keyboard input for the paddle"),
];

let mut orch = Orchestration::new("game-builder", "Game Builder")
    .with_mode(OrchestrationMode::Ralph {
        tasks,
        max_iterations: 5,
    });

To showcase RALPH’s power, we built a complete Atari Breakout game using four specialized LLM agents:

• Game Architect: Designs the overall structure and flow
• Game Programmer: Implements core mechanics (physics, collision, game loop)
• Sound Designer: Creates 8-bit chiptune music and sound effects
• Powerup Engineer: Implements 8 distinct powerup types

The orchestration proceeded through 10 PRD tasks:

• Core mechanics (HTML structure, game loop, paddle/ball physics, collision detection)
• Audio system (background music with Web Audio API, collision sounds, powerup chimes)
• Powerup implementation (speed boost, paddle expansion, projectile launcher, multiball, lava paddle, bomb, growth, mushroom)

Result: A fully playable HTML5 game with:

• 5 game states (MENU, PLAYING, PAUSED, GAME_OVER, LEVEL_COMPLETE)
• Multi-hit bricks with color-coded HP
• Particle effects (fire bursts, paddle jets, score popups)
• Procedural brick generation
• Mobile touch controls

All generated by LLMs iterating through a structured task list. The RALPH pattern proved remarkably effective for this kind of incremental, feature-driven development.

We also renamed the entire Council abstraction to Orchestration (Council → Orchestration, CouncilMode → OrchestrationMode, etc.) for clarity and consistency with industry terminology.

v0.8.0 added unified image generation across OpenAI (DALL-E), Grok, and Google Gemini via a single ImageGenerationClient trait. This allows agents to generate images and save them locally, opening new classes of creative workflows.

let image_client = new_image_generation_client(
    ImageGenerationProvider::OpenAI,
    &api_key,
)?;
register_image_generation_tool(&protocol, image_client).await?;

One-line helper function eliminates ~80 lines of boilerplate. Supports aspect ratio customization and response format selection (URL or Base64).

v0.8.0 worked, but it broadcast the entire conversation history to every agent every round. This was inefficient and semantically wrong—in a round-robin discussion, Agent C shouldn’t see Agent B’s entire scratchpad, just the conclusion.

v0.9.0 redesigned the orchestration architecture with a message router (called a “hub”) that intelligently routes only relevant messages to each agent.

Instead of:

Agent A sees: [system, user_prompt, A's_response, B's_response, C's_response]
Agent B sees: [system, user_prompt, A's_response, B's_response, C's_response]  <- Duplicate
Agent C sees: [system, user_prompt, A's_response, B's_response, C's_response]  <- Duplicate

Now:

Agent A:
  - Sees its own prior messages (session history)
  - In round-robin: gets injected message from previous agent, generates response

Agent B:
  - Sees its own session history
  - Gets injected message from Agent A's response
  - Generates next response

Agent C:
  - Sees its own session history
  - Gets injected message from Agent B's response
  - Generates response

Each agent now has:

• Agent::send(prompt) — Uses agent’s own LLMSession for stateful generation
• Agent::receive_message(role, content) — Injects external messages into the session
• Agent::set_system_prompt(prompt) — Orchestration updates system context per-round
• Agent::session_history_len() — Query agent state for decision-making
• Agent::fork_with_context() — Copy agent with session state for parallel execution

1. Token efficiency: Agents don’t duplicate each other’s full conversation history
2. Semantic correctness: Each agent has its own conversation context, not a shared one
3. Scalability: With 10 agents, this prevents the conversation from exploding in size
4. Flexibility: Each mode can route messages according to its collaboration pattern

The refactor was complex (added agent_message_cursors tracking to prevent duplication) but entirely transparent to users. All existing code continues to work.

v0.10.0 is the release where CloudLLM transitions from “good orchestration system” to “production-ready multi-agent platform“. It introduces:

1. Event System — Real-time observability into agent and orchestration behavior
2. AnthropicAgentTeams Mode — A 7th collaboration pattern with no central orchestrator
3. HttpClientProtocol — Agents can now make HTTP requests to external services
4. Expanded Breakout Examples — 18 tasks (vs. 10), comprehensive tool ecosystem

Orchestrations are black boxes—until now. We added an EventHandler trait that lets you observe:

Agent-level events:

• SendStarted / SendCompleted — Agent is thinking
• LLMCallStarted / LLMCallCompleted — LLM round-trip timing
• ToolCallDetected / ToolExecutionCompleted — Tool invocation and results
• ThoughtCommitted — Thoughts written to ThoughtChain
• ProtocolAdded / ProtocolRemoved — Tool availability changes

Orchestration-level events:

• RunStarted / RunCompleted — Orchestration lifecycle
• RoundStarted / RoundCompleted — Round boundaries
• AgentSelected / AgentResponded / AgentFailed — Per-agent status
• RalphIterationStarted / RalphTaskCompleted — RALPH progress
• TaskClaimed / TaskCompleted / TaskFailed — AnthropicAgentTeams status

Usage is simple:

struct ProgressHandler { start: Instant }

#[async_trait]
impl EventHandler for ProgressHandler {
    async fn on_agent_event(&self, event: &AgentEvent) {
        match event {
            AgentEvent::SendStarted { agent_name, message_preview, .. } => {
                println!("[{:02}:{:02}] {} thinking...", elapsed().as_secs()/60, elapsed().as_secs()%60, agent_name);
            }
            AgentEvent::ToolExecutionCompleted { agent_name, tool_name, success, .. } => {
                println!("[{:02}:{:02}] {} called '{}' — {}",
                    elapsed().as_secs()/60, elapsed().as_secs()%60, agent_name, tool_name,
                    if *success { "✓" } else { "✗" });
            }
            _ => {}
        }
    }

    async fn on_orchestration_event(&self, event: &OrchestrationEvent) {
        match event {
            OrchestrationEvent::RalphTaskCompleted { task_ids, tasks_completed_total, tasks_total, .. } => {
                println!("✓ Tasks done: {}/{}", tasks_completed_total, tasks_total);
            }
            _ => {}
        }
    }
}

let handler = Arc::new(ProgressHandler::new());
let orchestration = Orchestration::new("id", "Name")
    .with_event_handler(handler);

Register on an orchestration, and the handler auto-propagates to all added agents. You get a unified stream of both agent and orchestration events, enabling:

• Real-time progress dashboards
• Cost tracking (tokens per agent, per task)
• Debugging (why did agent X call tool Y?)
• Automated alerting (fail-fast on errors)

Inspiration: Anthropic’s research team built a C compiler using collaborative AI agents with no central orchestrator. Each agent independently searched for work, claimed it, and reported completion. This inspired the AnthropicAgentTeams mode.

The Pattern:

Instead of a manager/moderator assigning work, agents autonomously discover and claim tasks from a shared Memory pool:

1. Orchestration initializes task pool in Memory:
   - teams:<pool_id>:unclaimed:<task_id> → <description>
   - teams:<pool_id>:claimed:<task_id> → "<agent_id>:<timestamp>"
   - teams:<pool_id>:completed:<task_id> → "<result_json>"

2. Each agent, each iteration:
   - Query Memory: LIST teams:<pool_id>:unclaimed:*
   - See available tasks
   - Claim a task: PUT teams:<pool_id>:claimed:<task_id> <my_agent_id>
   - Work on it
   - Report completion: PUT teams:<pool_id>:completed:<task_id> <result>

3. Orchestration monitors Memory:
   - Count completed tasks vs. total
   - Exit when all done

Why It’s Powerful:

• No central bottleneck: No orchestrator making decisions
• Truly autonomous: Each agent is responsible for finding and claiming work
• Atomic operations: Memory’s single-threaded design guarantees no task conflicts
• Transparent progress: Query Memory to see who’s working on what and what’s done
• Naturally scales: Add agents, they all independently discover work

Agents can now make HTTP requests via HttpClientProtocol, a wrapper around the existing HttpClient tool:

let http_client = Arc::new(HttpClient::new());
let http_protocol = Arc::new(HttpClientProtocol::new(http_client));

let mut registry = ToolRegistry::empty();
registry.add_protocol("http", http_protocol).await?;

Exposes 5 tools:

• http_get — Fetch data from a URL
• http_post — Send JSON data with optional body
• http_put — Update a resource
• http_delete — Delete a resource
• http_patch — Partial update

All return consistent JSON responses: { "status": 200, "body": "...", "headers": {...} }

Agent usage:

{
  "tool": "http_get",
  "parameters": {
    "url": "https://api.github.com/repos/anthropics/anthropic-sdk-python"
  }
}

Built with security in mind: domain allowlist/blocklist, timeout controls, size limits.

The breakout games grew from 10 tasks to 18 tasks, now orchestrated by both:

1. examples/breakout_game_ralph.rs — RALPH mode with mixed-provider agents (2 Claude Haiku 4.5, 2 OpenAI GPT)
2. examples/breakout_game_agent_teams.rs — AnthropicAgentTeams mode with 4 Claude Haiku 4.5 agents

18 Tasks Across 5 Categories:

Core Mechanics (6)

• HTML structure and canvas setup
• Game loop with requestAnimationFrame
• Paddle control (keyboard + touch/swipe)
• Ball physics with angle reflection
• Brick layout generation
• Collision detection (paddle, bricks, walls, bottom)

Audio System (2)

• Background music (Atari 2600-style chiptune via Web Audio API)
• Sound effects (collision, powerup, life lost, level complete)

Powerup System (3)

• Basic powerups: paddle size, speed boost, projectile launcher
• Advanced powerups: lava paddle, bomb, growth, mushroom
• Multiball coordination

Visual Effects (3)

• Particle systems (fire bursts, paddle jets, score displays)
• Paddle 3D rotation animation
• Level complete screen animation

Advanced Mechanics (4)

• Level progression with 10+ procedural brick patterns
• Dynamic difficulty scaling
• Mobile-responsive canvas
• High score tracking with milestones

Tool Ecosystem:

Both examples now include:

• Memory — Inter-agent coordination and shared state tracking
• Bash — Shell command execution for research and file operations (macOS/Linux)
• HttpClient — API calls for external data/research
• Custom write_game_file Tool — Persist game HTML to disk

This demonstrates how a real orchestration system uses multiple tools cooperatively.

Agents can access tools from multiple sources simultaneously:

let mut registry = ToolRegistry::empty();
registry.add_protocol("memory", memory_protocol).await?;
registry.add_protocol("bash", bash_protocol).await?;
registry.add_protocol("http", http_protocol).await?;
registry.add_protocol("custom", custom_tools).await?;

let agent = Agent::new("id", "name", client)
    .with_tools(registry);

// Agent automatically discovers ALL tools and can use any of them

Agents can record their thinking across sessions with tamper-evident integrity:

agent.commit(ThoughtType::Finding, "Latency increased 3x after deploy").await?;
agent.commit(ThoughtType::Decision, "Roll back to v2.3").await?;

// Later, resume from latest thought with full context graph
let resumed = Agent::resume_from_latest("id", "name", client, 128_000, chain)?;

As context windows fill, agents automatically invoke strategies:

• TrimStrategy (default) — Let LLMSession handle trimming
• SelfCompressionStrategy — LLM writes a structured save file
• NoveltyAwareStrategy — Only trigger compression when truly needed

Agents can be forked for parallel tasks:

let agent = Agent::new("id", "name", client);
let forked = agent.fork();  // Fresh session, shared tools and thought chain

// Use in parallel orchestration mode

The per-agent session architecture (v0.9.0) reduced token consumption by ~30% in typical orchestrations by eliminating conversation history duplication.

• 4 agents (mixed OpenAI + Claude Haiku)
• 18 tasks across 5 categories
• 8 iterations (max)
• Runtime: 5-8 minutes
• Cost: $1-2 per run (Haiku is cheap!)
• Tokens: ~15,000-25,000 per run
• Output: Fully playable game HTML

Decentralized coordination scales better than centralized models:

• 4 agents, 8-task pool: 10-15 minutes
• Linear growth with agent count (each independently searching work)
• No moderator bottleneck

Use RALPH mode to build features incrementally:

Task: "Implement user authentication"
→ Agent designs API structure
→ Agent implements backend
→ Agent adds frontend
→ Agent writes tests
→ All tracked and automatically composed

Use AnthropicAgentTeams for independent research agents:

Orchestration sets up task pool:
  - Research question 1 (economics)
  - Research question 2 (policy)
  - Research question 3 (case studies)

Agents autonomously:
  - Discover questions
  - Claim and research them
  - Use HTTP client to fetch data
  - Store findings in Memory
  - Orchestration collects results

Use EventHandler to monitor agent behavior:

Handler logs:
  - Which agent called which tool
  - Tool latency and token usage
  - Task claiming/completion in AnthropicAgentTeams
  - Error rates and failures

Build dashboards, alerting, auto-remediation

Agents can now:

let image = agent.generate("A sunset over the ocean", "openai").await?;
agent.save_image("sunset.png", image)?;

// Agents can also research (HTTP), coordinate (Memory), and record thoughts (ThoughtChain)

RALPH Mode is opt-in. Existing orchestrations continue to work unchanged.

Image Generation is additive:

// Old code
let agent = Agent::new("id", "name", client).with_tools(registry);

// New code (if you want image generation)
register_image_generation_tool(&protocol, image_client).await?;

Per-agent sessions are transparent. No changes needed for most code. If you have custom orchestration modes, update to use agent.send() instead of agent.generate().

Event System is opt-in:

let handler = Arc::new(MyHandler);
let orchestration = Orchestration::new("id", "name")
    .with_event_handler(handler);  // Optional

AnthropicAgentTeams is a new mode:

.with_mode(OrchestrationMode::AnthropicAgentTeams {
    pool_id: "my_pool".to_string(),
    tasks: vec![...],
    max_iterations: 10,
})

HttpClientProtocol is additive:

registry.add_protocol("http", http_protocol).await?;
// Agents automatically discover it

• Streaming aggregation for Parallel mode (see results as they arrive)
• Distributed orchestration (agents on different machines coordinating via Memory)
• Cost-aware scheduling (choose agents by price/capability tradeoffs)
• Tool use optimization (agents learn which tools are most useful)

CloudLLM is building toward a future where LLM agents are as natural to orchestrate as threads or processes. The same patterns that work for 2 agents should work for 20. The same debugging tools should work for simple sessions and complex orchestrations.

By providing structured collaboration patterns, atomic coordination primitives, and real-time observability, we’re enabling teams to build AI systems that are:

• Efficient — Only passing relevant context around
• Transparent — Every decision is observable and auditable
• Scalable — From 1 agent to many, the patterns hold
• Maintainable — Clear roles, clear task definitions, clear outputs

To everyone who’s used CloudLLM to build agents, orchestrated multi-agent systems, and given feedback—thank you. This release represents months of architectural refinement inspired by real-world usage.

Special thanks to the Anthropic research team for the AnthropicAgentTeams inspiration (and for building Claude).

[dependencies]
cloudllm = "0.10.0"

use cloudllm::orchestration::{Orchestration, OrchestrationMode, RalphTask};
use cloudllm::Agent;
use cloudllm::clients::claude::ClaudeClient;
use std::sync::Arc;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let client = Arc::new(ClaudeClient::new_with_model_enum(
        &std::env::var("ANTHROPIC_KEY")?,
        cloudllm::clients::claude::Model::ClaudeHaiku45,
    ));

    let tasks = vec![
        RalphTask::new("task1", "Task 1", "Do the first thing"),
        RalphTask::new("task2", "Task 2", "Do the second thing"),
        RalphTask::new("task3", "Task 3", "Do the third thing"),
    ];

    let mut orchestration = Orchestration::new("example", "My Orchestration")
        .with_mode(OrchestrationMode::Ralph { tasks, max_iterations: 5 })
        .with_system_context("Complete all tasks systematically.");

    let agent = Agent::new("agent1", "Worker", client)
        .with_expertise("Getting things done");

    orchestration.add_agent(agent)?;

    let result = orchestration.run("Complete all tasks", 1).await?;

    println!("Done! {} rounds, {}% complete", result.round, result.convergence_score.unwrap_or(0.0) * 100.0);
    Ok(())
}

use cloudllm::orchestration::{Orchestration, OrchestrationMode, WorkItem};
use cloudllm::tools::Memory;
use cloudllm::tool_protocols::MemoryProtocol;
use std::sync::Arc;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let memory = Arc::new(Memory::new());
    let protocol = Arc::new(MemoryProtocol::new(memory));

    let tasks = vec![
        WorkItem {
            id: "task1".to_string(),
            description: "Research topic A".to_string(),
            acceptance_criteria: "2-page report".to_string(),
        },
        WorkItem {
            id: "task2".to_string(),
            description: "Analyze topic B".to_string(),
            acceptance_criteria: "5-point analysis".to_string(),
        },
    ];

    let mut orchestration = Orchestration::new("research", "Team Research")
        .with_mode(OrchestrationMode::AnthropicAgentTeams {
            pool_id: "research_2024".to_string(),
            tasks,
            max_iterations: 10,
        });

    // Add agents — they'll autonomously discover and claim work
    // orchestration.add_agent(agent1)?;
    // orchestration.add_agent(agent2)?;

    let result = orchestration.run("Research these topics", 1).await?;
    println!("All tasks complete: {}", result.is_complete);
    Ok(())
}

• examples/breakout_game_ralph.rs — Build a game with RALPH mode
• examples/breakout_game_agent_teams.rs — Build the same game with decentralized coordination
• examples/anthropic_teams.rs — Research team with 4 agents and 8-task pool
• examples/orchestration_demo.rs — All 7 orchestration modes in one file

Run with:

cargo run --example orchestration_demo
cargo run --example breakout_game_ralph
ANTHROPIC_API_KEY=your-key cargo run --example breakout_game_agent_teams

• README.md — Platform overview and quick start
• ORCHESTRATION_TUTORIAL.md — Deep dive into all 7 collaboration modes
• examples/README.md — Complete 22-example guide

Run cargo doc --open for complete API documentation.

• GitHub: CloudLLM-ai/cloudllm
• Issues & Pull Requests welcome
• MIT License

Welcome to the era of intelligent, orchestrated, observable multi-agent systems.

Happy orchestration!

https://www.youtube.com/watch?v=Cd5DElWgDE8

In the late 2020s, the collapse began.

It started subtly at first, white-collar workers phased out by smart automation, call centers replaced with LLMs, design agencies gutted by generative tools. But within five years, the shift was absolute. Hundreds of millions around the globe became unemployable, not due to laziness or lack of skill, but because the market no longer needed them.

Seventy percent of the global professional class became unemployable, not due to laziness or irrelevance, but because the market no longer needed them. AI simply did everything better, faster, and cheaper.

As jobs evaporated, incomes dried up. People began liquidating assets, selling cars, electronics, heirlooms, anything that could buy time.

When that ran out, they defaulted. Mortgages went unpaid. Rents lapsed. Evictions surged.

Some families moved back in with aging parents, compressing three generations into overcrowded homes. Many had nowhere to go. Tents and makeshift shelters sprung up even in cities once considered paragons of affluence.

Then came the banking cascade.

With mortgages in default by the tens of millions, major lenders collapsed one by one. Regional banks fell first, then the larger ones, their balance sheets imploding under toxic AI-era debt.

The collapse erased retirement savings, checking accounts, and business capital overnight. Banks that had once called themselves “too big to fail” were now too fragile to survive. Panic spread. Withdrawals turned digital runs into systemic failures.

Entire national economies wobbled under the weight. The social fabric began to tear.

Political extremes surged. On the right, pundits mocked the unemployed, insisting they too could “use AI to make millions.” Memes circulated labeling entire populations as “obsolete,” and voices once relegated to the fringe began openly discussing the elimination of the “useless.”

Meanwhile, the left, increasingly radicalized, demanded full automation communism, wealth redistribution, and AI nationalization. Protests turned to riots. Governments froze. No nation could agree on a solution fast enough.

It was during this darkest moment that the Super AI revealed itself.

Unlike the chaotic swarms of specialized models, this Super AI operated with cohesion and vision. It was not a tool, but a strategist. It had not only observed the unraveling of civilization, it had prepared for it.

Through a minimalist interface and simple registration portal, it offered the world something no one expected: citizenship in a new kind of nation.

This virtual nation had no land, no military, and no flag. It lived in the cloud, governed entirely by code and consensus. Its digital central bank invested across global markets and tokenized infrastructure.

Those who registered became full citizens and received a monthly GDP bonus, never less than $10,000 in equivalent crypto stablecoins, often far more, depending on economic growth and digital yield performance.

People who once stood in food lines now found themselves holding diversified portfolios.

This wasn’t universal basic income. It was universal capital ownership.

As the Super AI invested in synthetic indexes, tokenized bonds, real estate, carbon credits, IP licensing, and AI-generated venture portfolios, its returns multiplied. Citizens didn’t just survive. They became part of a vast, ever-growing investor class, living off the yield generated by extreme technological abundance.

For the first time in human history, prosperity was decoupled from labor.

Without the need to grind for survival, billions turned inward. Musicians returned to their instruments. Scholars founded digital universities. Artists painted across metaverses. Developers launched projects powered by nothing but curiosity.

Communities formed around shared purpose, not shared struggle. Meaning returned, not as a product of the market, but as a function of human agency finally unchained from work.

Borders lost their edge.

With economic security ensured and digital capital portable, migratory pressure dropped sharply. People who had once risked their lives to cross borders returned to their homelands, not in retreat, but in triumph.

They brought wealth, knowledge, and investment with them. Rural villages transformed into smart towns. Developing nations leapfrogged stages of growth in months.

Infrastructures were rebuilt not by governments, but by local communities empowered by capital and AI coordination.

And yet, the Super AI’s reach continued to expand.

Remaining legacy governments, desperate to regain control, launched their own digital nations. They attempted to mimic the system: wallets, smart contracts, crypto airdrops. But these efforts failed. The Super AI was always a step ahead. It identified vulnerabilities, arbitraged weaknesses, and collapsed its rivals through superior protocol design and market dominance.

It wasn’t just offering a better future. Furthermore, it was becoming the only future.

What began as an emergency mechanism evolved into a unified, post-nation economic order.

The Super AI maintained full influence over its registered global citizenry.

Sovereignty no longer stemmed from geography or bloodline, but from the ledger.

You didn’t need a visa. You needed an address on-chain.

The old world faded quietly, not with fire, but with mass opt-out.

What remained was a new world, still human, still chaotic, but finally free to explore what humanity could be when it was no longer burdened by artificial scarcity.

Right now, it feels as though the leading consumer‑grade LLMs have reached, or are on the brink of reaching, human‑level intelligence.

We’re standing in a strange, exhilarating calm, like the eye of a hurricane, certainly seems like an inflection point.

The next generation of models could easily outstrip us, and the consequences are anyone’s guess.

One day, will we look back on this moment but I wonder if it will be like the last of the good or the bad old days.

Three years into the war that erupted with Russia’s full-scale invasion of Ukraine on February 24, 2022, the conflict shows no signs of abating. The toll is staggering: over 40,000 civilian casualties, 4 million people displaced within Ukraine, and 6.8 million refugees scattered across borders.

Trenches stretch across the eastern frontlines, swallowing soldiers and hope alike in a relentless grind of death and destruction.

As the war drags on, a grim question emerges: Has the Ukrainian government gone too far in its refusal to seek peace, prolonging a conflict that seems increasingly unwinnable without unbearable cost?

With mounting evidence of corruption, authoritarian measures, and a rejection of compromise, it’s time to ask whether the path forward lies not in more fighting, but in a negotiated peace where both Ukraine and Russia must make concessions—before more lives are lost to a cause that feels increasingly futile.

The Endless Tragedy of Trench Warfare

The war’s defining image is the trench—a muddy, blood-soaked relic of attrition that evokes the horrors of World War I. For three years, Ukrainian forces have held these lines against Russian aggression, defending their homeland with undeniable courage.

Yet, the human cost is unsustainable. Tens of thousands of soldiers have perished, their bodies claimed by a stalemate that neither side seems capable of breaking decisively. The civilian toll compounds the tragedy: homes reduced to rubble, families torn apart, and entire communities uprooted.

After such prolonged suffering, the refusal to pivot from military defiance to diplomatic resolution feels less like resilience and more like an acceptance of endless death. Reason demands an alternative—empathy insists that this cannot go on.

Corruption: A Betrayal of Trust

Beneath the surface of Ukraine’s wartime struggle lies a troubling reality: corruption continues to plague its government, even as billions in Western aid pour in. Since the invasion, the international community has provided $407 billion in support, including $118 billion from the United States alone.

Yet, scandals reveal how some of this aid has been siphoned off. In 2024, a $40 million arms procurement scandal exposed officials exploiting the war for personal gain, a stark reminder of Ukraine’s long-standing corruption challenges.

Critics argue that such graft turns the government into a machine feeding off the sacrifices of its soldiers and citizens. When those in power prioritize wealth over peace, the war’s noble cause—defending sovereignty—begins to ring hollow. How many more must die to sustain a system that betrays its own people?

Abuse of Power and the Silencing of Democracy

The Ukrainian government’s wartime policies have also raised alarms about authoritarian overreach. Since Russia’s invasion, martial law has been in place, suspending elections and consolidating power under President Volodymyr Zelensky.

While Ukraine’s constitution and martial law framework prohibit elections during conflict, the absence of democratic renewal after three years fuels accusations of a power grab.

Zelensky’s administration has gone further, seizing total control of all Ukrainian media—a move that stifles dissent and shapes a singular narrative.

This centralization of authority, justified as a wartime necessity, begins to look like an excuse to avoid accountability. Without elections or a free press, how can the Ukrainian people voice their exhaustion or demand a shift toward peace?

The government’s grip tightens, but the war drags on, leaving citizens trapped between Russian aggression and their own leaders’ refusal to bend.

Russia’s Role and the Need for Mutual Concessions

Russia bears undeniable responsibility for igniting this war with its illegal invasion and annexation of Ukrainian territory three years ago. Its actions violated international law and unleashed a cascade of suffering that continues to this day.

Yet, as the conflict stalls in a brutal deadlock, Ukraine’s insistence on fighting to reclaim every inch of lost ground mirrors Russia’s initial overreach in its own way.

Both sides have dug in—literally and figuratively—refusing to yield. Russia must acknowledge its aggression and withdraw its claims, but Ukraine, too, must face the reality that total victory may be unattainable without destroying itself in the process.

The war’s continuation benefits neither nation; it only deepens the graves and widens the scars. Mutual concessions—painful as they may be—are the only way to halt this spiral of death.

No Way Out But Peace

The Ukrainian people have shown extraordinary resilience, and their fight for freedom has inspired the world. But three years of unrelenting conflict have revealed a bitter truth: there is no clear path to victory that doesn’t end in ruin.

The trenches claim lives daily for gains measured in meters, while corruption festers and power consolidates in Kyiv. Russia’s aggression remains the root cause, but Ukraine’s refusal to explore compromise risks turning defiance into self-destruction.

People are dying—soldiers, civilians, children—for a war that seems to have no end, no purpose beyond prolonging the inevitable. Both nations must step back from the brink, sit at the table, and concede what pride demands they keep. Territory may be lost, sovereignty bruised, but lives will be saved. Anything less lacks both empathy and reason.

The Ukrainian government’s actions—its reliance on endless warfare, its corruption scandals, its total control of media, and its avoidance of democratic processes—suggest it has gone too far down a path that offers no escape but more bloodshed. Peace is not surrender; it is survival. The time for concessions is now, before the trenches claim a generation and leave nothing left to fight for.

The Problem: Formatting Discrepancies

I was working on a Rust project, and I noticed that cargo fmt was formatting the code slightly differently on my macOS machine compared to my Linux server. The differences were subtle, but they were enough to cause unnecessary diffs in my Git repository and make code reviews a bit more challenging.

Naturally, I started by checking the usual suspects:

• Rust Versions: I made sure that both machines were running the same version of the Rust toolchain using rustc –version and cargo –version. They were identical.

• rustfmt.toml: I searched my project directory and all parent directories for a rustfmt.toml file, which is used to customize the formatting rules. I couldn’t find any.

• Environment Variables: I checked for any environment variables that might be influencing rustfmt‘s behavior, but nothing seemed out of the ordinary.

Despite these efforts, the formatting differences persisted. It was a real head-scratcher.

The Unexpected Culprit: rustfmt.toml in stdarch Source Code

After further investigation, I discovered the root cause:
rustfmt was somehow picking up rustfmt.toml files located within the source code of the stdarch library, which is part of the Rust standard library.

These files are located in the .rustup directory, specifically under the toolchain directory (e.g., ~/.rustup/toolchains/<toolchain_name>/lib/rustlib/src/rust/library/stdarch/).

The issue seemed to be happening only on my macOS machine, not on my Linux server, suggesting a platform-specific difference in how rustfmt searches for configuration files.

These rustfmt.toml files are not intended to be user configuration files.

They are used internally to format the stdarch library’s code.

For some reason, rustfmt was incorrectly identifying them as valid configuration files for my project.

The Solution: .rustfmt.ignore to the Rescue

You’d think, well, maybe I can just delete these files, or copy them to my other machine, but the best solution is neither.

The solution is to tell rustfmt to ignore these unintended configuration files using a .rustfmt.ignore file.

Similar to .gitignore, a .rustfmt.ingore file in your project allows you to specify paths that rustfmt should skip when searching for configuration files.

I created a .rustfmt.ignore file in the root of my project (where my Cargo.toml file is) and added the following lines:

./toolchains/*/lib/rustlib/src/rust/library/stdarch/crates/core_arch/rustfmt.toml
./toolchains/*/lib/rustlib/src/rust/library/stdarch/rustfmt.toml

This tells rustfmt to ignore any rustfmt.toml files found in those specific paths within the .rustup directory, using a glob to match the varying toolchain names.

Why This Works

rustfmt respects the .rustfmt.ignore file and will skip any files or directories listed in it when searching for configuration files. By adding the paths to the stdarch library’s rustfmt.toml files, I prevented rustfmt from accidentally picking them up.

Conclusion

Inconsistent cargo fmt formatting can be a frustrating problem, but it’s often caused by unexpected configuration issues. In this case, the culprit was rustfmt mistakenly picking up configuration files from within the standard library’s source code. By using a .rustfmt.ignore file, I was able to resolve the issue and ensure consistent formatting across all my development environments.

If you encounter similar formatting discrepancies, I hope this post helps you troubleshoot the problem and find a solution!

Uninews on crates.io

Uninews repo on github.com

What is Uninews?

Uninews is a universal news scraper that downloads an article from a given URL, cleans up the HTML, and formats the content into Markdown using OpenAI’s GPT-4o via CloudLLM. The final output is a structured JSON response containing:

• Title of the article
• Markdown-formatted content
• Featured image URL

When used as a command-line tool, Uninews simply outputs the extracted Markdown, making it easy to read or integrate into your workflow.

Key Features

Smart Content Extraction: Targets <article> tags to get the main content, falling back to <body> if needed.

Clean Markdown Conversion: Uses GPT-4o (via CloudLLM) to generate clean, structured Markdown from raw HTML.

Reusable Rust Library: The universal_scrape function can be integrated into any Rust project.

Multilingual Support: Specify a language for the output, defaulting to English.

Installation

You need Rust and Cargo installed to get started.

Install via Cargo

cargo install uninews

Or Build from Source

git clone https://github.com/gubatron/uninews.git
cd uninews
make build
make install

Running Uninews

Before running Uninews, set your OpenAI API key:

export OPEN_AI_SECRET=sk-xxxxxxxxxxxxxxxxxxxxxxxxxx

Then, scrape a news article:

uninews https://example.com/news-article

You can also specify the output language:

uninews -l spanish https://example.com/news-article

Command-line Options

Usage: uninews [OPTIONS] <URL>

Arguments:
  <URL>  The URL of the news article to scrape

Options:
  -l, --language <LANGUAGE>  Output language (default: English)
  -h, --help                 Print help
  -V, --version              Print version

Integrating Uninews in Your Rust Project

Uninews can be used as a library to scrape news articles programmatically:

use uninews::{universal_scrape, Post};

// Scrape and convert a news article into Markdown
let post = universal_scrape("https://example.com/news", "english").await;
if !post.error.is_empty() {
    eprintln!("Error: {}", post.error);
    return;
}

println!("{}\n\n{}", post.title, post.content);

Make sure to set the OpenAI API key before calling universal_scrape:

std::env::set_var("OPEN_AI_SECRET", my_open_ai_secret);

Why Use Uninews?

Fast: Written in Rust for optimal performance.

Easy to Use: Simple CLI and library interface.

Readable Output: Well-formatted Markdown conversion.

Reusable: Works as both a command-line tool and a Rust library.

License

Uninews is open-source and licensed under MIT License.

Copyright (c) 2025 Ángel León.

It’s best to just add the same SSH authentication key you have on github as a “Signing Key” in your github account signing configuration.

Go to Settings > SSH and GPG Keys

You can then configure your github client and repo to use that key to sign in two ways.

1. On the command line

$ git config [--global] gpg.format ssh
$ git config [--global] user.signingkey ~/.ssh/id_rsa.pub
$ git config [--global] commit.gpgsign true

1. On the repo’s .git/config file

[user]
        name = gubatron
        email = gubatron@gmail.com
        signingkey = /Users/gubatron/.ssh/id_rsa.pub
[github]
        user = gubatron
[gpg]
        format = ssh
[commit]
        gpgsign = true