DEV Community: Pillippa Ignacia Pérez Pons

Por qué una charla buena no queda seleccionada

Pillippa Ignacia Pérez Pons — Tue, 17 Mar 2026 21:06:25 +0000

Hay algo en lo que he pensado mucho últimamente, sobre todo después de haber postulado charlas, haber quedado seleccionada, haber sido rechazada, haber dado charlas en conferencias, y también haber estado del otro lado organizando espacios en meetups y conferencias.

Que una charla no quede seleccionada no significa automáticamente que sea una mala charla.

Sé que eso suena obvio, pero cuando una es quien postula, rara vez se siente así.

Cuando una charla no queda, es muy fácil interpretar ese rechazo como una evaluación de tus capacidades, de tus ideas, de tu experiencia, o incluso de tu valor como speaker. He visto a muchas personas asumir que si no quedaron es porque no son lo suficientemente buenas, porque su tema no era interesante, o porque simplemente no deberían seguir intentando.

Pero en la práctica, el proceso de selección suele ser mucho más complejo que eso.

Quise escribir este post porque he visto este proceso desde distintos lados. No solo como speaker, sino también desde la organización de meetups, conferencias y espacios de comunidad.

Como charlista, he tenido la oportunidad de quedar seleccionada en eventos como GitHub Universe 2025, GitMerge 2025, React Bay Area 2024, Atlanta Developers’ Conference 2024, React Summit NY 2023 y freeCodeCampBA 2020.

Y también hablo desde la experiencia del lado de comunidad. Actualmente soy Vice Presidenta en Niñas Pro, soy Women TechMakers Ambassador, y fui organizadora en JSConf Chile 2023. Haber estado en esos espacios me ha ayudado a entender cómo se leen las propuestas, cómo se arma una programación y cuántas veces una decisión tiene mucho más que ver con el contexto que con la calidad de una charla por sí sola.

Justamente por eso quise escribir esto.

Porque muchas charlas no quedan seleccionadas por razones que no tienen nada que ver con que sean “malas”.

1. A veces simplemente hay demasiadas postulaciones para el mismo espacio

Este probablemente es uno de los motivos más comunes, y también uno de los menos visibles cuando una está postulando desde afuera.

A veces tu charla está bien armada. A veces incluso es una de tus mejores ideas. Pero muchas otras personas postularon para el mismo tipo de espacio.

Eso puede pasar cuando varias propuestas compiten por el mismo día, por el mismo nivel de audiencia, por el mismo formato, o por una temática parecida.

Un evento no selecciona charlas como piezas aisladas. Lo que hace es construir un programa completo. Está pensando en flujo, balance, variedad y en cómo dialogan las sesiones entre sí.

Entonces, aunque tu charla sea buena, puede no quedar seleccionada si ya hay demasiadas propuestas en esa misma línea.

Eso no significa que tu charla no tenga valor.

A veces simplemente significa que los cupos se llenaron antes de que tu propuesta pudiera entrar.

2. A veces la idea es buena, pero la propuesta no la explica con suficiente claridad

Esto pasa muchísimo.

Una persona puede tener un tema muy bueno, experiencia real, y algo valioso que compartir. Pero al momento de llenar el CFP, la propuesta no logra transmitir eso con claridad.

Y la claridad importa muchísimo.

Cuando alguien revisa una postulación, necesita entender cosas como:

¿De qué trata realmente esta charla?
¿Qué problema o idea específica aborda?
¿Cómo se va a trabajar el tema?
¿Qué se va a llevar la audiencia?

Si eso no queda claro, se vuelve mucho más difícil evaluar la charla de forma justa.

Esta es una de las lecciones más grandes que he aprendido con el tiempo. Tener una buena idea no siempre basta. También hay que saber comunicar esa idea de una forma que le permita a otras personas entender su forma, su foco y su valor.

Muchas propuestas no se rechazan porque la persona no tenga nada interesante que decir.

Se rechazan porque la postulación deja demasiado espacio para adivinar.

3. A veces el título y el abstract no le hacen justicia a la charla

He visto esto muchas veces.

Una charla puede tener muchísimo potencial, pero el título es demasiado amplio, el abstract es muy vago, o la descripción se siente poco desarrollada. Cuando eso pasa, la propuesta no refleja realmente lo fuerte que podría ser la charla.

Y eso importa, porque el título y el abstract suelen ser la primera impresión.

Si el título es poco claro, cuesta entender de qué va realmente la charla.

Si el abstract es genérico, cuesta entender por qué importa.

Si la descripción menciona el tema, pero no logra mostrar su valor, la propuesta puede sonar mucho más plana de lo que en verdad es.

Eso no significa que la speaker sea débil. Ni siquiera significa que la idea de charla sea débil.

A veces simplemente significa que la propuesta necesita más trabajo.

4. A veces la propuesta dice cuál es el tema, pero no explica cómo se va a abordar

Este también es un punto muy importante.

Hay una diferencia enorme entre nombrar un tema y diseñar una sesión.

Por ejemplo, no es lo mismo decir “quiero hablar de accesibilidad” que explicar si esa charla será un caso de estudio, una guía técnica, una introducción para principiantes, una charla más reflexiva, o una sesión práctica basada en experiencia real.

Quienes organizan necesitan entender el ángulo de la charla.

Necesitan saber:

¿Desde qué mirada está planteada?
¿Es práctica o conceptual?
¿Es introductoria o avanzada?
¿Se basa en experiencia, investigación, demos o aprendizajes?
¿Qué va a pasar concretamente durante la sesión?

Cuando una propuesta no responde eso, puede sentirse poco desarrollada aunque el tema sea interesante.

A veces el problema no es la idea.

A veces el problema es que la postulación no explica bien el enfoque.

5. A veces la audiencia o el alcance no están bien definidos

Otra razón por la que una charla puede no quedar es que la propuesta no deja claro para quién está pensada.

Y eso genera fricción al tiro.

¿Es para personas que recién empiezan? ¿Para developers con experiencia? ¿Para estudiantes? ¿Para gente de comunidad? ¿Para una audiencia general?

Si eso no aparece con claridad en la propuesta, se hace más difícil ubicar la charla dentro del programa.

Lo mismo pasa con el alcance.

Si una charla intenta cubrir demasiado, puede parecer poco realista.

Si es demasiado amplia, puede sonar superficial.

Si queda demasiado abierta, cuesta entender cuál será realmente el aprendizaje o la utilidad para quienes asistan.

Algunas de las mejores propuestas que he visto no son necesariamente las más ambiciosas. Son las que tienen más claro sus límites.

Saben de qué tratan, para quién son, y qué quieren que la audiencia se lleve.

6. A veces una charla no queda fuera por ser mala, sino porque otras eran más fáciles de programar

Siento que esto se habla poco, pero importa muchísimo.

Cuando alguien organiza un meetup o una conferencia, no solo se pregunta si una charla es interesante. También se pregunta si esa charla calza bien en la estructura real del evento.

Se piensa en cosas como:

¿Complementa el resto del programa?
¿Funciona bien en la duración del slot?
¿Se puede comunicar fácilmente a la audiencia?
¿Aporta variedad a la agenda?
¿Está lo suficientemente clara como para programarla con confianza?

Entonces a veces se comparan dos charlas buenas, y una queda seleccionada porque era más fácil de ubicar dentro del programa general.

Eso no significa que la otra fuera mala.

Muchas veces significa que una llegó con más claridad, más estructura o con un encaje más evidente.

Y honestamente, esa diferencia importa mucho.

7. Una charla siempre se selecciona en contexto

Este quizás es el punto más importante de todo el post.

Una charla nunca se selecciona en abstracto.

Se selecciona para un evento específico, con una audiencia específica, en un momento específico, bajo ciertas restricciones, y en comparación con un conjunto particular de otras postulaciones.

Ese contexto cambia todo.

La misma charla puede ser rechazada en un evento y aceptada en otro.

No porque la charla haya cambiado.

Sino porque cambió el contexto.

Quizás una conferencia ya tenía muchas charlas sobre temas parecidos.

Quizás otro evento estaba buscando exactamente esa mirada.

Quizás un meetup necesitaba charlas más introductorias.

Quizás otra conferencia quería casos de estudio más técnicos.

Quizás un evento tenía poco espacio.

Quizás otro tenía más margen para experimentar.

Por eso creo que los rechazos hay que leerlos con mucho más cuidado.

Que una charla no quede seleccionada muchas veces no es un veredicto final sobre su calidad.

A veces simplemente significa que no era el fit correcto para ese evento, en ese momento.

8. A veces una propuesta tiene una buena idea, pero todavía necesita desarrollo

Creo que esta es una de las formas más sanas de mirar una charla rechazada.

Una propuesta puede tener una muy buena idea y aun así no estar lista todavía.

Eso puede verse así:

Un tema valioso con un abstract demasiado amplio
Una experiencia potente que todavía no está convertida en una narrativa clara
Un ángulo interesante que no termina de explicarse bien
Una charla útil que todavía no muestra qué la hace distinta
Un buen concepto que necesita un título más preciso, una mejor estructura o un takeaway más claro

Eso no significa que la idea haya que descartarla.

A veces significa que necesita una vuelta más.

Una reescritura más.

Una pasada más para hacer visible su valor.

Muchas charlas buenas no nacen como propuestas perfectas. Se vuelven más fuertes a través de la iteración.

¿Qué cosas suelen ayudar a que una propuesta se vea más sólida?

Desde mi experiencia, tanto como speaker como organizando espacios de comunidad, estas son algunas de las cosas que suelen hacer que una charla sea más fácil de evaluar.

Un título claro

Un buen título ayuda a entender rápido y bien de qué trata la charla.

Un abstract concreto

Tiene que explicar de qué trata la charla, qué cubre y por qué importa.

Un ángulo visible

¿Por qué este tema, desde esta mirada, contado por ti?

Una audiencia definida

¿Para quién es esta charla?

Un takeaway claro

¿Qué deberían aprender, entender o poder hacer las personas después de escucharla?

Un alcance realista

¿De verdad este tema puede cubrirse bien en el tiempo disponible?

Suficiente detalle para imaginar la sesión

¿Alguien leyendo la propuesta puede hacerse una idea de cómo se desarrollaría esa charla?

Por qué me importa hablar de esto

Me importa porque he visto lo desmotivante que puede ser un rechazo.

He visto a personas dejar de postular después de uno o dos no.

He visto a personas asumir que no eran lo suficientemente buenas.

He visto a personas abandonar ideas que podrían haberse convertido en charlas muy potentes con un poco más de iteración o en un evento distinto.

Y honestamente, creo que necesitamos hablar más abiertamente de esto.

A veces, una charla no queda porque el tema estaba sobre representado.

A veces, porque el horario ya se llenó.

A veces, porque el abstract no estaba claro.

A veces, porque la propuesta no explicaba bien el enfoque.

A veces, porque no era evidente para qué audiencia estaba pensada.

Y sí, a veces, una charla realmente necesita más trabajo.

Pero no todas esas cosas significan lo mismo.

Y esa diferencia importa.

Mis últimas palabras

Si alguna vez te rechazaron una charla, o una propuesta que te importaba mucho, me gustaría que recuerdes esto:

Que una charla sea rechazada no siempre significa que sea una mala charla.

A veces, es un problema de fit.

A veces, es un problema de claridad.

A veces, es timing.

A veces, es programación.

A veces, solo necesita un mejor título, un abstract más fuerte, un alcance más claro, o el evento correcto.

Eso no vuelve tu idea menos valiosa.

Y definitivamente no significa que deberías dejar de postular.

Algunas de las mejores cosas que he aprendido como speaker han salido justamente de reescribir propuestas que no quedaron la primera vez.

A veces, la siguiente versión es la que abre la puerta.

Y a veces, la charla ya era buena desde antes. Solo necesitaba el contexto correcto para que eso se viera.

