The Undeclared Dependencies

El mejor diagnóstico de un producto vive en servidores ajenos

Agustín Viñao — Thu, 15 Oct 2026 00:00:00 GMT

Cuando una persona falla en el checkout, la empresa recibe una queja. Cuando falla un agente, se escribe un registro mucho mejor — solo que no en los servidores propios.

Los registros propios muestran una sesión que empezó y se cortó. Un timeout, un código de error, un formulario que nunca se envió. Dicen que algo pasó, no por qué.

La traza del agente contiene el porqué: qué leyó en la página, qué campo probó, qué respuesta obtuvo, qué concluyó, adónde fue después. Es un diagnóstico del producto mejor que el que producen la mayoría de los estudios de usabilidad. Vive en la infraestructura de quien opera el agente.

Existe entonces una nueva clase de datos. Trata sobre la empresa, lo generó su fallo, y la empresa no es ni su dueña ni su destinataria. Nadie lo decidió. Es lo que resulta cuando quien observa el fallo es también quien se va.

El arreglo anterior tenía una simetría discreta. Quien chocaba con el muro era cliente, así que algún relato del fallo —por vago que fuera, «no me dejaba pagar»— llegaba a la puerta de la empresa. Imperfecto, pero llegaba a destino.

Ahora observador y destinatario están separados. Quien mejor puede explicar qué se rompió no tiene ninguna relación con la empresa ni motivo para enviarle nada.

De esto se siguen dos cosas para quien es dueño del producto.

→ Una telemetría de servidor más exhaustiva no reconstruirá estos fallos. La mitad que falta nunca estuvo de este lado del cable.

→ El operador del agente puede comparar los fallos de la empresa con los de todos los demás. La empresa no puede.

Nada de esto depende de cuántos agentes compran hoy. Depende de dónde se escribe el registro de un fallo cuando quien visita no es una persona, y de quién puede leerlo.

Una prueba para esta semana: elegir un recorrido de varios pasos y anotar dónde viviría el registro del fallo si quien visita fuera un agente. Si la respuesta no es «aquí», ahí está la brecha.

Paths are infinite. Acceptable outcomes fit on one page

Agustín Viñao — Thu, 15 Oct 2026 00:00:00 GMT

The first objection to “everything the system permits has to be acceptable” is that what a system permits is infinite. Retries, reorderings, half-finished states, combinations nobody designed.

It is infinite. Nobody should try to audit it.

Paths are the wrong unit. A multi-step flow with a few optional branches and a retry at each step already has more distinct routes than anyone will ever walk, and each route you do walk tells you about that route and nothing else.

Now look at where the routes end. A transactional flow terminates in an outcome: an order exists or it doesn’t, money moved or it didn’t, a record sits in some state. That set is small. A few dozen at most, often under ten.

→ Order placed, paid in full.
→ Order placed, payment pending, customer told.
→ Nothing happened, customer told why.

So you don’t declare the routes. You declare the codomain: the outcomes the company is willing to stand behind. Every route, including the ones nobody has imagined, gets classified at its end instead of along its length. It lands inside the set or it doesn’t.

That turns an exploratory task into a declarative one. Exploration needs people with time and imagination, and it never finishes. Declaration needs one person with the authority to say “we’d sign that”, and it fits on a page.

It also changes what a surprising path means. A route you never thought of that ends in a declared outcome is fine, and you never needed to know it existed. One that ends outside the set is a finding no test written around the happy path could have produced.

The expensive part isn’t technical. Someone has to decide what the company stands behind, and that is a business decision, not an engineering one. In most teams the first discovery is that nobody has ever been asked.

Next time someone says this can’t be done because the space is infinite, ask for the outcomes, not the paths. If the acceptable ones can’t be written on a single page, the problem sits upstream of the system.

Paths are infinite. Acceptable outcomes fit on one page.

The best diagnosis of your product lives on someone else's servers

Agustín Viñao — Thu, 15 Oct 2026 00:00:00 GMT

When a person fails in your checkout, you get a complaint. When an agent fails there, a far better record gets written — just not on your servers.

Your own logs show a session that started and stopped. A timeout, an error code, a form that never submitted. They tell you something happened, not why.

The agent’s trace holds the why: what it read on the page, which field it tried, what came back, what it concluded, where it went next. That is a better diagnosis of your product than most usability studies produce. It sits in the infrastructure of whoever runs the agent.

So a new class of data now exists. It’s about you, it was generated by your failure, and you’re neither its owner nor its recipient. Nobody decided that. It’s what falls out when the one who observes the failure is also the one who leaves.

The old arrangement had a quiet symmetry. The person who hit the wall was your customer, so some account of the failure — however vague, “it wouldn’t let me pay” — arrived at your door. Imperfect, but it landed with you.

Now the observer and the recipient have separated. The party best placed to explain what broke has no relationship with you and no reason to send you anything.

Two things follow for whoever owns the product.

→ More thorough server-side telemetry won’t reconstruct these failures. The missing half was never on your side of the wire.

→ The agent’s operator can compare your failures against everyone else’s. You can’t.

