Guías · MCP
MCP se queda sin sesiones: qué cambia con la versión de julio de 2026 y qué gana tu empresa
La revisión 2026-07-28 de MCP quita las sesiones: qué cambia, qué se gana, qué riesgos hay y qué preguntar a tu proveedor, sin jerga y con fuentes.
Por Rafa Martínez y el equipo de Kalmia Zen · 11 min de lectura · Actualizada el 9 de octubre de 2026
- Pide El asistente envía la petición con su versión y lo que sabe hacer. Sin saludo previo.
- Reparte La pasarela lee la cabecera, sabe qué herramienta es y la manda a cualquier servidor libre.
- Pregunta Si falta un dato, el servidor contesta «necesito esto» con un estado firmado, en vez de dejar la llamada abierta.
- Responde Tú das el dato o el permiso desde el asistente.
- Termina El asistente repite la petición con tu respuesta y la acaba cualquier servidor, aunque el primero se haya reiniciado.
Leer la transcripción
Hola a todos y bienvenidos a un nuevo análisis a fondo. Hoy vamos a meternos de lleno en algo verdaderamente masivo, la reciente actualización del 28 de julio de 2026 del Model Context Protocol, o MCP para los amigos. A ver, para los que trabajan integrando asistentes y agentes de inteligencia artificial en entornos corporativos, este protocolo abierto ya es el puente fundamental hacia bases de datos y herramientas de empresa. Pero ojo, porque esta revisión en particular no es solo un parche más, que va, representa literalmente la mayor transformación estructural del protocolo desde su creación. Así que vamos a desgranar exactamente qué significa esta revolución sin estado y cómo va a cambiar para siempre el futuro de la IA empresarial. Y bueno, para entender la magnitud de este cambio, primero tenemos que dimensionar el ecosistema. Hablemos de cifras
puras y duras. 500 millones. Sí, estamos hablando de 500 millones de descargas mensuales de sus kits de desarrollo. Además, el protocolo ya cuenta con más de 950 servidores activos solo en el directorio de conectores de Claude. Esto ya no es un simple experimento de laboratorio. El MCP se ha convertido en pura infraestructura crítica. Grandes gigantes de la industria dependen de él a diario, por lo que cualquier cambio arquitectónico a este nivel tiene un impacto global brutal. Para desentrañar todo este lío, vamos a seguir una ruta muy clara. Primero, veremos la introducción al nuevo estándar. Segundo, la arquitectura sin estado. Tercero, las nuevas extensiones oficiales. Y por último, cómo afrontar la infraestructura y la transición. Arrancamos con la sección 1, introducción al nuevo estándar. El objetivo central de MCP siempre ha sido estandarizar cómo la
inteligencia artificial se comunica con los sistemas de una empresa, ya sea un ERP, un gestor de correos o un software de facturación. Pero a medida que la adopción ha crecido exponencialmente, la forma de gestionar estas conexiones empezó a mostrar grietas importantes. El problema de la arquitectura antigua, en la que se basaba en sesiones, es bastante evidente. Imaginemos una gestoría tradicional, donde un expediente completo solo existe en la memoria del único empleado que atendió el primer día. Si ese empleado está ocupado, toca esperar. Si se va a casa, hay que empezar de cero. En términos técnicos, todas las peticiones de un asistente de IA tenían que ir a un servidor específico que guardaba la memoria de esa sesión concreta. Y claro, esto requería mantener conexiones fijas, usar bases de datos adicionales y, en fin,
generaba unos cuellos de botella gigantescos para el escalado empresarial. Pasamos al plato fuerte. La sección 2. Arquitectura completamente sin estado. La solución a todos esos cuellos de botella es precisamente este salto a una arquitectura stateless o sin estado. Básicamente, MCP elimina por completo las sesiones activas, por lo que ya no hay que atar a cada cliente a una máquina específica. Cualquier servidor que esté disponible puede tomar cualquier petición en cualquier momento. El cambio técnico aquí es radical. En el modelo anterior, de 2025, la conversación siempre empezaba con un saludo inicial obligatorio, un comando llamado Initialize y un número de sesión metido en la cabecera. Pero ahora, en el modelo de 2026, todo eso desaparece de un plumazo. Cada petición es totalmente independiente. El asistente simplemente envía la petición indicando directamente su
versión y lo que sabe hacer, sin saludos previos ni ataduras de ningún tipo a una sesión persistente. Y esto nos lleva a un nuevo flujo de trabajo que es súper constante y fluido. Fijaos en la secuencia. Primero, el asistente pide. Segundo, una pasarela lee la cabecera y reparte la tarea libremente a cualquier servidor que esté desocupado. Tercero, si de repente falta un dato crucial en medio del proceso, el servidor pregunta, devolviendo un estado temporal en lugar de quedarse ahí bloqueando una conexión abierta. Cuarto, el asistente responde con la información requerida. Y quinto, cualquier servidor, incluso uno totalmente diferente al inicial, retoma el estado y termina el trabajo. Es un sistema increíblemente resistente a fallos. Claro, las ventajas de este nuevo sistema son auténtica música para los oídos de cualquier
equipo de tecnología. Al cargarnos las sesiones, las empresas pueden usar por fin balanceadores de carga estándar. Además, pueden apagar servidores y escalar a cero cuando no se usan. Esto significa que una empresa paga exclusivamente cuando el sistema está trabajando de verdad, ahorrando unos costes enormes. Y lo mejor, si un servidor se reinicia inesperadamente a mitad de una tarea, otro toma el relevo de forma totalmente invisible, sin interrumpir para nada la experiencia del usuario. Todo esto logra infraestructuras mucho más limpias. Pero claro, aquí surge la duda del millón. Si no hay sesión, ¿cómo narices recordamos un carrito de compras o el progreso de una tarea súper compleja? Bueno, la respuesta es el identificador de estado firmado. En lugar de esconder la sesión en una conexión, el contexto ahora se vuelve completamente explícito. El servidor entrega este identificador, una
especie de token, al asistente. Y el asistente simplemente lo envía de vuelta en la siguiente interacción como si fuera un dato más. Eso sí, es absolutamente vital que este identificador esté firmado criptográficamente, sea aleatorio y tenga una caducidad clara. Todo esto para evitar que el estado pueda ser manipulado maliciosamente por el camino. Vamos a la sección 3, extensiones oficiales clave. Con esta base sin estado ya bien consolidada, la nueva versión de MCP crece hacia afuera, formalizando un sistema de extensiones que son opcionales pero increíblemente potentes. Esta actualización trae tres extensiones oficiales principales que realmente amplían las fronteras de lo que la IA puede hacer de forma nativa. Hablamos de MCP Apps, la extensión de tareas y la de autorización empresarial. Cada una viene a resolver problemas específicos que antes requerían soluciones a medida y que,
sinceramente, a menudo eran bastante inestables. MCP Apps representa un cambio de paradigma brutal para la experiencia de usuario. Básicamente permite que un servidor despliegue interfaces gráficas e interactivas directamente dentro del chat del asistente. Ya no se trata de leer solo texto aburrido. Ahora es posible tener a la IA mostrándonos un calendario funcional para elegir una fecha o un formulario súper dinámico para aprobar un presupuesto. Y todo esto contenido de forma segura sin tener que salir nunca de la conversación principal. Las otras dos extensiones atacan directamente los procesos de a fondo y la seguridad pura y dura. La extensión de tareas es vital para esos procesos que tardan horas, como generar un informe complejo de fin de mes. En lugar de mantener una llamada abierta colgando indefinidamente, el servidor devuelve un número
de tarea y el asistente simplemente pregunta por su progreso más adelante. Por su parte, la autorización empresarial es la pieza clave para la gobernanza corporativa, ya que permite vincular el acceso de la IA de forma centralizada con el mismo directorio de identidades que la empresa ya usa para su red interna. Y por último, llegamos a la sección 4, infraestructura y transición. Al analizar la realidad del día a día, vemos implicaciones muy serias para la gobernanza. A nivel de seguridad e infraestructura, el balance es fascinante. Por el lado positivo, ganamos monitoreo estandarizado con OpenTelemetry y las pasarelas ahora pueden enrutar el tráfico leyendo solo las cabeceras, sin abrir el contenido sensible. Pero ojo aquí porque hay nuevos riesgos que vigilar de cerca. El principal es la repetición involuntaria de acciones. Pensémoslo, como ya
no hay sesiones, si una conexión falla aunque sea un milisegundo, el asistente simplemente repite la petición. Si esa petición era cobrar una factura, el sistema tiene que tener la inteligencia, lo que en tecnología llamamos idempotencia, para reconocer que es un duplicado y no cobrarle al cliente dos veces. Y como en toda gran evolución tecnológica, hay partes del código anterior que irremediablemente se quedan por el camino. Se han marcado como obsoletas varias funciones. Destaca muchísimo la retirada del registro dinámico de aplicaciones, que se cambia por un registro mucho más seguro basado en URL. Pero la decisión que más debate está generando es la retirada del sampling por parte del servidor. Es decir, que el servidor le pida al asistente que use su modelo de lenguaje. A partir de ahora, los servidores tendrán que llamar a los modelos de lenguaje por
su cuenta. Y esto, amigos, desplaza por completo quién asume y quién paga realmente la factura de esas llamadas a la API. De todos modos, para la tranquilidad de los equipos de tecnología, no hace falta entrar en pánico todavía. Aunque la revisión se publicó en julio de 2026, y gigantes de la infraestructura como Google, Cloudflare, AWS y GitHub adoptaron rapidísimamente este nuevo estándar, el protocolo nos da un margen bastante amplio. Las funciones marcadas como obsoletas van a seguir operativas durante al menos 12 meses. Por lo tanto, la verdadera fecha límite en el horizonte, ese momento en el que lo antiguo realmente podría dejar de funcionar, es el 28 de julio de 2027. En definitiva, MCP ha madurado de forma increíble. Ha pasado de ser una simple herramienta
local a convertirse en un protocolo completamente distribuido, escalable y robusto. Y mientras el reloj avanza inexorablemente hacia esa fecha límite de julio de 2027, el balón está ahora en el tejado de los equipos de desarrollo, que tendrán que auditar sistemas, planificar migraciones y asegurar la compatibilidad. La verdadera pregunta que nos queda flotando en el aire es, en esta nueva e inminente era sin estado, qué empresas lograrán escalar su inteligencia artificial de forma nativa y cuáles se quedarán atrás arrastrando arquitecturas obsoletas. Ha sido un verdadero placer desgranar toda esta información hoy. Nos vemos en el próximo análisis a fondo.
El 28 de julio de 2026 se publicó la revisión 2026-07-28 de MCP, el estándar abierto con el que los asistentes y los agentes de IA usan programas y datos de una empresa. Es el cambio más grande desde que existe: el protocolo deja de tener sesiones. En agosto llegaron las versiones de los grandes (Google, AWS, Cloudflare, Microsoft) y la conversación saltó a la prensa técnica de medio mundo.
Si MCP te suena a sopa de letras, empieza por qué es MCP para una empresa. Aquí contamos qué ha cambiado, qué se gana, qué riesgos nuevos hay y qué conviene preguntar a quien te monte o te venda un conector.
Las fechas
| Fecha | Qué pasó |
|---|---|
| 25 de noviembre de 2025 | Revisión anterior de MCP, la que usa casi todo lo que hay hoy en marcha |
| Diciembre de 2025 | MCP pasa a la Agentic AI Foundation, dentro de la Linux Foundation |
| 21 de mayo de 2026 | Se cierra la versión candidata y empiezan diez semanas de pruebas |
| 28 de julio de 2026 | Revisión 2026-07-28 publicada; los SDK oficiales de TypeScript, Python, Go y C# ya la hablan |
| Agosto de 2026 | Google (día 5), Cloudflare (día 6) y las pasarelas publican su soporte |
| 28 de julio de 2027 | Primera fecha en la que se podrá retirar lo que esta versión marca como obsoleto |
Según el blog oficial, los SDK de MCP rondan ya los 500 millones de descargas al mes, y Anthropic cuenta más de 950 servidores en el directorio de conectores de Claude. No es un experimento: es infraestructura.
Qué era una sesión y por qué estorbaba
Hasta ahora, una conversación entre un asistente y un servidor MCP empezaba con un saludo (initialize) en el que los dos se presentaban, y el servidor daba un número de sesión que el asistente repetía en cada petición. Funciona bien con un servidor en tu ordenador. Con muchos usuarios es un problema: como esa conversación vive en la memoria de un servidor concreto, todas las peticiones tienen que ir a esa misma máquina.
Es como una gestoría en la que tu expediente sólo lo tiene en la cabeza el empleado que te atendió el primer día: si está ocupado, esperas; si se va a casa, empiezas de cero. Para repartir el trabajo entre varias máquinas hacía falta «pegar» a cada cliente a su servidor o guardar las sesiones en una base aparte (normalmente Redis). Más piezas, más cosas que se rompen.
- Saludo El asistente envía el saludo inicial (initialize) al servidor
- Sesión El servidor crea una sesión y da un número que vive en su memoria
- Atadura Todas las peticiones siguientes deben ir a ese mismo servidor
- Problema Si ese servidor está ocupado o se reinicia, la conversación se pierde o espera
Qué cambia, en una tabla
| Antes (2025-11-25) | Ahora (2026-07-28) |
|---|---|
| Saludo inicial obligatorio | Cada petición dice su versión y lo que sabe hacer; hay una consulta opcional, server/discover, para preguntarlo antes |
| Número de sesión en una cabecera | No hay sesión: si hace falta recordar algo (un carrito, un expediente), el servidor da un identificador y la herramienta lo recibe como un dato más |
| El servidor podía preguntar al asistente en mitad de una llamada | El servidor contesta «necesito esto» con un estado firmado y el asistente repite la petición con la respuesta |
| Para enrutar había que abrir el cuerpo de la petición | Dos cabeceras dicen qué se pide y a qué herramienta, así que una pasarela reparte sin abrir nada |
| La lista de herramientas se pedía una y otra vez | El servidor dice cuánto tiempo se puede guardar la lista |
| Cada uno medía a su manera | Hueco estándar para el rastreo con OpenTelemetry |
| Tareas largas dentro del núcleo | Pasan a una extensión, junto con otras dos |
Lo que se gana
- Escalar como una web cualquiera. Cualquier petición puede llegar a cualquier copia del servidor detrás de un balanceador normal. Ya no hay que atar a cada cliente a una máquina.
- Servidores que se apagan cuando no se usan. Google lo explica con Cloud Run y Cloud Functions: el servidor puede bajar a cero cuando nadie lo usa. Para una pyme, eso es pagar sólo cuando trabaja.
- Reinicios y actualizaciones invisibles. Si un servidor se reinicia a mitad de una tarea, otro la termina. En Japón lo probaron matando el proceso a mitad de una llamada: uno nuevo la acabó con el estado que había devuelto el asistente.
- Menos piezas. El servidor MCP de GitHub ha quitado el almacén de sesiones en Redis que necesitaba antes.
- Pasarelas que controlan sin abrir el contenido. Con las cabeceras nuevas, una pasarela puede repartir, limitar y registrar quién usa qué herramienta sin leer los datos de la petición. Si no coinciden la cabecera y el contenido, la petición se rechaza.
- Más barato de usar con IA. Las listas de herramientas se pueden guardar en caché y la especificación pide devolverlas siempre en el mismo orden, lo que ayuda a la caché del modelo de lenguaje.
- Saber qué ha pasado. El rastreo estándar permite seguir una petición del asistente a la herramienta y hasta tu programa.
¿Se pierde el control de la sesión?
No: se mueve a un sitio mejor. Lo que antes vivía escondido en la conexión ahora es explícito: si un proceso necesita recordar algo entre llamadas, el servidor da un identificador (el número de carrito, el del expediente) y el asistente lo envía como un dato más. Se ve, se registra y se puede caducar.
A cambio, la especificación pone reglas claras: un identificador no es una prueba de identidad, debe ser aleatorio, conviene que caduque y el servidor debe comprobar que pertenece a quien lo usa. Es la versión moderna del viejo riesgo de robar una sesión, y está escrito en la guía oficial de seguridad.
- Petición El asistente pide algo que necesita recordar (un carrito, un expediente)
- Identificador El servidor genera un identificador aleatorio para ese dato
- Envío El asistente envía ese identificador como un dato más en cada petición
- Comprobación El servidor comprueba que el identificador pertenece a quien lo usa y que no ha caducado
Seguridad: lo que mejora
- Credenciales atadas a quien las emite. El asistente comprueba quién le ha dado cada permiso y no puede reutilizarlo con otro servidor de autorización. Cierra los ataques de «confusión» entre servidores.
- Alta de aplicaciones por URL. En lugar de que cualquier aplicación se registre sola (el registro dinámico, ahora obsoleto), la aplicación se identifica con una dirección que publica sus datos.
- Acceso gestionado por la empresa. Con la extensión de autorización empresarial, el directorio de la empresa (el mismo con el que entras al correo) decide a qué servidores MCP accede cada persona, y se da y se quita desde un único sitio.
- Una cabecera menos que robar. Sin número de sesión, desaparece un objetivo clásico.
Seguridad: lo que hay que vigilar
- Estados manipulados. El estado que el servidor devuelve para continuar una tarea vuelve por el asistente: hay que firmarlo y caducarlo, porque alguien podría alterarlo. Akamai lo resumió en junio: la nueva versión cierra riesgos antiguos y abre otros.
- Repetir acciones sin querer. Ya no se puede retomar una respuesta cortada: el asistente repite la petición. Si la herramienta cobra, envía un correo o crea un pedido, tiene que reconocer la repetición para no hacerlo dos veces. Lo advierten Equixly y WorkOS: la migración no da errores y las pruebas pasan, pero el duplicado aparece en producción.
- Que una pasarela se fíe sólo de las cabeceras. Las cabeceras ayudan a repartir, pero quien decide si algo se permite tiene que mirar también el contenido.
- Lo de siempre sigue ahí. La inyección de instrucciones a través de lo que la IA lee y las herramientas con descripciones trampa no se resuelven con esta versión. OWASP mantiene su lista de los diez riesgos de MCP, y en febrero se corrigió en el SDK de TypeScript un fallo grave que mezclaba datos entre clientes justamente en despliegues sin estado: sin estado no significa sin cuidado.
Las extensiones: MCP crece por fuera
La versión formaliza un sistema de extensiones: funciones opcionales, apagadas por defecto, que cliente y servidor activan si los dos las entienden. Las oficiales:
- MCP Apps. Un servidor puede enseñar una pantalla interactiva (un formulario, un panel, un calendario) dentro del chat del asistente, aislada del resto. Ya la entienden Claude, ChatGPT, Copilot en VS Code y Microsoft 365, entre otros. Para una empresa, es poder ofrecer una pequeña aplicación dentro de varios asistentes a la vez.
- Tareas. Para trabajos largos: el servidor devuelve un número de tarea y el asistente pregunta cómo va, en lugar de esperar con la conexión abierta.
- Autorización gestionada por la empresa, la que hemos contado arriba.
Lo que se retira (con calma)
Se marcan como obsoletas: que el servidor pida al asistente que use su modelo de lenguaje («sampling»), la lista de carpetas del usuario («roots»), el envío de registros por el protocolo, el registro dinámico de aplicaciones y el transporte HTTP+SSE antiguo. Siguen funcionando: la política nueva obliga a mantener lo obsoleto al menos doce meses, así que no podrá desaparecer antes del 28 de julio de 2027 (salvo por un riesgo de seguridad, con un mínimo de noventa días). Para el transporte HTTP+SSE las propias fuentes oficiales no coinciden en el plazo: el anuncio habla de un año y el registro de obsoletos, de tres meses.
La retirada más comentada es la del «sampling»: los servidores que lo usaban tendrán que llamar al modelo de lenguaje por su cuenta, y eso cambia quién paga esas llamadas.
Cómo lo ha recibido el mundo
- Estados Unidos. Google dice que lideró el trabajo para quitar el estado y lo resume como más escala y más seguridad sin más complicación. AWS lo ofrece como opción en su pasarela de agentes, Cloudflare ya ejecuta servidores enteros sin estado y GitHub se adelantó cinco días a la publicación. Anthropic anunció que llegará a sus productos de Claude «pronto», sin fecha.
- Crítica. El propio responsable del protocolo reconoció que para quien tenga su propia implementación es bastante trabajo. Varias voces avisan de que las versiones nuevas y viejas no se entienden entre sí salvo que el servidor hable las dos, y la retirada del «sampling» es la que más molesta.
- Japón. Las pruebas prácticas confirman lo prometido (un servidor muerto a mitad de la llamada, otro que la termina) y avisan de que el estado que viaja por el asistente debe ir firmado.
- China. Se presenta como una actualización que rompe compatibilidad; algún proyecto ha optado por hablar sólo la versión nueva.
- Europa. En Alemania y Francia se ha contado como el paso que permite escalar los servidores libremente; en España, como un cambio que no rompe lo que ya funciona hoy.
Qué significa para tu empresa
Si usas un asistente con conectores que te da un proveedor, no tienes que hacer nada hoy: lo que funciona sigue funcionando y hay al menos un año de margen. Pero conviene hacer estas preguntas a quien te los monte:
- ¿Qué servidores MCP usamos, quién los publica y qué versión hablan (2025-11-25, 2026-07-28 o las dos)?
- ¿Cuál es el plan para antes de julio de 2027?
- ¿El acceso pasa por un inicio de sesión de verdad o, mejor, por el directorio de la empresa?
- Si una herramienta hace algo con consecuencias (cobrar, enviar, crear), ¿qué pasa si la petición se repite?
- Los identificadores que guardan el estado, ¿son aleatorios, caducan y están atados a cada usuario?
- ¿Cada herramienta tiene sólo los permisos que necesita?
- ¿Queda registrado quién usó qué herramienta y qué hizo?
- Lo que no se puede deshacer, ¿lo aprueba una persona?
- ¿Los SDK y los servidores están al día y con versiones fijas?
Si vas a construir algo nuevo y lo vas a poner en internet para muchos usuarios, la versión nueva es la buena: más barata de mantener y más fácil de escalar. Si es un conector local para una persona, el cambio te afecta poco.
Lo que hacemos nosotros
Nuestro sistema de agentes ofrece sus herramientas por MCP desde el primer día, pero en local, por la entrada y salida estándar del ordenador, donde las sesiones nunca fueron un problema. Lo construimos con el SDK oficial de Python de la serie 1; la serie 2, la que habla la versión nueva, salió el mismo 28 de julio y ya va por la 2.3. También usamos como cliente el servidor MCP de una herramienta externa que todavía habla una revisión de 2025, y sigue funcionando: es justo la ventana de compatibilidad.
Nuestro plan es el que recomendamos: actualizar con calma, por escrito y con pruebas, antes de que termine el plazo, y sin tocar lo que funciona sólo porque haya una versión nueva.
Qué no resuelve
Quitar las sesiones hace MCP más fácil de escalar y de vigilar, pero no decide por ti qué herramientas debe tener un agente ni con qué permisos. Una herramienta con demasiado poder es igual de peligrosa con o sin sesiones. La regla de siempre sigue siendo la mejor: empezar por leer, dar los permisos mínimos, registrarlo todo y que una persona apruebe lo que no se puede deshacer. Lo contamos paso a paso en cómo conectar tu ERP a la IA con MCP.
Fuentes
- MCP: registro de cambios de la revisión 2026-07-28
- Blog oficial de MCP: la especificación 2026-07-28 (28 de julio de 2026)
- Blog oficial de MCP: la versión candidata (cerrada el 21 de mayo de 2026)
- MCP: versiones y compatibilidad con 2025-11-25
- MCP: buenas prácticas de seguridad (incluye el secuestro de identificadores de estado)
- MCP: extensiones (MCP Apps, tareas y autorización gestionada por la empresa)
- MCP: política de ciclo de vida y retirada de funciones
- Google Developers: escalar la infraestructura de agentes con MCP sin estado (5 de agosto de 2026)
- Anthropic: MCP 2026-07-28 llega a Claude (28 de julio de 2026)
- AWS: AgentCore Gateway y la especificación 2026-07-28
- Cloudflare: la nueva generación de MCP (6 de agosto de 2026)
- GitHub: su servidor MCP adopta la nueva especificación (23 de julio de 2026)
- Agentic AI Foundation (Linux Foundation): de herramienta local a protocolo distribuido
- Akamai: la nueva especificación cierra riesgos antiguos y abre otros (resumen en SiliconANGLE, 25 de junio de 2026)
- Equixly: MCP sin estado y el riesgo de repetir acciones (5 de agosto de 2026)
- OSV: CVE-2026-25536, fuga de datos entre clientes en el SDK de TypeScript
- Zenn (Japón): prueba práctica de MCP sin estado matando el servidor a mitad de una llamada
- Web Reactiva (España): MCP sin estado explicado
- OWASP: MCP Top 10 (borrador)
Registro de cambios
- 9 de octubre de 2026: primera versión.
Más sobre MCP
Hablas con Rafa Martínez, fundador ¿Qué tarea repites cada semana?
En 30 minutos te digo si merece un agente, cuánto costaría y por dónde empezar. Si no merece la pena, también te lo digo. Gratis.
¿Prefieres hablar ya? Llama al 910 052 322 (te atiende nuestro agente de voz, a cualquier hora) o escríbenos por WhatsApp.