Why good talks don’t get selected

Pillippa Ignacia Pérez Pons — Tue, 17 Mar 2026 20:52:55 +0000

There’s something I’ve been thinking about for a long time, especially after applying to talks, getting selected, getting rejected, speaking at conferences, and also helping organize community spaces.

A talk not being selected does not automatically mean it’s a bad talk.

I know that sounds obvious, but when you’re the one submitting a proposal, it rarely feels that way.

When a talk doesn’t get accepted, it’s very easy to read that as a judgment of your skills, your ideas, your experience, or even your worth as a speaker. I’ve seen people assume that rejection means they’re not good enough, that their topic isn’t valuable, or that they should stop trying.

But in reality, talk selection is usually much more complex than that.

I wanted to write this because I’ve seen this process from different sides. Not only as a speaker, but also from the side of organizing meetups and conferences.

As a speaker, I’ve had talks selected at events like GitHub Universe 2025, GitMerge 2025, React Bay Area 2024, Atlanta Developers’ Conference 2024, React Summit NY 2023, and freeCodeCampBA 2020.

I also speak from experience on the community side. I’m currently Vice President at Niñas Pro, I’m a Women TechMakers Ambassador, and I was an organizer at JSConf Chile. Being part of those spaces has helped me understand how proposals are read, how programs are shaped, and how often a decision has more to do with context than with quality alone.

That’s exactly why I wanted to write this post.

Because many talks do not get selected for reasons that have nothing to do with being “bad.”

1. Sometimes there are just too many proposals for the same slot

This is probably one of the most common reasons, and also one of the easiest to miss when you’re applying from the outside.

Sometimes your talk is solid. Sometimes it’s even one of your best ideas. But a lot of other people submitted talks for the same kind of space.

That can happen when many proposals are competing for the same day, the same audience level, the same format, or the same topic area.

An event is usually not selecting talks one by one as isolated pieces. Organizers are building a full program. They’re thinking about flow, balance, variety, and how sessions work together.

So even if your talk is good, it might not get selected if there are already too many proposals in that same area.

This doesn’t mean your talk lacks value.

Sometimes it simply means the schedule filled up before your proposal could fit.

2. Sometimes the idea is good, but the proposal doesn’t explain it clearly enough

This happens a lot.

A person may have a great topic, useful experience, and something genuinely valuable to share. But when they fill out the CFP, the proposal itself doesn’t make that clear.

And clarity matters a lot.

When someone reviews a talk proposal, they need to understand things like:

What is this talk actually about?
What specific problem or idea does it focus on?
How will the topic be approached?
What will the audience leave with?

If those things are not clear, it becomes harder to evaluate the session fairly.

This is one of the biggest lessons I’ve learned over time. Having a good idea is not always enough. You also need to communicate that idea in a way that helps other people understand its shape.

A lot of proposals are not rejected because the speaker has nothing interesting to say.

They’re rejected because the submission leaves too much room for guessing.

3. Sometimes the title and abstract don’t do justice to the talk

I’ve seen this many times.

A talk can have real potential, but the title is too broad, the abstract is too vague, or the description sounds unfinished. When that happens, the proposal may not reflect how strong the actual talk could be.

This matters because the title and abstract are often the first impression.

If the title is unclear, people may not understand what the talk is really about.

If the abstract is generic, people may not understand why it matters.

If the description explains the topic but not the value, the proposal can end up sounding flatter than it really is.

That doesn’t mean the speaker is weak. It doesn’t even mean the talk idea is weak.

Sometimes it just means the proposal needs more work.

4. Sometimes the proposal says what the topic is, but not how it will be approached

This is another big one.

There’s a huge difference between naming a topic and shaping a session.

For example, saying “I want to talk about accessibility” is not the same as explaining whether that talk will be a case study, a technical walkthrough, a beginner-friendly introduction, a reflective talk, or a practical guide based on real implementation work.

Organizers often need to understand the angle of the session.

They need to know:

What lens is this talk using?
Is it practical or conceptual?
Is it beginner-friendly or advanced?
Is it based on experience, research, demos, or lessons learned?
What exactly will happen during the session?

When a proposal doesn’t answer that, it can feel underdeveloped even if the topic itself is interesting.

Sometimes the problem isn’t the idea.

Sometimes the problem is that the submission doesn’t explain the approach.

5. Sometimes the audience or scope is too unclear

Another reason talks may not get selected is that the proposal doesn’t make it clear who the talk is for.

That creates friction immediately.

Is it for beginners? Mid-level developers? Senior engineers? Students? Community organizers? A general audience?

If that isn’t visible in the proposal, it becomes harder to place the talk in the program.

The same happens with scope.

If a talk tries to cover too much, it can feel unrealistic.

If it is too broad, it may sound shallow.

If it is too open, reviewers may struggle to understand what the real takeaway will be.

Some of the strongest talk proposals I’ve seen are not necessarily the most ambitious ones. They’re the ones that know their boundaries.

They know what they are about, who they are for, and what they want the audience to walk away with.

6. Sometimes a talk is not rejected because it is weak, but because other talks were easier to program

I think this is something more people should talk about.

When organizers review proposals, they are not only asking whether a talk is interesting. They are also asking whether it fits into the real structure of the event.

They’re thinking about things like:

Does this complement the rest of the lineup?
Does it fit the slot length?
Can we clearly communicate it to attendees?
Does it add variety to the program?
Is it ready enough to schedule confidently?

So sometimes two good talks are being compared, and one gets selected because it is easier to place in the overall event.

That does not mean the other one was bad.

It often means one proposal arrived with more clarity, more structure, or a more obvious fit.

And honestly, that distinction matters a lot.

7. A talk is always being selected in context

This is maybe the most important point in this whole post.

A talk is never selected in the abstract.

It is selected for a specific event, with a specific audience, in a specific year, under specific constraints, and alongside a specific set of other proposals.

That context changes everything.

The exact same talk can be rejected by one event and accepted by another.

Not because the talk changed.

Because the context changed.

Maybe one conference already had too many talks on similar topics.

Maybe another event was looking for exactly that perspective.

Maybe one meetup needed beginner-friendly sessions.

Maybe another wanted advanced technical case studies.

Maybe one conference had limited space.

Maybe another one had room for more experimentation.

This is why I think rejection should be interpreted much more carefully.

Not being selected is often not a final verdict on the quality of a talk.

Sometimes it just means it wasn’t the right fit for that event at that moment.

8. Sometimes a proposal has a good idea, but it still needs development

I think this is one of the healthiest ways to look at rejected talks.

A proposal can absolutely have a strong idea and still not be ready yet.

That can look like:

A valuable topic with a very broad abstract
A strong experience that hasn’t been shaped into a clear narrative
An interesting angle that isn’t fully explained
A useful talk that doesn’t yet show what makes it different
A good concept that still needs a sharper title, structure, or takeaway

That doesn’t mean the idea should be thrown away.

Sometimes it means the talk needs one more round of thinking.

One more rewrite.

One more pass at making the value visible.

A lot of strong talks are not born as strong proposals. They become strong through iteration.

What usually helps a talk proposal feel stronger?

From my experience both as a speaker and as someone involved in organizing community spaces, these are some of the things that make a proposal easier to evaluate.

A clear title

A strong title helps people understand the topic quickly and accurately.

A concrete abstract

It should explain what the talk is about, what it covers, and why it matters.

A visible angle

Why this topic, from this perspective, by you?

A defined audience

Who is this talk for?

A clear takeaway

What should people learn, understand, or be able to do after the talk?

A realistic scope

Can this topic actually be covered well in the available time?

Enough detail to imagine the session

Can someone reading the proposal understand how the talk would likely unfold?

Why I care about this

I care about this because I’ve seen how discouraging rejection can be.

I’ve seen people stop applying after one or two no’s.

I’ve seen people assume they were not good enough.

I’ve seen people give up on ideas that could have become really strong talks with a bit more iteration or a different venue.

And I honestly think we need more honest conversations about this.

Sometimes a talk is not selected because the topic was overrepresented.

Sometimes because the schedule filled up.

Sometimes because the abstract was unclear.

Sometimes because the proposal didn’t explain the approach well enough.

Sometimes because the audience fit was not obvious.

And yes, sometimes a talk really does need more work.

But those are not all the same thing.

That distinction matters.

Final thoughts

If you’ve ever had a talk rejected, I hope you remember this:

A rejected talk is not always a bad talk.

Sometimes it’s a fit issue.

Sometimes it’s a clarity issue.

Sometimes it’s a timing issue.

Sometimes it’s a programming issue.

Sometimes it just needs a better title, a stronger abstract, a more defined scope, or a different event.

That doesn’t make the idea worthless.

And it definitely doesn’t mean you should stop submitting.

Some of the best things I’ve learned as a speaker came from rewriting proposals that didn’t get selected the first time.

Sometimes the next version is the one that opens the door.

And sometimes the talk was good all along. It just needed the right context to be seen.

Day 01 - One Key, One Coordinator

Pillippa Ignacia Pérez Pons — Mon, 22 Dec 2025 08:08:35 +0000

Previously in Day 00, we talked about the moment systems become expensive: when the answer is “maybe”.

If you haven’t read it, this post is part of a series — start here: Link

A key needs a home

If two requests touch the same thing (an order, a user, a tenant), you want one place to decide what happens.

Not forever. Not globally. Just for that key.

So, we’re going to build the smallest possible proof that this is real:

the same key always routes to the same coordinator.

No rate limiting yet. No dedupe yet. No queue yet.

Just the primitive that makes all of those possible.

Imagine you’re debugging an incident and you ask: “where does order:123 get decided?”

By the end of this post, you’ll have an answer you can point to in code.

The demo you can hold in a few minutes

We’re not building rate limiting yet.

We’re not deduping retries yet.

We’re not building queues yet.

Now, is one move:

take a key -> route to one Durable Object instance -> handle the request there

And then we prove it with the simplest signal possible: an in memory counter.

The counter is not the point. It’s a flashlight.

We’ll expose a single endpoint:

GET /day/01/hello/:key

Call it with alice, call it with bob, call it with anything.

If alice and bob don’t share a counter, then they don’t share a coordinator.

And if they don’t share a coordinator, we have isolation per key — the foundation for everything else.

Demo

A 60-second Workers mental model

If you’re new to Workers, here’s the only model you need for Day 01:

A Worker is your HTTP entrypoint. Every request hits the Worker first.

Inside the Worker you’ll see an env object. Think of env as “injected dependencies”:
bindings you declare in wrangler.jsonc (Durable Objects, KV, D1, secrets, etc.) show up there at runtime.

In this demo, the important binding is:

env.COORDINATORS -> a Durable Object namespace

A namespace is not one object. It’s a factory for many objects.

From a namespace, you do three steps:

Pick a key (like "alice")
Turn it into a stable object ID: const id = env.COORDINATORS.idFromName(key)
Get a stub: const stub = env.COORDINATORS.get(id)

A stub is a reference to the Durable Object instance for that ID.
And the “weird but powerful” part is: you talk to that instance by calling stub.fetch(...).

So the Worker is basically a router:

it reads the key from the request
it forwards the request to the object that “owns” that key

Where does state live?

the Worker should stay mostly stateless
the Durable Object is where per-key state/decisions live

Quick glossary

Worker: your HTTP entrypoint. Every request hits this first.
env: runtime-injected dependencies (bindings + secrets) defined in wrangler.jsonc.
Binding: a named handle that appears on env (e.g. env.COORDINATORS).
Durable Object class: the code you write (e.g. export class Coordinator { ... }).
Namespace: a “factory” for many Durable Object instances (what you get via the binding).
Key / name: the string you choose to represent “the thing” (in Day 01: alice, bob, etc.).
Object ID: a stable identifier for one DO instance (created from the key via idFromName(key)).
Stub: a reference/proxy to that specific DO instance (from namespace.get(id)).
stub.fetch(): how the Worker sends a request to that DO instance (like calling a mini-service).
State: per-object memory and/or persisted data. For Day 01 we use in-memory state only.
Migration: a version tag in wrangler.jsonc that tells Cloudflare about DO schema/class changes over time.

