Cómo implementar un squad de agentes autónomos al estilo Kitten Agent Blog

Introducción

El workshop Kitten Agent Blog de AgentCamp 2026 plantea una idea muy atractiva: un equipo de agentes con personalidad propia que colabora para levantar un blog, escribir artículos, generar portadas y publicar el resultado mediante CI/CD.

La propuesta funciona muy bien como ejercicio porque transforma un flujo técnico habitual —planificar, redactar, revisar, construir y desplegar— en un squad de agentes con responsabilidades separadas:

Astro, el agente arquitecto.
Whiskers, el agente redactor.
Luna, el agente visual.
Rocket, el agente publicador.

Ahora bien, conviene aterrizarlo con precisión: un “squad de agentes autónomos” no debería entenderse como una caja mágica que opera sin control. En un entorno profesional, lo más razonable es diseñarlo como una orquestación de tareas asistidas por IA, con contratos de entrada/salida, permisos mínimos, revisiones humanas y automatización reproducible.

En este artículo veremos cómo implementar una versión práctica de ese patrón usando piezas conocidas del ecosistema GitHub:

Un repositorio para el blog.
GitHub Actions para orquestar el flujo.
GitHub Pages para publicar.
GitHub Copilot como ayuda de desarrollo y revisión.
Un proveedor de modelos de lenguaje o generación de imágenes, por ejemplo Azure OpenAI, si tu organización ya lo tiene aprobado.

Importante: este artículo no asume una CLI pública específica llamada gh aw, ni un archivo estándar agentic.yaml, ni comandos de Copilot inexistentes o no documentados. Si en el workshop se utiliza una capacidad concreta de GitHub Agentic Workflows, la idea aquí es mostrar el patrón de implementación de forma portable y verificable.

Qué significa “squad de agentes” en este contexto

Antes de escribir YAML o workflows, necesitamos una definición operativa.

Un agente, para este caso, es una unidad de trabajo con:

Rol: qué responsabilidad tiene.
Contexto: qué información puede leer.
Entrada: qué datos necesita para actuar.
Salida: qué artefacto debe producir.
Guardrails: qué límites no puede cruzar.
Punto de revisión: cuándo una persona debe validar el resultado.

Aplicado al Kitten Agent Blog, el diseño puede quedar así:

Agente	Rol	Entrada principal	Salida esperada	Revisión recomendada
Astro	Arquitectura editorial	Tema, audiencia, objetivos	Brief, estructura y checklist	Sí
Whiskers	Redacción	Brief aprobado	Borrador Markdown	Sí
Luna	Imagen y assets	Brief visual	Prompt de imagen y asset generado o seleccionado	Sí
Rocket	Publicación	Contenido aprobado	Build y despliegue en GitHub Pages	Automática + revisión de logs

La clave es no mezclar responsabilidades. Si Whiskers escribe, no despliega. Si Rocket despliega, no reescribe contenido. Esa separación permite auditar el flujo y reducir errores.

Requisitos previos

Para implementar el patrón necesitas:

Un repositorio de GitHub para el blog.
GitHub Actions habilitado.
GitHub Pages configurado para el repositorio.
Un generador estático compatible con tu blog, por ejemplo Jekyll si usas GitHub Pages con estructura _posts.
Python, Node.js u otro runtime para tus scripts de apoyo, según tu stack.
Acceso a un proveedor de IA generativa si quieres automatizar redacción o generación visual.
Una política clara de revisión humana antes de publicar contenido generado.

Si vas a usar Azure OpenAI, configura las credenciales como secrets del repositorio y sigue la documentación oficial de tu tenant, región, modelo desplegado y versión de API aprobada. No incrustes claves en el código ni en archivos Markdown.

Arquitectura propuesta

Una estructura sencilla del repositorio podría ser:

.
├── _posts/
│   └── 2026-02-27-ejemplo.md
├── assets/
│   └── images/
├── .github/
│   └── workflows/
│       ├── agent-squad.yml
│       └── pages.yml
├── agents/
│   ├── astro.md
│   ├── whiskers.md
│   ├── luna.md
│   └── rocket.md
├── tasks/
│   └── brief.yml
├── scripts/
│   ├── astro_plan.py
│   ├── whiskers_draft.py
│   ├── luna_prompt.py
│   └── validate_post.py
└── README.md

