In Agent Systems Lab, four execution slots complete eight decisions by tick 60, compared with six decisions with one slot. A limit on admitted work makes the review queue much smaller, but the waiting moves upstream. Those are results of a deterministic teaching model, not measurements of a team's productivity.

The conversations I have been having about agentic systems took me back to Donella Meadows' Thinking in Systems: feedback loops, delays, bottlenecks, and what happens when a local improvement meets the rest of the system. This experiment is my way of making one of those questions concrete.

The question and the boundary

What changes when execution gets faster and review capacity stays fixed?

The model has two queues. Tasks wait for admission before execution; after execution, they can wait for review. Admitted work in progress includes tasks executing, waiting for review, or being reviewed. A decision releases a task's WIP allocation.

Admission waiting sits outside the WIP limit but inside the measurement boundary. Otherwise, limiting admission could appear to remove work simply by moving it out of view.

The reviewer here is one synthetic resource, separate from the playground's Reviewer agent. This numerical experiment does not invoke the Researcher, Builder or Reviewer agents, a model provider, or an actual human. A tick is a unit of logical time; it has no measured conversion to seconds.

Hold the workload fixed

The checked-in scenario schedules 24 tasks, arriving every two ticks, from tick 0 to tick 46. Each task takes eight execution ticks and six review ticks. There is one reviewer, and every review accepts.

I compare three policies:

• A: one execution slot, no WIP limit.
• B: four execution slots, no WIP limit.
• C: four execution slots, with at most three admitted tasks.

A to B changes execution capacity. B to C changes only the admission limit. All three use the same arrivals and service times.

Four execution slots do not produce four times the output

At tick 60, including transitions at that tick, the model reports:

Moving from A to B gives a 4× increase in execution slots and an 8/6, or 1.33×, increase in decisions over this window. Execution helps, but the fixed reviewer cannot keep up with everything arriving from it: B has 15 tasks waiting for review.

This ratio includes startup and the chosen observation window. It is not a scaling law for agents. The useful observation is the mismatch between how quickly work becomes ready and how quickly it can leave review.

A smaller review queue can hide the same amount of waiting

C completes the same eight decisions as B. Its review queue has just one task, but 13 tasks now wait for admission. Both policies still have 16 unfinished tasks.

The WIP limit has changed where work waits. It has not removed demand or added review capacity. To see whether this is just an effect of stopping at tick 60, I also follow all 24 tasks until the final decision:

Here B and C have identical per-task decision times. C keeps the reviewer supplied while admitting less work. The reduction in review waiting is balanced by waiting before admission.

These percentiles cover the same 24 tasks per policy, using nearest rank. The tick-60 comparison covers only six completed tasks for A and eight for B and C; comparing latency percentiles for those smaller completed cohorts would answer a different question.

Reproduce it

For this article I reran the scenario and compared the report with the published reference. The scenario and deterministic report hashes matched. The implementation and source links below refer to public revision 8bf1669a68a9072326d35abfb18ee979a3766531.

With Git, uv and Python 3.11 or newer available:

git clone https://github.com/saski/agent-systems-lab.git
cd agent-systems-lab
git checkout 8bf1669a68a9072326d35abfb18ee979a3766531
make setup
uv run --locked systems-lab experiment review-capacity \
  --scenario experiments/review-capacity/scenario.json

The command prints a manifest pointing to a fresh directory under .lab/experiments/review-capacity/. Inspect scenario.json, report.json and manifest.json. The expected deterministic report SHA-256 is:

a3a9c0396620438fa7c039f5aa9aace98a85cff968ba5004c52e5e25f473e58a

This command invokes no providers or agent workers. Docker is not needed for the numerical experiment. The experiment guide has the charts, metric definitions, and a saved-trace replay you can open locally. GitHub displays that HTML guide as source; it does not run the replay there.

What I would take into a real workflow

I would measure arrivals, admission waiting, execution, review waiting and accepted output together. A dashboard showing only faster execution or a shrinking review queue can miss the cost elsewhere in the system.

A WIP limit is a policy to test. In this model it bounds admitted work without slowing B's delivery timing. Whether that is useful in practice depends on costs the model does not represent: stale context, interruptions, deadlines and work that needs another pass.

The limitations are deliberate. Arrivals are finite and scheduled, tasks have uniform service times, every review accepts, and there is no randomness, rework, fatigue, failure or quality measure. This experiment cannot establish real reviewer capacity, an optimal WIP limit, agent safety, or productivity gains. It supports a narrower conclusion: when execution gets faster and review stays fixed, count where all the unfinished work goes.

The numerical model and CLI are implemented. The standalone learning guide is documentation; the integrated Experiments dashboard remains pending in the public revision used here. You can inspect the simulation and metric calculations, or read how I organise the surrounding tools in Arnesto.

