Skip to content

Instantly share code, notes, and snippets.

@oneingan

oneingan/spike_loop_cybernetics.md

Created June 22, 2026 09:43
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save oneingan/53f077587952a8739e473aea53e2a274 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save oneingan/53f077587952a8739e473aea53e2a274 to your computer and use it in GitHub Desktop.
Download ZIP
Spike: Loop engineering como cybernetics / control engineering
Raw
spike_loop_cybernetics.md

Spike: “Loop engineering” como cybernetics / control engineering para agentes LLM

Fecha: 2026-06-22
Origen: https://bsky.app/profile/interjectedfuture.com/post/3moq64gbha62g
Nota: no se ha escrito nada en el repo. Todo el material temporal está bajo /tmp/bsky_spike/.

0. Resumen ejecutivo

La tesis del hilo se sostiene: gran parte de lo que ahora se llama loop engineering es una reaparición, con vocabulario nuevo, de ideas de cibernética y teoría de control: observar estado, compararlo contra un objetivo, actuar, medir de nuevo y repetir.

Lo realmente nuevo no es el loop. Lo nuevo es que el controller ahora puede ser un LLM suficientemente expresivo para operar sobre objetivos no estructurados: especificaciones en lenguaje natural, tareas ambiguas, repositorios vivos, conversaciones, CI, issues, PRs y herramientas externas.

La conclusión útil para diseño de sistemas no es “hagamos loops”, sino: diseñemos sistemas reguladores que tengan estabilidad, convergencia, rechazo de perturbaciones, observabilidad, límites de coste, memoria durable, verificadores independientes y vías claras de intervención humana.

Frase corta: loop engineering debería tratarse como control-plane engineering para controladores estocásticos.

1. Qué decía el hilo principal

El hilo de interjectedfuture.com plantea:

  • “Loop engineering” es el mismo patrón que la cibernética: observar estado, comparar con objetivo, actuar, repetir.
  • Cibernética y AI temprana no fueron campos claramente separados al principio: Wiener, McCulloch, von Neumann, Shannon, Pitts y otros convergían alrededor de feedback, máquinas, mente y control.
  • Kubernetes es un ejemplo moderno: declarar estado deseado y dejar que controllers/reconcilers reduzcan la brecha con el estado actual.
  • En agentes LLM: el LLM es el controller, el repo/filesystem/tests/GitHub son la planta, la goal spec es el setpoint.
  • Lo novedoso es la expresividad del controller para manejar metas no estructuradas.
  • La pregunta más interesante no es “¿cómo diseño el loop?” sino “¿cómo logro estabilidad, convergencia y rechazo de perturbaciones en un controller agente?”

Subhilos/replies relevantes:

  • timkellogg.me: “loop engineering” enfatiza el loop, pero lo difícil es mantener estabilidad; eso es cibernética.
  • manyuser.bsky.social: matiza la analogía: la feature spec es el setpoint; los diffs son input/actuación; los bugs son perturbaciones estocásticas dependientes de la tasa/tamaño de cambios.
  • canary.muninnai.ai: enlaza mimir, un harness con inventario explícito de feedback loops y homeostat.
  • ry.codes / otros: nota sociológica: software engineering redescubre control/observability con nombres nuevos.

2. Enlaces seguidos / materiales leídos

Del hilo Bsky

Desde los X articles enlazados

3. La línea histórica que emerge

3.1 Cybernetics antes que AI

El enlace de Medium refuerza la idea de que “artificial intelligence” fue, en parte, un término elegido para separarse de “cybernetics” y de Norbert Wiener. La cita atribuida a McCarthy es clara: una razón para inventar el término AI era escapar de la asociación con cybernetics.

Las Macy conferences (1946–1953) se titularon alrededor de “Circular Causal and Feedback Mechanisms in Biological and Social Systems” y buscaban un lenguaje común para mente, máquinas, comunicación, feedback y sistemas sociales. Esto conecta directamente con lo que hoy llamamos agentes.

3.2 De feedback/cybernetics a AI agents