La carpeta agents/ no representa un estándar de producto. Es simplemente una convención del repositorio para guardar instrucciones y contratos de cada agente.

Definir los agentes como contratos

En lugar de empezar por la automatización, conviene empezar por las instrucciones.

Astro: agente arquitecto

Archivo agents/astro.md:

# Astro Architect Agent

## Responsabilidad

Diseñar la estructura editorial del artículo antes de escribirlo.

## Debe producir

- Título propuesto.
- Audiencia objetivo.
- Objetivo técnico del artículo.
- Estructura H2/H3.
- Riesgos factuales.
- Lista de validaciones antes de redactar.

## No debe hacer

- Inventar APIs, comandos o capacidades.
- Escribir el artículo completo.
- Añadir fuentes no verificadas.
- Modificar fechas de publicación o metadatos temporales.

Whiskers: agente redactor

Archivo agents/whiskers.md:

# Whiskers Writer Agent

## Responsabilidad

Redactar el artículo en Markdown a partir del brief aprobado.

## Debe producir

- Artículo completo.
- Front matter válido si aplica.
- Explicaciones claras para audiencia técnica.
- Advertencias cuando una capacidad dependa del entorno del lector.

## No debe hacer

- Publicar cambios.
- Cambiar rutas de imágenes sin instrucción explícita.
- Incluir comandos no verificados.
- Presentar una integración experimental como si fuera estable.

Luna: agente visual

Archivo agents/luna.md:

# Luna Image Agent

## Responsabilidad

Proponer o generar recursos visuales para el artículo.

## Debe producir

- Prompt visual.
- Descripción accesible para `alt`.
- Nombre de archivo sugerido.
- Restricciones de formato, tamaño y estilo.

## No debe hacer

- Sobrescribir assets existentes sin aprobación.
- Usar imágenes sin derechos claros.
- Publicar imágenes sin revisión humana.

Rocket: agente publicador

Archivo agents/rocket.md:

# Rocket Publisher Agent

## Responsabilidad

Construir, validar y desplegar el blog.

## Debe producir

- Build reproducible.
- Logs de validación.
- Despliegue solo desde contenido aprobado.

## No debe hacer

- Reescribir artículos.
- Saltarse tests.
- Desplegar si fallan validaciones.

Definir una tarea de contenido

Un squad necesita una tarea común. Podemos representarla como YAML.

Archivo tasks/brief.yml:

title: "Cómo implementar un squad de agentes autónomos al estilo Kitten Agent Blog"
audience:
  - arquitectos de software
  - developers
  - responsables técnicos
goal: "Explicar un patrón práctico para coordinar agentes de IA en la creación y publicación de un blog técnico."
constraints:
  - "No inventar APIs ni comandos."
  - "Separar planificación, redacción, assets y publicación."
  - "Incluir revisión humana antes del despliegue."
output:
  format: "markdown"
  target_folder: "_posts"

Este archivo es deliberadamente simple. La ventaja es que cualquier script, workflow o herramienta agentic puede consumirlo sin depender de una plataforma concreta.

Implementar Astro: planificación editorial

Astro no necesita publicar nada. Su misión es transformar el brief en un plan revisable.

Un script mínimo podría leer tasks/brief.yml y generar un plan base. Si usas un modelo de lenguaje, el punto correcto para integrarlo es una función adaptadora, no el workflow completo.

Archivo scripts/astro_plan.py:

from pathlib import Path
import yaml

BRIEF_PATH = Path("tasks/brief.yml")
AGENT_PATH = Path("agents/astro.md")
OUTPUT_PATH = Path("artifacts/astro-plan.md")


def main():
    brief = yaml.safe_load(BRIEF_PATH.read_text(encoding="utf-8"))
    agent_instructions = AGENT_PATH.read_text(encoding="utf-8")

    OUTPUT_PATH.parent.mkdir(parents=True, exist_ok=True)

    plan = f"""# Plan editorial de Astro

## Instrucciones del agente

{agent_instructions}

## Brief

- Título: {brief["title"]}
- Objetivo: {brief["goal"]}
- Formato: {brief["output"]["format"]}
- Carpeta destino: {brief["output"]["target_folder"]}

## Estructura propuesta

1. Introducción y contexto.
2. Definición práctica de squad de agentes.
3. Arquitectura del repositorio.
4. Contratos de agentes.
5. Orquestación con GitHub Actions.
6. Validaciones y guardrails.
7. Publicación con GitHub Pages.
8. Conclusión.

## Riesgos factuales

- No asumir comandos de GitHub Copilot que no estén documentados.
- No asumir una configuración estándar para Agentic Workflows si no está disponible públicamente.
- No incrustar credenciales de proveedores de IA.
- No publicar contenido generado sin revisión.

## Checklist para Whiskers

- Mantener tono técnico y divulgativo.
- Explicar límites y supuestos.
- Evitar marketing excesivo.
- Usar Markdown válido.
"""

    OUTPUT_PATH.write_text(plan, encoding="utf-8")
    print(f"Plan generado en {OUTPUT_PATH}")