Original & conversation on LinkedIn

Empezó en el Q3 de 2025 como un fork de la configuración de Eduardo Ferro Aldama. Durante bastante tiempo se llamó Augmented Code Configuration. El nombre dejó de servir cuando aquello creció más allá de las reglas de una herramienta de coding. Arnesto salió de juntar arnés con Ernesto.

La parte útil de esa evolución son las decisiones que puedo enseñar con archivos concretos. Esta es una fotografía de la versión pública del 6 de octubre de 2026.

Pocas reglas siempre presentes

Las instrucciones universales viven en .agents/rules/base.md. Ahí están los hábitos que quiero en cualquier tarea: entender el objetivo antes de tocar nada, hacer el cambio más pequeño que resuelva el problema, verificarlo y explicar lo que queda incierto.

El detalle de Python, React o Makefile se carga cuando la tarea lo necesita. Las convenciones de un repositorio pertenecen a ese repositorio. Esta separación evita que una instrucción para un proyecto acabe condicionando todos los demás.

Por ejemplo, «no digas que una comprobación ha pasado si no la has ejecutado» merece estar siempre presente. Las instrucciones de un pipeline de BigQuery sólo aportan algo cuando estoy trabajando con BigQuery.

Los skills se buscan; no se vuelcan todos al contexto

Un skill contiene un procedimiento reutilizable. Puede ayudar a revisar un Dockerfile, preparar una entrevista o trabajar con un documento. El catálogo por dominio permite encontrar los que encajan sin leer toda la biblioteca.

La regla práctica es usar primero el catálogo que ofrece el cliente activo y abrir el SKILL.md elegido. Si el cliente no tiene catálogo, se consulta la sección relevante del índice por dominio. El inventario completo sirve para mantener la biblioteca; cargarlo como prólogo de cada tarea no ayuda.

También distingo conocer un procedimiento de poder ejecutarlo. Compartir un skill entre herramientas no comparte una sesión de navegador, una credencial ni los permisos de otra herramienta.

La intención duradera vive fuera del chat

Planning e intentional compaction me ayudaron a conservar lo importante durante tareas largas; aquí debo mucho a HumanLayer y Dexter Horthy. OpenSpec añadió una estructura para conectar requisitos, decisiones, ejecución y verificación, gracias también a Alvaro Moya.

En Arnesto, docs/openspec/ contiene esas especificaciones; thoughts/ guarda investigación y planes. Cuando una tarea cambia de sesión, debería ser posible recuperar por qué se tomó una decisión sin reconstruir toda la conversación.

No todo pertenece a Arnesto. Las recetas y la evidencia de un experimento pertenecen al proyecto que lo realiza. Los logs completos y el estado temporal quedan fuera del historial publicado. Arnesto conserva los mecanismos reutilizables. Esta guía de artefactos de coordinación explica la frontera.

Compartir convenciones no implica compartir el estado de cada herramienta

Trabajo con distintas superficies: Codex, Cursor, Claude o Gemini en local; Hermes con Telegram; OpenCode y OmniRoute en algunas rutas de ejecución. También evalúo otras herramientas. El objetivo es poder cambiar piezas sin perder las convenciones que ya funcionan.

setup-symlinks.sh conecta reglas y skills con los clientes compatibles. Algunas configuraciones se inicializan desde templates/ y después se mantienen en su runtime. No son todas enlaces vivos al repositorio.

Las credenciales, sesiones, bases de datos locales y permisos siguen siendo responsabilidad de cada herramienta. En particular, Codex y Orca conservan directorios separados: contienen bastante más que una preferencia de modelo. La guía de límites entre runtimes documenta esa decisión.

Delegar exige acotar la tarea y revisar lo que vuelve

Un ejemplo concreto es el adaptador de workers. Su contrato declara el directorio de trabajo, los archivos permitidos, la sensibilidad, el modelo y la validación. Un fragmento de su estructura es:

{
  "task_class": "bounded_code",
  "sensitivity": "non_sensitive",
  "allowed_files": ["README.md"],
  "validation": {
    "command": ["make", "test"]
  },
  "require_changes": true
}

Es un fragmento explicativo, no un contrato completo para lanzar un worker. Los límites también importan: allowed_files comprueba cambios después de la ejecución; no es un sandbox de escritura. El adaptador tampoco aporta aislamiento de red o de sistema de archivos. Una lista de permisos en un JSON no basta para afirmar que un proceso está aislado.

Quien coordina sigue siendo responsable de preparar el alcance, revisar el diff y ejecutar la validación. Si una comprobación no corre, el resultado debe decirlo. Y si una tarea se envía a un proveedor externo, el material debe estar autorizado para ese destino.

Qué reutilizaría primero

