{"id":169,"date":"2026-09-22T13:58:06","date_gmt":"2026-09-22T19:58:06","guid":{"rendered":"https:\/\/zherpa.ai\/blog\/?p=169"},"modified":"2026-09-22T14:02:47","modified_gmt":"2026-09-22T20:02:47","slug":"webmcp-comercio-agentes-ia","status":"publish","type":"post","link":"https:\/\/zherpa.ai\/blog\/investigacion\/webmcp-comercio-agentes-ia\/","title":{"rendered":"WebMCP y el comercio para agentes de IA: cu\u00e1ndo se justifica preparar una web para que la opere un agente"},"content":{"rendered":"

Durante d\u00e9cadas hemos dise\u00f1ado sitios web bajo una premisa casi invisible: quien opera la p\u00e1gina es una persona<\/strong>.<\/p>\n

Por eso construimos men\u00fas, botones, buscadores, filtros, formularios, configuradores y carritos. Una persona observa la interfaz, interpreta sus opciones y decide d\u00f3nde hacer clic.<\/p>\n

Los agentes de inteligencia artificial introducen una segunda posibilidad. El cliente puede seguir siendo humano, pero parte del trabajo digital necesario para alcanzar su objetivo podr\u00eda realizarlo su agente.<\/p>\n

Eso plantea una pregunta empresarial m\u00e1s importante que simplemente \u201c\u00bfqu\u00e9 es WebMCP?\u201d:<\/p>\n

\u00bfCu\u00e1ndo existe suficiente valor entre expresar una intenci\u00f3n y obtener un resultado v\u00e1lido como para justificar que una web exponga funciones directamente a agentes de IA?<\/strong><\/p>\n

La respuesta resulta especialmente interesante en comercio electr\u00f3nico, productos personalizados y servicios configurables.<\/p>\n

Y ya podemos observarla en una implementaci\u00f3n real.<\/p>\n

Zherpa.tech utiliza WebMCP para exponer capacidades de su aplicaci\u00f3n a agentes: descubrir Capacidades Agentivas, formar un Crew, construir una hip\u00f3tesis de ROI y preparar una solicitud de evaluaci\u00f3n. El recorrido termina deliberadamente antes de producir un efecto externo: la persona debe revisar y confirmar el env\u00edo.<\/p>\n

Ese caso permite estudiar algo que pronto podr\u00eda ser relevante para muchas empresas: una web puede seguir teniendo interfaz para personas y, simult\u00e1neamente, desarrollar una superficie operativa para sus agentes.<\/strong><\/p>\n

\u00bfQu\u00e9 es WebMCP?<\/h2>\n

WebMCP es una API web que permite que una aplicaci\u00f3n proporcione herramientas JavaScript a agentes de inteligencia artificial.<\/p>\n

La especificaci\u00f3n vigente al 17 de septiembre de 2026 describe estas herramientas como funciones de la aplicaci\u00f3n con descripciones en lenguaje natural y esquemas estructurados que pueden ser invocados por agentes. Tambi\u00e9n contempla que usuario y agente colaboren dentro de la misma interfaz web, reutilizando la l\u00f3gica existente de la aplicaci\u00f3n y compartiendo contexto.<\/p>\n

Chrome lo explica de una manera particularmente sencilla: el sitio declara las acciones disponibles como herramientas; el navegador las presenta al agente; el agente proporciona argumentos estructurados y el c\u00f3digo de la aplicaci\u00f3n realiza el trabajo.<\/p>\n

Esto introduce una diferencia importante frente a la automatizaci\u00f3n visual.<\/p>\n

Supongamos que una tienda tiene un bot\u00f3n: Agregar al carrito.<\/strong><\/p>\n

Un agente que s\u00f3lo observa la interfaz debe localizarlo, comprender qu\u00e9 representa, relacionarlo con determinado producto e interactuar correctamente con \u00e9l.<\/p>\n

Con WebMCP, la aplicaci\u00f3n puede proporcionar directamente una herramienta estructurada equivalente.<\/p>\n

El objetivo ya no es \u00fanicamente conseguir que el agente entienda la p\u00e1gina<\/strong>. La propia aplicaci\u00f3n puede explicarle qu\u00e9 puede hacer<\/strong>.<\/p>\n

Web convencional frente a web preparada para agentes<\/h2>\n

Una web convencional expresa gran parte de sus posibilidades mediante elementos dise\u00f1ados para personas. Una web con WebMCP puede conservar exactamente esa experiencia y a\u00f1adir contratos estructurados para agentes.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Web convencional<\/th>\nWeb con WebMCP<\/th>\n<\/tr>\n<\/thead>\n
La persona interpreta la interfaz<\/td>\nPersona y agente pueden participar<\/td>\n<\/tr>\n
Las capacidades se manifiestan principalmente mediante UI<\/td>\nDeterminadas capacidades tambi\u00e9n se declaran como tools<\/td>\n<\/tr>\n
La automatizaci\u00f3n puede necesitar interpretar la interfaz<\/td>\nEl agente recibe nombre, descripci\u00f3n y par\u00e1metros de la herramienta<\/td>\n<\/tr>\n
La persona traduce su intenci\u00f3n a filtros y formularios<\/td>\nEl agente puede ayudar a convertir intenci\u00f3n en par\u00e1metros<\/td>\n<\/tr>\n
La UI conduce el recorrido<\/td>\nTools y UI pueden compartir el mismo estado<\/td>\n<\/tr>\n
Los clics expresan acciones<\/td>\nEl agente puede invocar funciones estructuradas<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Esto no significa que WebMCP elimine la interfaz gr\u00e1fica. La especificaci\u00f3n habla precisamente de colaboraci\u00f3n entre usuario y agente dentro de la misma experiencia. La diferencia es que la interfaz deja de ser necesariamente el \u00fanico lenguaje operativo de la aplicaci\u00f3n<\/strong>.<\/p>\n

El caso m\u00e1s sencillo: comprar una playera<\/h2>\n

Consideremos una tienda convencional. El cliente quiere una playera negra talla M.<\/p>\n

Puede buscar \u201cplayera\u201d, seleccionar categor\u00eda, aplicar color, elegir talla, abrir una ficha y agregarla al carrito. El recorrido funciona razonablemente bien porque existen pocas variables.<\/p>\n

Ahora cambiemos la solicitud:<\/p>\n

\n

\u201cQuiero una playera negra talla M, de algod\u00f3n, con este dise\u00f1o centrado al frente, aproximadamente de 20 cent\u00edmetros de ancho. No quiero gastar m\u00e1s de $500 y necesito recibirla antes del viernes.\u201d<\/p>\n<\/blockquote>\n

El problema ha cambiado. El cliente ya no busca \u00fanicamente un producto. Est\u00e1 intentando construir una configuraci\u00f3n v\u00e1lida<\/strong>.<\/p>\n

La tienda debe resolver modelos disponibles, tallas, colores, material, zona imprimible, dimensiones m\u00e1ximas, compatibilidad de la t\u00e9cnica de impresi\u00f3n, precio, inventario, producci\u00f3n y fecha de entrega.<\/p>\n

El cliente conoce bastante bien lo que quiere conseguir<\/strong>. Pero no necesariamente conoce todos los par\u00e1metros que el sistema necesita para vend\u00e9rselo<\/strong>.<\/p>\n

\u00c9ste es precisamente el tipo de distancia donde una interfaz agentiva podr\u00eda resultar valiosa.<\/p>\n

\u00bfC\u00f3mo ser\u00eda una tienda WebMCP?<\/h2>\n

Una tienda podr\u00eda mantener su e-commerce convencional y exponer adicionalmente herramientas para agentes. Conceptualmente podr\u00edan existir funciones como search_products<\/code>, get_customization_options<\/code>, validate_design<\/code>, calculate_price<\/code>, check_delivery<\/code>, create_preview<\/code> y add_to_cart<\/code>.<\/p>\n

Estos nombres son ilustrativos; no pertenecen al contrato de Zherpa.tech ni pretendemos presentarlos como herramientas obligatorias de WebMCP.<\/p>\n

El agente podr\u00eda convertir la petici\u00f3n humana en par\u00e1metros y consultar las reglas reales de la tienda. Quiz\u00e1 descubra que la playera elegida s\u00f3lo admite un estampado frontal de 18 cent\u00edmetros. En lugar de inventar una soluci\u00f3n, podr\u00eda comunicar que puede reducir el dise\u00f1o o buscar otro modelo que permita 20 cent\u00edmetros.<\/p>\n

La IA interpreta la intenci\u00f3n. El negocio conserva la autoridad sobre lo que realmente puede fabricar, entregar y vender.<\/strong><\/p>\n

Zherpa.tech: el mismo patr\u00f3n, implementado realmente<\/h2>\n

La hip\u00f3tesis de la playera puede parecer futurista. Pero el patr\u00f3n ya puede observarse en Zherpa.tech<\/a>.<\/p>\n

La implementaci\u00f3n WebMCP V16.2 dispone de herramientas reales que permiten a un agente recorrer progresivamente una experiencia comercial:<\/p>\n

Necesidad \u2192 descubrir capacidades \u2192 formar Crew \u2192 calcular ROI \u2192 preparar evaluaci\u00f3n \u2192 confirmaci\u00f3n humana.<\/strong><\/p>\n

1. discover_agent_capabilities<\/code><\/h3>\n

La primera herramienta recibe una necesidad empresarial. Su inputSchema<\/code> admite business_need<\/code>, business_area<\/code>, desired_outcome<\/code>, constraints<\/code> y max_results<\/code>.<\/p>\n

La herramienta busca exclusivamente dentro del cat\u00e1logo p\u00fablico vigente de Zherpa y devuelve las Capacidades Agentivas potencialmente relacionadas. Cada coincidencia puede incluir nombre, \u00e1rea, trabajo, resumen, sistemas, lo que puede hacer, lo que no puede hacer, precio mensual, precio anual y relevancia.<\/p>\n

No crea capacidades inexistentes ni promete resultados. Adem\u00e1s, est\u00e1 marcada como lectura, no produce consecuencias externas y pertenece a Clase A.<\/p>\n

El agente interpreta la necesidad, pero Zherpa.tech conserva la fuente de verdad sobre qu\u00e9 existe realmente en el cat\u00e1logo.<\/strong><\/p>\n

De \u201ctengo un problema\u201d a una capacidad concreta<\/h2>\n

Imaginemos que un director comercial dice a su agente:<\/p>\n

\n

\u201cTenemos oportunidades que se enfr\u00edan porque los vendedores no mantienen actualizado el siguiente paso. Quiero saber si Zherpa tiene alguna capacidad que pueda ayudar y cu\u00e1nto costar\u00eda.\u201d<\/p>\n<\/blockquote>\n

El agente puede expresar esa necesidad mediante discover_agent_capabilities<\/code>. No tiene que inventar qu\u00e9 vende Zherpa. Tampoco tiene que limitarse a inferirlo leyendo p\u00e1ginas. La herramienta devuelve \u00fanicamente capacidades del cat\u00e1logo real.<\/p>\n

Supongamos que entre las coincidencias aparece seguimiento-comercial<\/code>. El usuario podr\u00eda entonces decir: \u201cAgr\u00e9gala a mi Crew.\u201d<\/p>\n

2. build_crew<\/code><\/h3>\n

build_crew<\/code> permite consultar o modificar el Crew visible en la p\u00e1gina. Admite las acciones get<\/code>, set<\/code>, add<\/code>, remove<\/code> y clear<\/code>.<\/p>\n

S\u00f3lo acepta IDs reales del cat\u00e1logo y permite hasta 13 capacidades. Cuando modifica el Crew, el cambio tambi\u00e9n aparece en la interfaz para que la persona pueda verlo.<\/p>\n

Adem\u00e1s, la respuesta proporciona la composici\u00f3n del Crew y su informaci\u00f3n econ\u00f3mica: inversi\u00f3n, descuentos y ahorros correspondientes a la configuraci\u00f3n.<\/p>\n

Aqu\u00ed aparece una propiedad importante de WebMCP: agente e interfaz humana no necesitan vivir en mundos separados.<\/strong><\/p>\n

Ahora viene la pregunta empresarial: \u00bfvale lo que cuesta?<\/h2>\n

El director podr\u00eda continuar: \u201cAntes de solicitar una evaluaci\u00f3n quiero saber si econ\u00f3micamente tiene sentido.\u201d<\/p>\n

3. calculate_roi<\/code><\/h3>\n

calculate_roi<\/code> construye una hip\u00f3tesis de costo-beneficio para una o hasta tres capacidades utilizando la misma l\u00f3gica de la calculadora visible.<\/p>\n

No basta con pedirle al modelo: \u201cInv\u00e9ntame un ROI.\u201d La herramienta exige datos econ\u00f3micos correspondientes a las capacidades evaluadas.<\/p>\n

Para seguimiento-comercial<\/code>, por ejemplo, uno de los drivers admite conjuntamente variables como lost_deals_followup<\/code>, recoverable_deal_pct<\/code>, avg_deal_ticket<\/code> y deal_margin_pct<\/code>. Otro puede utilizar oportunidades sin siguiente paso, minutos necesarios para revisarlas y costo horario del responsable comercial.<\/p>\n

Si falta informaci\u00f3n necesaria, la herramienta devuelve status: \"needs_input\"<\/code> y especifica los datos faltantes.<\/p>\n

Cuando existen suficientes variables, devuelve la hip\u00f3tesis calculada, que puede incluir fuga econ\u00f3mica mensual, valor recuperable, inversi\u00f3n equivalente, beneficio neto, ROI, relaci\u00f3n beneficio\/costo, break-even y otros resultados seg\u00fan el caso.<\/p>\n

Y conserva una frontera esencial: la estimaci\u00f3n es una hip\u00f3tesis, no una garant\u00eda de retorno.<\/strong><\/p>\n

Aqu\u00ed empieza a aparecer el caso de negocio de WebMCP<\/h2>\n

El usuario comenz\u00f3 con lenguaje empresarial: \u201cMis vendedores dejan enfriar oportunidades.\u201d El agente ayud\u00f3 a traducir esa intenci\u00f3n.<\/p>\n

Pero no invent\u00f3 el cat\u00e1logo, la capacidad, sus restricciones, el precio, la configuraci\u00f3n del Crew, las reglas econ\u00f3micas ni las variables necesarias para calcular ROI.<\/p>\n

Humano expresa intenci\u00f3n \u2192 agente interpreta \u2192 herramientas consultan reglas reales \u2192 aplicaci\u00f3n calcula \u2192 humano eval\u00faa.<\/strong><\/p>\n

Comparemos con la playera:<\/p>\n

Humano expresa intenci\u00f3n \u2192 agente interpreta \u2192 tienda consulta cat\u00e1logo y restricciones \u2192 aplicaci\u00f3n valida configuraci\u00f3n y precio \u2192 humano eval\u00faa.<\/strong><\/p>\n

La estructura es sorprendentemente similar.<\/p>\n

Personalizaci\u00f3n: donde el valor potencial aumenta<\/h2>\n

Esto nos conduce a nuestra principal hip\u00f3tesis empresarial.<\/p>\n

WebMCP podr\u00eda resultar especialmente valioso cuando existe una distancia considerable entre lo que el cliente sabe pedir y los par\u00e1metros necesarios para producir una transacci\u00f3n v\u00e1lida.<\/strong><\/p>\n

Un producto est\u00e1ndar tiene poca distancia: \u201cQuiero este libro.\u201d<\/p>\n

Una configuraci\u00f3n tiene m\u00e1s: \u201cQuiero una laptop con suficiente memoria para estas cargas de trabajo, menos de cierto presupuesto y entrega esta semana.\u201d<\/p>\n

Una personalizaci\u00f3n puede tener todav\u00eda m\u00e1s: \u201cQuiero esta playera con este dise\u00f1o, estas dimensiones, este material y esta fecha de entrega.\u201d<\/p>\n

Y determinados servicios B2B presentan una distancia comparable: \u201cTengo este problema comercial, estas restricciones, estos sistemas y este objetivo. \u00bfQu\u00e9 combinaci\u00f3n necesito y econ\u00f3micamente tiene sentido?\u201d<\/p>\n

La hip\u00f3tesis no es que WebMCP genere autom\u00e1ticamente m\u00e1s ventas. No encontramos evidencia suficiente para sostener esa afirmaci\u00f3n.<\/p>\n

La hip\u00f3tesis es que puede reducir trabajo de traducci\u00f3n y configuraci\u00f3n entre intenci\u00f3n y resultado<\/strong>. Eso s\u00ed puede probarse.<\/p>\n

Entonces, \u00bfcu\u00e1ndo se justifica implementar WebMCP?<\/h2>\n

Chrome recomienda comenzar por el recorrido del usuario: identificar qu\u00e9 objetivos quiere completar, d\u00f3nde existe trabajo tedioso y en qu\u00e9 puntos una herramienta puede ayudar. No existe una lista universal de tools que todos los sitios deban implementar.<\/p>\n

Desde una perspectiva empresarial proponemos evaluar cinco condiciones: que exista una tarea y no s\u00f3lo informaci\u00f3n; que exista fricci\u00f3n entre intenci\u00f3n y ejecuci\u00f3n; que la empresa pueda definir una fuente de verdad; que las acciones puedan delimitarse por permisos, reversibilidad y consecuencias; y que exista algo que podamos medir.<\/p>\n

Si no podemos demostrar que el recorrido mejora alguna m\u00e9trica relevante, WebMCP corre el riesgo de convertirse en otra implementaci\u00f3n tecnol\u00f3gica buscando un problema.<\/p>\n

Qu\u00e9 medir<\/h2>\n

Una prueba empresarial deber\u00eda comparar el recorrido convencional contra el recorrido asistido.<\/p>\n

Tiempo hasta resultado v\u00e1lido:<\/strong> desde la intenci\u00f3n inicial hasta una configuraci\u00f3n que realmente pueda ejecutarse o comprarse.<\/p>\n

N\u00famero de interacciones:<\/strong> cu\u00e1ntos pasos necesita el usuario.<\/p>\n

Errores de configuraci\u00f3n:<\/strong> cu\u00e1ntas combinaciones terminan siendo inv\u00e1lidas.<\/p>\n

Correcciones humanas:<\/strong> con qu\u00e9 frecuencia el usuario debe corregir la interpretaci\u00f3n del agente.<\/p>\n

Abandono:<\/strong> d\u00f3nde se interrumpe el proceso.<\/p>\n

Conversi\u00f3n:<\/strong> cuando corresponda, cu\u00e1ntas configuraciones v\u00e1lidas terminan en una transacci\u00f3n.<\/p>\n

Incidentes agentivos:<\/strong> intentos de ejecutar acciones incorrectas, fuera de alcance o sin autorizaci\u00f3n.<\/p>\n

S\u00f3lo despu\u00e9s de medir esas variables tendr\u00eda sentido afirmar que existe retorno.<\/p>\n

La autonom\u00eda no tiene por qu\u00e9 ser binaria<\/h2>\n

Uno de los aspectos m\u00e1s interesantes de Zherpa.tech V16.2 es precisamente lo que no<\/strong> permite hacer autom\u00e1ticamente.<\/p>\n

4. request_evaluation<\/code><\/h3>\n

Esta herramienta prepara una solicitud de evaluaci\u00f3n utilizando informaci\u00f3n de contacto, necesidad y, cuando corresponde, Crew, ROI y capacidad personalizada.<\/p>\n

Pero no la env\u00eda.<\/p>\n

Su resultado establece status: \"awaiting_human_confirmation\"<\/code>, submitted: false<\/code> y review_required: true<\/code>.<\/p>\n

La solicitud queda preparada en la interfaz. S\u00f3lo despu\u00e9s de una acci\u00f3n humana expl\u00edcita se produce el env\u00edo hacia Zoho CRM. La implementaci\u00f3n clasifica este punto como Clase B, Human-in-the-Loop<\/strong>, y proh\u00edbe el env\u00edo autom\u00e1tico.<\/p>\n

Esto demuestra que preparar una web para agentes no obliga a escoger entre \u201cla IA s\u00f3lo recomienda\u201d y \u201cla IA puede hacer cualquier cosa\u201d. Podemos dise\u00f1ar diferentes grados de autonom\u00eda seg\u00fan las consecuencias.<\/p>\n

Leer, configurar, calcular, preparar, confirmar<\/h2>\n

El recorrido de Zherpa.tech permite visualizarlo: descubrir una capacidad es lectura, Clase A; modificar el Crew cambia estado local y es reversible, Clase A; calcular ROI es simulaci\u00f3n reversible, Clase A; preparar evaluaci\u00f3n involucra datos y prepara una acci\u00f3n externa, Clase B; enviar requiere acci\u00f3n humana.<\/p>\n

Esta separaci\u00f3n es especialmente relevante para comercio electr\u00f3nico.<\/p>\n

Una tienda podr\u00eda permitir que el agente busque \u2192 compare \u2192 personalice \u2192 valide \u2192 calcule \u2192 prepare carrito<\/strong> sin concederle autom\u00e1ticamente autoridad para comprar \u2192 pagar \u2192 aceptar condiciones<\/strong>.<\/p>\n

La autonom\u00eda puede aumentar progresivamente con la reversibilidad y el riesgo de cada acci\u00f3n.<\/p>\n

WebMCP no elimina los riesgos de los agentes<\/h2>\n

Convertir funciones de negocio en herramientas tambi\u00e9n crea superficie de riesgo.<\/p>\n

Chrome advierte expresamente sobre la inyecci\u00f3n indirecta de instrucciones: contenido malicioso que intenta alterar el comportamiento del agente. Tambi\u00e9n recomienda utilizar anotaciones como untrustedContentHint<\/code>, readOnlyHint<\/code> y consequentialHint<\/code> para ayudar a agentes y navegadores a interpretar las propiedades de una herramienta.<\/p>\n

Zherpa.tech utiliza algunas de ellas en su contrato real. discover_agent_capabilities<\/code>, por ejemplo, est\u00e1 marcado como lectura y no consecuencial. describe_custom_capability<\/code> y request_evaluation<\/code> identifican contenido no confiable porque procesan informaci\u00f3n proporcionada por el usuario.<\/p>\n

Pero existe una distinci\u00f3n importante: la seguridad no se resuelve simplemente agregando annotations. Las herramientas deben dise\u00f1arse alrededor de permisos, validaci\u00f3n, datos, consecuencias y fronteras operativas.<\/p>\n

Un matiz t\u00e9cnico importante: WebMCP todav\u00eda est\u00e1 evolucionando<\/h2>\n

WebMCP no debe presentarse como una infraestructura universal y terminada.<\/p>\n

La especificaci\u00f3n del 17 de septiembre de 2026 es un Draft Community Group Report<\/strong> y se\u00f1ala expl\u00edcitamente que no constituye un est\u00e1ndar W3C ni est\u00e1 actualmente en el Standards Track.<\/p>\n

Chrome contin\u00faa presentando su implementaci\u00f3n dentro de un Origin Trial \/ Intent to Experiment<\/strong>. Esto importa para cualquier decisi\u00f3n empresarial.<\/p>\n

Existe suficiente tecnolog\u00eda para experimentar y construir. Todav\u00eda no existe suficiente madurez para asumir compatibilidad universal, adopci\u00f3n masiva o retorno comercial demostrado.<\/p>\n

Zherpa.tech como implementaci\u00f3n temprana<\/h2>\n

Zherpa.tech V16.2 utiliza document.modelContext<\/code> como API WebMCP autoritativa y conserva navigator.modelContext<\/code> como alias de compatibilidad heredada cuando corresponde. La implementaci\u00f3n combina una herramienta declarativa con herramientas imperativas.<\/p>\n

Tambi\u00e9n publica mecanismos propios de descubrimiento y auditor\u00eda mediante \/.well-known\/webmcp<\/code>, \/webmcp-tools.json<\/code> y \/llms.txt<\/code>.<\/p>\n

Aqu\u00ed es importante no confundir implementaci\u00f3n propia con especificaci\u00f3n: el registro de Zherpa declara expresamente que la forma de esos artefactos es una decisi\u00f3n de descubrimiento y auditor\u00eda de Zherpa y no se presenta como parte estandarizada de WebMCP<\/strong>.<\/p>\n

Otro detalle t\u00e9cnico que conviene preservar: la implementaci\u00f3n V16.2 declara inputSchema<\/code>, annotations y funciones de ejecuci\u00f3n para sus tools imperativas, pero no declara actualmente un outputSchema<\/code> formal<\/strong>. Los resultados descritos son contratos efectivos producidos por los handlers.<\/p>\n

De e-commerce a intent commerce<\/h2>\n

La tienda de playeras nos permite regresar a la pregunta original.<\/p>\n

Durante a\u00f1os hemos optimizado: p\u00e1gina \u2192 producto \u2192 clic \u2192 carrito \u2192 conversi\u00f3n.<\/strong><\/p>\n

Los agentes podr\u00edan a\u00f1adir otro recorrido: intenci\u00f3n \u2192 restricciones \u2192 configuraci\u00f3n v\u00e1lida \u2192 autorizaci\u00f3n \u2192 transacci\u00f3n.<\/strong><\/p>\n

Podr\u00edamos llamarlo agent commerce<\/em>. Pero quiz\u00e1 haya una descripci\u00f3n todav\u00eda m\u00e1s precisa: intent commerce<\/strong>.<\/p>\n

El punto de partida ya no es necesariamente \u201cquiero navegar este cat\u00e1logo\u201d. Puede ser: \u201cEsto es lo que necesito conseguir.\u201d<\/p>\n

El agente ayuda a interpretar esa intenci\u00f3n. Las herramientas del negocio determinan qu\u00e9 es realmente posible. La aplicaci\u00f3n valida reglas y calcula consecuencias. La persona conserva la capacidad de revisar y decidir donde corresponde.<\/p>\n

La pregunta empresarial correcta<\/h2>\n

Por eso, la pregunta para un director no deber\u00eda ser: \u201c\u00bfDebemos poner WebMCP en nuestra p\u00e1gina?\u201d<\/strong><\/p>\n

Deber\u00eda ser: \u201c\u00bfCu\u00e1nto trabajo existe entre lo que nuestro cliente quiere y una configuraci\u00f3n v\u00e1lida que nuestro negocio puede entregar?\u201d<\/strong><\/p>\n

Si la respuesta es \u201cmuy poco\u201d, quiz\u00e1 una interfaz convencional sea suficiente.<\/p>\n

Si la respuesta involucra m\u00faltiples variables, reglas, comparaciones, restricciones, c\u00e1lculos y decisiones, puede existir un caso interesante para experimentar con agentes.<\/p>\n

Y entonces aparece una segunda pregunta: \u201c\u00bfQu\u00e9 partes de ese recorrido puede ejecutar un agente de forma reversible y cu\u00e1les deben permanecer bajo autorizaci\u00f3n humana?\u201d<\/strong><\/p>\n

Zherpa.tech ofrece ya una respuesta concreta a esa arquitectura:<\/p>\n

Necesidad \u2192 discover_agent_capabilities<\/code> \u2192 build_crew<\/code> \u2192 calculate_roi<\/code> \u2192 request_evaluation<\/code> \u2192 revisi\u00f3n humana \u2192 confirmaci\u00f3n \u2192 efecto externo.<\/strong><\/p>\n

No demuestra todav\u00eda que WebMCP vaya a aumentar ventas. Tampoco demuestra que todas las webs deban implementarlo.<\/p>\n

Demuestra algo m\u00e1s acotado y, por ahora, m\u00e1s \u00fatil: una aplicaci\u00f3n web puede convertir funciones reales del negocio en herramientas estructuradas para agentes sin entregarles necesariamente la decisi\u00f3n final.<\/strong><\/p>\n

La siguiente etapa ya no consiste en demostrar que t\u00e9cnicamente se puede. Consiste en medir si hacerlo crea suficiente valor.<\/p>\n

Fuentes<\/h2>\n