if __name__ == "__main__":
    main()

Este ejemplo no llama a ningún proveedor de IA. Es intencionado: primero construimos un pipeline reproducible. Después podemos sustituir o ampliar partes concretas con llamadas a modelos aprobados.

Implementar Whiskers: redacción asistida

Whiskers toma el plan de Astro y genera un borrador. En una implementación real, aquí puedes usar:

Redacción manual asistida por GitHub Copilot en el editor.
Un script interno conectado a un modelo aprobado.
Un workflow agentic disponible en tu organización.
Una combinación de generación automática y revisión editorial.

Lo importante es que Whiskers produzca un borrador, no que lo publique.

Archivo scripts/whiskers_draft.py:

from pathlib import Path
from datetime import date

PLAN_PATH = Path("artifacts/astro-plan.md")
OUTPUT_DIR = Path("_drafts")


def slugify(text: str) -> str:
    return (
        text.lower()
        .replace("á", "a")
        .replace("é", "e")
        .replace("í", "i")
        .replace("ó", "o")
        .replace("ú", "u")
        .replace("ñ", "n")
        .replace(" ", "-")
    )


def main():
    plan = PLAN_PATH.read_text(encoding="utf-8")
    title = "Cómo implementar un squad de agentes autónomos al estilo Kitten Agent Blog"
    slug = slugify(title)
    output_path = OUTPUT_DIR / f"{date.today().isoformat()}-{slug}.md"

    OUTPUT_DIR.mkdir(parents=True, exist_ok=True)

    draft = f"""---
layout: post
title: "{title}"
description: "Borrador generado para revisión editorial."
categories: ["Blog", "Copilot", "GenAI", "AI/ML"]
tags: ["AgentCamp 2026", "GitHub Copilot"]
---

# Borrador generado por Whiskers

> Este borrador requiere revisión humana antes de ser publicado.

## Plan utilizado

{plan}

## Contenido pendiente

Desarrollar el artículo a partir del plan aprobado.
"""

    output_path.write_text(draft, encoding="utf-8")
    print(f"Borrador generado en {output_path}")


if __name__ == "__main__":
    main()

En producción, este script puede enriquecerse para llamar a un modelo de lenguaje. Si lo haces, mantén estas reglas:

Usa variables de entorno o secrets para credenciales.
Registra qué prompt se ha usado.
Guarda la salida como borrador.
Exige revisión humana antes de mover el archivo a _posts.
No permitas que el agente modifique metadatos sensibles sin autorización.

Implementar Luna: prompts visuales y assets

Luna no tiene por qué generar imágenes directamente en el primer paso. Puede producir un prompt visual, una descripción accesible y una propuesta de ubicación del asset.

Archivo scripts/luna_prompt.py:

from pathlib import Path
import yaml

BRIEF_PATH = Path("tasks/brief.yml")
OUTPUT_PATH = Path("artifacts/luna-image-brief.md")


def main():
    brief = yaml.safe_load(BRIEF_PATH.read_text(encoding="utf-8"))

    OUTPUT_PATH.parent.mkdir(parents=True, exist_ok=True)

    image_brief = f"""# Brief visual de Luna

## Artículo

{brief["title"]}

## Prompt visual sugerido

Ilustración editorial de cuatro agentes de IA colaborando en la creación de un blog técnico:
un agente diseña la arquitectura, otro redacta contenido, otro prepara imágenes y otro supervisa el despliegue.
Estilo profesional, limpio, tecnológico y amable. Sin logotipos no autorizados.

## Alt text sugerido

Ilustración de varios agentes autónomos colaborando para crear y publicar un blog técnico.

## Reglas

- No sobrescribir imágenes existentes.
- Validar derechos de uso.
- Optimizar peso y dimensiones antes de publicar.
- Revisar manualmente el resultado antes de incluirlo en el post.
"""

    OUTPUT_PATH.write_text(image_brief, encoding="utf-8")
    print(f"Brief visual generado en {OUTPUT_PATH}")