Empezaría por una regla que evite un fallo recurrente, un skill que resuelva una tarea habitual y un lugar donde conservar requisitos y decisiones. Después comprobaría esas piezas con trabajo real. Copiar todos mis modelos, rutas y clientes de golpe haría difícil saber qué está aportando valor.

La guía de desarrollo y el Makefile permiten inspeccionar cómo se valida el repositorio. Esas comprobaciones detectan incoherencias concretas de la configuración; no demuestran que cualquier agente vaya a comportarse bien en cualquier tarea.

Eso es lo que quiero conservar de Arnesto mientras el ecosistema sigue moviéndose: decisiones que puedo explicar, límites visibles y evidencia suficiente para revisar lo que ha ocurrido. Para explorar qué pasa cuando muchas tareas llegan a la revisión humana, estoy usando Agent Systems Lab.

Original & conversation on LinkedIn

Original & conversation on LinkedIn

In a randomized study, 52 mostly junior software engineers with Python experience worked with Trio, an unfamiliar asynchronous programming library. Some had access to an AI assistant; others worked without it.

Three findings stood out:

• Learning: the AI group averaged 50% on the subsequent assessment, compared with 67% in the control group. That is a gap of 17 percentage points.
• Speed: the AI group finished about two minutes faster on average, but the difference was not statistically significant.
• Debugging: this was the area with the largest gap, which matters when the next task is to inspect and supervise generated code.

The researchers also looked at how participants used the assistant. Asking for explanations and building understanding were associated with better learning outcomes than delegating the work wholesale. Those interaction patterns came from small groups; they are useful signals, not proof that a particular prompting style causes better learning.

My takeaway is to treat AI as a comprehension partner when learning something new: ask why, inspect the result, and make sure I can explain and debug it myself. Finishing a task and understanding it are different outcomes, and I want to keep paying attention to both.

This study concerns a specific learning task and an immediate assessment. It does not establish what happens to long-term expertise or to experienced developers working in familiar codebases.

Original & conversation on LinkedIn

If you abstract the PM role, much of it is cognitive orchestration: understanding context, synthesizing inputs, defining problems, prioritizing, specifying intent, aligning stakeholders, validating outcomes. These are exactly the structured knowledge workflows agents are starting to absorb. So yes, parts of the Product domain are now in scope for automation, just like parts of engineering were until now.

The shift I see in engineering is toward system design, orchestration and problem framing. That is where I expect more of our value to sit as implementation becomes easier.

A similar shift is reaching product. What remains is the PM as a decision architect inside increasingly automated socio-technical systems. Which is also why product and engineering are converging: engineers move toward product definition as implementation friction drops, while PMs move toward system design as coordination becomes programmable.

Rich Holmes’ example of a product workflow using Claude Cowork prompted this reflection.

Here is another flow from the same source: Rich Holmes’ example with the Ideate Agent in Stitch

Original & conversation on LinkedIn

Me emociona recibir el Make It Happen Spirit Award de Eventbrite tras una etapa de casi ocho años en Eventbrite en los que he tenido la suerte de crecer, equivocarme, aprender y asumir (¡muy!) distintos tipos de responsabilidad, pasando de Staff Engineer a Engineering Manager.

Esto no se habría logrado sin el talento, la empatía, la visión, la generosidad y la confianza de la gente con la que he trabajado durante todo este tiempo (¡hola, Juan Iglesias!). Equipos que se implican, que se cuidan, que discuten con rigor y que empujan juntos cuando las cosas se ponen difíciles. Este premio es, sobre todo, suyo.

Me emociona especialmente que se reconozca no solo el impacto técnico y los resultados, sino también una forma de hacer: conectar decisiones de ingeniería con valor real para clientes, construir sistemas sólidos y, al mismo tiempo, crear espacios donde las personas crecen y quieren quedarse.

Gracias a todas las personas que me han acompañado en este camino. Y a todos los que os habéis alegrado de forma genuina ✨

Seguimos.

Original & conversation on LinkedIn

Those sent me down a deeper path: how to reduce AI hallucinations and keep coding sessions genuinely productive, not just fast. One piece that really clicked was “Tu CLAUDE.md no funciona (sin Context Engineering)”: Tu CLAUDE.md no funciona (sin Context Engineering)

From there, I got to the Frequent Intentional Compaction (FIC) framework, and this implementation as a Claude plugin: stepwise-dev

So, I decided to get my hands dirty and cloned Edu’s augmented coding tools repo: my augmentedcode-configuration fork …adding a translation of the FIC Claude plugin, wiring it up as Cursor commands.

Still experimenting, but chasing the idea of explicit, repeated compaction of intent and context feels like gaining control when using these tools for coding. Less magic, more discipline.

Original & conversation on LinkedIn