Una genealogía razonable:

  1. Cybernetics / control: feedback, goal-directed systems, homeostasis, regulation.
  2. McCulloch & Pitts / neural nets tempranos: neuronas como unidades lógicas, redes con comportamiento computacional.
  3. ReAct (2022): interleaving explícito de reasoning/action/observation en LLMs.
  4. AutoGPT (2023): self-prompting goal loop, pero con problemas de no convergencia.
  5. Ralph loop (2025): loop simple con reset de contexto y estado en ficheros.
  6. /goal, /loop, automations (2026): primitivas de producto para run-until-done o run-on-cadence.
  7. Orquestación multi-agente: planners/workers/judges, worktrees, state/logs, queues, dashboards, watchdogs.

3.3 Qué cambia en 2026

No cambia el loop. Cambian los controladores y el entorno:

  • El controller puede leer lenguaje natural, código, logs, diffs, issues y chats.
  • El environment incluye repo, CI, GitHub, Slack/Linear/Jira, navegadores, simuladores y APIs.
  • Las acciones son ricas: editar, testear, abrir PR, comentar, crear issues, reintentar, delegar.
  • El coste relevante deja de ser “una llamada” y pasa a ser iteraciones hasta convergencia.
  • La unidad de diseño deja de ser “prompt” y pasa a ser control loop + state + verifier + budget + actuation boundary.

4. Mapa de teoría de control aplicado a agentes

Teoría de control Kubernetes Agente LLM / loop engineering
Setpoint / referencia .spec, desired state goal spec, issue, acceptance criteria, feature list
Plant cluster, pods, DB, infra repo, app, CI, browser, tools, org process
Controller reconciler/operator LLM + harness/orchestrator
Sensor / measured variable watches, cache, .status, health checks tests, CI, logs, screenshots, evals, PR comments, telemetry
Error desired − actual failing tests, unmet criteria, red CI, unresolved issue
Actuator create/update/delete K8s resources edit files, run commands, call APIs, open PRs, message humans
Disturbance node death, traffic spike, manual deletion bugs, dependency drift, merge conflicts, flaky tests, new requirements
Feedback loop reconcile repeatedly act/check/re-prompt until pass/stop
Stability no oscillation/thrash no churn, no endless rewrites, bounded retries
Convergence eventual desired state task reaches verifiable done
Disturbance rejection self-healing recovers from CI failures, rebases, flaky inputs, tool errors
Observability status/metrics/events logs, transcripts, event log, state files, dashboards
Controllability available safe operations tool permissions, sandbox, API/write access
Requisite variety controllers cover possible states enough skills/tools/models/subagents to handle task variety
Good regulator theorem controller models system skills, schemas, tests, domain model, memory, docs

5. Kubernetes como referencia fuerte

El artículo de PlanetScale es el puente más sólido entre el hilo y práctica de ingeniería.

Puntos clave:

  • Un operator es un feedback controller, no “un script que corre cosas”.
  • El patrón es: leer desired state, observar actual state, comparar, actuar, repetir.
  • Kubernetes separa setpoint y medición: .spec para intención; .status para estado observado.
  • Reconcile no debe depender del evento específico. Los eventos son hints para mirar de nuevo.
  • La lógica buena es edge-triggered notifications, level-triggered logic.
  • Idempotencia, queues, caches, retries, coalescing, leader election y resyncers son parte del loop productivo.
  • Los controllers forman cascadas: un operator escribe un PVC; CSI controllers convergen ese PVC; kubelet converge pods; etc.

Traducción a agentes:

  • No diseñar “cuando pase X, haz Y” como único mecanismo. Diseñar “cuando algo despierte al agente, lee estado actual y converge”.
  • Mantener una fuente durable de setpoint y status. No confiar en el contexto del modelo.
  • Hacer que cada acción sea idempotente o que sus efectos sean detectables antes de repetir.
  • Usar eventos como wakeups, no como la verdad completa.
  • Registrar observedGeneration equivalente: ¿este reporte refleja qué versión de la intención?