if __name__ == "__main__":
    main()

Si conectas este paso con un servicio de generación de imágenes, asegúrate de:

Usar el servicio autorizado por tu organización.
Guardar el prompt y el resultado para trazabilidad.
Revisar posibles problemas de marcas, personas reales o contenido sensible.
Generar texto alternativo útil para accesibilidad.

Implementar Rocket: validación y publicación

Rocket debe ser el agente más conservador. Su trabajo es construir y desplegar, no reinterpretar el contenido.

Para un sitio publicado con GitHub Pages, puedes separar dos workflows:

Un workflow de squad que genera artefactos y borradores.
Un workflow de Pages que publica solo cuando hay cambios aprobados en la rama principal.

Workflow del squad

Archivo .github/workflows/agent-squad.yml:

name: Agent Squad

on:
  workflow_dispatch:

permissions:
  contents: read

concurrency:
  group: agent-squad
  cancel-in-progress: false

jobs:
  plan-and-draft:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pyyaml

      - name: Astro plan
        run: python scripts/astro_plan.py

      - name: Whiskers draft
        run: python scripts/whiskers_draft.py

      - name: Luna image brief
        run: python scripts/luna_prompt.py

      - name: Upload generated artifacts
        uses: actions/upload-artifact@v4
        with:
          name: agent-squad-artifacts
          path: |
            artifacts/
            _drafts/

Este workflow no escribe en la rama principal. Produce artefactos descargables para revisión. Es menos espectacular que un despliegue totalmente automático, pero mucho más seguro para un blog técnico.

Workflow de publicación con GitHub Pages

Archivo .github/workflows/pages.yml:

name: Deploy GitHub Pages

on:
  push:
    branches:
      - main

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: github-pages
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure Pages
        uses: actions/configure-pages@v5

      - name: Build with Jekyll
        uses: actions/jekyll-build-pages@v1
        with:
          source: .
          destination: ./_site

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./_site

  deploy:
    environment:
      name: github-pages
      url: $

    runs-on: ubuntu-latest
    needs: build

    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

En este diseño, Rocket despliega únicamente lo que ya ha llegado a main. El control de calidad ocurre antes, mediante revisión de pull request, validaciones y ownership del repositorio.

Añadir validaciones antes de publicar

Un squad de agentes necesita límites técnicos. Algunas validaciones recomendables:

El front matter debe ser YAML válido.
Las fechas no deben modificarse salvo instrucción explícita.
Las rutas de imágenes deben existir.
No debe haber secretos en el contenido.
No deben aparecer comandos inventados.
Los enlaces deben tener formato válido.
Los artículos generados deben pasar revisión humana.

Un script simple de validación puede comprobar parte de estas reglas.

Archivo scripts/validate_post.py:

from pathlib import Path
import re
import sys

POSTS_DIR = Path("_posts")
SECRET_PATTERNS = [
    re.compile(r"api[_-]?key\s*=", re.IGNORECASE),
    re.compile(r"secret\s*=", re.IGNORECASE),
    re.compile(r"password\s*=", re.IGNORECASE),
]


def validate_file(path: Path) -> list[str]:
    errors = []
    text = path.read_text(encoding="utf-8")

    if not text.startswith("---"):
        errors.append("No empieza con front matter YAML.")

    for pattern in SECRET_PATTERNS:
        if pattern.search(text):
            errors.append("Posible secreto encontrado en el contenido.")

    if "copilot-cli" in text:
        errors.append("Referencia a 'copilot-cli' detectada. Verifica que sea una herramienta oficial y disponible antes de publicar.")

    if "gh aw" in text:
        errors.append("Referencia a 'gh aw' detectada. Verifica disponibilidad oficial antes de publicar.")

    return errors


def main():
    failed = False

    for path in POSTS_DIR.glob("*.md"):
        errors = validate_file(path)
        if errors:
            failed = True
            print(f"\nErrores en {path}:")
            for error in errors:
                print(f"- {error}")

    if failed:
        sys.exit(1)

    print("Validación completada sin errores críticos.")


if __name__ == "__main__":
    main()

Puedes añadir este script al workflow de publicación antes del build:

      - name: Validate posts
        run: python scripts/validate_post.py