None of this depends on how many agents are buying today. It depends on where the record of a failure gets written when the visitor is not a person, and who gets to read it.

A test for this week: pick one multi-step journey and write down where the failure record would live if the visitor were an agent. If the answer isn’t “here,” you’ve found the gap.

Los caminos son infinitos. Los resultados aceptables caben en una página

Agustín Viñao — Tue, 13 Oct 2026 00:00:00 GMT

La primera objeción a «todo lo que el sistema permite tiene que ser aceptable» es que lo que un sistema permite es infinito. Reintentos, reordenamientos, estados a medio terminar, combinaciones que nadie diseñó.

Es infinito. Nadie debería intentar auditarlo.

El camino es la unidad equivocada. Un flujo de varios pasos, con unas pocas ramas opcionales y un reintento en cada paso, ya tiene más rutas distintas de las que nadie recorrerá jamás, y cada ruta que se recorre informa sobre esa ruta y sobre ninguna otra.

Ahora, a ver dónde terminan las rutas. Un flujo transaccional termina en un resultado: un pedido existe o no existe, el dinero se movió o no se movió, un registro queda en algún estado. Ese conjunto es pequeño. Unas pocas decenas como mucho, a menudo menos de diez.

→ Pedido realizado, pagado por completo.
→ Pedido realizado, pago pendiente, cliente avisado.
→ No pasó nada, cliente informado del motivo.

Así que no se declaran las rutas. Se declara el codominio: los resultados que la empresa está dispuesta a respaldar. Cada ruta, incluso las que nadie imaginó, se clasifica al final en lugar de a lo largo de su recorrido. Cae dentro del conjunto o no cae.

Eso convierte una tarea exploratoria en una declarativa. Explorar requiere personas con tiempo e imaginación, y nunca termina. Declarar requiere a una persona con la autoridad para decir «eso lo firmaríamos», y cabe en una página.

También cambia lo que significa un camino inesperado. Una ruta en la que nadie había pensado y que termina en un resultado declarado no es un problema, y nunca hizo falta saber que existía. Una que termina fuera del conjunto es un hallazgo que ninguna prueba escrita en torno al happy path habría podido producir.

Lo caro no es lo técnico. Alguien tiene que decidir qué respalda la empresa, y eso es una decisión de negocio, no de ingeniería. En la mayoría de los equipos, el primer descubrimiento es que a nadie se lo habían preguntado nunca.

La próxima vez que alguien diga que esto no se puede hacer porque el espacio es infinito, conviene pedir los resultados, no los caminos. Si los aceptables no caben en una sola página, el problema está más arriba que el sistema.

Los caminos son infinitos. Los resultados aceptables caben en una página.

Los tickets de soporte bajan. Ese es el problema

Agustín Viñao — Thu, 08 Oct 2026 00:00:00 GMT

Todo equipo de soporte con el que trabajé mide lo mismo: el volumen de tickets, en baja. Un trimestre más tranquilo se lee como un triunfo.

No siempre lo es, y el gráfico solo no alcanza para saber cuál de las dos cosas pasó.

Durante años, ese número significó más o menos una sola cosa: menos problemas, o mejor autoservicio. Un humano que no podía resolver algo solo tenía exactamente un movimiento disponible: abrir un ticket. Esa queja era la única señal real que tenía la empresa de que algo no funcionaba, en el momento en que no funcionaba.

El agente no tiene ese movimiento, y nunca iba a desarrollar uno. Cuando se topa con una pared, no llama a soporte. Prueba otro camino, otra fuente, directamente otro proveedor, y nadie río abajo se entera nunca. No hay ticket para una puerta que se cerró en silencio.

Entonces la misma métrica —tickets a la baja— tiene ahora dos causas que no tienen nada que ver entre sí, y apuntan en direcciones opuestas. Una es que la calidad mejora: se rompen menos cosas. La otra es que los clientes se van sin dejar rastro, esquivando la falla en vez de reportarla. Al poner los dos meses lado a lado, los dos gráficos resultan indistinguibles.

Nadie construyó esta métrica para que fuera fácil de engañar. Se construyó sobre un supuesto razonable: un usuario que se topa con una pared, lo dice. Ese mismo supuesto se sostuvo con cada tipo de usuario que la empresa atendió, hasta que llegó uno nuevo que no lo sostiene en absoluto, y nadie actualizó la métrica para notar la diferencia.

Esto no es un problema de volumen. Hoy, la mayoría del tráfico agéntico es búsqueda y comparación, no transacciones —la urgencia acá no tiene nada que ver con cuántos agentes compran. Es un problema de señal: el único número que los equipos de soporte reportan hacia arriba acaba de perder la capacidad de distinguir estas dos historias.

Que el conteo de tickets baje no prueba nada sobre la calidad hasta que alguien pueda decir quién dejó de llamar, y por qué.

Your support tickets are down. That's the problem

Agustín Viñao — Thu, 08 Oct 2026 00:00:00 GMT

Every support team I’ve worked with tracks the same number: ticket volume, down and to the right. A quieter quarter reads as a win.