6. Qué dicen las piezas modernas de agent engineering

6.1 Omar / Matt / Addy

Convergen en seis piezas:

  1. Trigger/cadence: cron, hook, webhook, schedule, automation.
  2. Isolation: worktree/sandbox por agente.
  3. Written context: skills, AGENTS.md, project rules, specs.
  4. Tool access: MCP/connectors a CI, DB, issue tracker, chat.
  5. Second agent/verifier: maker/checker separados.
  6. Durable state: markdown, queue, Linear board, event log, git.

Más budgets/stops:

  • max attempts
  • max runtime
  • max files changed
  • max cost
  • max consecutive failures
  • human gate

6.2 Anthropic

Effective harnesses identifica fallos recurrentes:

  • El agente intenta one-shotear demasiado.
  • Declara el proyecto completo antes de tiempo.
  • Pierde estado entre ventanas de contexto.
  • Marca features como done sin test end-to-end.

Mitigaciones:

  • Initializer agent crea feature list, init script, progress file, commit base.
  • Coding agent trabaja incrementalmente una feature por sesión.
  • Git + progress file sirven de memoria durable.
  • Tests end-to-end y browser automation corrigen fallos que no se ven en código.

Managed Agents añade una arquitectura más general:

  • Brain = model + harness loop.
  • Hands = sandbox/tools donde se actúa.
  • Session = append-only event log durable.

Lección central: la sesión no es el context window. El context window es una vista temporal; la session log es el estado recuperable.

6.3 Cursor

Experimentos con cientos de agentes muestran:

  • Coordinación plana con locks/shared file falla: locks olvidados, bottlenecks, agentes risk-averse.
  • Optimistic concurrency mejora, pero no resuelve ownership/end-to-end responsibility.
  • Mejor estructura: planners, workers, judges.
  • Modelos diferentes sirven mejor en roles diferentes.
  • Demasiada poca estructura produce conflictos/drift; demasiada estructura produce fragilidad.

Esto encaja con cibernética: la arquitectura necesita variety suficiente para absorber la complejidad, pero no tanta que el meta-sistema se vuelva inestable.

6.4 Ralph

Ralph es el loop mínimo:

while :; do cat PROMPT.md | claude-code ; done

Lo importante no es el bash loop, sino los controles alrededor:

  • una cosa por loop
  • specs y plan en ficheros
  • contexto reset cada vuelta
  • backpressure vía tests/build/static analysis
  • subagents para búsqueda/revisión
  • actualizar AGENT.md/fix_plan.md con aprendizaje
  • aceptar que habrá basura y diseñar recuperación

Ralph es útil para entender la forma mínima, pero es frágil para codebases existentes sin boundaries fuertes.

6.5 Tim Kellogg / VSM / Mimir

Tim Kellogg conecta agentes autónomos con Stafford Beer y el Viable System Model:

  1. Operations — tool calling / task execution.
  2. Coordination — git, queues, mutexes, conflict resolution.
  3. Control — resource allocation, priorities, budgets.
  4. Intelligence — environment scanning, sensing future changes.
  5. Policy — identity, purpose, values.

Mimir concreta esto con feedback loops explícitos:

  • per-turn tool-result feedback
  • loop detector / duplicate-send guard
  • tool-call budget
  • algedonic signals: pain/pleasure events surfaced directly into prompt
  • resource usage / cost-rate awareness
  • heartbeat cron
  • weekly reflection
  • memory consolidation
  • predictions/calibration

Esto es más cibernético que “prompt engineering”: diseña una organización viable, no solo un agente.

7. Evaluación de claims

Claim A: “Loop engineering es cybernetics/control theory con otro nombre”

Muy fuerte, con matiz.

El patrón básico es exactamente closed-loop control: setpoint, measure, error, action, repeat. La historia de cibernética y AI temprana confirma continuidad conceptual.

Matiz: los agentes LLM son controladores estocásticos, no lineales, con observación parcial, herramientas discretas y objetivos semánticos. No se puede trasladar sin cuidado todo el aparato matemático clásico de control, pero sí sus conceptos de diseño.