Guardrails organizativos

Además de los controles técnicos, conviene añadir controles de proceso.

1. Pull requests obligatorias

No permitas que el flujo generado por agentes publique directamente en main. Lo recomendable es:

Generar borradores.
Abrir una pull request.
Revisar contenido, fuentes, imágenes y metadatos.
Aprobar.
Fusionar.
Desplegar.

2. CODEOWNERS

Puedes usar CODEOWNERS para exigir revisión de áreas sensibles:

_posts/ @equipo-editorial
assets/images/ @equipo-diseno
.github/workflows/ @equipo-plataforma

3. Permisos mínimos

Configura los workflows con los permisos mínimos necesarios. Por ejemplo, el workflow de generación puede tener solo lectura de contenidos si no necesita escribir cambios.

permissions:
  contents: read

El workflow de Pages, en cambio, necesita permisos específicos para desplegar:

permissions:
  contents: read
  pages: write
  id-token: write

4. Separación entre generación y publicación

No mezcles generación de contenido con despliegue. Es mejor tener dos fases:

Fase creativa: genera plan, borrador e imagen.
Fase de publicación: valida, compila y despliega.

Esa separación facilita auditoría, rollback y revisión.

Dónde encajan GitHub Copilot y Agentic Workflows

GitHub Copilot puede aportar valor en varias partes del proceso:

Ayudando a escribir scripts.
Revisando workflows.
Proponiendo tests.
Refactorizando prompts o validadores.
Asistiendo a Whiskers en la redacción del borrador.

Si tu organización tiene acceso a capacidades agentic integradas en GitHub, puedes mapear los roles del squad a esas capacidades. La idea importante es mantener el mismo contrato:

Astro planifica.
Whiskers redacta.
Luna prepara assets.
Rocket despliega.
Las personas revisan y aprueban.

No bases tu arquitectura en comandos o archivos de configuración que no estén disponibles en tu entorno. Si una capacidad está en beta o limitada a un programa concreto, trátala como una dependencia opcional y documenta el fallback.

Patrón recomendado de ejecución

Un flujo profesional podría ser:

Crear o actualizar tasks/brief.yml.
Lanzar manualmente el workflow Agent Squad.
Descargar los artefactos generados.
Revisar el plan de Astro.
Completar o ajustar el borrador de Whiskers.
Revisar el brief visual de Luna y generar o seleccionar la imagen.
Crear una pull request con el artículo y los assets.
Ejecutar validaciones.
Aprobar la pull request.
Fusionar en main.
Dejar que Rocket publique mediante GitHub Pages.

Este enfoque conserva la narrativa de agentes autónomos, pero introduce los controles necesarios para publicar contenido técnico fiable.

Errores habituales

Tratar los agentes como si fueran infalibles

Los agentes pueden ayudar, pero no sustituyen la revisión técnica. Si el artículo menciona APIs, SDKs, límites de servicio o comandos, debe validarse con documentación oficial o evidencia verificable.

Dar permisos de escritura demasiado pronto

Un agente que puede escribir en main, modificar workflows y desplegar producción concentra demasiado riesgo. Empieza con artefactos y pull requests.

Mezclar generación de imágenes con publicación automática

Las imágenes generadas también requieren revisión. Pueden tener problemas de estilo, licencias, accesibilidad o coherencia con la marca.

No guardar prompts ni contexto

Si no guardas el brief, el prompt y el resultado, será difícil explicar por qué el agente produjo una salida determinada.

Automatizar antes de definir el contrato

Primero define qué debe hacer cada agente. Después automatiza.

Conclusión

Implementar un squad de agentes al estilo Kitten Agent Blog es una buena forma de aprender a combinar IA generativa, automatización y publicación continua. La clave no está en delegarlo todo a una herramienta concreta, sino en diseñar un flujo con responsabilidades claras:

Astro estructura.
Whiskers redacta.
Luna prepara la parte visual.
Rocket valida y despliega.

Con GitHub Actions, GitHub Pages, Copilot y un proveedor de IA aprobado por tu organización, puedes construir una experiencia muy cercana a un equipo de agentes colaborando. Pero para que sea publicable en un entorno real, el squad necesita guardrails: permisos mínimos, revisión humana, validaciones automáticas y trazabilidad de los cambios.

La autonomía útil no es ausencia de control. Es automatización bien delimitada.