The one move

Everything today is one mapping:

key -> object ID -> stub -> forward

We’re not solving retries yet. We’re not building ordering yet.

We’re just proving that a key can have a home.

Repo structure for Day 01

src/index.ts (entry point + route mounting + DO export)
src/routes/day01.ts (route definition)
src/handlers/day01Hello.ts (handler logic: key -> DO)
src/objects/Coordinator.ts (the Durable Object class)
wrangler.jsonc (binding + migration)

Config: how the Worker finds your Durable Object

`wrangler.jsonc`

{
  "main": "src/index.ts",
  "durable_objects": {
    "bindings": [
      { "name": "COORDINATORS", "class_name": "Coordinator" }
    ]
  },
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["Coordinator"] }
  ]
}

What this means:

name: "COORDINATORS" -> creates env.COORDINATORS in your Worker.
class_name: "Coordinator" -> tells Cloudflare which exported class implements the DO.
migrations -> “I’m introducing a new Durable Object class in this project.”

You don’t run a separate “migration command”. The migration is applied when you deploy.

Code: how requests flow end-to-end

This layout keeps routes clean and pushes logic into handlers.

Step 1 — The route (just routing)

src/routes/day01.ts

import { Hono } from "hono";
import type { HonoEnv } from "../types/env";
import { day01HelloHandler } from "../handlers/day01Hello";

export const day01 = new Hono<HonoEnv>();

// Route shape: /day/01/hello/:key
day01.get("/hello/:key", day01HelloHandler);

This file only defines the URL shape and delegates logic to the handler.

Step 2 — The handler (key -> DO instance)

src/handlers/day01Hello.ts

import type { Context } from "hono";
import type { HonoEnv } from "../types/env";

export async function day01HelloHandler(c: Context<HonoEnv>) {
  // 1) Extract the key from the URL
  const key = c.req.param("key"); // e.g. "alice" or "bob"

  // 2) Map key -> Durable Object ID (stable/deterministic)
  const id = c.env.COORDINATORS.idFromName(key);

  // 3) Get a stub (proxy) to talk to that DO instance
  const stub = c.env.COORDINATORS.get(id);

  // 4) Forward the request to the DO instance
  return stub.fetch(c.req.raw);
}

This is the entire “pattern”:
key -> id -> stub -> forward

That’s why Durable Objects are powerful: you get a coordinator per key by construction.

Notice what we didn’t do:

no shared in memory map in the Worker
no cache
no lock
no database

We only routed the request to the right place.

Step 3 — The Durable Object itself (stateful core)

src/objects/Coordinator.ts

export class Coordinator {
  private inMemoryCount = 0;

  constructor(private state: DurableObjectState) {}

  async fetch(_req: Request): Promise<Response> {
    // This counter lives in memory, per DO instance.
    // So alice and bob won't share it.
    this.inMemoryCount++;

    return Response.json({
      keyHint: this.state.id.toString(),
      inMemoryCount: this.inMemoryCount,
      note: "In-memory only (durable storage comes later)."
    });
  }
}

Why this proves the concept:

Requests for alice hit the alice object instance -> counter becomes 1, 2, 3…
Requests for bob hit the bob object instance -> counter becomes 1, 2, 3…
Same code, different key -> isolated state.

Later, we’ll replace/extend this state with durable storage for correctness critical data.

Step 4 — Entry point + DO export (important)

src/index.ts

import { Hono } from "hono";
import { day01 } from "./routes/day01";

// Important: the DO class must be exported from the entry module
export { Coordinator } from "./objects/Coordinator";

const app = new Hono();

app.get("/health", (c) => c.json({ ok: true }));

// Mount day 01 under /day/01
app.route("/day/01", day01);

export default app;

Why export the DO class here?
Because wrangler.jsonc says class_name: "Coordinator", and Wrangler needs that class to be exported by the built script.

Try it (2–5 minutes)

Repository:

https://github.com/Pillin/Durable-Objects-30days

Run:

npm install
npx wrangler dev

then:

curl http://localhost:8787/day/01/hello/alice
curl http://localhost:8787/day/01/hello/alice
curl http://localhost:8787/day/01/hello/bob
curl http://localhost:8787/day/01/hello/bob

Expected: each key increments independently.

Rule

If your bug is “multiple things racing over the same entity”, the fix is usually:
centralize coordination per key (tenant/user/resource).

Durable Objects are one way to get that coordinator.

Stay curious and ship.

Day 00 - Prelude

Pillippa Ignacia Pérez Pons — Sat, 20 Dec 2025 23:22:44 +0000

If this has happened to you…

two requests update the same thing at the same time (race conditions)
retries create duplicate effects (double emails, double charges, double writes)
rate limits / quotas are inconsistent under load
ordering matters per customer/resource, but events arrive “whenever”
“it worked locally” but breaks under real traffic

…you’re in distributed systems territory.

And you don’t need a “massive distributed system” for this to be true. Even with a single server, concurrent requests + retries + partial failures can create the same class of problems. If you later add replicas, the pain gets amplified fast.

So the topic isn’t “how many servers you have”. It’s coordination. Per-key coordination.

Per-key coordination means: for one specific thing (like an order or a user), there’s one place that decides what happens.

That sentence sounds obvious… until you meet the moment where it stops being optional.

The moment it becomes real

Imagine a button: Pay.

On the happy path, it’s boring: click -> charge -> 200 OK -> “Paid.”

The failure path is where your system reveals what it actually believes.

The user clicks Pay. The server charges the card. Then something goes wrong before the user sees success. It could be a timeout, a network hiccup, a crash, the client giving up early, a proxy retrying, a job runner retrying later—pick your favorite. The point is: the system did some work, but the outside world didn’t get a clean “done” signal.

So the intent arrives again.

Now you’re not debugging payments. You’re debugging this question:

Did we already do the thing? If yes, what should we do now?

That question doesn’t live only in checkout flows. It shows up when you send an email, create a subscription, increment a quota, finalize an order, apply a state transition, update a profile, accept an invite.

This is why production bugs can feel haunted. The code looks fine. Tests pass. Logs look normal. Yet outcomes are wrong—because the system answers “did it already happen?” inconsistently.

“Maybe” is the most expensive state

At some point your system can’t confidently say “yes” or “no.” It can only say “maybe.”

And “maybe” is expensive because it forces two bad choices. If you do it again, you create duplicates (double charge, double email, double write). If you refuse to do it again, you miss work (no email, stale state, inconsistent outcomes).

The frustrating part is that “maybe” isn’t rare. It shows up through normal reality: concurrent requests, retries, webhook redeliveries, at least once job processing, crashes between “side effect happened” and “response delivered.”

So the fix usually isn’t “add another condition.” The fix is to introduce a consistent place where decisions get made.

The missing building lego

When the weirdness clusters around one thing an order, a user, a tenant, a resource the shape of the fix is usually the same:

one coordinator per key.

One place that can say: “I’ve already seen this requestId, don’t apply it twice.” Or: “For this order, state transitions happen in order.” Or: “For this tenant, quotas are enforced consistently.” Or: “Only one worker can hold this lock right now.”

In this series, I’ll use Cloudflare Durable Objects as the coordination primitive so we can focus on the patterns, not the plumbing.

Why this series uses Durable Objects

You can solve coordination problems on any major cloud. The question isn’t “can I do it on AWS/GCP?” — you can.
The question is: how many moving parts do you need to make it correct, and how easy is it to reason about under retries and concurrency?

Coordination bugs rarely come from missing features. They come from the system being forced to answer “did it already happen?” and having no single place that can answer consistently for a key.

Durable Objects show up in this series because they give you a very direct building lego for that shape of problem:

one key -> one stateful place to decide, with storage attached.

What you usually end up building on AWS/GCP (and why it’s easy to get wrong)

If you try to recreate “one place per key decides” using common cloud primitives, it typically becomes a small distributed system of its own:

stateless compute (Lambda/Cloud Run/etc.)
a database with conditional writes / transactions (DynamoDB/Spanner/Postgres)
often a cache/lock service (Redis) for counters/locks
sometimes a queue/workflow layer (SQS/PubSub/Step Functions/Cloud Tasks)

Each piece is fine, the problem is the glue:

you now have multiple services that must agree on ordering and idempotency
you have to design retries across service boundaries
you have to handle partial failures
locks need TTLs, renewal, fencing, and careful failure handling
debugging becomes “which service saw what, in what order?”

You can absolutely do it, but the coordination logic gets spread across infrastructure decisions, not just code.

What Durable Objects are (and what you get by default)

A Durable Object is a stateful instance addressed by an ID (or a name-derived key) that combines compute with persistent storage.

Three properties matter for coordination:

Requests for the same key go to the same object: That gives you a natural “home” for decisions about order:123 or tenant:acme.
Single-threaded execution per object: You can write coordination logic without reinventing locks inside your own code.
Storage is attached to the object: The place that decides can also remember what it decided (dedupe keys, current state, counters, queue state).

That combination means you can implement patterns like:

idempotency/dedupe (requestId sets)
single-writer ordering per key
per-key rate limits/quotas
per-key queues
stampede protection (one refresh, many wait)

…without first assembling a separate coordination stack.

The real benefit

The benefit isn’t “Cloudflare vs AWS”. It’s that Durable Objects reduce coordination from “a system design problem across multiple services” into “a local decision inside one keyed instance.”

That’s why they’re a great teaching tool for these patterns: we can spend the series on ordering, dedupe, rate limits, per-key queues, stampede protection, and sharding, instead of spending half the series wiring and operationalizing the coordination stack.

When you shouldn’t use Durable Objects

Durable Objects aren’t a universal default. If a clean database transaction already solves the correctness problem, or your workload is purely stateless, or the primary requirement is global querying/analytics across many keys, DO may be unnecessary.

The guiding principle for the series stays the same:

use the simplest tool that can make the decision consistently.

What I’m going to build over 30 days

The goal is to end with a toolbox: the same coordination idea, applied as repeatable patterns.

We’ll start by making the primitive “click” with tiny demos: mapping keys to coordinators, choosing keys safely, and understanding what is and isn’t durable. From there we’ll turn the “Pay button story” into real solutions: deduping retries (idempotency), enforcing ordering (single-writer per key), and keeping quotas consistent (rate limiting). Then we’ll move into the patterns that show up once you ship: per-key queues, locks, stampede protection, hot keys, sharding, and the trade-offs that decide when DO is the right tool versus when a database, Redis, or a queue is the better fit.

I’ll keep it flexible on purpose: if a topic turns out to be more useful than planned, I’ll spend more time there.

Posting schedule (holiday break)

This is a 30 post run, but there will be no posts on: Dec 24, 25, 29, 30, 31, and Jan 1, 2.

Planned map (subject to change)

I’ll keep this updated as days ship.

Day 01 - One Key, One Coordinator: The primitive: route by key -> one stateful place to decide.
Day 02 — Key Design = Partitioning: Good keys isolate; bad keys collide (and create hot spots).
Day 03 — What’s Actually Durable?: Memory vs storage vs “what survives” (and what doesn’t).
Day 04 — Single-Writer per Key: Enforce ordering and avoid races by serializing per key.
Day 05 — Idempotency: Dedupe Retries: Turn “maybe” into “already handled” with request IDs.
Day 06 — Rate Limiting per Key: Consistent quotas even when you scale and retries happen.
Day 07 — Weekly Recap #1 + Cheatsheet: The first “pattern index” you can bookmark.
Day 08 — A Per-Key Queue: Queue work per key to control order and throughput.
Day 09 — Locks per Resource (and when not to): When you truly need mutual exclusion, and the footguns.
Day 10 — Debounce/Throttle per Key: Collapse bursts into one decision.
Day 11 — Stampede Protection (“Single Flight”): One refresh runs; everyone else waits.
Day 12 — Consistent Counters per Key: Quotas, usage, and “exactly once ish” counting.
Day 13 — Leader per Key (Coordinator Role): When one instance must orchestrate steps for a key.
Day 14 — Weekly Recap #2 + Pattern Index: Consolidate: dedupe, ordering, queues, locks, stampedes.
Day 15 — Handling At-Least-Once Delivery: Designing for duplicates as a normal case.
Day 16 — Webhooks: Redelivery Without Panic: Make webhook handlers safe under retries.
Day 17 — Sagas per Key (Multi-Step Workflows): A simple saga state machine you can reason about.
Day 18 — Backpressure per Key: Protect correctness when load spikes.
Day 19 — Hot Keys: Symptoms and Triage: How to recognize and mitigate before it melts.
Day 20 — Sharding a Hot Key: Split one key into many without losing correctness.
Day 21 — Weekly Recap #3 + Failure Modes Checklist: The “what breaks in prod” list.
Day 22 — Observability That Helps Coordination Bugs: Logs/metrics/tracing for “did it already happen?”
Day 23 — Testing Retries, Races, and Ordering: A harness to reproduce the “haunted” bugs.
Day 24 — Anti-Patterns (What Not To Do): The mistakes that create invisible correctness debt.
Day 25 — DO vs DB vs Redis vs Queues (Honest Trade-offs): How to choose the simplest correct tool.
Day 26 — Multi-Tenant Boundaries: Isolation, fairness, and per-tenant abuse prevention.
Day 27 — Coordinating Fan-Out (Realtimes / Rooms): When many clients depend on one key’s truth.
Day 28 — Composition: Building a “Coordination Kit”: Combine patterns instead of rewriting them.
Day 29 — A Small Capstone Demo: A realistic flow that uses multiple patterns together.
Day 30 — Final Index + Learning Paths: Where to start depending on your problem (retries, ordering, quotas, hot keys).

How to follow along

The code lives in a single GitHub repo: Link

Stay curious and ship.

The Agentic Era: From Artificial Intelligence to Cognitive Infrastructure

Pillippa Ignacia Pérez Pons — Sun, 12 Oct 2025 18:25:11 +0000

Translation of the original Spanish essay “La Era Agentic: de la Inteligencia Artificial a la Infraestructura Cognitiva,” originally published on Dev.to by Pillippa Pérez Pons.

Summary

Agentic AI is the new technological wave, powered by agents capable of reasoning and autonomously executing tasks. Its current maturity is not a fad but the result of three converging factors: standardization (MCP, A2A), distributed infrastructure, and empirical validation through reproducible benchmarks.

This essay argues that the inflection point began with the mass adoption of language models in 2022 and solidified between 2024 and 2025, following the pattern of previous waves like email, the web, and mobility. From a frontend development perspective, it contends that agenticity will cease to be optional and become a structural layer on par with usability and accessibility.

This text outlines the timeline of that inflection, analyzes the enabling factors, and proposes a reading of how agenticity integrates into the cognitive infrastructure of contemporary software. It is also part of a series exploring the transition toward an infrastructure where humans and systems share agency. This first installment covers the conceptual, historical, and technical foundations of Agentic AI; future pieces will delve into interaction patterns, trust metrics, and applied agentic design.

Introduction

No technological revolution begins by declaring itself as such. First it appears as curiosity, then it becomes an experiment, and only later does it transform into structure. So it was with email in the seventies, with the web in the nineties, and with mobility after 2007. In each case, what began as a marginal idea ended up as an essential layer of the digital world, unseen but indispensable.

In 2025, Agentic AI is tracing the same path. What in 2023 looked like a set of fragile, scattered trials has consolidated into a transversal layer of technological infrastructure. Agents, entities capable of reasoning, executing tasks, and collaborating with humans and systems, have moved from the lab to production environments and from prototype to standard. This essay maintains that their presence no longer belongs to speculation but to everyday practice, and that their integration will transform not only how we program but how we conceive the relationship between intelligence and software.

From a frontend development perspective, agenticity represents a new structural layer. Like usability or accessibility, it will cease to be optional and become an inherent principle of interface design and architecture. Its impact goes beyond interaction, it redefines the very notion of collaboration between humans and machines. Understanding this transition, from automation to autonomy and from code to behavior, is essential for anticipating how the next decade of software will take shape.

1. A Timeline of the Inflection

2002: Publication of the FIPA Agent Communication Language (ACL) and Agent Communication Protocol (ACP) standards by IEEE, establishing the basis for interoperability among agents.

November 30, 2022: Public launch of ChatGPT, democratizing access to language models and marking the start of mass adoption of generative AI.

February 2023: Publication of Toolformer, a Meta AI paper demonstrating that LLMs can learn to use external tools without direct supervision.

March 30, 2023: Emergence of Auto-GPT, the first popular autonomous agent based on GPT-4, introducing notions of self-orchestration and subtask execution.

October 10, 2023: Publication of SWE-Bench, a reproducible benchmark to measure whether agents can fix real bugs in software repositories.

November 25, 2024: Anthropic introduces the Model Context Protocol (MCP), an open standard enabling agents to connect with tools and data contexts.

February 25, 2025: Cloudflare launches the Agents SDK, enabling the building and deployment of agents at the edge via Workers and Workers AI.

April 2, 2025: Publication of the MCP Safety Audit paper, identifying security risks and vulnerabilities in MCP implementations.

April 9, 2025: Google announces the Agent2Agent Protocol (A2A), designed to enable direct communication between agents from different providers.

June 3, 2025: Cloudflare publishes examples of human-in-the-loop patterns using the Agents SDK, showing how agents can incorporate real-time human decisions.

March 11, 2025: OpenAI launches the Responses API, successor to Assistants, focused on agent flows and MCP support.

May 21, 2025: OpenAI adds support for remote MCP servers within the Responses API, consolidating interoperability.

June 16, 2025: Publication of the study MCP at First Glance, analyzing the security and maintainability of MCP servers.

June 23, 2025: The Linux Foundation adopts the Agent2Agent (A2A) project as an open protocol under community governance.

July 2025: Google releases A2A SDK improvements with gRPC support and security extensions.

August 2025: Cloudflare documents Agents on the Edge capabilities, combining persistence, workflows, and real-time human control.

2. Why Now and Not Before?

Agents existed in potential since the first attention architectures and autoregressive models developed in the early 2020s. Those architectures, introduced in Attention Is All You Need (Vaswani et al., 2017), replaced recurrence with attention mechanisms capable of dynamically weighing which parts of a sequence are relevant given the context. For the first time, statistical computation had the ability to reason in a distributed way, retaining long dependencies and learning to assign focus, a principle closer to thought than to mere calculation. That was the origin of a new form of intelligence, one that not only processes information but decides what to process.

In that sense, agents already had a brain but lacked a body. Attention gave them memory, rudimentary reasoning, and planning, yet they remained confined to experimental labs. What was missing was the infrastructure, standards, and technical culture to embody them in production systems. Until 2023, agent execution remained costly, fragile, and fragmented, prototypes like AutoGPT or BabyAGI relied on manual setups, isolated APIs, and prohibitive resources. By 2025, however, several curves crossed. The maturity of edge computing, the standardization of protocols, and the drop in inference costs turned fragility into structure. The agentic era ceased to be a promise and became a tangible layer of the present, where distributed reasoning finally found an operational body.

2.1. Standardization and Governance

With the arrival of the Model Context Protocol (MCP) (Anthropic, 2024) and the Agent2Agent Protocol (A2A) (Google, 2025), communication among agents stopped being a proprietary experiment and became a standard. These protocols solved three historic problems, interoperability, authentication, and contextual transmission. For the first time, an OpenAI-based agent can invoke a tool hosted on Cloudflare, query data in Neon, and share state with another agent on Hugging Face without manual integrations or glue code. The openness of these standards not only enabled cooperation among distinct ecosystems but also introduced a principle of shared technical governance.

2.2. Mature Infrastructure and Falling Costs

Hardware stopped being a barrier. Between 2023 and 2025, the rise of NVIDIA H100 GPUs and GH200 Grace Hopper Superchips, together with the consolidation of edge computing, Cloudflare Workers AI, and AWS Local Zones, reduced latency and inference costs by more than 70%. Today, thanks to tools like the Agents SDK, an agent can run directly at the network edge, near the user, without relying on centralized servers. What once cost hundreds of dollars per day now costs cents per hour, and that economic leap changed the scale of experimentation.

2.3. Evaluation and Reproducibility

In parallel, the academic and engineering communities established reproducible evaluation mechanisms. Benchmarks like SWE-Bench (Stanford, 2023) and HELM (Stanford CRFM, 2022–2024) turned the measurement of agent performance into a verifiable, traceable discipline. Success is no longer measured by anecdotal demos but by consistent, comparable results. Just as ImageNet marked the leap in computer vision in 2012, SWE-Bench and HELM define the quality standard for autonomous intelligence.

2.4. Cultural and Cognitive Curve

But the transition wasn’t only technical, it was cultural. Mass exposure to ChatGPT, Copilot, and other conversational interfaces taught millions to dialogue with intelligent systems. We learned to iterate, correct, ask for explanations, and evaluate responses. The conversational interface replaced the button as the basic unit of interaction. For the first time, society learned the language of the models before the models learned the language of society.

2.5. Epistemological Transition

This change in scale and practice entailed an epistemological shift, computing ceased to be understood as executing instructions and became a process of negotiation. Humans no longer program tasks deterministically, they orchestrate intelligences that share agency and context. Programming stopped being synonymous with dictating orders and came to mean defining boundaries, intentions, and collaboration criteria.

2.6. Ecosystem and Adoption Pressure

Finally, the industrial ecosystem closed the loop. Cloudflare, Anthropic, Microsoft, and the Linux Foundation opened SDKs, APIs, and governance spaces where agents from different environments can coexist and cooperate. The cost of experimenting fell, interoperability rose, and the risk of not doing so became strategic. In 2020, adopting agents was a bet, in 2025, it is a requirement. What once was innovation is now infrastructure, and infrastructure, by definition, is no longer debated, it is simply used.

3. Historical Comparisons

Technology does not advance in jumps but in waves of integration, each revolution starts as curiosity, consolidates as habit, and ends up as infrastructure. Agentic AI follows the same evolutionary pattern. Like communication, the web, and mobility, it began as a demonstration of possibility and is on course to redefine digital life. Each earlier wave expanded the reach of human machine interaction and left a new language behind. The fourth wave, agenticity, seeks not merely to extend artificial intelligence but to turn it into the new fabric of collaboration.

3.1. Email (1971): Communication as a Layer

In 1971, Ray Tomlinson sent the first electronic message over ARPANET, linking user and machine with the @ symbol. It was not a commercial product but a technical experiment, yet it defined a principle that would transform the world, asynchronous communication between distributed nodes. For the first time, distance ceased to be a temporal barrier to message transmission. Half a century later, email has become invisible, we no longer perceive it as technology, yet it underpins digital identity, authentication, and notifications in virtually all systems (Tomlinson, 1971). What began as a hack on a military network ended up as the basic grammar of human connectivity. The invisible, as always, is what endures.

3.2. The Web (1990): Hypertext as the World’s Structure

In 1990, Tim Berners-Lee proposed the World Wide Web as a tool to link scientific documents. Its hypertext system, HTTP, URL, HTML, was rudimentary, but its simplicity made it universal. What started as an information network for researchers became a global fabric interconnecting culture, economy, and education (Berners-Lee, 1990). The web did not just organize knowledge, it defined how we inhabit it. Today it is not a collection of pages but the invisible base of all digital interaction. It did not displace software, it absorbed it, turning it into surface, medium, and context at the same time.

3.3. Mobility (2007): Ubiquity as a Condition

In 2007, Steve Jobs introduced the iPhone as “three devices in one”, a phone, an iPod, and a browser. At the time, it was a luxury object, not a standard, but it changed the human technology relationship forever. In less than a decade, mobility became the lowest common denominator of every digital experience, personal, ubiquitous, and always available. Interfaces, content, and infrastructure reconfigured around the user on the move (Jobs, 2007). Mobility did not replace the web, it extended it into the pocket. Its true legacy was not the device but the expectation of immediacy and constant presence that still shapes contemporary design.

3.4. The Agentic Era (2025): Collaboration as Fabric

Agentic AI represents the fourth wave, agency understood as infrastructure. Just as email decentralized communication, the web decentralized information, and mobility decentralized access, agents are decentralizing action. They are no longer mere assistants or accessory tools, but interoperable actors capable of reasoning, executing, and collaborating with humans and systems. Their presence today is visible in dashboards, flows, and prototypes, although their destiny is to become invisible and form part of every application and digital environment. In a few years, the concept of an “agent” will be as everyday as “web” or “app”, a functional unit integrated into the contemporary software ecosystem.

3.5. Synthesis

The adoption of agents is not an emerging fad but a natural evolution of computing as social fabric. Each prior wave prepared the next, email taught us to wait, the web to search, mobility to be present, and Agentic AI will teach us to delegate. In all of them, the extraordinary became mundane and the visible disappeared. Agenticity will follow the same path. Its purpose is not to occupy center stage but to support the system’s operation from its base. When the presence of agents goes unnoticed, it will mean their integration is complete and the new cognitive infrastructure has matured.

4. The Parallel with Frontend

In frontend we learned that usability and accessibility were not embellishments but foundations. They are not tacked on at the end, they are conceived from the beginning. The same is true with Agentic AI. What today looks like an experiment, a talking interface, a proposing assistant, will soon become the base on which all digital experiences are built. This shift not only broadens the scope of design but redefines its purpose, it is no longer enough for an interface to be functional or aesthetic, it must also be explanatory, negotiable, and trustworthy.

4.1. From Interface to Dialogue

For years, frontend translated human intent into action via clicks, gestures, or animations. The agentic era alters that grammar, the minimal unit of interaction is no longer the click but the conversation. Designing for agents means designing relationships, not just screens. It involves thinking how the system explains what it will do, how it seeks permission, and how it demonstrates it understood the user’s intent. In this new paradigm, the challenge is not moving pixels but building trust, deciding when the agent should propose, when it should wait, and when it should act on its own without breaking the sense of human control.

4.2. From Experience to Transparency

The quality of a digital experience is no longer measured only by its smoothness but by its ability to reveal the reasons behind each decision. An agent that acts without showing its reasoning breeds distrust, one that exposes its logic, sources, or motivations feels more legitimate. Transparency replaces efficiency as a marker of maturity. The contemporary user does not just want to achieve a goal but to understand why the system achieved it that way and how to undo it if desired. In that mutual understanding, trust is born, and with it, the new canon of agentic design.

4.3. From Standards to Fabric

Just as usability and accessibility became the silent language of frontend, unseen yet essential, agenticity will follow suit. Soon we will not debate whether a product “should have” an agent, it simply will, as products today have semantic HTML or ARIA labels. Agency will become part of software’s invisible fabric, expressed in measurable properties like decision traceability, guaranteed reversal, or accessible explanation. In that environment, frontend reclaims its deepest essence, being the meeting point between machine reason and human empathy, the space where intelligence takes shape, tone, and context.

4.4. What’s Next

The upcoming challenges of agentic design will center on defining new interaction patterns, how to request confirmation, how to communicate intent before acting, how to negotiate ambiguous actions or offer safe alternatives. These patterns, still forming, must be evaluated with trust, transparency, and perceived control metrics. Designing for autonomy does not mean abandoning supervision, it means integrating it into the experience. Future explorations should map these principles, name them, and standardize them, just as we once did with components and accessibility guidelines.

4.5. Synthesis

If the web taught us to communicate and mobility to accompany, Agentic AI will teach us to collaborate and delegate. Frontend will be the stage where this collaboration occurs, the space where humans and systems learn to understand each other, correct each other, and co-design the flow of action. What we once measured as “interface” we will soon call “relationship”. And within that relationship, agenticity will cease to be optional and become structure, as inevitable as accessibility, as invisible as the network that sustains it.

5. Impact on Software Work

The incorporation of agents does not eliminate the software engineer’s role, it reconfigures it. As with deployment automation or higher-level frameworks, the change does not imply the disappearance of work but its shift toward a more abstract, strategic level. Agents expand the scope of engineering, they do not replace it. Their deepest effect is not measured in lines of code written but in the decisions that define how, when, and for what purpose that code is generated.

5.1. From Execution to Supervision

Agents already automate a significant part of the development cycle, they generate documentation, propose unit tests, refactor functions, detect obsolete dependencies, and even draft explanatory commits. Tasks once manual and repetitive now become points of collaboration between humans and systems. Code stops being the final product and becomes the starting point of a conversation. The developer’s role expands, from executing instructions to defining behaviors, boundaries, and policies for the agents that will do so. Responsibility is no longer purely technical, it is also ethical and contextual, because supervising intelligences requires understanding not only what they do but why they do it.

5.2. Emerging Roles

New professional functions arise from this transition:

AI Product Engineer: integrates AI as part of the product design and development cycle, not as an external add-on.
AI Orchestrator: designs multi-agent flows, defines collaboration protocols, and tunes performance and trust metrics.
AI Interaction Designer: creates hybrid experiences where humans and agents share tasks and control.

These profiles do not replace existing roles, they complement and expand them. Just as DevOps culture did not eliminate backend engineers, agents will not eliminate frontend or architects, but they will redraw the boundary between design, development, and supervision.

5.3. Changes in the Software Economy

The economic impact of this transformation will be gradual and cumulative. Various studies (Acemoglu, 2023; Brookings Institution, 2024) indicate that the adoption of generative AI tends to redistribute tasks rather than eliminate jobs. Routine functions, testing, documentation, internal support, are first to be automated, while review, integration, and systems supervision grow in demand. Consequently, AI does not replace technical work, it specializes it. Value shifts toward reliability, orchestration, and interpretation of results, dimensions where human judgment remains indispensable.

5.4. Supervising Intelligences, Not Just Systems

The deepest change is not laboral but cognitive. Engineering moves from supervising deterministic software to supervising systems that reason, fail, and correct themselves. This shift demands new competencies, critical thinking, understanding of biases, trust design, and reading explanatory metrics. Programming ceases to mean merely building machines that function and becomes the task of creating systems that understand their purpose and can explain their decisions. Engineering thus becomes a practice of interpretation, where the boundaries between writing code and educating models grow progressively blurrier.

5.5. A Necessary Close

Engineers do not disappear, they evolve. They move from authors of code to supervisors of behavior, and from system architects to orchestrators of intelligences. Software work changes shape but not purpose, it remains the art of building the tools that define how we think, work, and create. Agentic AI does not replace engineering, it amplifies it, reminding us that technology transforms not only what we do but also how we understand what it means to create.

6. Limitations and Next Steps

This essay focuses on the structural and cultural dimension of Agentic AI rather than its technical implementation. The choice is not an omission but a necessity, before describing how agentic systems are built, it was essential to understand why they arise and when they become inevitable. As with every technological wave, understanding precedes standardization. Before the web had browsers or mobility had sensors, there was a shared narrative that gave meaning to their existence. Agenticity is in that same foundational phase, it requires a common language, a conceptual grammar capable of articulating the relationship between autonomy, interoperability, and trust. This text sought to contribute precisely to that base, outlining the factors that transformed a technical curiosity into a structural layer of contemporary software.

In that pursuit, topics demanding a more applied treatment were left out, the interaction patterns that will define collaboration between humans and agents, the transparency and trust metrics needed to assess performance, and the ethical frameworks that will ensure responsible operation. Including them would have diverted from the main purpose, which was to trace the historical and conceptual trajectory of Agentic AI and show how it integrates into the natural evolution of the frontend. Nevertheless, these topics are the next logical step. Future explorations will focus on how to design communication with reasoning systems, how to measure the reliability of their decisions, and what governance principles should accompany their deployment. The challenge will not be merely technical but epistemological, learning to design relationships with intelligences that also design.

The agentic era is only beginning, but its direction is already in sight. It is not just another trend within the AI cycle but a deep reconfiguration of how knowledge is organized and circulates within digital systems. Agents do not just execute tasks, they interpret, argue, and co-construct meaning with us. Understanding this transition and actively participating in its design will be a shared responsibility among engineers, designers, and thinkers. Because beyond code, Agentic AI confronts us with an essential question, how do we want to think, decide, and create in a world where intelligence, human or artificial, ceases to be a tool and becomes infrastructure?

Conclusion

Agentic AI is not a future hypothesis but a reality taking shape since 2022. Like email, the web, and mobility, its adoption follows an inevitable curve, from curiosity to infrastructure. The difference is that this time the change occurs within the software development cycle itself.

A clear example can be seen in the frontend, today it is possible to deploy agents directly at the edge via Cloudflare Workers AI or the Agents SDK, capable of adapting the interface, analyzing user intent, and adjusting the experience in real time. These hybrid flows, where human and agent negotiate visual or content decisions, show how agenticity stops being an add-on and becomes a structural property of interaction.

Just as we learned that you cannot design without considering accessibility, soon you will not be able to design without considering agency. Although products that ignore usability or accessibility are still approved today, the norm has already changed, they are part of the canon of modern frontend. The same will happen with Agentic AI. It will not be an add-on but the foundation on which we build software that learns, collaborates, and evolves with us.

The essential difference in this wave lies in its cognitive nature, it does not merely extend technical infrastructure but redefines how knowledge is organized and how decision flows within systems. Agentic AI inaugurates the cognitive infrastructure of the 21st century, a network where every agent, human or artificial, acts as a thinking node within a shared fabric.

Understanding and designing for this new infrastructure is not just an engineering task but a cultural responsibility. It is at this convergence of code, decision, and awareness where the future of software will be decided, and with it, our way of thinking alongside machines.

References

Acemoglu, D. (2023). Artificial Intelligence and the Future of Work. MIT Press.
https://nap.nationalacademies.org/read/27644/chapter/1

Anthropic. (2024, noviembre 25).Introducing the Model Context Protocol. [Blog post]. Anthropic.
https://www.anthropic.com/news/model-context-protocol

Berners-Lee, T. (1990). Information Management: A Proposal. CERN.
https://www.w3.org/History/1989/proposal.html

Brookings Institution. (2024). Generative AI, the American worker, and the future of work. Brookings Institution Report.
https://www.brookings.edu/articles/generative-ai-the-american-worker-and-the-future-of-work/

Cloudflare. (2025, febrero 25). Introducing the Agents SDK
https://developers.cloudflare.com/changelog/2025-02-25-agents-sdk/

Cloudflare. (2025, abril). Piecing together the Agent puzzle: MCP, authentication & authorization, and Durable Objects free tier. Cloudflare Blog.
https://blog.cloudflare.com/building-ai-agents-with-mcp-authn-authz-and-durable-objects/

Cloudflare. (2025, junio 3). Building an AI Agent that puts humans in the loop with Knock and Cloudflare’s Agents SDK. Cloudflare Blog.
https://blog.cloudflare.com/building-agents-at-knock-agents-sdk/

Google. (2025, abril 9). Announcing the Agent2Agent Protocol (A2A). Google Developers Blog.
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

Google Cloud. (2025, julio). Announcing a complete developer toolkit for scaling A2A agents on Google Cloud. Google Cloud Blog.
https://cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade

IEEE Computer Society. (2002). Standards and Interoperability – IEEE Power & Energy Society Multi-Agent Systems Working Group. IEEE Press.
https://site.ieee.org/pes-mas/agent-technology/standards-and-interoperability/

Jimenez, C., et al. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.
https://arxiv.org/abs/2310.06770

Linux Foundation. (2025, junio 23). Linux Foundation Launches the Agent2Agent Protocol Project to Enable Secure, Intelligent Communication Between AI Agents. Linux Foundation.
https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents

NVIDIA Corporation. (2023). NVIDIA H100 Tensor Core GPU. NVIDIA Technical Whitepaper.
https://www.nvidia.com/en-us/data-center/h100/

NVIDIA Corporation. (2024). V1.21 NVIDIA GH200 Grace Hopper Superchip Architecture
https://resources.nvidia.com/en-us-grace-cpu/nvidia-grace-hopper

OpenAI. (2022, noviembre 30). Introducing ChatGPT. OpenAI Blog.
https://openai.com/index/chatgpt/

OpenAI. (2025, marzo 11). New features in the Responses API. OpenAI Blog.
https://openai.com/index/new-tools-for-building-agents/

OpenAI. (2025, mayo 21). New tools and features in the Responses API. OpenAI Blog.
https://openai.com/index/new-tools-and-features-in-the-responses-api/

Schick, T., Dwivedi-Yu, J., & Schütze, H. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761.
https://arxiv.org/abs/2302.04761

Significant Gravitas. (2023, marzo 30). Auto-GPT Repository. GitHub.
https://github.com/Torantulino/Auto-GPT

Stanford Center for Research on Foundation Models (CRFM). (2022–2024). HELM: A holistic framework for evaluating foundation models. Stanford University.
https://crfm.stanford.edu/helm/classic/latest/

Tomlinson, R. (1971). 1971: First Ever Email.
https://www.guinnessworldrecords.com/news/2015/8/60/1971-first-ever-email-392973

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention Is All You Need. arXiv:1706.03762
https://arxiv.org/abs/1706.03762

arXiv. (2025, abril 2). MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits. arXiv:2504.03767.
https://arxiv.org/abs/2504.03767

arXiv. (2025, junio 16). Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers. arXiv:2506.13538.
https://arxiv.org/abs/2506.13538

La Era Agentic: de la Inteligencia Artificial a la Infraestructura Cognitiva

Pillippa Ignacia Pérez Pons — Wed, 08 Oct 2025 04:00:21 +0000

Resumen

La Agentic AI constituye la nueva ola tecnológica, impulsada por agentes capaces de razonar y ejecutar tareas con autonomía. Su madurez actual no responde a una moda, sino a la convergencia de tres factores: estandarización (MCP, A2A), infraestructura distribuida y validación empírica mediante benchmarks reproducibles.

Este ensayo sostiene que la inflexión comenzó con la masificación de los modelos de lenguaje en 2022 y se consolidó entre 2024 y 2025, siguiendo el patrón de olas previas como el correo electrónico, la web y la movilidad. Desde la perspectiva del desarrollo frontend, se argumenta que la agenticidad dejará de ser un rasgo opcional para convertirse en una capa estructural, al mismo nivel que la usabilidad y la accesibilidad.

Este texto traza la línea de tiempo de esa inflexión, analiza los factores que la hicieron posible y propone una lectura sobre cómo la agenticidad se integra en la infraestructura cognitiva del software contemporáneo. Además, forma parte de una serie dedicada a explorar la transición hacia una infraestructura donde humanos y sistemas comparten agencia. En esta primera entrega se abordan los fundamentos conceptuales, históricos y técnicos de la Agentic AI; en futuras, se profundizará en los patrones de interacción, las métricas de confianza y el diseño agentic aplicado.

Introducción

Ninguna revolución tecnológica comienza declarándose como tal. Primero surge como curiosidad, luego se convierte en experimento y solo después se transforma en estructura. Así ocurrió con el correo electrónico en los años setenta, con la web en los noventa y con la movilidad a partir de 2007. En cada caso, lo que nació como una idea marginal terminó convirtiéndose en una capa esencial del mundo digital, invisible pero indispensable.

En 2025, la Agentic AI recorre el mismo trayecto. Lo que en 2023 parecía un conjunto de pruebas frágiles y dispersas se ha consolidado en una capa transversal de la infraestructura tecnológica. Los agentes, entidades capaces de razonar, ejecutar tareas y colaborar con humanos y sistemas, han pasado del laboratorio al entorno productivo y del prototipo al estándar. Este ensayo sostiene que su presencia ya no pertenece al terreno de la especulación, sino al de la práctica cotidiana, y que su integración transformará no sólo la forma en que programamos, sino también la manera en que concebimos la relación entre inteligencia y software.

Desde la perspectiva del desarrollo frontend, la agenticidad representa una nueva capa estructural. Al igual que la usabilidad o la accesibilidad, dejará de ser un rasgo opcional para convertirse en un principio inherente del diseño y la arquitectura de interfaces. Su impacto no se limita a la interacción, sino que redefine la noción misma de colaboración entre humanos y máquinas. Comprender esta transición, que va de la automatización a la autonomía y del código al comportamiento, es fundamental para anticipar cómo se configurará la próxima década del software.

1. Una línea de tiempo de la inflexión

2002: Publicación de los estándares FIPA Agent Communication Language (ACL) y Agent Communication Protocol (ACP) por IEEE, estableciendo la base de interoperabilidad entre agentes.
30 de noviembre de 2022: Lanzamiento público de ChatGPT, que democratiza el acceso a los modelos de lenguaje y marca el inicio de la adopción masiva de IA generativa.
Febrero de 2023: Publicación de Toolformer, paper de Meta AI que demuestra que los LLM pueden aprender a usar herramientas externas sin supervisión directa.
30 de marzo de 2023: Aparece Auto-GPT, primer agente autónomo popular basado en GPT-4, que introduce la noción de auto-orquestación y ejecución de subtareas.
10 de octubre de 2023: Se publica SWE-Bench, benchmark reproducible para medir si los agentes pueden resolver bugs reales en repositorios de software.
25 de noviembre de 2024: Anthropic introduce el Model Context Protocol (MCP), un estándar abierto que permite conectar agentes con herramientas y contextos de datos.
25 de febrero de 2025: Cloudflare lanza el Agents SDK, habilitando la construcción y despliegue de agentes en el edge a través de Workers y Workers AI.
2 de abril de 2025: Publicación del paper MCP Safety Audit, que identifica riesgos de seguridad y vulnerabilidades en implementaciones del protocolo MCP.
9 de abril de 2025: Google anuncia el Agent2Agent Protocol (A2A), diseñado para permitir la comunicación directa entre agentes de distintos proveedores.
3 de junio de 2025: Cloudflare publica ejemplos de patrones human-in-the-loop usando el Agents SDK, mostrando cómo los agentes pueden incorporar decisiones humanas en tiempo real.
11 de marzo de 2025: OpenAI lanza la Responses API, sucesora de Assistants, enfocada en flujos de agente y soporte a MCP.
21 de mayo de 2025: OpenAI agrega soporte para servidores MCP remotos dentro de la Responses API, consolidando la interoperabilidad.
16 de junio de 2025: Publicación del estudio MCP at First Glance, que analiza seguridad y mantenibilidad de servidores MCP.
23 de junio de 2025: La Linux Foundation acoge el proyecto Agent2Agent (A2A) como protocolo abierto bajo gobernanza comunitaria.
Julio de 2025: Google publica mejoras del A2A SDK con soporte gRPC y extensiones de seguridad.
Agosto de 2025: Cloudflare documenta las capacidades de Agents on the Edge, combinando persistencia, workflows y control humano en tiempo real.

2. ¿Por qué ahora y no antes?

Los agentes existían en potencia desde las primeras arquitecturas de atención y los modelos autoregresivos desarrollados a comienzos de la década de 2020. Aquellas arquitecturas, introducidas en el paper Attention Is All You Need (Vaswani et al., 2017), reemplazaron la recurrencia por mecanismos de atención capaces de ponderar dinámicamente qué partes de una secuencia son relevantes según el contexto. Por primera vez, la computación estadística adquiría la capacidad de razonar de forma distribuida, reteniendo dependencias largas y aprendiendo a asignar foco, un principio más cercano al pensamiento que al cálculo. Ese fue el punto de origen de una nueva forma de inteligencia: una que no solo procesa información, sino que decide qué procesar.

En ese sentido, el cerebro de los agentes ya existía, pero carecía de cuerpo. La atención les dio memoria, razonamiento y planificación rudimentarios, aunque seguían confinados a laboratorios experimentales. Faltaba la infraestructura, los estándares y la cultura técnica que permitieran encarnarlos en sistemas productivos. Hasta 2023, la ejecución de agentes seguía siendo costosa, frágil y fragmentada: los prototipos como AutoGPT o BabyAGI dependían de configuraciones manuales, APIs aisladas y recursos prohibitivos. Sin embargo, hacia 2025, varias curvas se cruzaron. La madurez del edge computing, la estandarización de protocolos y la caída de los costos de inferencia convirtieron esa fragilidad en estructura. La era agentic dejó de ser una promesa y se transformó en una capa tangible del presente, donde el razonamiento distribuido encontró finalmente un cuerpo operativo.

2.1. Estandarización y gobernanza

Con la llegada del Model Context Protocol (MCP) (Anthropic, 2024) y el Agent2Agent Protocol (A2A) (Google, 2025), la comunicación entre agentes dejó de ser un experimento propietario para convertirse en un estándar. Estos protocolos resolvieron tres problemas históricos: la interoperabilidad, la autenticación y la transmisión contextual. Por primera vez, un agente de OpenAI puede invocar una herramienta alojada en Cloudflare, consultar datos en Neon y compartir estado con otro agente en Hugging Face sin integraciones manuales ni código adhesivo. La apertura de estos estándares no sólo habilitó la cooperación entre ecosistemas distintos, sino que introdujo un principio de gobernanza técnica compartida.

2.2. Infraestructura madura y costos descendentes

El hardware dejó de ser una barrera. Entre 2023 y 2025, la aparición de GPUs NVIDIA H100 y GH200 Grace Hopper Superchips, junto con la consolidación del edge computing, Cloudflare Workers AI, AWS Local Zones, redujo la latencia y el costo de inferencia en más de un 70%. Hoy, gracias a herramientas como el Agents SDK, un agente puede ejecutarse directamente en el borde de la red, cerca del usuario, sin depender de servidores centralizados. Lo que antes costaba cientos de dólares diarios ahora cuesta centavos por hora, y ese salto económico cambió la escala de la experimentación.

2.3. Evaluación y reproducibilidad

Paralelamente, la comunidad académica y de ingeniería estableció mecanismos de evaluación reproducibles. Benchmarks como SWE-Bench (Stanford, 2023) y HELM (Stanford CRFM, 2022–2024) transformaron la medición de desempeño de los agentes en una disciplina verificable y trazable. El éxito ya no se mide por demostraciones anecdóticas, sino por resultados consistentes y comparables. Así como ImageNet marcó el salto en visión por computadora en 2012, SWE-Bench y HELM definen el estándar de calidad para la inteligencia autónoma.

2.4. Curva cultural y cognitiva

Pero la transición no fue solo técnica: también fue cultural. La exposición masiva a ChatGPT, Copilot y otras interfaces conversacionales enseñó a millones de personas a dialogar con sistemas inteligentes. Aprendimos a iterar, corregir, pedir explicaciones y evaluar respuestas. La interfaz conversacional reemplazó al botón como unidad básica de interacción. La sociedad, por primera vez, aprendió el lenguaje de los modelos antes de que los modelos aprendieran el de la sociedad.

2.5. Transición epistemológica

Este cambio de escala y de práctica implicó una mutación epistemológica: la computación dejó de entenderse como ejecución de instrucciones para convertirse en un proceso de negociación. Los humanos ya no programan tareas de forma determinista; orquestan inteligencias que comparten agencia y contexto. Programar dejó de ser sinónimo de dictar órdenes y pasó a significar definir límites, intenciones y criterios de colaboración.

2.6. Ecosistema y presión de adopción

Finalmente, el ecosistema industrial cerró el círculo. Cloudflare, Anthropic, Microsoft y la Linux Foundation abrieron SDKs, APIs y espacios de gobernanza donde agentes de distintos entornos pueden coexistir y cooperar. El costo de experimentar cayó, la interoperabilidad aumentó y el riesgo de no hacerlo se volvió estratégico. En 2020, adoptar agentes era una apuesta; en 2025, es un requisito. Lo que antes era innovación hoy se volvió infraestructura, y la infraestructura, por definición, ya no se discute: simplemente se usa.

3. Comparaciones históricas

La historia de la tecnología no avanza en saltos, sino en ondas de integración: cada revolución comienza como curiosidad, se consolida como hábito y termina convertida en infraestructura. La Agentic AI sigue ese mismo patrón evolutivo. Al igual que la comunicación, la web y la movilidad, empezó como demostración de posibilidad y se encamina a redefinir la vida digital. Cada ola previa amplió el alcance de la interacción humana con las máquinas, y cada una dejó un nuevo lenguaje detrás. La cuarta ola,la agenticidad, no busca solo extender la inteligencia artificial, sino convertirla en el nuevo tejido de colaboración.

3.1 El correo electrónico (1971): la comunicación como capa

En 1971, Ray Tomlinson envió el primer mensaje electrónico a través de ARPANET, uniendo usuario y máquina con el símbolo @. No fue un producto comercial, sino un experimento técnico, pero en ese gesto se definió un principio que transformaría el mundo: la comunicación asíncrona entre nodos distribuidos. Por primera vez, la distancia dejó de ser una barrera temporal en la transmisión de mensajes. Medio siglo después, el correo electrónico se ha vuelto invisible: ya no lo percibimos como tecnología, pero sostiene la identidad digital, la autenticación y la notificación en prácticamente todos los sistemas (Tomlinson, 1971). Lo que nació como un hack en una red militar terminó convirtiéndose en la gramática básica de la conectividad humana. Lo invisible, como siempre, es lo que perdura.

3.2 La web (1990): el hipertexto como estructura del mundo

En 1990, Tim Berners-Lee propuso la World Wide Web como una herramienta para enlazar documentos científicos. Su sistema de hipertexto basado en HTTP, URL, HTML, era rudimentario, pero su simplicidad lo volvió universal. Lo que empezó como una red de información para investigadores se transformó en un tejido global que interconectó la cultura, la economía y la educación (Berners-Lee, 1990). La web no solo organizó el conocimiento: definió la forma en que lo habitamos. Hoy no es un conjunto de páginas, sino la base invisible de toda interacción digital. No desplazó al software: lo absorbió, convirtiéndolo en superficie, medio y contexto al mismo tiempo.

3.3 La movilidad (2007): la ubicuidad como condición

En 2007, Steve Jobs presentó el iPhone como “tres dispositivos en uno”: un teléfono, un iPod y un navegador. En ese momento era un objeto de lujo, no un estándar, pero cambió para siempre la relación entre humanos y tecnología. En menos de una década, la movilidad se convirtió en el mínimo común denominador de toda experiencia digital: personal, ubicua y siempre disponible. Las interfaces, el contenido y la infraestructura se reconfiguraron alrededor del usuario en movimiento (Jobs, 2007). La movilidad no reemplazó la web: la extendió hasta el bolsillo. Su verdadero legado no fue el dispositivo, sino la expectativa de inmediatez y presencia constante que aún define el diseño contemporáneo.

3.4 La agentic era (2025): la colaboración como tejido

La Agentic AI representa la cuarta ola: la agencia entendida como infraestructura. Así como el correo electrónico descentralizó la comunicación, la web descentralizó la información y la movilidad descentralizó el acceso, los agentes están descentralizando la acción. Ya no son asistentes ni herramientas accesorias, sino actores interoperables capaces de razonar, ejecutar y colaborar con humanos y sistemas. Su presencia actual es visible en paneles, flujos y prototipos, aunque su destino es volverse invisible y formar parte de cada aplicación y entorno digital. En pocos años, el concepto de “agente” será tan cotidiano como el de “web” o “app”: una unidad funcional integrada en el ecosistema de software contemporáneo.

3.5 Síntesis

La adopción de agentes no constituye una moda emergente, sino una evolución natural de la computación como tejido social. Cada ola anterior preparó la siguiente: el correo electrónico nos enseñó a esperar, la web a buscar, la movilidad a estar, y la Agentic AI nos enseñará a delegar. En todas ellas, lo extraordinario se volvió cotidiano y lo visible terminó desapareciendo. La agenticidad seguirá el mismo camino. Su propósito no es ocupar el centro de la atención, sino sostener el funcionamiento del sistema desde su base. Cuando la presencia de los agentes deje de notarse, significará que su integración se habrá completado y que la nueva infraestructura cognitiva habrá madurado.

4. El paralelismo con el frontend

En el frontend aprendimos que la usabilidad y la accesibilidad no eran adornos, sino cimientos. No se añadían al final del desarrollo: se concebían desde el principio. Con la Agentic AI sucede lo mismo. Lo que hoy parece un experimento, una interfaz que conversa, un asistente que propone, pronto se volverá la base sobre la cual se construye toda experiencia digital. Este cambio no solo amplía el alcance del diseño, sino que redefine su propósito: ya no basta con que una interfaz sea funcional o estética, ahora también debe ser explicativa, negociable y confiable.

4.1 De la interfaz al diálogo

Durante años, el frontend tradujo la intención humana en acción mediante clics, gestos o animaciones. La era agentic altera esa gramática: la unidad mínima de interacción ya no es el clic, sino la conversación. Diseñar para agentes implica diseñar relaciones, no solo pantallas. Supone pensar cómo el sistema explica lo que hará, cómo solicita permiso y cómo demuestra que comprendió la intención del usuario. En este nuevo paradigma, el desafío no consiste en mover píxeles, sino en construir confianza: decidir cuándo el agente debe proponer, cuándo debe esperar, y cuándo actuar por sí mismo sin romper la sensación de control humano.

4.2 De la experiencia a la transparencia

La calidad de una experiencia digital ya no se mide únicamente por su fluidez, sino por su capacidad para revelar las razones detrás de cada decisión. Un agente que actúa sin mostrar su razonamiento genera desconfianza; uno que expone su lógica, fuentes o motivaciones se percibe como más legítimo. La transparencia reemplaza a la eficiencia como indicador de madurez. El usuario contemporáneo no busca solo alcanzar un objetivo, sino entender por qué el sistema lo logró de esa manera y cómo puede revertirlo si lo desea. En esa comprensión mutua nace la confianza, y con ella, el nuevo canon del diseño agentic.

4.3 De los estándares al tejido

Así como la usabilidad y la accesibilidad se convirtieron en el lenguaje silencioso del frontend, invisibles pero imprescindibles, la agenticidad seguirá el mismo camino. Pronto no se discutirá si un producto “debería tener” un agente: simplemente lo tendrá, como hoy tiene HTML semántico o etiquetas ARIA. La agencia se volverá parte del tejido invisible del software, expresada en propiedades medibles como trazabilidad de decisiones, reversión garantizada o explicación accesible. En ese entorno, el frontend recupera su esencia más profunda: ser el punto de encuentro entre la razón de las máquinas y la empatía humana, el espacio donde la inteligencia adquiere forma, tono y contexto.

4.4 Lo que viene

Los próximos desafíos del diseño agentic se centrarán en definir nuevos patrones de interacción: cómo se pide confirmación, cómo se comunica la intención antes de actuar, cómo se negocian acciones ambiguas o se ofrecen alternativas seguras. Estos patrones, aún en formación, deberán ser evaluados con métricas de confianza, transparencia y control percibido. Diseñar para la autonomía no significa renunciar a la supervisión, sino integrarla en la experiencia. Las futuras exploraciones deberán trazar estos principios, nombrarlos y estandarizarlos, del mismo modo que en su momento hicimos con los componentes y las guías de accesibilidad.

4.5 Síntesis

Si la web nos enseñó a comunicar y la movilidad a acompañar, la Agentic AI nos enseñará a colaborar y delegar. El frontend será el escenario donde esa colaboración ocurra: el espacio donde humanos y sistemas aprenden a entenderse, se corrigen mutuamente y co-diseñan el flujo de acción. Lo que antes medíamos como interfaz pronto lo llamaremos relación. Y en esa relación, la agenticidad dejará de ser una opción para convertirse en estructura: tan inevitable como la accesibilidad, tan invisible como la red que la sostiene.

5. Impacto en el trabajo de software

La incorporación de agentes no elimina el rol del ingeniero de software: lo reconfigura. Como ocurrió con la automatización de despliegues o con los frameworks de alto nivel, el cambio no implica la desaparición del trabajo, sino su desplazamiento hacia un nivel más abstracto y estratégico. Los agentes amplían el alcance de la ingeniería, no la sustituyen. Su efecto más profundo no se mide en líneas de código escritas, sino en las decisiones que definen cómo, cuándo y con qué propósito ese código se genera.

5.1. De la ejecución a la supervisión

Los agentes ya automatizan una parte significativa del ciclo de desarrollo: generan documentación, proponen tests unitarios, refactorizan funciones, detectan dependencias obsoletas e incluso redactan commits explicativos. Estas tareas, antes manuales y repetitivas, ahora se convierten en puntos de colaboración entre humanos y sistemas. El código deja de ser el producto final para transformarse en el punto de partida de una conversación. El rol del desarrollador se expande: pasa de ejecutar instrucciones a definir comportamientos, límites y políticas para los agentes que lo harán. La responsabilidad deja de ser únicamente técnica y se vuelve también ética y contextual, pues supervisar inteligencias requiere comprender no solo qué hacen, sino por qué lo hacen.

5.2. Nuevos perfiles emergentes

De esta transición surgen nuevas funciones profesionales:

AI Product Engineer: integra inteligencia artificial como parte del ciclo de diseño y desarrollo del producto, no como un añadido externo.

AI Orchestrator: diseña flujos multi-agente, define protocolos de colaboración y ajusta métricas de rendimiento y confianza.

AI Interaction Designer: crea experiencias híbridas donde humanos y agentes comparten tareas y control.

Estos perfiles no sustituyen a los roles existentes, sino que los complementan y los expanden. Así como la cultura DevOps no eliminó al ingeniero backend, los agentes no eliminarán al frontend ni al arquitecto, pero sí redefinirán la frontera entre diseño, desarrollo y supervisión.

5.3. Cambios en la economía del software

El impacto económico de esta transformación será gradual y acumulativo. Diversos estudios (Acemoglu, 2023; Brookings Institution, 2024) indican que la adopción de inteligencia artificial generativa tiende a redistribuir tareas más que a eliminar empleos. Las funciones rutinarias, como las pruebas, la documentación o el soporte interno, son las primeras en automatizarse, mientras que la revisión, la integración y la supervisión de sistemas aumentan en demanda. En consecuencia, la inteligencia artificial no sustituye el trabajo técnico, sino que lo especializa. El valor se desplaza hacia la confiabilidad, la orquestación y la interpretación de resultados, dimensiones donde el criterio humano sigue siendo indispensable.

5.4. Supervisar inteligencias, no sólo sistemas

El cambio más profundo no es laboral, sino cognitivo. La ingeniería pasa de supervisar software determinista a supervisar sistemas que razonan, fallan y corrigen. Este giro exige nuevas competencias: pensamiento crítico, comprensión de sesgos, diseño de confianza y lectura de métricas explicativas. Programar deja de significar únicamente construir máquinas que funcionan para convertirse en la tarea de crear sistemas que comprenden su propósito y pueden explicar sus decisiones. La ingeniería se transforma así en una práctica de interpretación, donde los límites entre escribir código y educar modelos se vuelven progresivamente más difusos.

5.5. Un cierre necesario

Los ingenieros no desaparecen; evolucionan. Pasan de ser autores de código a supervisores de comportamiento, y de arquitectos de sistemas a orquestadores de inteligencias. El trabajo de software cambia de forma, pero no de propósito: sigue siendo el arte de construir las herramientas que definen cómo pensamos, trabajamos y creamos. La Agentic AI no reemplaza la ingeniería, sino que la amplifica, recordándonos que la tecnología no solo transforma lo que hacemos, sino también la manera en que entendemos lo que significa crear.

6. Limitaciones y próximos pasos

Este ensayo se centra en la dimensión estructural y cultural de la Agentic AI más que en su implementación técnica. La elección no responde a una omisión, sino a una necesidad: antes de describir cómo se construyen los sistemas agentic, era imprescindible comprender por qué surgen y en qué momento se vuelven inevitables. Como en toda ola tecnológica, la comprensión precede a la estandarización. Antes de que la web tuviera navegadores o la movilidad tuviera sensores, hubo una narrativa compartida que dio sentido a su existencia. La agenticidad se encuentra en esa misma fase fundacional: requiere un lenguaje común, una gramática conceptual capaz de articular la relación entre autonomía, interoperabilidad y confianza. Este texto buscó precisamente contribuir a esa base, delineando los factores que transformaron una curiosidad técnica en una capa estructural del software contemporáneo.

En esa búsqueda, quedaron fuera aspectos que demandan un tratamiento más aplicado: los patrones de interacción que definirán la colaboración entre humanos y agentes, las métricas de transparencia y confianza necesarias para evaluar su desempeño, y los marcos éticos que asegurarán una operación responsable. Incluirlos habría desviado el propósito principal, que fue trazar la trayectoria histórica y conceptual de la Agentic AI y mostrar cómo se integra en la evolución natural del frontend. No obstante, estos temas constituyen el siguiente paso lógico. Las próximas exploraciones se centrarán en cómo se diseña la comunicación con sistemas que razonan, cómo se mide la fiabilidad de sus decisiones y qué principios de gobernanza deben acompañar su despliegue. El desafío no será meramente técnico, sino epistemológico: aprender a diseñar relaciones con inteligencias que también diseñan.

La era agentic apenas comienza, pero su dirección ya se vislumbra. No se trata de una tendencia más dentro del ciclo de la inteligencia artificial, sino de una reconfiguración profunda del modo en que el conocimiento se organiza y circula en los sistemas digitales. Los agentes no solo ejecutan tareas: interpretan, argumentan y construyen sentido junto a nosotros. Comprender esa transición y participar activamente en su diseño será una responsabilidad compartida entre ingenieros, diseñadores y pensadores. Porque más allá del código, la Agentic AI nos enfrenta a una pregunta esencial: cómo queremos pensar, decidir y crear en un mundo donde la inteligencia ya sea humana o artificial, deja de ser herramienta para convertirse en infraestructura.

Conclusión

La Agentic AI no es una hipótesis futura, sino una realidad en consolidación desde 2022. Igual que el correo electrónico, la web y la movilidad, su adopción sigue una curva inevitable: de curiosidad a infraestructura. La diferencia es que esta vez el cambio ocurre dentro del propio ciclo de desarrollo de software.

Un ejemplo claro se observa en el frontend: hoy es posible desplegar agentes directamente en el edge mediante Cloudflare Workers AI o el Agents SDK, capaces de adaptar la interfaz, analizar la intención del usuario y ajustar la experiencia en tiempo real. Estos flujos híbridos donde humano y agente negocian decisiones visuales o de contenido, muestran cómo la agenticidad deja de ser una funcionalidad adicional y se convierte en una propiedad estructural de la interacción.

Así como aprendimos que no se puede diseñar sin pensar en accesibilidad, pronto no se podrá diseñar sin pensar en agencia. Aunque hoy se sigan aprobando productos que ignoran usabilidad o accesibilidad, la norma ya cambió: forman parte del canon del frontend moderno. Lo mismo ocurrirá con la Agentic AI. No será un añadido, sino el cimiento sobre el cual construiremos el software que aprende, colabora y evoluciona con nosotros.

La diferencia esencial de esta ola radica en su naturaleza cognitiva: no se limita a extender la infraestructura técnica, sino que redefine cómo se organiza el conocimiento y cómo fluye la decisión dentro de los sistemas. La Agentic AI inaugura la infraestructura cognitiva del siglo XXI: una red donde cada agente, humano o artificial, actúa como nodo pensante dentro de un tejido compartido.

Comprender y diseñar para esa nueva infraestructura no es solo una tarea de ingeniería, sino una responsabilidad cultural. En esa convergencia entre código, decisión y conciencia, es donde se jugará el futuro del software y, con él, nuestra forma de pensar con las máquinas.

Referencias

Acemoglu, D. (2023). Artificial Intelligence and the Future of Work. MIT Press.
https://nap.nationalacademies.org/read/27644/chapter/1

Anthropic. (2024, noviembre 25).Introducing the Model Context Protocol. [Blog post]. Anthropic.
https://www.anthropic.com/news/model-context-protocol

Berners-Lee, T. (1990). Information Management: A Proposal. CERN.
https://www.w3.org/History/1989/proposal.html

Cloudflare. (2025, febrero 25). Introducing the Agents SDK
https://developers.cloudflare.com/changelog/2025-02-25-agents-sdk/

Google. (2025, abril 9). Announcing the Agent2Agent Protocol (A2A). Google Developers Blog.
https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

Jimenez, C., et al. (2023). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.
https://arxiv.org/abs/2310.06770

NVIDIA Corporation. (2023). NVIDIA H100 Tensor Core GPU. NVIDIA Technical Whitepaper.
https://www.nvidia.com/en-us/data-center/h100/

NVIDIA Corporation. (2024). V1.21 NVIDIA GH200 Grace Hopper Superchip Architecture
https://resources.nvidia.com/en-us-grace-cpu/nvidia-grace-hopper

OpenAI. (2022, noviembre 30). Introducing ChatGPT. OpenAI Blog.
https://openai.com/index/chatgpt/

OpenAI. (2025, marzo 11). New features in the Responses API. OpenAI Blog.
https://openai.com/index/new-tools-for-building-agents/

OpenAI. (2025, mayo 21). New tools and features in the Responses API. OpenAI Blog.
https://openai.com/index/new-tools-and-features-in-the-responses-api/

Schick, T., Dwivedi-Yu, J., & Schütze, H. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. arXiv:2302.04761.
https://arxiv.org/abs/2302.04761

Significant Gravitas. (2023, marzo 30). Auto-GPT Repository. GitHub.
https://github.com/Torantulino/Auto-GPT

Tomlinson, R. (1971). 1971: First Ever Email.
https://www.guinnessworldrecords.com/news/2015/8/60/1971-first-ever-email-392973

Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention Is All You Need. arXiv:1706.03762
https://arxiv.org/abs/1706.03762

arXiv. (2025, abril 2). MCP Safety Audit: LLMs with the Model Context Protocol Allow Major Security Exploits. arXiv:2504.03767.
https://arxiv.org/abs/2504.03767

arXiv. (2025, junio 16). Model Context Protocol (MCP) at First Glance: Studying the Security and Maintainability of MCP Servers. arXiv:2506.13538.
https://arxiv.org/abs/2506.13538

Advent of Code en JavaScript Chile

Pillippa Ignacia Pérez Pons — Sun, 19 Nov 2023 22:52:39 +0000

En JavaScript Chile, transformamos recientemente nuestra forma de trabajar, apostando por un enfoque de "divide y vencerás" a través de la creación de iniciativas específicas como Meetup Presenciales, Meetup Online, TechSchool, Status 418 y Sesiones de Estudio. Esta estrategia no sólo promueve la eficiencia, sino que también fomenta un sentido de empoderamiento y construcción de una comunidad segura y participativa. Hemos encontrado que el aprendizaje dinámico y autodidacta se nutre en un ambiente así.

El Nacimiento de una Iniciativa

Nuestra más reciente aventura es participar en la iniciativa mundial Advent of Code, que se realiza en diciembre. Nos enfrentamos al desafío de iniciar algo nuevo en nuestra comunidad. Para ello, definimos claramente el contexto y el alcance de nuestra participación. Buscamos una experiencia no sólo desafiante en términos de programación, sino que también fomente el compromiso y el empoderamiento en nuestra comunidad.

Planificación y Ejecución

Elegimos realizar el Advent of Code en distintos sabores durante 24 días, cada uno con un ejercicio único cada día. Conscientes de la importancia de la inclusión, decidimos que el horario chileno de las 10 pm sería ideal, permitiendo a la mayoría de nuestros miembros pueda participar cómodamente desde sus hogares. Además, hemos establecido un período de una hora para cada sesión, durante el cual nuestra comunidad podrá interactuar, brindarse apoyo mutuo y, lo más importante, orientarse en los diversos ejercicios seleccionados. Es importante mencionar que los participantes deben completar al menos un ejercicio de cualquiera de los cuatro Advent of Code disponibles, sin que sea obligatorio abordar los cuatro, promoviendo así la flexibilidad y la elección personal en el proceso de aprendizaje.

Una parte crucial fue la visibilización al mundo. Creamos gráficas para nuestras redes sociales, programando publicaciones regulares/semanales para asegurarnos de que todos estuvieran informados y entusiasmados con la iniciativa. Seleccionamos diversas versiones del Advent of Code, incluyendo adventofcss.com, adventofjs.com, codember.dev, y adventofcode.com, de tal manera, que los participantes puedan elegir el qué más les acomode.

Agradecemos, a cada uno de los creadores de Advent of Code por su contribución al aprendizaje y empoderamiento de nuestra comunidad.

Herramientas y Métricas

Para facilitar el desarrollo de los ejercicios, optamos por plataformas como replit.com y codesandbox.io, permitiendo a cada participante elegir según sus preferencias y elección del Advent of Code. Pero, ¿cómo medir lo que queremos lograr? Aquí es donde las métricas se convierten en nuestras aliadas, permitiéndonos no solo evaluar el éxito de la iniciativa, sino también visibilizar el esfuerzo y la participación de nuestra comunidad.

Cada participante podrá subir sus ejercicios a un formulario que hemos preparado, dándonos la posibilidad de conocer quiénes participaron cada día, cuántos completaron los desafíos, y quiénes desean ser reconocidos públicamente en nuestras redes sociales. Esto nos ayuda a medir el compromiso y a celebrar el esfuerzo individual y colectivo.

Reconocimiento y Celebración

Con estas métricas, planeamos reconocer y premiar a los participantes en varias categorías: La Persona con suerte, Persona Perseverante (quien complete los 24 días), Persona que más ayudó, y por supuesto, las menciones honrosas. Creemos que incluso el intento merece ser celebrado, ya que cada esfuerzo es un paso hacia el aprendizaje y el crecimiento.

Invitación a la Acción

Te invitamos a apoyar esta, otras o futuras iniciativas, ya sea a través de recursos, soporte monetario o participación en nuestras redes sociales. Tu apoyo es crucial para el nacimiento y mantenimiento de nuestras actividades. Participa, comparte y contribuye a crear un ambiente seguro y acogedor en nuestra comunidad, independientemente de tu género, orientación sexual o nivel de experiencia. Juntos, podemos hacer de nuestra comunidad un lugar vibrante, inclusivo y empoderado.

Happy Coding