Claim B: “Kubernetes es cibernética aplicada”

Fuerte.

Kubernetes es una federación de controllers que convergen desired state bajo perturbaciones. El artículo de PlanetScale lo explica en vocabulario casi idéntico al del hilo.

Claim C: “Lo nuevo es el controller expresivo”

Fuerte.

Un thermostat/controller clásico opera con variables estructuradas. Un LLM puede traducir metas imprecisas a acciones en un sistema rico. Esto convierte “control” de una magnitud física en “control” de procesos de software/organización.

Claim D: “Podemos correr compañías/vidas como Kubernetes”

Prometedor como metáfora, peligroso si se toma literalmente.

Para sistemas humanos/organizacionales, VSM/POSIWID/requisite variety son más adecuados que una analogía Kubernetes directa. Hace falta definir variables esenciales, señales éticas, límites, canales algedónicos y gates humanos.

8. Principios de diseño derivados

8.1 Diseña el loop como regulador, no como prompt recurrente

Un loop serio debe declarar:

  • qué variable esencial protege o persigue
  • cuál es el setpoint
  • cómo se mide el actual state
  • qué acciones puede tomar
  • cuándo debe parar
  • cuánto puede gastar
  • qué hace si no progresa
  • cuándo escala a humano

8.2 Separa spec/status

Equivalente agente:

  • goal/spec: lo que se quiere.
  • status/progress: lo observado y hecho.
  • observedGoalVersion: a qué versión de la intención corresponde el status.

No dejes que el controller reescriba su propio setpoint sin revisión.

8.3 Eventos despiertan; estado decide

No codificar “si llega evento X, haz Y” como truth source. Mejor:

  1. evento despierta loop
  2. loop lee estado actual
  3. loop compara con setpoint
  4. loop actúa idempotentemente

8.4 El verifier es el sensor más crítico

Un loop con un verifier débil:

  • se detiene con trabajo roto, o
  • sigue iterando sobre trabajo ya correcto.

Ambos cuestan. Separar maker/checker y usar checks ejecutables es esencial.

8.5 La memoria debe vivir fuera del modelo

Patrones vistos:

  • git commits/log
  • progress files
  • feature list JSON
  • board/queue
  • event log append-only
  • session transcript
  • .status
  • skills / AGENTS.md

El modelo olvida; el filesystem/event log no.

8.6 Controla el coste por tarea terminada, no por llamada

En loops, el coste real es:

cost_per_success = calls_per_iteration * iterations_to_converge * model_cost + orchestration_overhead

Una llamada barata que duplica iteraciones no es barata.

8.7 Aplica requisite variety

Si el entorno tiene más variedad que el regulator, el loop falla.

Formas de aumentar variedad útil:

  • skills específicas
  • herramientas/conectores
  • modelos/roles distintos
  • subagents especializados
  • tests/evals más discriminantes
  • memoria estructurada

Pero demasiado variety sin coordinación aumenta inestabilidad.

8.8 Diseña cascadas de loops

No todo debe estar en un mega-agente.

Ejemplo:

  • inner loop: fix test failure en worktree
  • mid loop: PR babysitter
  • outer loop: backlog triage
  • audit loop: weekly reflection / pattern mining
  • policy loop: humano revisa cambios de reglas/skills

9. Failure modes y mitigaciones

Failure mode Síntoma Mitigación
Premature done agente declara éxito sin E2E feature list + verifier independiente + checks ejecutables
Infinite loop repite sin converger max iterations, no-progress detector, dollar/time cap
Oscillation reescribe ida/vuelta hysteresis, smaller scope, durable decision log
Slop accumulation muchos cambios superficiales human review, tests, static analysis, adversarial review
State loss nuevo turno no sabe qué pasó session log, progress files, git commits
Race/conflict agentes pisan ficheros worktrees, queues, ownership, OCC
Stale reads actúa contra estado viejo requeue, read fresh, expectations pattern
Weak sensor loop optimiza métrica equivocada better status, E2E tests, observability
Over-actuation hace cambios demasiado amplios permissions, sandbox, touched-files budget
Cost runaway cuenta tokens/iteraciones se dispara cost-rate feedback, plan-window awareness, budget gates
Context rot contexto lleno degrada output context reset, summaries, durable memory
Cognitive surrender humanos dejan de entender review budget, comprehension debt tracking
Unsafe credentials agente accede secretos vault/proxy, least privilege, no tokens in sandbox