It isn’t always one, and the chart alone can’t tell you which.

For years, that number meant roughly one thing: fewer problems, or better self-service. A human who couldn’t solve something alone had exactly one move left — open a ticket. That complaint was the only real signal the business had that something didn’t work, the moment it didn’t work.

An agent doesn’t have that move, and it was never going to develop one. When it hits a wall, it doesn’t call support. It tries another path, another source, another provider entirely, and nobody downstream ever hears about it. There’s no ticket for a door that quietly closed.

So the same metric — tickets down — now has two unrelated causes behind it, pointing in opposite directions. One is quality improving: fewer things are breaking. The other is customers leaving without a trace, routed around the failure instead of reporting it. Pull up both months side by side and the two charts are indistinguishable.

Nobody built this metric to be fooled. It was built on a fair assumption: a user who hits a wall tells you about it. That same assumption held for every kind of user the business has ever served, until a new one arrived that doesn’t hold it at all, and nobody updated the metric to notice the difference.

This isn’t a volume problem. Most agentic traffic today is search and comparison, not transactions — the urgency here has nothing to do with how many agents are buying. It’s a signal problem: the one number support teams report upward just lost the ability to tell these two stories apart.

A ticket count going down proves nothing about quality until someone can say who stopped calling, and why.

Listar los canales que no se controlan

Agustín Viñao — Tue, 06 Oct 2026 00:00:00 GMT

En cualquier empresa, la respuesta dónde puede comprar un cliente es siempre la misma: la web, quizás la app, quizás un buscador de tiendas.

Nadie menciona los otros doce lugares donde esa respuesta ya existe.

Agregadores. Revendedores. Listados de directorios. Catálogos de socios. Y ahora, asistentes de IA que ya muestran el producto a alguien que nunca visitó la web de la empresa.

Ninguno de esos pide permiso para existir. Hacen scraping, reciben un feed de productos, sindican desde quien tenga una API. Un agente que compara opciones no revisa cuál es el canal oficial. Responde con lo que puede leer, y un listado de un revendedor con tres años de antigüedad se lee tan confiado como la página principal.

Entonces el mapa que tiene la mayoría de las empresas —los canales que construyeron, con las URLs que son propias— es preciso justo en la parte que nunca fue el problema. Se queda en silencio exactamente donde el diagnóstico dice que ocurre el daño: los canales que nadie en la empresa vigila.

Esto no es un proyecto de datos. Es un inventario, y hoy, en la mayoría de las empresas, no existe. Alcanza con elegir un resultado que un cliente puede obtener —un precio, una hoja de especificaciones, un horario de tienda— y anotar cada lugar donde esa respuesta existe, incluidos los que la empresa no opera ni aprobó nunca.

Todavía no hace falta ningún criterio. Ningún juicio sobre qué canales son buenos o malos. Solo la lista, y la incomodidad de descubrir qué corta queda la columna de lo propio y lo ajeno.

No se puede decidir qué cuenta como un resultado aceptable en un canal que no se sabía que existía, y tampoco se puede detectar uno malo ahí —no hay nada contra qué compararlo. Cada paso siguiente depende de que la lista esté completa, no solo la parte que ya se construyó.

La brecha no es técnica. Hacer la lista nunca fue el trabajo de nadie, así que nadie la escribió nunca.

Listar los canales que no se controlan. Ahí es donde el mapa deja de ser propio.

List the channels you don't control

Agustín Viñao — Tue, 06 Oct 2026 00:00:00 GMT

Ask anyone at your company where a customer can buy from you. You’ll get your website, maybe your app, maybe a store locator.

Nobody mentions the other dozen places where that answer already lives.

Aggregators. Resellers. Directory listings. Partner catalogs. And now, AI assistants that already surface your product to someone who never visited your site at all.

None of those ask your permission to exist. They scrape, they get fed a product feed, they syndicate from whoever has an API. An agent comparing options doesn’t check which channel is the official one. It just answers from whatever it can read, and a reseller’s three-year-old listing reads just as confidently as your homepage.

So the map most companies have — the channels they built, with the URLs they own — is accurate about exactly the part that was never the problem. It goes quiet precisely where the diagnosis says the damage happens: the channels nobody at the company is watching.

This isn’t a data project. It’s an inventory, and today, at most companies, it doesn’t exist. Pick one result a customer can get — a price, a spec sheet, a store hours listing — and write down every place that answer lives, including the ones you don’t operate and never approved.

No criteria needed yet. No judgment about which channels are good or bad. Just the list, and the discomfort of discovering how short the owned column is next to it.

You can’t decide what counts as an acceptable outcome on a channel you didn’t know existed, and you can’t detect a bad one there either — there’s nothing to compare it against. Every step after this one depends on the list being complete, not just the part you built.

The gap isn’t technical. Listing was never anyone’s job, so nobody ever wrote it down.

List the channels you don’t control. That’s where the map stops being yours.

La pérdida invisible no es aleatoria

Agustín Viñao — Fri, 02 Oct 2026 00:00:00 GMT

La pérdida invisible parece ruido pero no lo es. Algunos agentes se traban, algunas sesiones terminan sin conversión, y todo se compensa en el promedio. No es así. Cae primero sobre los clientes más rentables.

Primero, cómo se acumula el fallo: Un flujo de varios pasos solo tiene éxito si lo tiene cada paso. Un 95% solo tiene un paso, a modo ilustrativo, flujos de cinco pasos terminan el 77% de las veces; con diez pasos, cerca del 60%. Un humano resuelve el paso ambiguo con contexto. Un agente no tiene contexto con qué resolverlo, cada paso conlleva un riesgo real.

Ahora, dónde está el margen. Configuradores, cotizaciones, checkout de varios pasos, autenticación, todo lo que tenga campos condicionales. Esos flujos se extienden, y existen porque lo que hay detrás es lo bastante complejo como para valer más. Los flujos simples son simples tienen menos valor, proveen menos valor, son comunes.

Así que los flujos con más probabilidad de fallar son los que más ganan. La curva de fallo y la curva de margen apuntan en el mismo sentido.

Importa también lo que pasa en el fallo. Kevin Indig ejecutó tareas de agentes sobre 100 productos B2B, cinco ejecuciones por producto. Cuando el agente encontraba un error de acceso, recurría a fuentes de terceros el 77% de las veces. Sin error, el 17%. El agente no reintenta ni llama a nadie. Busca la alternativa, descarta la opcion en curso, es decir, va a buscar otra solucion.

Nada lo señala. Ningún ticket, ningún error en los logs que se lea como una pérdida. La compra cara que nunca se completó se promedia con los flujos baratos donde los agentes sí tienen éxito, y la cifra combinada se ve sana porque los flujos que funcionan son los que menos ganan.

Nada de esto depende del volumen. Incluso una porción pequeña del tráfico de agentes se inclina hacia los flujos donde perderlo cuesta más.

Antes de mirar la conversión combinada, conviene ordenar los flujos por margen y después por cantidad de pasos. Donde las dos listas coinciden es donde se concentra la pérdida invisible. Esa coincidencia es el primer lugar donde mirar y el último donde un dashboard la va a mostrar.

Your invisible attrition isn't random

Agustín Viñao — Fri, 02 Oct 2026 00:00:00 GMT

Invisible attrition sounds like noise. Some agents stall, some sessions end without a conversion, and it all averages out. It doesn’t. It lands on your most profitable customers first.

Start with how failure compounds. A multi-step flow only succeeds if every step does. Take an illustrative 95% per step: five steps finish about 77% of the time, ten steps about 60%. A human patches the ambiguous step with context. An agent has no context to patch it with, so every step carries real risk.

Now look at where your margin sits. Configurators, quotes, multi-step checkout, authentication, anything with conditional fields. Those flows have the most steps, and they exist because what’s behind them is complex enough to be worth more. Simple flows are simple because the thing behind them is cheap.

So the flows most likely to fail are the flows that earn the most. The failure curve and the margin curve point the same way.

What happens at the failure matters too. Kevin Indig ran agent tasks against 100 B2B products, five runs each. When the agent hit an access error, it fell back to third-party sources 77% of the time. Without one, 17%. The agent doesn’t retry and doesn’t call anyone. It answers from someone else’s version of you.

Nothing flags it. No ticket, no error in your logs that reads as a loss. The expensive purchase that never completed gets averaged with the cheap flows where agents succeed, and the blended number looks healthy because the flows that work are the ones that earn least.

None of this depends on volume. Even a small share of agent traffic is skewed toward the flows where losing it costs the most.

Before you look at blended conversion, rank your flows by margin, then rank them by number of steps. Where the two lists overlap is where your invisible attrition concentrates. That overlap is the first place to look, and the last place a dashboard will show it.

No hace falta un equipo de IA

Agustín Viñao — Tue, 29 Sep 2026 00:00:00 GMT

Es común ver la misma reacción a los agentes de IA en las companías: un equipo nuevo, una partida de presupuesto nueva, un programa de preparación agéntica.

Nada de eso es lo que falta.

El agente no hace lo esperable: hace lo posible. Durante años, esa brecha la cubría un humano que corregía la interpretación, reconciliaba las contradicciones, y se quejaba cuando algo no cuadraba. Esa brecha nunca tuvo dueño porque nunca hizo falta que lo tuviera.

Tratar a los agentes de IA como motivo para crear una función nueva es tratarlos como una revolución. No lo son. Son un nuevo tipo de usuario con una sola propiedad que importa: sin supuestos, sin contexto compartido, sin ninguna vacilación antes de hacer algo que nadie esperaba.

La solución no es un equipo nuevo. Es especificar mejor, y ese trabajo ya tiene dueño en cada una de sus partes. El mensaje es de quien lo escribe. El flujo es de quien lo construyó. Qué cuenta como un resultado aceptable es de quien maneja esa parte del negocio.

Se puede probar en un solo flujo. Preguntar a quien lo maneja qué resultado está dispuesto a respaldar si alguien va más allá del happy path. Nada de herramientas nuevas, nada de contrataciones nuevas. Solo una respuesta que alguien ya tenía la autoridad de dar y que nunca se le pidió.

Un equipo paralelo para hacerse cargo de la experiencia de agente de IA no consigue esa respuesta. Suma un quinto dueño a un problema que ya tiene cuatro, y de paso le da permiso a todos los demás para dejar de ocuparse de él.

Nada de esto es trabajo nuevo. Es el mismo proceso de requisitos, con una pregunta más antes de lanzar cualquier cosa: qué pasa cuando alguien, o algo, hace más que el happy path.

Esa pregunta va en los requisitos, en QA, en el checklist de release de cada entrega. No en la hoja de ruta de un equipo que todavía no existe.

No hace falta un equipo de IA. Hace falta que quien ya es dueño de cada decisión deje de especificar solo para lo que esperaba que pasara.

El subsidio que nadie sabía que recibía

Agustín Viñao — Tue, 29 Sep 2026 00:00:00 GMT

Todo producto que se lanza está subespecificado. No es un defecto — es un hecho. Ninguna especificación sobrevive el contacto con cada caso ambiguo, cada contradicción entre canales, cada camino que nadie quiso habilitar.

Durante años esa brecha se mantuvo invisible, porque alguien la llenaba gratis.

Cuatro cosas pasaban, en silencio, cada vez que un humano usaba los sistemas:

→ Resolvían la ambigüedad de forma local. Interpretaban lo que se quería decir, no solo lo que estaba escrito.

→ Reconciliaban contradicciones entre canales. Una página decía una cosa, otra decía algo distinto — elegían la que tenía sentido y seguían adelante sin avisar que alguna de las dos estaba mal.

→ Se quedaban dentro del camino diseñado, aun cuando el sistema les permitía desviarse más. No porque las reglas se lo impidieran. Lo hacía el hábito, o la cortesía, o el aburrimiento.

→ Cuando nada de eso funcionaba, se quejaban. Esa queja era el único sensor de calidad real que existía.

Cada una parece menor por separado. Juntas, eran la razón por la que el comportamiento real del sistema se mantenía cerca de lo diseñado, en vez de derivar hacia todo lo que técnicamente permitía.

Nada de esto se diagramó nunca. Nadie lo tuvo a su cargo, ni lo versionó, ni escribió un SLA sobre eso. El usuario humano era una dependencia no declarada en la arquitectura — la única que nunca apareció en un documento de diseño.

Un agente no hereda ninguno de estos cuatro servicios. No infiere la intención. No va a notar una contradicción salvo que se le indique revisarla. No tiene ningún hábito que lo mantenga en el happy path. Y cuando falla, no se queja — simplemente prueba otra cosa, en otro lado, y nadie se entera.

Las empresas no enfrentan una tecnología nueva. Están perdiendo un subsidio que nunca supieron que recibían.

La solución no es un equipo nuevo ni un presupuesto nuevo de preparación para la IA. Es escribir, por fin, qué hacía esa dependencia en silencio — porque no se gobierna una dependencia que nunca se declaró, ni se declara una que nunca se nombró.

You don't need an AI team

Agustín Viñao — Tue, 29 Sep 2026 00:00:00 GMT

Every company reacting to agents is standing up the same thing: a new team, a new budget line, an agent readiness program.

None of that is what’s missing.

An agent doesn’t do what’s expected. It does what’s possible. For years the gap between those two was covered by a human who corrected the interpretation, reconciled the contradictions, and complained when something was off. That gap never had an owner because it never needed one.

Treating agents as the reason to build a new function is treating them as a revolution. They aren’t. They’re a new type of user with one property that matters: no assumptions, no shared context, no hesitation before doing something nobody expected.

The fix isn’t a new team. It’s specifying better, and that work already has an owner for every piece of it. The message belongs to whoever writes it. The flow belongs to whoever built it. What counts as an acceptable outcome belongs to whoever runs that part of the business.

Try it on one flow. Ask whoever owns it what result they’re willing to stand behind if someone goes further than the happy path. No new tooling, no new hires. Just an answer someone already had the authority to give and was never asked for.

Standing up a parallel team to own agent experience doesn’t get you that answer. It adds a fifth owner to a problem that already has four, and quietly gives everyone else permission to stop caring about it.

None of this is new work. It’s the same requirements process, with one extra question before anything ships: what happens when someone, or something, does more than the happy path.

That question belongs in requirements, in QA, in the release checklist you already run. Not in a roadmap for a team that doesn’t exist yet.

You don’t need an AI team. You need whoever already owns each decision to stop specifying only for what they expected to happen.

Perfect exit, zero voice

Agustín Viñao — Thu, 24 Sep 2026 00:00:00 GMT

A customer who leaves sends two signals. Exit says something is wrong. Voice says what. An agent has perfect exit and no voice, and markets aren’t built for that combination.

Albert Hirschman laid out the frame in 1970, in Exit, Voice, and Loyalty. Organizations correct themselves through those two channels. Exit is blunt: revenue drops, no reason attached. Voice is specific: a complaint names the failing step, the wrong number, the contradiction. Voice is what turns a loss into a fix.

Voice only happens when leaving is costly. People stay long enough to complain because they have an account, a history, something to lose. Hirschman called that loyalty.

An agent has none of it. Switching costs nothing: the next candidate is the next call in the same run. Nothing accumulates, so nothing is worth fighting for. And there is nobody to complain to. A failure is a return value inside its own context, not a message addressed to you.

In systems terms, it’s a client that drops the connection without an error code. Worse, on your side it isn’t even a drop. It’s a session that ended, indistinguishable from a visitor who never came.

The one measurement I’d trust is Kevin Indig’s, from his Growth Memo in July. He ran pricing tasks against 100 B2B products, five runs each. When the agent hit an access error, it fell back to third-party sources 77% of the time. Without one, 17%. That’s exit, quantified.

None of this depends on how much demand agents carry today. It depends on what happens to the signal. Firms improve because someone tells them where they’re broken. For the share of demand that goes through agents, nobody does, so the broken step stays broken and the market has no way to notice.

For any channel you run, ask which signal reaches you when a visitor fails there. If the honest answer is “a slightly smaller number,” you’re running on exit alone, and exit alone never says what to fix.

The agent isn't hostile. It behaves like a fuzzer

Agustín Viñao — Tue, 22 Sep 2026 00:00:00 GMT

A fuzzer has no opinion about your product. It doesn’t know what a user “would” do. It just tries every input the system accepts, including the ones nobody designed for, until something breaks.

That’s the best description I’ve found for how an AI agent behaves inside a transactional flow.

Any multi-step flow — search, select, fill in details, confirm, pay — has a state space much larger than the path the business had in mind. Retries out of order. Partial completions. Combinations nobody wrote a test for. That space always existed. It stayed empty because a human got bored, got confused, or just never thought to try it.

An agent doesn’t get bored. It has no social sense that a path is “not meant for it.” It just keeps going until it finds a state the system accepts.

This is not the same question security asks. Security asks what a hostile actor can do, and measures the answer in damage. Nothing here is hostile. The agent isn’t trying to break your flow — it’s indifferent to whether the path was intended. A perfectly secure system can still hand an indifferent actor a result nobody signed off on.

Worse than a bug: when the agent finds one of those paths, it usually succeeds. Not a crash, not an error. A completed transaction the system permitted and nobody authorized, indistinguishable in your logs from a normal one.

The rule that used to hold — nobody will do that, nobody would think of it — was never written into any requirement. It was a guess about human psychology, quietly doing the job of a spec.

Product and engineering don’t have a discipline for this yet, because until now the actor exercising the happy path also happened to be the one who stayed on it.

If you want to know what your system actually allows, stop asking whether the tests pass. Ask what happens when something tries everything.

Agents barely buy anything. That's not the point

Agustín Viñao — Thu, 17 Sep 2026 00:00:00 GMT

Checkout accounts for roughly two percent of the agentic traffic anyone has actually measured. The other ninety-eight percent is search and comparison — agents looking, not buying.

That’s not my estimate. HUMAN Security has been tracking this for a while now, and the split has barely moved: product and search pages take up somewhere around three-quarters to four-fifths of everything agents do, checkout stays in the low single digits.

If someone in the room uses that to say “agents aren’t buying yet, so this isn’t urgent,” they’re reading the right number and drawing the wrong conclusion from it. Agents fail constantly before they ever reach checkout — that’s expected, unremarkable. The real question isn’t whether they fail. It’s what happens to your business when they do.

Two percent isn’t the number that matters here. It’s a lagging indicator, and a narrow one — it only counts what makes it all the way to checkout. Everything that happens before that never shows up there: dead ends, stale information, sessions abandoned two steps early. It shows up nowhere, because almost nothing in most companies is built to notice a query that goes silent.

That’s the actual case for urgency, and it isn’t about scale. It’s about the gap between when the damage happens and when anyone could see it. A checkout metric only tells you about the transactions that survived contact with your systems. It says nothing about the ones that didn’t — and by the time checkout volume is large enough to be alarming, the weak parts of your funnel will have been quietly filtering out agent traffic for a long time, unmeasured.

Waiting for volume to justify the work means waiting for a signal that, by construction, can’t reach you until the problem has already been running for years.

Don’t build a program around two percent. Build one around the fact that the other ninety-eight percent happens exactly where nobody’s watching.

What the system allows was never what the company wanted

Agustín Viñao — Tue, 15 Sep 2026 00:00:00 GMT

Every flow you’ve ever shipped accepts more than the happy path. Extra steps, out-of-order submissions, retries in odd sequences, combinations nobody put on a whiteboard. That gap between what’s designed and what’s technically allowed has always existed.

Take any multi-step transactional flow: search, select, enter details, confirm, pay. The intended path is one line through that space. The actual state space — every retry, every partial submission, every order the steps could technically arrive in — is enormously larger, and it was there from the day the flow shipped.

It never showed up as a problem, because for years the people using your systems didn’t go looking for it. Not because a rule stopped them. Because they got bored, or confused, or too polite to keep pushing on something that looked wrong, and gave up or called instead.

That’s the part nobody wrote down. Somewhere in every one of those decisions sits an assumption like “nobody’s going to do that, why would they” — and it held, quietly, for years, because it happened to be true of the actual users hitting the system. It was never a requirement. It was a bet on human psychology, embedded in code that has no idea it’s making that bet.

An agent doesn’t carry that psychology. It has no boredom threshold, no social discomfort, no instinct that a sequence looks wrong. It takes a permitted path exactly as readily as the intended one — and when it does, the system doesn’t fail. It succeeds, at something nobody signed off on.

That’s the actual gap this shift exposes: what the system allows and what the company wanted were never the same set. They only looked identical because nobody had walked the distance between them.

Ask whoever owns a transactional flow in your company whether they can name that distance — or whether the honest answer is that nobody’s ever measured it.

The agent doesn't absorb your org chart. It executes it

Agustín Viñao — Tue, 15 Sep 2026 00:00:00 GMT

Three channels, three teams, three release cycles. Nobody designed the divergence between your website, your app, and your partner listings. It’s just what happens when ownership is split and nothing forces reconciliation.

The website team ships weekly. The app team runs its own backlog on its own cadence. Whoever owns the partner feed updates it whenever they remember it exists. None of them talk to each other about what the customer actually sees, because that conversation isn’t in anyone’s job description.

This is Conway’s Law doing what it always does: your channels mirror your org chart, not your product.

For a decade this cost nothing visible. A human hit the mismatch, shrugged, and picked whichever channel seemed more current — or just called to check. That correction happened silently, inside someone’s head, and never once showed up as a ticket.

An agent doesn’t do that. It reads one channel and treats what it finds as ground truth, confidently. Feed it two channels and it has no basis to prefer one over the other, so it either picks arbitrarily or fails outright — and either way it acts on the result.

The org chart that used to stay safely internal now shows up directly in your product’s behavior. The agent doesn’t absorb the cost of your team structure. It executes it, step by step, as if it were policy.

This isn’t a data sync problem you close out once. The divergence keeps regenerating for as long as separate teams ship on separate schedules with no shared source of truth between them. The fix isn’t reconciling the data. It’s deciding, in advance, which channel is authoritative before an agent has to guess on your behalf.

Pick one fact your company states publicly — a price, a policy, a deadline — and trace who last touched it on every channel where it appears.

Two questions about your own company you probably can't answer

Agustín Viñao — Wed, 09 Sep 2026 00:00:00 GMT

Ask anyone in your company two questions. Watch how long it takes before someone changes the subject.

Question one, about information:

→ In how many places does your company answer the same question — pricing, hours, availability, policy — and do those answers agree with each other?

Most companies have never run this check. Not because it’s hard. Because nobody owns every channel at once, so nobody has ever lined them up side by side.

Question two, about functionality:

→ Can anyone here list what your systems actually permit — not what they were designed to do, but every path a determined user could complete successfully?

This one lands harder, for a specific reason. QA proves the happy path works. Nobody tests what else the system accepts. Test suites read “given valid input, expect correct output” — never “enumerate everything this accepts and check it against what the business wanted.” That second suite doesn’t exist anywhere, because until now nothing exhaustive enough needed it to.

Both questions went unanswered for years without cost, because a human sat in the gap for both of them — noticing when two pages disagreed, losing interest before finding every path a form technically allowed. An agent does neither. It treats whichever channel it lands on as the truth, and it has no boredom keeping it off a sequence nobody meant to leave open.

Underneath both questions sits a harder one: how much of your system is defined by what you actually specified, versus what you assumed a human would quietly supply?

Nobody can answer that one either. The assumed part was never written down. It lived in the person filling the gap, and it left the day they stopped being the one filling it.

Try the first question this week. It’s answerable in an afternoon, and most people who try it are surprised by what they find.

Your users were your consensus protocol

Agustín Viñao — Thu, 03 Sep 2026 00:00:00 GMT

Your website says one price. Your app shows another. A support agent quotes a third. Nobody decided this split should exist — it’s just what three teams updating three channels, on three schedules, produce.

For years that didn’t matter, because a human sat in the gap. Someone reading the outdated page would think “let me just check by calling” and quietly correct for the drift, entirely in their own head. That correction never touched a dashboard, never got logged anywhere. It happened before they acted, and nobody had to ask them to make it.

That’s the part worth naming precisely. Every channel your company runs is effectively its own database, replicated from a shared truth that was never written down anywhere a machine can read. N replicas, no consensus protocol running between them. The system held together for years because the reader resolved the conflict at read time, silently, for free, before acting on whatever they found.

Remove that reader and you don’t get a system that’s slightly less accurate. You get split-brain: every reader acting on a different truth, with full confidence, and no signal anywhere that another version exists. An agent that reads your site gets one answer. One that reads a listing on someone else’s platform gets a different one. Neither doubts what it found, because doubting requires already knowing there’s something to doubt it against.

This is also why fixing the one outdated channel doesn’t fix the failure mode. The problem was never which channel happened to be wrong that week. It’s that nothing in the system has ever compared them against each other, so nothing knows they disagree — and nothing will, until the day a reader who can’t self-correct acts on the wrong one.

Before you touch any single channel, find out how many of yours currently answer the same question right now — and whether they agree with each other.

Nobody tests what else is allowed

Agustín Viñao — Tue, 01 Sep 2026 00:00:00 GMT

Your QA suite tests one thing: that the happy path works.

Give it valid input, expect the correct output. That’s the entire contract most test suites encode. Nobody writes the other suite — enumerate everything the system accepts, then check it against what the business actually wanted.

That gap stayed invisible for years, because nobody walked it. A human user, moving through a multi-step transactional flow — search, select, fill in data, confirm — would get bored, hesitate at an unfamiliar state, or just call someone instead of poking at the edges. The state space you never tested stayed unvisited by convention, not by design.

An agent doesn’t share that convention. It doesn’t get bored. It doesn’t feel like an intermediate state is odd and back away. It tries whatever the system allows, and when one of those paths resolves — a retry sequence nobody anticipated, a combination of steps nobody validated together — it completes the transaction. Not a failure. A success, at a destination nobody signed off on.

That’s the part that never shows up in an incident report, because nothing broke. The system did exactly what it was built to permit. It just permitted more than anyone specified.

The fix isn’t more test cases for scenarios you can already imagine. It’s a second question, asked of every flow you’ve already shipped: not “does the intended path work,” but “what else does this path allow, and would we stand behind it if it happened.”

Most companies have never run that second query, because until now nobody exhaustive enough existed to need the answer.

Pull up any multi-step flow you own. Ask an engineer what the state space actually permits, separate from what it was designed to do. If nobody can answer in a sentence, that’s the exact gap an agent will find first — and it won’t file a bug report when it does.

The subsidy you never knew you were receiving

Agustín Viñao — Tue, 25 Aug 2026 00:00:00 GMT

Every product you ship is underspecified. Not a flaw — a fact. No spec survives contact with every ambiguous case, every channel contradiction, every path nobody meant to allow.

For years that gap stayed invisible, because someone filled it for free.

Four things happened, silently, every time a human used your systems:

→ They resolved ambiguity locally. Interpreted what you meant, not just what you wrote.

→ They reconciled contradictions across channels. One page said one thing, another said something else — they picked whichever made sense and moved on without telling you either one was wrong.

→ They stayed inside the path you designed, even when the system let them wander further. Not because your rules stopped them. Habit did, or courtesy, or boredom.

→ When none of that worked, they complained. That complaint was the only real sensor you had on your own quality.

Each one looks minor on its own. Together, they were the reason your system’s actual behavior stayed close to what you designed, instead of drifting toward everything it technically allowed.

None of it was ever diagrammed. Nobody owned it, versioned it, or wrote an SLA against it. The human user was an undeclared dependency in your architecture — the only one that never showed up in a design doc.

An agent inherits none of these four services. It doesn’t infer intent. It won’t notice a contradiction unless told to check. It has no habit keeping it on the happy path. And when it fails, it doesn’t complain — it just tries something else, somewhere else, and you never find out.

Companies aren’t facing a new technology. They’re losing a subsidy they never knew they were receiving.

The fix isn’t a new team or a new budget for AI readiness. It’s writing down, finally, what that dependency was quietly doing for you — because you can’t govern a dependency you never declared, and you can’t declare one you never named.

What an agent sees of your company is your worst channel

Agustín Viñao — Thu, 20 Aug 2026 00:00:00 GMT

Ten years ago you moved your best experience to a mobile app: real-time inventory, loyalty, personalization, features the website never got. You also built the one channel a shopping agent can’t read.

An agent can’t open an app store, install a binary, and log in the way a human does. No DOM to parse, no URL to fetch, no button behind a paywall it can tap. So it reads what’s public: your website.

That’s not a random sample of your business. It’s whatever’s left on the site you stopped actively maintaining the day the app became the priority.

The gap is architectural, not strategic. A website exposes structure a machine can parse: pages, links, text. An app is a compiled binary behind a store, built for touch, with no equivalent surface. You didn’t hide your best experience from agents on purpose. You just built it somewhere machines can’t follow.

Roughly 71% of observed agentic traffic in April 2026 came from browser-based agents, per HUMAN Security — tools reading pages the way a person would. They’re not waiting for an app integration. They’re already on the page you stopped updating.

There’s a second-order effect. When an agent compares you to a competitor, it’s weighing your outdated web presence against whatever the other company shows publicly. A smaller competitor that never built an app, and kept a decent website instead, wins that comparison by default. The company that invested the most ends up looking the worst.

This is a window, not a permanent state. Agents will get into apps eventually. Until they do, whatever’s on your website is the only version of you they can act on.

Pull up your homepage right now. Check what it says about pricing, hours, or availability, and compare it to what your app shows. Whichever one disagrees is the version an agent already believes.