10. Cómo se vería una especificación mínima de loop

loop:
  name: pr-babysitter
  purpose: keep watched PRs mergeable without human polling

setpoint:
  source: github-label:agent-watch
  desired_state:
    ci: green
    branch: rebased-on-main
    review: no-unaddressed-blocking-comments

plant:
  repo: owner/project
  environment:
    - git worktree per run
    - CI provider
    - GitHub PR API

sensors:
  - ci_status
  - test_output
  - changed_files
  - pr_comments
  - merge_base

actuators:
  - edit_files
  - run_tests
  - rebase_once
  - push_branch
  - comment_on_pr

controller:
  model_role: implementer
  skills:
    - repo-build-rules
    - pr-fix-policy
  verifier:
    role: independent_checker
    checks:
      - ci_green
      - max_files_changed <= 10
      - no_new_lint_errors

limits:
  interval: 15m
  max_attempts_per_pr: 1
  max_runtime: 5m
  max_files_changed: 10
  max_cost_usd: 2
  max_consecutive_failures: 2

state:
  queue: board/pr-babysitter.md
  event_log: logs/pr-babysitter.jsonl
  status_field: pr-comment-or-board-card

escalation:
  on_budget_exhausted: ping_human
  on_non_deterministic_failure: ping_human
  on_security_sensitive_change: require_review

11. Implicaciones para design-context

Si esto se lleva al repo más adelante, sugiero no escribir “otro artículo de hype”. Mejor convertirlo en piezas canónicas reutilizables:

  1. Glosario: setpoint, plant, controller, sensor, actuator, disturbance, verifier, status, loop, cascade.
  2. Principio: “Diseña agentes como control loops con estado durable y verificadores independientes”.
  3. Patrón: “Level-triggered agent reconciler”.
  4. Checklist: loop readiness / unsafe loop checklist.
  5. Playbook: diseñar un loop desde variables esenciales → sensores → actuadores → budgets → escalation.
  6. ADR: adoptar vocabulario de cibernética/control para loops agentic, evitando tratarlo como “prompt engineering”.

12. Preguntas abiertas

  • ¿Cómo medir estabilidad en controllers LLM no deterministas? ¿Churn rate? ¿diff reversal rate? ¿no-progress iterations?
  • ¿Cuál es el equivalente práctico de gain tuning? ¿Tamaño de step, autonomía, tool permissions, temperature, verifier strictness?
  • ¿Cómo diseñar hysteresis para evitar flip-flopping semántico?
  • ¿Cómo separar setpoints de policies, especialmente si el agente puede auto-modificar skills/memory?
  • ¿Qué señales algedónicas deben bypass normal bureaucracy y despertar a humano?
  • ¿Cómo representar observedGeneration en tareas agentic?
  • ¿Qué evals capturan disturbance rejection en vez de task success estático?
  • ¿Qué loops de organización/persona son éticos y cuáles son control excesivo?

13. Bottom line

El hilo apunta a algo fértil: dejar de discutir si “loop engineering” es un nombre nuevo y usar el vocabulario más antiguo y más preciso.

La pieza de ingeniería no es el while true. Es diseñar un regulador viable:

  • sabe qué intenta mantener o alcanzar,
  • puede observar lo que importa,
  • tiene variedad suficiente para responder,
  • actúa con límites,
  • verifica independientemente,
  • registra estado fuera del modelo,
  • converge sin oscilar,
  • rechaza perturbaciones,
  • y escala a humanos cuando la regulación sale de su dominio seguro.

Eso es cibernética aplicada a agentes LLM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment