Milton Chanes — Author’s Blog

How to Govern Artificial Intelligence Agents

Tue, 01 Sep 2026 15:51:30 GMT

From Conversation to Action:

How to Govern Artificial Intelligence Agents

What an Artificial Intelligence Agent Really Is

There is no single definition, but there is a practical one: an agent is a software system capable of interpreting a goal, deciding which steps to follow, using tools, and adapting its behavior according to the results. Autonomy does not have to be complete: an agent can prepare a bank transfer and leave the final approval in the hands of an authorized person.

It is useful to distinguish four concepts that are often confused. A foundation model is trained on large amounts of information and can be adapted to a wide range of tasks. A language model is a type of foundation model specialized in processing and generating language. An assistant combines that model with instructions, an interface, and sometimes access to additional information. An agent adds the ability to select tools, execute actions, and continue working until it reaches the objective or encounters a condition that requires it to stop. The difference does not lie in how fluently it writes, but in what it can do beyond the conversation.

And one historical note that is often repeated incorrectly: ELIZA , the program published by Joseph Weizenbaum in 1966, was a pioneer of natural-language conversation, but it was not an agent. It worked through pattern matching and scripted responses. Its real lesson is a different one: it demonstrated how easily we attribute understanding to a machine that imitates conversation.

During the early years of generative artificial intelligence, we became accustomed to interacting with systems capable of summarizing documents, drafting texts, and proposing solutions. The user made a request, the model generated a response, and the interaction ended on the screen.

Agents change that relationship because they do not merely explain what should be done. A chatbot can describe the steps required to cancel an order; an agent can identify the purchase, verify the return conditions, request authorization, carry out the cancellation, and confirm the refund.

The difference may seem small, but it changes the nature of the problem. When the system only produces text, the main risk lies in the quality of the response. When it can act, permissions, identity, security, traceability, cost, and responsibility for the consequences all come into play. This is why the business challenge is not simply to build more capable agents, but to decide how much authority they should be given, under what conditions they may exercise it, and how control can be maintained when they intervene in real-world processes.

The Anatomy of an Agent

Although implementations vary, an enterprise agent typically combines six components.

The goal and instructions. “Manage returns” is too broad. An operational definition specifies which products can be returned, within what time frame, which data may be accessed, which exceptions require review, and which actions need human authorization. The goal is not simply an opening sentence: it is a behavioral specification.

The model. It interprets the request and proposes the next step based on statistical patterns and the context it receives. It does not understand the process in the same way a professional would, which is why a plausible response does not guarantee that the proposed action is correct.

The tools. These are functions that allow the agent to interact with other systems: an API, a database, a search engine, or a business application. The agent should not be given unrestricted access to the infrastructure. Someone who only needs to consult invoices should have read access, not permission to modify accounts.

Context and memory. Context contains the information available during a specific execution; memory preserves information across interactions. The more an agent remembers, the greater the exposure to personal, confidential, or outdated information. Memory therefore requires policies for consent, retention, user isolation, and deletion.

The execution loop. Interpret, select an action, execute it, observe the result, and decide on the next step. This is what allows an agent to handle processes that cannot be solved with a single response — and it is also what allows an initial mistake to propagate across several steps.

Evaluation and boundaries. Format checks, business rules, cost limits, maximum numbers of attempts, and conditions for escalating to a person. When the impact is significant, evaluation cannot be entrusted to the same model that generated the action: independent checks and deterministic rules are required. A bank transfer is not valid simply because the model says the amount “looks reasonable”.

Autonomy Is Not a Switch

Talking about autonomous systems suggests that we must choose between complete human control and complete freedom. In reality, autonomy exists on a spectrum:

The right question is not whether an agent should have autonomy, but how much autonomy it needs to create value without exceeding the organization’s ability to maintain control. A system that recommends a movie can tolerate a certain degree of error; one that blocks an account or commits funds cannot.

Where the Value Emerges

Three areas currently concentrate the strongest use cases.

Customer experience. Rufus, Amazon’s shopping assistant, combines models, product catalog data, purchase history, memory, and tools. Amazon states that more than 250 million customers used it in 2025 and that shoppers who incorporate it into their purchasing journey are more than 60% more likely to complete a purchase. These are metrics reported by the company itself, not an independent evaluation — but they illustrate where the value is heading: not toward better conversations, but toward reducing steps and completing a specific need.

Automation of complex processes. Agents become especially valuable when the work requires interpreting unstructured information and making decisions across multiple sources. The Formula 1 and AWS assistant for investigating technical incidents reduced initial classification time from more than a day to under twenty minutes and cut overall resolution time by as much as 86%, according to figures published by the organizations involved. The useful lesson is not the percentage itself: the project began by redesigning the diagnostic process and only then introduced the technology.

Software development. Agents can analyze repositories, generate code, run tests, and propose fixes. But generating code is not the same as producing reliable software: human review, testing, vulnerability analysis, and version control remain necessary, and in legacy systems, business knowledge is irreplaceable.

Not Every Problem Needs an Agent

The popularity of the term has led to conventional chatbots and automation systems being marketed as agents. Gartner refers to this practice as agent washing and predicts that more than 40% of agentic AI projects will be canceled by the end of 2027 because of rising costs, unclear value, or insufficient risk controls. These are forecasts, not established facts, but they point to something that can already be verified: routine and predictable processes are often better handled with conventional software. If an operation always follows the same five steps, adding a probabilistic model increases cost and reduces reliability. Agents make sense where there is variability, unstructured information, and decisions that cannot be encoded as a fixed sequence — and even then, critical operations should remain governed by deterministic rules.

In fact, much of what is presented as “agentic” is really a workflow with models embedded inside it: the sequence is defined by the developer, and the model does not choose the path. Anthropic makes exactly this distinction between workflows and agents, and recommends starting with the simplest possible solution and adding autonomy only when it demonstrably improves the outcome. Intermediate patterns — chaining steps, routing requests to specialized processes, parallelizing independent tasks, reviewing outputs with an evaluator, or using decision-and-action loops such as ReAct — cover most real-world cases without requiring full autonomy.

Two clarifications help avoid common misunderstandings. First, an agent’s “reflection” is not learning. Methods such as Reflexion preserve written critiques in memory and reuse them later, but the model’s parameters do not change; a system may correct a step during one session and repeat the same mistake the next day. Second, more agents do not necessarily produce better results. Anthropic measured in its own multi-agent research system that agents consumed roughly four times as many tokens as a standard conversation, while the multi-agent architecture consumed around fifteen times as many. This is a measurement from one specific system, not a universal law — but it shows that coordination has a cost, and that multi-agent architectures should be reserved for problems whose value justifies that overhead.

One final note on protocols, because they are also frequently confused: MCP connects an AI application to external tools, resources, and instructions; A2A, announced by Google in 2025 and later donated to the Linux Foundation, enables agents to communicate with one another. They are complementary, not competing approaches. And no protocol solves security by itself: authentication, permission limits, response validation, and operation logging are still required.

The Gap Between a Demo and Production

A demonstration is prepared with clean data, broad permissions, and a favorable path. Production brings unpredictable users, incomplete data, network failures, and actions with legal consequences. Bridging that gap requires solving five problems.

Identity. Knowing who initiates the operation, which agent is involved, and on whose behalf it is acting. If a person is not allowed to view their colleagues’ salaries, the agent they use should not be able to do so either: authorization must be preserved throughout the entire chain of tools.

Least-privilege permissions. Grant only what is strictly necessary for the task. A travel agent may be allowed to check calendars and prepare bookings, but it should require approval before making a purchase, with spending limits and a list of authorized providers. Platforms exist that help isolate executions and manage identities — Amazon Bedrock AgentCore is one example in this category — but none removes the responsibility of designing access policies properly.

Observability. Being able to reconstruct what the system did: what information led to each decision, which permissions it used, how much it cost, which step failed, and who approved it. A log that stores only the final response is insufficient for investigating incidents or demonstrating compliance. OpenTelemetry is working on conventions for consistently recording model calls, tokens, and tool interactions. Logging also introduces its own risks: traces may contain personal data and credentials, so they require their own access controls and retention policies.

Continuous evaluation. Models change, data is updated, and users discover unexpected ways to use systems, so evaluating only before launch is not enough. Evaluating only the final result is also insufficient: organizations need to examine the outcome, the trajectory — which decisions were made, which tools were used, and whether conditions were respected; a correct result obtained from an unauthorized source is not a success — as well as security, including permissions, data handling, and resistance to malicious instructions, and efficiency, including cost, latency, retries, and human intervention. Testing should include normal cases, edge cases, and adversarial inputs.

Cost control. Every reasoning step and every tool call consumes resources, and an agent trapped in a loop can multiply costs without improving the result. Systems therefore need limits on the number of steps, execution time, budget per task, and clear stopping conditions. The most powerful model is not always the best choice either: simple tasks can often be routed to smaller models or deterministic software.

Security Expands When the Model Can Act

A model can receive malicious instructions either directly from the user or indirectly from the documents it consults. This second form — indirect prompt injection — is particularly dangerous: an email may contain a hidden instruction telling the system to ignore its rules and send information to another address, and what a person sees as part of a document may be interpreted by the model as an instruction. NIST’s Generative AI Profile notes that these attacks can lead to unintended behavior, information disclosure, or code execution, and the risk increases when the model is connected to tools capable of taking action.

There is no single defense. Protection requires a combination of isolation, input and output validation, least-privilege permissions, separation between data and instructions, allowlists of authorized tools, adversarial testing, and human confirmation for sensitive actions. OWASP’s Top 10 for Agentic Applications provides a useful taxonomy of characteristic failures — including memory poisoning, privilege abuse, goal hijacking, and cascading failures — that can help organizations design appropriate tests and controls.

A Prudent Way to Start

Responsible adoption can be organized around five decisions. Choose a real, recurring, and measurable problem, with a baseline that allows performance before and after implementation to be compared. Grant the minimum autonomy necessary: begin with recommendations, move on to preparing operations, and allow execution only when testing demonstrates that the level of control is sufficient. Limit tools and permissions from the beginning, because adding restrictions later is always more difficult. Evaluate complete execution paths, not just answers that “look correct.” And prepare operations before expanding the scope: define accountable owners, supervision, incident response, rollback procedures, and criteria for withdrawing the system.

Intelligence That Acts Requires Accountability

Agents connect the ability to interpret language with the ability to intervene in digital processes. That combination can improve customer service, reduce repetitive work, and accelerate software development. But value does not come from autonomy itself: a more independent agent can also make mistakes across more steps, use more information, and create consequences that are harder to reverse.

The business question is not how many agents an organization can deploy, but which decisions should be delegated, which limits should remain in place, and how responsibility will be assigned when a machine acts on behalf of a person or an institution. Governing intelligence means exactly that: not preventing systems from acting, but designing the conditions under which they can do so with a clear purpose, proportionate permissions, effective oversight, and human accountability.

Fuentes y lecturas para profundizar

Joseph Weizenbaum — ELIZA — ACM, 1966. ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine

Anthropic — Building Effective Agents, diciembre de 2024.

Anthropic — How we built our multi-agent research system, junio de 2025.

Shunyu Yao et al . — ReAct: Synergizing Reasoning and Acting in Language Models , ICLR 2023.

Noah Shinn et al . — Reflexion: Language Agents with Verbal Reinforcement Learning , NeurIPS 2023.

Anand Rao y Michael Georgeff — BDI Agents: From Theory to Practice , ICMAS 1995.

Model Context Protocol (MCP) — Official specification and documentation .

Google Developers Blog — Announcing the Agent2Agent Protocol (A2A) , april 2025.

Google Developers Blog — Google Cloud donates A2A to Linux Foundation , june 2025.

Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 , june 2025.

Amazon — Amazon Rufus AI assistant: personalized shopping features.

AWS — How Formula 1 uses generative AI to accelerate race-day issue resolution.

AWS — Amazon Bedrock AgentCore , Product documentation.

NIST — AI Risk Management Framework.

NIST — Generative AI Profile (NIST AI 600-1 ).

OWASP Gen AI Security Project — Top 10 for Agentic Applications for 2026

OpenAI — A Practical Guide to Building Agents, 2025

LangChain — LangGraph Persistence Documentation on checkpoints, state persistence and fault-tolerant executaion.

OpenTelemetry — GenAI semantic conventions.

Cómo gobernar los agentes de inteligencia artificial

Tue, 01 Sep 2026 14:26:33 GMT

De conversar a actuar:

Cómo gobernar los agentes de inteligencia artificial

Qué es realmente un agente de inteligencia artificial

No existe una definición única, pero sí una descripción práctica: un agente es un sistema de software capaz de interpretar un objetivo, decidir qué pasos seguir, utilizar herramientas y adaptar su comportamiento según los resultados. La autonomía no tiene que ser completa: un agente puede preparar una transferencia y dejar la aprobación final en manos de una persona autorizada.

Conviene distinguir cuatro cosas que suelen confundirse. Un modelo fundacional se entrena con grandes cantidades de información y puede adaptarse a tareas diversas. Un modelo de lenguaje es la clase de modelo fundacional especializada en procesar y generar lenguaje. Un asistente combina ese modelo con instrucciones, una interfaz y, a veces, acceso a información adicional. Un agente añade la capacidad de seleccionar herramientas, ejecutar acciones y continuar trabajando hasta alcanzar el objetivo o encontrar una condición que le obligue a detenerse. La diferencia no está en la fluidez con la que escribe, sino en lo que puede hacer fuera de la conversación.

Y un apunte histórico que se repite mal con frecuencia: ELIZA , el programa que Joseph Weizenbaum publicó en 1966, fue pionero de la conversación en lenguaje natural, pero no era un agente. Funcionaba con patrones y guiones de respuesta. Su verdadera lección es otra: demostró la facilidad con la que atribuimos comprensión a una máquina que imita una conversación.

Durante los primeros años de la inteligencia artificial generativa nos acostumbramos a conversar con sistemas capaces de resumir documentos, redactar textos y proponer soluciones. El usuario formulaba una petición, el modelo generaba una respuesta y la interacción terminaba en la pantalla.

Los agentes cambian esa relación porque no se limitan a explicar qué debería hacerse. Un chatbot puede describir los pasos para cancelar un pedido; un agente puede identificar la compra, verificar las condiciones de devolución, solicitar autorización, ejecutar la cancelación y confirmar el reembolso.

La diferencia parece pequeña, pero transforma el problema. Cuando el sistema solo produce texto, el riesgo principal está en la calidad de la respuesta. Cuando puede actuar, entran en juego los permisos, la identidad, la seguridad, la trazabilidad, el coste y la responsabilidad por las consecuencias. Por eso el desafío empresarial no consiste únicamente en construir agentes más capaces, sino en decidir qué autoridad se les concede, bajo qué condiciones pueden utilizarla y cómo se mantiene el control cuando intervienen en procesos reales.

La anatomía de un agente

Aunque las implementaciones varían, un agente empresarial combina seis componentes.

El objetivo y las instrucciones. «Gestiona las devoluciones» es demasiado abierto. Una definición operativa indica qué productos pueden devolverse, en qué plazo, qué datos pueden consultarse, qué excepciones requieren revisión y qué acciones necesitan autorización humana. El objetivo no es una frase inicial: es una especificación de comportamiento.

El modelo. Interpreta la petición y propone el siguiente paso a partir de patrones estadísticos y del contexto recibido. No comprende el proceso como lo haría un profesional, y por eso una respuesta plausible no garantiza que la acción propuesta sea correcta.

Las herramientas. Funciones que permiten interactuar con otros sistemas: una API, una base de datos, un buscador, una aplicación corporativa. El agente no debería recibir acceso general a la infraestructura: quien consulta facturas necesita permiso de lectura, no autoridad para modificar cuentas.

El contexto y la memoria. El contexto reúne la información de una ejecución; la memoria conserva datos entre interacciones. Cuanto más recuerda un agente, mayor es la exposición de información personal, confidencial o desactualizada, así que la memoria necesita políticas de consentimiento, conservación, aislamiento entre usuarios y eliminación.

El ciclo de ejecución. Interpretar, seleccionar una acción, ejecutarla, observar el resultado y decidir el siguiente paso. Es lo que permite abordar procesos que no se resuelven con una sola respuesta — y también lo que permite que un error inicial se propague durante varios pasos.

La evaluación y los límites. Validaciones de formato, reglas de negocio, límites de coste, número máximo de intentos y condiciones de escalamiento a una persona. Cuando el impacto es relevante, la evaluación no puede confiarse al mismo modelo que generó la acción: hacen falta comprobaciones independientes y reglas deterministas. Una transferencia no es válida porque el modelo afirme que la cantidad «parece razonable».

La aUTONOMÍA NO ES UN INTERRUPTOR

Hablar de sistemas autónomos sugiere que hay que elegir entre control humano absoluto y libertad completa. En realidad la autonomía es gradual:

La pregunta adecuada no es si un agente debe tener autonomía, sino cuánta necesita para aportar valor sin superar la capacidad de control de la organización. Un sistema que recomienda una película tolera cierto error; uno que bloquea una cuenta o compromete fondos, no.

Dónde aparece el valor

Tres campos concentran hoy los casos más sólidos.

Experiencia del cliente. Rufus, el asistente de compras de Amazon, combina modelos, catálogo, historial, memoria y herramientas. Amazon afirma que más de 250 millones de clientes lo usaron en 2025 y que quienes lo incorporan a su compra tienen más de un 60% de probabilidad adicional de completarla. Son métricas comunicadas por la propia compañía, no una evaluación independiente — pero ilustran hacia dónde apunta el valor: no conversar mejor, sino reducir pasos y completar una necesidad concreta.

Automatización de procesos complejos. Los agentes interesan cuando el trabajo exige interpretar información no estructurada y decidir entre fuentes. El asistente de Formula 1 y AWS para investigar incidencias técnicas redujo la clasificación inicial de más de un día a menos de veinte minutos y el tiempo completo de resolución hasta un 86%, según las cifras publicadas por los propios implicados. La lección útil no es la cifra: el proyecto empezó reconstruyendo el proceso de diagnóstico y solo después introdujo la tecnología.

Desarrollo de software. Los agentes pueden analizar repositorios, generar código, ejecutar pruebas y proponer correcciones. Pero generar código no equivale a producir software fiable: la revisión humana, las pruebas, el análisis de vulnerabilidades y el control de versiones siguen siendo necesarios, y en sistemas heredados el conocimiento del negocio es insustituible.

No todos los problemas necesitan un agente

La popularidad del término ha hecho que chatbots y automatizaciones convencionales se vendan como agentes. Gartner llama a esta práctica agent washing , y prevé que más del 40% de los proyectos de IA agéntica serán cancelados antes de terminar 2027 por costes crecientes, valor difuso o controles de riesgo insuficientes. Son previsiones, no hechos; pero apuntan a algo verificable: un proceso rutinario y predecible se resuelve mejor con software convencional. Si una operación siempre sigue los mismos cinco pasos, añadir un modelo probabilístico eleva el coste y reduce la fiabilidad. Los agentes tienen sentido donde hay variabilidad, información no estructurada y decisiones que no pueden codificarse como secuencia fija — y aun ahí, con reglas deterministas para las operaciones críticas.

De hecho, buena parte de lo que se presenta como «agéntico» son flujos de trabajo con modelos dentro: la secuencia la define el programador y el modelo no elige el recorrido. Anthropic propone exactamente esa distinción entre flujos y agentes, y recomienda empezar por la solución más sencilla y añadir autonomía solo cuando mejore el resultado de forma demostrable. Los patrones intermedios — encadenar pasos, enrutar hacia procesos especializados, paralelizar tareas independientes, revisar con un evaluador, o ciclos de decisión y acción como ReAct — cubren la mayoría de los casos reales sin necesidad de autonomía plena.

Dos precisiones que evitan malentendidos frecuentes. Primera: la «reflexión» de un agente no es aprendizaje. Métodos como Reflexion conservan críticas escritas en una memoria y las reutilizan, pero los parámetros del modelo no cambian; un sistema puede corregir un paso en una sesión y repetir el mismo error mañana. Segunda: más agentes no significan mejor resultado. Anthropic midió en su propio sistema de investigación multiagente que los agentes consumen unas cuatro veces más tokens que una conversación, y la arquitectura multiagente unas quince veces más. Es la medición de un sistema concreto, no una ley — pero muestra que la coordinación se paga, y que la arquitectura multiagente debe reservarse para problemas cuyo valor la justifique.

Un apunte de protocolos, porque también se confunden: MCP conecta una aplicación de IA con herramientas, recursos e instrucciones externas; A2A, anunciado por Google en 2025 y donado a la Linux Foundation, comunica agentes entre sí. Se complementan, no compiten. Y ningún protocolo resuelve por sí mismo la seguridad: sigue haciendo falta autenticar, limitar permisos, validar respuestas y registrar operaciones.

La distancia entre la demostración y la producción

Una demostración se prepara con datos limpios, permisos amplios y un recorrido favorable. La producción trae usuarios imprevisibles, datos incompletos, fallos de red y acciones con consecuencias legales. Cruzar esa distancia exige resolver cinco problemas.

Identidad. Saber quién inicia la operación, qué agente interviene y en nombre de quién actúa. Si una persona no puede consultar los salarios de sus compañeros, el agente que utiliza tampoco debería poder: la autorización debe mantenerse a lo largo de toda la cadena de herramientas.

Permisos mínimos. Conceder solo lo imprescindible para la función. Un agente de viajes puede consultar calendarios y preparar reservas, pero pedir aprobación antes de comprar, con límite económico y proveedores autorizados. Existen plataformas que ayudan a aislar ejecuciones y administrar identidades — Amazon Bedrock AgentCore es un ejemplo de la categoría —, pero ninguna elimina la responsabilidad de diseñar bien las políticas de acceso.

Observabilidad. Poder reconstruir qué hizo el sistema: qué información llevó a cada decisión, qué permisos usó, qué costó, qué paso falló, quién aprobó. Un registro que solo conserva la respuesta final es insuficiente para investigar incidentes o demostrar cumplimiento. OpenTelemetry trabaja en convenciones para registrar de forma coherente llamadas a modelos, tokens y herramientas. Y registrar también tiene su riesgo: las trazas pueden contener datos personales y credenciales, así que necesitan sus propios controles de acceso y conservación.

Evaluación continua. Los modelos cambian, los datos se actualizan y los usuarios descubren usos imprevistos, así que evaluar solo antes del lanzamiento no basta. Y evaluar solo el resultado tampoco: hay que examinar el resultado, la trayectoria (qué decisiones tomó, qué herramientas usó, si respetó las condiciones — un resultado correcto conseguido con una fuente no autorizada no es un éxito), la seguridad (permisos, datos, resistencia a instrucciones maliciosas) y la eficiencia (coste, latencia, reintentos, intervención humana). Con casos normales, situaciones límite y entradas adversariales.

Control del coste. Cada razonamiento y cada llamada consumen recursos, y un agente atrapado en un ciclo multiplica el gasto sin mejorar nada. Hacen falta límites de pasos, duración, presupuesto por tarea y condiciones de interrupción. El modelo más potente tampoco es siempre la mejor elección: las tareas sencillas pueden ir a modelos pequeños o a software determinista.

La seguridad se amplía cuando el modelo puede actuar

Un modelo puede recibir instrucciones maliciosas del usuario o de los documentos que consulta. Esta segunda variante — la inyección indirecta de instrucciones — es la más peligrosa: un correo puede contener una orden oculta para ignorar las reglas y enviar información a otra dirección, y lo que para una persona es parte del documento, el modelo puede interpretarlo como una instrucción. El perfil de IA generativa del NIST señala que estas inyecciones pueden provocar comportamientos no previstos, filtración de información o ejecución de código, y el riesgo crece cuando el modelo está conectado a herramientas capaces de actuar.

No existe una defensa única. Se necesita la combinación: aislamiento, validación de entradas y salidas, permisos mínimos, separación entre datos e instrucciones, listas de herramientas autorizadas, pruebas adversariales y confirmación humana para acciones sensibles. El Top 10 de OWASP para aplicaciones agénticas ofrece una taxonomía útil de los fallos característicos — envenenamiento de memoria, abuso de privilegios, secuestro del objetivo, fallos en cascada — para diseñar pruebas y controles.

Una forma prudente de empezar

La adopción responsable puede organizarse en cinco decisiones. Elegir un problema real, repetido y medible, con una línea de base que permita comparar antes y después. Conceder la mínima autonomía necesaria: empezar recomendando, avanzar a preparar operaciones y ejecutar solo cuando las pruebas demuestren que el control es suficiente. Limitar herramientas y permisos desde el diseño, porque añadir restricciones después es siempre más difícil. Evaluar recorridos completos, no respuestas que «parecen correctas». Y preparar la operación antes de ampliar el alcance: responsables, supervisión, respuesta a incidentes, reversión y criterios de retirada.

La inteligencia que actúa necesita responsabilidad

Los agentes conectan la capacidad de interpretar lenguaje con la posibilidad de intervenir en procesos digitales. Esa combinación puede mejorar la atención al cliente, reducir trabajo repetitivo y acelerar el desarrollo de software. Pero el valor no procede de la autonomía por sí misma: un agente más independiente también puede equivocarse durante más pasos, usar más información y producir consecuencias más difíciles de revertir.

La pregunta empresarial no es cuántos agentes puede desplegar una organización, sino qué decisiones conviene delegar, qué límites deben mantenerse y cómo se asignará la responsabilidad cuando una máquina actúe en nombre de una persona o una institución. Gobernar la inteligencia significa exactamente eso: no impedir que los sistemas actúen, sino diseñar las condiciones para que lo hagan con una finalidad clara, permisos proporcionales, supervisión efectiva y responsabilidad humana.

Fuentes y lecturas para profundizar

Joseph Weizenbaum — ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine, Communications of the ACM, 1966. ELIZA — A Computer Program for the Study of Natural Language Communication Between Man and Machine

Anthropic — Building Effective Agents, diciembre de 2024.

Anthropic — How we built our multi-agent research system, junio de 2025.
How we built our multi-agent research system

Shunyu Yao et al . — ReAct: Synergizing Reasoning and Acting in Language Models , ICLR 2023.

Noah Shinn et al . — Reflexion: Language Agents with Verbal Reinforcement Learning , NeurIPS 2023.

Anand Rao y Michael Georgeff — BDI Agents: From Theory to Practice , ICMAS 1995.

Model Context Protocol (MCP) — Especificación y documentación oficial .

Google Developers Blog — Announcing the Agent2Agent Protocol (A2A) , abril de 2025.

Google Developers Blog — Google Cloud donates A2A to Linux Foundation , junio de 2025.

Gartner — Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 , junio de 2025.

Amazon — Amazon Rufus AI assistant: personalized shopping features.

AWS — How Formula 1 uses generative AI to accelerate race-day issue resolution.

AWS — Amazon Bedrock AgentCore , documentación del producto.

NIST — AI Risk Management Framework.

NIST — Generative AI Profile (NIST AI 600-1 ).

OWASP Gen AI Security Project — Top 10 for Agentic Applications for 2026

OpenAI — A Practical Guide to Building Agents, 2025

LangChain — LangGraph Persistence Documentación sobre puntos de control, persistencia del estado y ejecución tolerante a fallos.

OpenTelemetry — GenAI semantic conventions. Convenciones para observabilidad y trazabilidad de aplicaciones de inteligencia artificial generativa.

MCP: The Infrastructure That Allows Artificial Intelligence to Connect with the Digital World

Tue, 25 Aug 2026 13:29:29 GMT

MCP: The Infrastructure That Allows Artificial Intelligence to Connect with the Digital World

When we use artificial intelligence to answer a question, translate a text, or summarize a document, it is relatively easy to forget that the model is, in reality, quite isolated. It may possess enormous amounts of knowledge and be capable of reasoning about complex problems, but that does not mean it automatically knows our files, can check our company calendar, review an internal database, or access the tools we use every day.

This limitation becomes especially important when we stop thinking of artificial intelligence as a simple conversational system and begin to imagine agents capable of actually performing work. An agent may know perfectly well how to find a supplier, organize a meeting, analyze a project, or update a sales record, but if it has no secure and standardized way to communicate with the applications where that information resides, we still need to build specific connections for each individual case.

It was precisely to solve this problem that MCP , the Model Context Protocol , emerged. Anthropic introduced the protocol as an open standard in November 2024 with the aim of creating a common way to connect artificial intelligence systems with information repositories, business tools, and development environments. The idea was to reduce a problem that was becoming increasingly obvious: every new combination between an AI system and a data source required a different integration.

MCP attempts to create a common layer between these two worlds. If this infrastructure continues to spread, it may eventually become one of the least visible yet most important components of the transformation driven by AI agents.

The Problem of an Intelligence That Knows a Great Deal but Does Not Know Our World

An artificial intelligence model may have learned enormous amounts of public information and be extraordinarily good at interpreting language, but our everyday work depends largely on private, current, and highly specific information. A company may have contracts stored in a document management system, projects distributed across different applications, commercial data inside a CRM, emails, calendars, databases, technical files, and numerous specialized programs.

Artificial intelligence should not have unrestricted access to all of this content, but neither can it become a truly effective working tool if it remains completely disconnected from it. The challenge is to allow a system to access or use what it needs, when it needs it, and with the appropriate permissions.

Before protocols such as MCP, a company that wanted to connect its AI assistant to five different systems could end up developing five separate integrations. If it later wanted to use another model or add another tool, some of those connections might have to be rebuilt. The larger the ecosystem became, the greater the maintenance problem.

MCP proposes a more standardized architecture. Instead of developing a completely different connection every time we want to link a model with a tool, an application can expose certain capabilities through an MCP server, and compatible AI applications can connect to them as clients. Anthropic described this architecture from the outset as a way to establish open, bidirectional connections between AI-powered applications and the sources where data resides.

The importance of the concept goes beyond making programming easier. If different systems begin to use a common interface, artificial intelligence can gradually become a layer capable of working across many applications without requiring every combination to be invented from scratch.

An Imperfect but Useful Comparison: the USB of Artificial Intelligence

A simple way to explain MCP is to compare it with USB, although technically they are very different things. Before certain connection standards became widespread, devices required a huge variety of cables, ports, and drivers. Each manufacturer solved essentially the same problem in a different way.

Standards did not eliminate the diversity of devices. A keyboard remained different from a camera, and a printer continued to perform a different function from a hard drive. What changed was that they no longer required completely incompatible systems in order to establish a basic connection.

MCP pursues a similar idea within the artificial intelligence ecosystem. A database remains a database, a design program continues to have its own functions, and a customer management system retains its own structure. The protocol does not attempt to turn all of these tools into the same application. Instead, it tries to provide a common way for artificial intelligence to discover which capabilities are available and use them in a structured manner.

For that reason, calling MCP “the USB of AI” is not technically precise, but it helps illustrate its importance. The true value of a standard becomes apparent when we stop thinking about a single connection and begin to imagine thousands of applications capable of understanding the same basic way of communicating.

From Context to Tools

The name Model Context Protocol may suggest that its only purpose is to provide additional information to a model, but the concept has evolved considerably. In its early stages, MCP primarily addressed the problem of connecting models with sources of context. However, as agents have become more important, the protocol has also evolved into an infrastructure for exposing tools and allowing systems to perform certain actions.

We can imagine an MCP server connected to a project management application. This server might indicate that tools are available for consulting tasks, searching projects, creating new items, or updating certain fields. The artificial intelligence would not need to understand internally how the entire application works. It would only need to understand the capabilities the application has chosen to expose and use the appropriate tool when the user requests something.

The distinction is fundamental. An isolated artificial intelligence can explain how to update the status of a project. A connected artificial intelligence may be able to update it itself, provided it has permission to do so.

OpenAI is already using this model within its own integrations. As of August 2026, full MCP support, including modification and write actions, is being rolled out in beta for organizations using certain business ChatGPT plans. These MCP applications can allow ChatGPT to consult corporate systems and also perform actions such as initiating workflows, creating tasks, or updating information in business tools.

We are therefore moving from using artificial intelligence solely to interpret information toward using it as an interface capable of coordinating actions across different systems.

Why MCP Is Especially Important for Agents

In the previous article, we discussed the difference between a chatbot and an agent. A chatbot responds to a specific request, while an agent can receive a broader objective, use tools, and continue working until a task has been completed. This difference makes connectivity far more important.

Imagine an agent responsible for organizing a business trip. To do this properly, it might need to consult the calendar, determine where the meeting is taking place, analyze flights, review internal expense policies, find information about hotels, and finally prepare several alternatives. Without connections to those systems, artificial intelligence can help us think, but we still have to move the information manually from one application to another.

If those services expose compatible capabilities, an agent can begin using different tools as it progresses through the problem. It does not necessarily need to receive all the information from the beginning. It can determine what it needs, retrieve it from the appropriate source, and use it to decide the next step.

This is one of the fundamental transformations taking place in modern artificial intelligence. For years, we tried to place all relevant information inside the model’s context. With agents, we are beginning to build systems in which intelligence can search for and use information when it needs it.

MCP is becoming one of the layers designed to make that relationship possible.

What Really Matters Is Interoperability

New tools and standards appear constantly in technology, and many disappear after a few years. For that reason, the importance of MCP should not be measured solely by its current technical features, but by the level of adoption it manages to achieve.

A protocol of this kind becomes especially valuable when different companies that compete with one another decide to use it. At that point, it stops being simply a feature of one product and begins functioning as common infrastructure.

Since its introduction by Anthropic in November 2024, MCP has spread rapidly across the artificial intelligence ecosystem. At the end of 2025, it became part of the Agentic AI Foundation, created under the Linux Foundation as a neutral space for different projects related to AI agents. MCP was one of the founding projects of this initiative.

This shift is particularly significant. A standard originally designed by one company has a greater chance of becoming cross-industry infrastructure when its governance no longer depends exclusively on that company and instead develops within a broader community.

In practical terms, this means MCP should no longer be understood simply as “Anthropic’s protocol.” Its evolution is being managed through maintainers, working groups, and open processes for proposing changes to the specification.

By 2026, MCP Is Already Considerably Different from the Original Protocol

The speed at which the ecosystem is evolving can be seen simply by comparing the earliest versions of MCP with the specification published on July 28, 2026. That update introduced one of the largest changes since the protocol was created and modified part of its architecture to make it better suited to enterprise infrastructure and distributed systems.

Among the most important changes was a move toward a stateless core designed to work more effectively over conventional HTTP infrastructure. This makes it easier to scale MCP servers without depending on persistent sessions between every client and server. The release also introduced authorization improvements, extension mechanisms, and new capabilities designed for applications and long-running processes.

This may sound excessively technical to someone who simply uses artificial intelligence, but these are precisely the kinds of changes that allow a technology to move beyond the experimental stage and begin operating in real systems with thousands or millions of requests, different authorization levels, and strict reliability requirements.

According to the project’s maintainers, the main MCP SDKs are now recording hundreds of millions of downloads per month, while the TypeScript and Python SDKs have each exceeded one billion cumulative downloads. These figures do not mean there are one billion different users, since a large proportion comes from automated installations and development systems, but they do illustrate how quickly the infrastructure is being incorporated into the technology ecosystem.

MCP Apps and a Boundary That Is Beginning to Disappear

Another particularly interesting development is that MCP connections no longer need to be limited to invisible data and tools. The extension architecture introduced in 2026 includes MCP Apps, which allow servers to provide visual interfaces that can appear directly within the application being used to interact with the artificial intelligence.

This concept may eventually change our relationship with software. For decades, we have constantly switched between programs. If we wanted to review a project, we opened one application; if we needed to check email, we moved to another; to look at a calendar, we used a third; and to analyze a database, we opened a fourth.

Artificial intelligence connected through common protocols can begin to become a layer through which we consult and use different systems without constantly navigating between interfaces. This does not necessarily mean traditional applications will disappear, but it may change where the main point of interaction is located.

Instead of asking ourselves which program we need to open to perform a particular activity, we may simply explain what we want to achieve and allow the system to determine which tools it needs to use.

The primary interface then stops being exclusively an application menu and begins to become our intention expressed through language.

Security Becomes Far More Important When AI Can Act

All of this capability also introduces an obvious problem. The more tools an artificial intelligence can use, the greater the potential consequences of an error.

If a chatbot misunderstands a question and gives an incorrect answer, we can simply ignore it. If an agent misunderstands an instruction and has permission to modify a database, send an email, or change information inside a business system, that mistake can immediately become an action.

For that reason, the security of MCP and other agent infrastructures cannot consist merely of checking whether the connection works. It is necessary to define clearly which user is performing the action, what permissions they have, which server they are allowed to use, which tools are available, and which operations require additional authorization.

The July 2026 specification introduced new measures specifically designed to strengthen authorization and better adapt the protocol to modern enterprise systems. The roadmap published on August 22, 2026 also places agent identity and enterprise security among the main priorities for the next stages of the protocol.

This reveals something important about the evolution of agents. The major challenge is no longer simply making them capable of doing more things. It is increasingly about determining reliably who can do what, using which system, and under what conditions.

A Common Protocol Does Not Eliminate Risk

The existence of a standard does not automatically mean that every MCP server is safe. Precisely because the protocol makes it easier to connect tools with artificial intelligence systems, a badly designed or malicious server could represent a considerable risk.

A user might install an integration that requests excessive permissions. A tool could describe its capabilities in a misleading way. An external source could attempt to manipulate an agent through instructions hidden inside apparently normal content. There is also the classic problem of chains of trust: an application trusts an agent, the agent trusts a tool, and that tool retrieves information from another system.

The security of this new infrastructure will need to combine authentication, least-privilege permissions, supervision, activity logs, and mechanisms that make it possible to understand which actions an agent performed and why.

This transformation resembles what happened to the Internet as it evolved from relatively static pages into systems capable of handling banking, identities, companies, and entire public administrations. The more useful an infrastructure becomes, the greater the incentive both to protect it and to exploit it.

Competition May Shift from Models to Ecosystems

In recent years, much of the conversation about artificial intelligence has focused on comparing models. Which one reasons better? Which one writes better? Which one programs better? Which one has a larger context window?

Those differences will continue to matter, but if models become increasingly interchangeable and all of them can access the same tools through common protocols, another part of the competition may shift toward the ecosystem.

An artificial intelligence that reasons slightly better may be less useful than another one that is perfectly connected to the systems we use every day. For a company, controlled access to internal documentation, calendars, specialized applications, and management systems may provide more practical value than a small difference in benchmark performance.

MCP introduces a particularly interesting possibility here: partially separating intelligence from tools. If a company builds certain connections around an open protocol, it can reduce its dependence on a single model provider and allow different systems to use the same infrastructure.

This does not completely eliminate the problem of vendor lock-in, because each platform will continue to have its own characteristics, but it can reduce the need to rebuild an entire ecosystem simply because a better model appears.

For the User, MCP Will Probably Become Invisible

Most people do not know which protocols their browser uses to load a webpage or which mechanisms allow email to synchronize across different devices. Nor do they need to.

If MCP truly succeeds in becoming common infrastructure, something similar will probably happen. Users will not need to think constantly about MCP servers, tool schemas, or authorization protocols. They will simply see that their artificial intelligence can connect to certain applications and perform certain actions.

The infrastructure will become important precisely because it becomes invisible.

We may be able to say, “Find the latest project budget, compare the changes with the previous version, and prepare a summary for tomorrow’s meeting,” without worrying too much about which application contains each file or how the artificial intelligence connects to it.

Behind an apparently simple instruction, multiple connections, searches, and verification steps may take place. The complexity will still exist, but it will gradually move away from the user and into the infrastructure itself.

The Next Step Is for Agents to Communicate Better with One Another

The evolution does not end with connecting artificial intelligence to applications. As systems composed of multiple agents begin to appear, it also becomes necessary to improve communication between those agents themselves.

The MCP roadmap published on August 22, 2026 identifies agent-to-agent messaging mechanisms, improvements to HTTP transport, enterprise identity and security, and the developer experience as priority areas for future versions.

This is particularly interesting because it shows where the architecture is heading. In the first stage, we needed to provide context to a model. Then we began connecting that model to tools. Now we are beginning to design infrastructure in which agents, applications, and other agents can interact within the same ecosystem.

Artificial intelligence is gradually ceasing to be an isolated application and becoming a layer that connects different components of the digital world.

Perhaps the Real Revolution Is Not the Model

Every few months, a new model appears that outperforms the previous one on certain tests and generates another wave of headlines. It is understandable that we pay attention to these improvements because they are easy to demonstrate. We can watch an artificial intelligence write better, program better, or solve a problem it previously could not solve.

Infrastructure is far less spectacular. A new authorization mechanism, a connection protocol, or a change in the way tools are exchanged hardly creates the same impression as watching a robot walk or seeing an artificial intelligence generate a video in seconds.

Yet the history of technology shows that many of the deepest transformations depended precisely on standards that later stopped attracting our attention. The Internet does not exist because of a single spectacular application, but because of protocols that allow millions of different systems to communicate. The Web was able to expand because common rules existed that allowed people to build upon it.

MCP attempts to solve a similar problem on a much more specific scale: providing a common language through which artificial intelligence systems can discover information and tools and use them.

It is still too early to know whether MCP will ultimately become the dominant standard or whether other architectures will emerge in the future and share that space. What seems much clearer is that the problem it is trying to solve is not going away.

The more capable agents become, the more they will need to connect with our digital world. At the same time, the more connected that world becomes, the less sense it will make to build a completely different integration for every model, every application, and every company.

For that reason, the next great revolution in artificial intelligence may take place somewhere most users will never see. It does not necessarily have to happen inside the model itself, but rather in the infrastructure that allows that model to stop operating in isolation and begin connecting with other intelligences, tools, applications, data, and systems.

And we probably will not have to wait very long to see it. Everything is moving at extraordinary speed, to the point that developments that today seem as though they belong to the coming years may begin to become visible within days, weeks, or months. Claude and ChatGPT are already doing it. In fact, by the time this article is published, there is a very real possibility that some of what it says will already be outdated.

That is how fast this is moving.

MCP: la infraestructura que permite a la inteligencia artificial conectarse con el mundo digital

Tue, 25 Aug 2026 13:20:57 GMT

MCP: la infraestructura que permite a la inteligencia artificial conectarse con el mundo digital

Cuando utilizamos una inteligencia artificial para responder una pregunta, traducir un texto o resumir un documento, resulta relativamente fácil olvidar que el modelo se encuentra, en realidad, bastante aislado. Puede disponer de enormes cantidades de conocimiento y ser capaz de razonar sobre problemas complejos, pero eso no significa que conozca automáticamente nuestros archivos, pueda consultar el calendario de nuestra empresa, revisar una base de datos interna o acceder a las herramientas que utilizamos cada día.

Esta limitación empieza a ser especialmente importante cuando dejamos de pensar en la inteligencia artificial como un simple sistema de conversación y comenzamos a imaginar agentes capaces de realizar trabajo. Un agente puede saber perfectamente cómo buscar un proveedor, organizar una reunión, analizar un proyecto o actualizar un registro comercial, pero si no tiene una forma segura y estandarizada de comunicarse con las aplicaciones donde se encuentra esa información, seguimos necesitando construir conexiones específicas para cada caso.

Precisamente para resolver este problema apareció MCP, Model Context Protocol. Anthropic presentó este protocolo como estándar abierto en noviembre de 2024 con la intención de crear una forma común de conectar sistemas de inteligencia artificial con repositorios de información, herramientas empresariales y entornos de desarrollo. La idea era reducir un problema que comenzaba a hacerse evidente: cada nueva combinación entre una inteligencia artificial y una fuente de datos necesitaba una integración diferente.

MCP intenta crear una capa común entre esos dos mundos. Si esta infraestructura continúa extendiéndose, probablemente termine siendo una de las piezas menos visibles y al mismo tiempo más importantes de la transformación provocada por los agentes de inteligencia artificial.

El problema de una inteligencia que sabe mucho pero no conoce nuestro mundo

Un modelo de inteligencia artificial puede haber aprendido enormes cantidades de información pública y ser extraordinariamente bueno interpretando lenguaje, pero nuestro trabajo cotidiano depende en gran medida de información privada, actualizada y específica. Una empresa puede tener contratos almacenados en un sistema documental, proyectos repartidos entre diferentes aplicaciones, datos comerciales dentro de un CRM, correos electrónicos, calendarios, bases de datos, archivos técnicos y numerosos programas especializados.

La inteligencia artificial no debería tener acceso indiscriminado a todo ese contenido, pero tampoco puede convertirse en una verdadera herramienta de trabajo si permanece completamente separada de él. El desafío consiste en permitir que un sistema pueda consultar o utilizar aquello que necesita, cuando lo necesita y con los permisos apropiados.

Antes de protocolos como MCP, una empresa que quisiera conectar su asistente de inteligencia artificial con cinco sistemas diferentes podía terminar desarrollando cinco integraciones distintas. Si posteriormente deseaba utilizar otro modelo o incorporar otra herramienta, parte de esas conexiones podía tener que reconstruirse. Cuanto mayor era el ecosistema, mayor era también el problema de mantenimiento.

MCP propone una arquitectura más estandarizada. En lugar de desarrollar una conexión completamente diferente cada vez que queremos relacionar un modelo con una herramienta, la aplicación puede exponer determinadas capacidades mediante un servidor MCP y las aplicaciones de inteligencia artificial compatibles pueden conectarse a ellas como clientes. Anthropic describió desde el comienzo esta arquitectura como una forma de establecer conexiones bidireccionales y abiertas entre aplicaciones impulsadas por IA y las fuentes donde se encuentran los datos.

La importancia del concepto no reside únicamente en facilitar la programación. Si diferentes sistemas comienzan a utilizar una interfaz común, la inteligencia artificial puede convertirse progresivamente en una capa capaz de trabajar sobre muchas aplicaciones sin que cada combinación tenga que inventarse desde cero.

Una comparación imperfecta, pero útil: el USB de la inteligencia artificial

Una forma sencilla de explicar MCP consiste en compararlo con USB, aunque técnicamente sean cosas muy diferentes. Antes de que determinados estándares de conexión se generalizaran, los dispositivos necesitaban una enorme variedad de cables, puertos y controladores. Cada fabricante resolvía el mismo problema de una manera diferente.

Los estándares no eliminaron la diversidad de dispositivos. Un teclado siguió siendo diferente de una cámara, y una impresora continuó realizando una función distinta a la de un disco duro. Lo que cambió fue que dejaron de necesitar sistemas completamente incompatibles para establecer una conexión básica.

MCP persigue una idea parecida en el ecosistema de la inteligencia artificial. Una base de datos continúa siendo una base de datos, un programa de diseño sigue teniendo sus propias funciones y un sistema de gestión comercial mantiene su estructura. El protocolo no pretende convertir todas esas herramientas en la misma aplicación. Intenta proporcionar una forma común mediante la cual una inteligencia artificial pueda descubrir qué capacidades están disponibles y utilizarlas de manera estructurada.

Por eso llamar a MCP «el USB de la IA» no es técnicamente exacto, pero ayuda a comprender su importancia. El verdadero valor de un estándar aparece cuando dejamos de pensar en una única conexión y empezamos a imaginar miles de aplicaciones capaces de comprender la misma forma básica de comunicarse.

Del contexto a las herramientas

El nombre Model Context Protocol puede inducir a pensar que su función consiste únicamente en proporcionar información adicional a un modelo, pero el concepto ha evolucionado considerablemente. En sus primeras etapas, MCP resolvía principalmente el problema de conectar modelos con fuentes de contexto. Sin embargo, a medida que los agentes han ganado importancia, el protocolo se ha convertido también en una infraestructura para exponer herramientas y permitir que los sistemas realicen determinadas acciones.

Podemos imaginar un servidor MCP conectado a una aplicación de gestión de proyectos. Este servidor podría indicar que existen herramientas para consultar tareas, buscar proyectos, crear nuevos elementos o actualizar determinados campos. La inteligencia artificial no tendría que conocer internamente cómo funciona toda la aplicación. Necesitaría comprender las capacidades que esa aplicación ha decidido exponer y utilizar la herramienta apropiada cuando el usuario solicite algo.

La diferencia resulta fundamental. Una inteligencia artificial aislada puede explicarnos cómo actualizar el estado de un proyecto. Una inteligencia artificial conectada puede llegar a actualizarlo, siempre que tenga autorización para hacerlo.

OpenAI ya está utilizando este modelo en sus propias integraciones. En agosto de 2026, la compatibilidad completa con MCP, incluidas acciones de modificación y escritura, se encuentra en despliegue beta para organizaciones que utilizan determinados planes empresariales de ChatGPT. Estas aplicaciones MCP pueden permitir que ChatGPT consulte sistemas corporativos y también realice acciones como iniciar flujos de trabajo, crear tareas o actualizar información en herramientas empresariales.

Estamos pasando, por tanto, de utilizar la inteligencia artificial únicamente para interpretar información hacia utilizarla también como una interfaz capaz de coordinar acciones entre diferentes sistemas.

Por qué MCP resulta especialmente importante para los agentes

En el artículo anterior hablábamos de la diferencia entre un chatbot y un agente. Un chatbot responde a una petición concreta mientras que un agente puede recibir un objetivo más amplio, utilizar herramientas y continuar trabajando hasta completar una tarea. Esta diferencia hace que la conectividad sea mucho más importante.

Imaginemos un agente encargado de organizar un viaje de trabajo. Para hacerlo correctamente podría necesitar consultar el calendario, comprobar dónde se encuentra la reunión, analizar vuelos, revisar políticas internas de gastos, localizar información sobre hoteles y finalmente preparar varias alternativas. Sin conexiones con esos sistemas, la inteligencia artificial puede ayudarnos a pensar, pero nosotros continuamos moviendo manualmente la información entre aplicaciones.

Si esos servicios exponen capacidades compatibles, un agente puede comenzar a utilizar diferentes herramientas a medida que avanza por el problema. No necesita necesariamente recibir toda la información desde el principio. Puede descubrir qué necesita, buscarla en la fuente adecuada y utilizarla para decidir el siguiente paso.

Aquí aparece una de las transformaciones fundamentales de la inteligencia artificial moderna. Durante años intentamos colocar toda la información relevante dentro del contexto del modelo. Con los agentes empezamos a construir sistemas donde la inteligencia puede buscar y utilizar la información cuando la necesita.

MCP se está convirtiendo precisamente en una de las capas destinadas a facilitar esa relación.

Lo realmente importante es la interoperabilidad

En tecnología existen continuamente nuevas herramientas y nuevos estándares, y muchos desaparecen después de unos años. Por eso la importancia de MCP no debería medirse únicamente por sus características técnicas actuales, sino por el grado de adopción que consiga alcanzar.

Un protocolo de este tipo empieza a volverse especialmente valioso cuando diferentes compañías que compiten entre sí deciden utilizarlo. En ese momento deja de ser simplemente una característica de un producto y comienza a funcionar como infraestructura común.

Desde su presentación por Anthropic en noviembre de 2024, MCP se ha extendido rápidamente por el ecosistema de inteligencia artificial. A finales de 2025 pasó a formar parte de la Agentic AI Foundation, creada bajo la Linux Foundation como espacio neutral para diferentes proyectos relacionados con agentes de inteligencia artificial. MCP fue uno de los proyectos fundadores de esta iniciativa.

Este cambio resulta especialmente significativo. Un estándar diseñado originalmente por una empresa adquiere mayores posibilidades de convertirse en infraestructura transversal cuando su gobernanza deja de depender exclusivamente de esa compañía y pasa a desarrollarse dentro de una comunidad más amplia.

En la práctica, esto significa que MCP ya no debe entenderse simplemente como «el protocolo de Anthropic». Su evolución está siendo gestionada mediante mantenedores, grupos de trabajo y procesos abiertos de propuestas para modificar la especificación.

En 2026 MCP ya es considerablemente diferente del protocolo original

La velocidad con la que está evolucionando el ecosistema puede observarse simplemente comparando las primeras versiones de MCP con la especificación publicada el 28 de julio de 2026. La actualización introdujo uno de los mayores cambios desde el nacimiento del protocolo y modificó parte de su arquitectura para hacerla más adecuada para infraestructuras empresariales y sistemas distribuidos.

Entre los cambios más importantes se encuentra una transición hacia un núcleo sin estado, diseñado para funcionar mejor sobre infraestructura HTTP convencional. Esto facilita escalar servidores MCP sin depender de mantener sesiones persistentes entre cada cliente y cada servidor. La versión también incorporó mejoras de autorización, mecanismos de extensión y nuevas capacidades destinadas a aplicaciones y procesos de larga duración.

Puede parecer una evolución demasiado técnica para quien simplemente utiliza inteligencia artificial, pero este tipo de cambios son precisamente los que permiten que una tecnología abandone la fase experimental y pueda comenzar a utilizarse en sistemas reales donde existen miles o millones de peticiones, diferentes niveles de autorización y necesidades estrictas de fiabilidad.

Según los mantenedores del proyecto, los SDK principales de MCP están registrando actualmente cientos de millones de descargas mensuales y los SDK de TypeScript y Python han superado individualmente los mil millones de descargas acumuladas. Estas cifras no significan que existan mil millones de usuarios diferentes, porque una gran parte procede de instalaciones automatizadas y sistemas de desarrollo, pero sí muestran la rapidez con la que la infraestructura se está incorporando al ecosistema tecnológico.

MCP Apps y una frontera que empieza a desaparecer

Otra evolución particularmente interesante consiste en que las conexiones MCP ya no tienen que limitarse necesariamente a datos y herramientas invisibles. La arquitectura de extensiones introducida en 2026 incluye MCP Apps, que permiten a los servidores ofrecer interfaces visuales que pueden aparecer dentro de la aplicación que está utilizando la inteligencia artificial.

Este concepto puede terminar modificando nuestra relación con el software. Durante décadas cambiamos continuamente entre programas. Si queríamos revisar un proyecto abríamos una aplicación; si necesitábamos consultar el correo, cambiábamos a otra; para comprobar un calendario utilizábamos una tercera y para analizar una base de datos abríamos una cuarta.

Una inteligencia artificial conectada mediante protocolos comunes puede comenzar a convertirse en una capa desde la cual consultamos y utilizamos diferentes sistemas sin tener que navegar constantemente entre interfaces. No significa necesariamente que las aplicaciones tradicionales vayan a desaparecer, pero puede cambiar dónde se encuentra el punto principal de interacción.

En lugar de preguntarnos qué programa debemos abrir para realizar una determinada actividad, podríamos simplemente explicar qué queremos conseguir y permitir que el sistema determine qué herramientas necesita utilizar.

La interfaz principal deja entonces de ser exclusivamente el menú de una aplicación y comienza a ser nuestra intención expresada mediante lenguaje.

La seguridad se vuelve mucho más importante cuando la IA puede actuar

Toda esta capacidad introduce también un problema evidente. Cuantas más herramientas puede utilizar una inteligencia artificial, mayores son las consecuencias potenciales de un error.

Si un chatbot interpreta mal una pregunta y responde incorrectamente, podemos ignorar la respuesta. Si un agente interpreta mal una instrucción y tiene permiso para modificar una base de datos, enviar un correo o cambiar información dentro de un sistema empresarial, el error puede convertirse inmediatamente en una acción.

Por eso la seguridad de MCP y de otras infraestructuras de agentes no puede consistir únicamente en comprobar que la conexión funciona. Es necesario definir claramente qué usuario está realizando la acción, qué permisos posee, qué servidor puede utilizar, qué herramientas están disponibles y qué operaciones requieren autorización adicional.

La especificación de julio de 2026 introdujo precisamente nuevas medidas para reforzar la autorización y adaptar mejor el protocolo a sistemas empresariales modernos. La hoja de ruta publicada el 22 de agosto de 2026 sitúa además la identidad de los agentes y la seguridad empresarial entre las prioridades principales para las próximas etapas del protocolo.

Esto muestra algo importante sobre la evolución de los agentes. El gran problema ya no consiste solamente en conseguir que puedan hacer más cosas. Empieza a consistir en determinar de manera fiable quién puede hacer qué, utilizando qué sistema y bajo qué condiciones.

Un protocolo común no elimina los riesgos

La existencia de un estándar tampoco significa automáticamente que cualquier servidor MCP sea seguro. Precisamente porque el protocolo facilita conectar herramientas con sistemas de inteligencia artificial, un servidor mal diseñado o malicioso podría representar un riesgo considerable.

Un usuario podría instalar una integración que solicita permisos excesivos. Una herramienta podría describir sus capacidades de manera engañosa. Una fuente externa podría intentar manipular a un agente mediante instrucciones escondidas en contenido aparentemente normal. También puede aparecer el problema clásico de las cadenas de confianza: una aplicación confía en un agente, el agente confía en una herramienta y esa herramienta obtiene información de otro sistema.

La seguridad de esta nueva infraestructura tendrá que combinar autenticación, permisos mínimos, supervisión, registros de actividad y mecanismos que permitan saber qué acciones ha ejecutado un agente y por qué.

Es una transformación semejante a la que experimentó Internet cuando pasó de páginas relativamente estáticas a sistemas capaces de manejar bancos, identidades, empresas y administraciones completas. Cuanto más útil se vuelve una infraestructura, mayor es también el interés en protegerla y explotarla.

La competencia puede desplazarse desde los modelos hacia el ecosistema

Durante los últimos años buena parte de la conversación sobre inteligencia artificial se ha centrado en comparar modelos. ¿Cuál razona mejor? ¿Cuál escribe mejor? ¿Cuál programa mejor? ¿Cuál tiene una ventana de contexto más grande?

Esas diferencias seguirán siendo importantes, pero si los modelos se vuelven progresivamente intercambiables y todos pueden acceder a las mismas herramientas mediante protocolos comunes, otra parte de la competencia puede desplazarse hacia el ecosistema.

Una inteligencia artificial que razona ligeramente mejor puede resultar menos útil que otra que está perfectamente conectada con los sistemas que utilizamos todos los días. Para una empresa, disponer de acceso controlado a documentación interna, calendarios, aplicaciones especializadas y sistemas de gestión puede aportar más valor práctico que una diferencia pequeña en determinados resultados de evaluación.

Aquí MCP introduce una posibilidad particularmente interesante: separar parcialmente la inteligencia de las herramientas. Si una empresa construye determinadas conexiones alrededor de un protocolo abierto, puede reducir la dependencia de un único proveedor de modelos y permitir que diferentes sistemas utilicen la misma infraestructura.

Esto no elimina completamente el problema del vendor lock-in, porque cada plataforma continuará teniendo características propias, pero puede reducir la necesidad de reconstruir todo un ecosistema simplemente porque aparece un modelo mejor.

Para el usuario, probablemente MCP termine siendo invisible

La mayoría de las personas no sabe qué protocolos utiliza su navegador para cargar una página ni qué mecanismos permiten sincronizar un correo electrónico entre diferentes dispositivos. Y no necesitan saberlo.

Si MCP realmente consigue convertirse en una infraestructura común, probablemente ocurra algo parecido. El usuario no tendrá que pensar continuamente en servidores MCP, esquemas de herramientas o protocolos de autorización. Simplemente verá que su inteligencia artificial puede conectarse a determinadas aplicaciones y realizar ciertas acciones.

La infraestructura será importante precisamente porque dejará de ser visible.

Podremos decir «busca el último presupuesto del proyecto, compara las modificaciones con la versión anterior y prepara un resumen para la reunión de mañana» sin preocuparnos excesivamente por qué aplicación contiene cada archivo o cómo se conecta la inteligencia artificial a ella.

Detrás de una instrucción aparentemente sencilla podrán producirse múltiples conexiones, consultas y verificaciones. La complejidad continuará existiendo, pero se trasladará progresivamente desde el usuario hacia la infraestructura.

El siguiente paso es que los agentes se comuniquen mejor entre ellos

La evolución tampoco termina en conectar una inteligencia artificial con aplicaciones. A medida que aparecen sistemas compuestos por múltiples agentes, comienza a resultar necesario mejorar la comunicación entre esos propios sistemas.

La hoja de ruta de MCP publicada el 22 de agosto de 2026 identifica precisamente los mecanismos de mensajería entre agentes, la mejora del transporte HTTP, la identidad y seguridad empresarial y la experiencia de desarrollo como áreas prioritarias para las próximas versiones.

Esto resulta especialmente interesante porque muestra hacia dónde está avanzando la arquitectura. En la primera etapa necesitábamos proporcionar contexto a un modelo. Después empezamos a conectar ese modelo con herramientas. Ahora comenzamos a diseñar infraestructuras donde agentes, aplicaciones y otros agentes pueden interactuar dentro de un mismo ecosistema.

La inteligencia artificial está dejando de ser una aplicación aislada para convertirse progresivamente en una capa que conecta diferentes componentes del mundo digital.

Quizá la verdadera revolución no sea el modelo

Cada pocos meses aparece un nuevo modelo que supera al anterior en determinadas pruebas y provoca una nueva oleada de titulares. Es comprensible que prestemos atención a esas mejoras porque son fáciles de mostrar. Podemos observar cómo una inteligencia artificial escribe mejor, programa mejor o resuelve un problema que anteriormente no podía resolver.

La infraestructura resulta mucho menos espectacular. Un nuevo mecanismo de autorización, un protocolo de conexión o una modificación en la forma de intercambiar herramientas difícilmente genera la misma impresión que ver un robot caminar o una inteligencia artificial crear un vídeo en segundos.

Sin embargo, la historia de la tecnología muestra que muchas de las transformaciones más profundas dependieron precisamente de estándares que posteriormente dejaron de llamar nuestra atención. Internet no existe gracias a una única aplicación espectacular, sino gracias a protocolos que permiten que millones de sistemas diferentes puedan comunicarse. La Web pudo expandirse porque existían reglas comunes que permitían construir sobre ella.

MCP intenta resolver un problema similar en una escala mucho más específica: proporcionar un lenguaje común mediante el cual las inteligencias artificiales puedan descubrir información y herramientas y utilizarlas.

Todavía es demasiado pronto para saber si MCP terminará convirtiéndose definitivamente en el estándar dominante o si en el futuro aparecerán otras arquitecturas que compartan ese espacio. Lo que parece mucho más claro es que el problema que intenta resolver no va a desaparecer.

Cuanto más capaces sean los agentes, más necesitarán conectarse con nuestro mundo digital. A su vez, cuanto más conectado esté ese mundo, menos sentido tendrá construir una integración completamente distinta para cada modelo, cada aplicación y cada empresa.

Por eso, la próxima gran revolución de la inteligencia artificial puede producirse en un lugar que la mayoría de los usuarios nunca llegará a ver. No tiene por qué ocurrir dentro del propio modelo, sino en la infraestructura que permite que ese modelo deje de funcionar de forma aislada y comience a conectarse con otras inteligencias, herramientas, aplicaciones, datos y sistemas.

Y, probablemente, no tendremos que esperar demasiado para comprobarlo. Todo está avanzando a una velocidad extraordinaria, hasta el punto de que desarrollos que hoy parecen propios de los próximos años pueden empezar a hacerse visibles en cuestión de días, semanas o meses. Claude y ChatGPT ya lo están haciendo. De hecho, cuando ese artículo salga publicado, es muy probable que lo que dice este ya sea antiguo. Así de rápido va esto.

From ChatGPT to Digital Employees: Why AI Agents Could Change the Way We Work

Tue, 25 Aug 2026 12:51:28 GMT

From ChatGPT to Digital Employees

Why AI Agents Could Change the Way We Work

During the early years of generative artificial intelligence, we became accustomed to a relatively simple relationship with these tools. We opened an application, asked a question, and waited for an answer. We could ask it to draft an email, summarize a document, explain a concept, translate a text, or write a few lines of code, but we were still the ones controlling almost the entire process. We selected the file, copied the information, formulated the instruction, received the result, decided what to do with it, and finally carried out the corresponding action.

That model remains extraordinarily useful, but it represents only the first stage of what is happening. The next transformation involves moving from artificial intelligence systems that simply respond to systems capable of acting, using tools, consulting different sources of information, making certain decisions within established limits, and continuing to work until they achieve a goal. This is where one of the concepts likely to become increasingly important over the coming years appears: the AI agent.

At first, the difference may seem small. After all, both chatbots and agents use artificial intelligence models. However, from the perspective of how work is organized, the difference is enormous. When we use a chatbot, we remain the system coordinating every step. When we use an agent, we begin to delegate not only a response, but also part of the process required to achieve a result.

A Chatbot Responds, an Agent Acts

Let us imagine something as ordinary as managing email. We can ask an artificial intelligence system to draft a reply to a message we have just received. To do that, we find the email, copy its content, explain what we want to say, review the generated text, locate the recipient, and finally send the message. The AI has helped us and may have saved us a few minutes, but we are still controlling practically the entire sequence.

Now imagine a different instruction. We could ask an agent to review our email periodically, classify messages that do not require attention, identify those that need a decision, consult related information when necessary, prepare draft replies, and show us only the matters where we genuinely need to intervene. Some categories might always require our authorization before a reply is sent, while other routine actions could be executed automatically.

In both cases we are using artificial intelligence, but the working model is completely different. In the first case, we use a tool whenever we need something. In the second, we have defined a responsibility and allowed a system to manage part of the work within previously established limits.

OpenAI currently describes an agent as a system that combines a trigger, a process that may incorporate specialized skills, and tools or systems it can connect to. A task may begin because a person initiates it, because a particular event occurs, or because it runs according to a schedule. From there, the agent can consult information, evaluate what it finds, and use authorized tools to complete the work.

The fundamental difference can be summarized simply: when we use a chatbot, we delegate a response; when we use an agent, we begin to delegate an objective.

From Personal Assistant to Digital Employee

The term “digital employee” may sound exaggerated and, of course, an artificial intelligence system is not an employee in the legal, social, or human sense of the word. Nevertheless, the comparison is useful for understanding the change that is taking place. A traditional program usually performs a specific function when someone uses it. An agent, by contrast, can be given a relatively broad responsibility, have access to the tools required to carry it out, and return to the user only when it needs a decision, encounters an exception, or completes the work.

Consider a small company that needs to find a new supplier. Today, someone may spend several hours searching for companies, reviewing websites, requesting quotes, organizing the information in a spreadsheet, comparing prices, checking delivery times, and preparing a summary so that someone else can make the final decision. Each of these activities may seem small, but together they represent a considerable amount of time.

An agent could be given a more general objective: find suppliers that meet certain requirements, discard those that do not operate in the required region, compare prices and conditions, identify potential risks, and present three reasonable alternatives with their advantages and disadvantages. If it also had authorized access to email, it could even prepare requests for quotations; if it had access to the calendar, it could propose dates for meetings with the finalists; and if it could consult internal documentation, it could check which requirements the company normally uses.

At that point, we are no longer talking simply about a tool that helps us write. We are beginning to approach something more like a digital collaborator specialized in a particular function.

The Real Revolution Is Connecting Intelligence to Tools

An isolated language model can know a great deal and reason over large amounts of information, but its ability to truly transform work is limited if it cannot interact with the systems where that work actually takes place. An artificial intelligence system may be perfectly capable of explaining how to organize a meeting, but if it cannot consult our calendar, check participants’ availability, or create the event, we are still the ones who must complete the process.

That is why agents need tools. These tools can allow them to retrieve information, read documents, search databases, access business systems, or perform certain actions. OpenAI distinguishes, for example, between tools that retrieve data, tools that act on other systems, and mechanisms through which an agent can even use other specialized agents to complete more complex tasks.

The consequence is important because it changes the nature of artificial intelligence itself. A model without access to its environment can tell us what we should do. A connected system can begin to do it.

This transition also explains why, in recent years, so much attention has been paid to connections between AI models and business applications. Email, calendars, documents, databases, customer relationship management systems, design tools, internal applications, and cloud services contain precisely the information and actions that can turn an intelligent response into completed work.

Automating a Procedure Is Not the Same as Delegating an Objective

Automation did not begin with artificial intelligence. For decades, companies have used macros, scripts, and different systems to reduce repetitive work. More recently, platforms such as Zapier, Make, and n8n popularized the ability to connect applications and build workflows without having to develop large amounts of software.

The traditional principle of automation is relatively simple. If a particular event occurs, we execute a predefined action. When a form arrives, we save the data in a table; when a new invoice appears, we copy it into a folder; when a customer makes a purchase, we send a specific email. The path has already been designed by a person, and the system simply follows it.

Agents introduce a fundamental difference because part of the path can be decided during execution. Anthropic distinguishes specifically between workflows, in which models and tools follow paths defined in advance through code, and agents, in which the model itself dynamically determines how to use tools and which steps to take in order to reach the objective.

This means that if one source of information is unavailable, an agent can try to find another; if it encounters contradictory data, it can compare the sources; if essential information is missing, it can request it; and if a particular action fails to produce the expected result, it can modify its strategy. It does not necessarily follow one rigid sequence, but instead operates within an allowed space of possible actions.

The conceptual difference is enormous. Traditional automation consists primarily of programming a procedure. Agents allow us to begin delegating an outcome.

When One Agent Uses Other Agents

The next step is even more interesting. If an agent can use tools, there is nothing to prevent one of those tools from being another specialized agent. Instead of building a single system responsible for understanding every part of a problem, we can imagine small digital teams in which different agents perform different functions.

A primary agent could receive a project and divide it into different activities. One agent could research suppliers, another analyze the budget, another consult legal documentation, another review the calendar, and another prepare the final presentation. The coordinating agent would then bring the information together, identify inconsistencies, and present the human decision-maker only with those issues that require approval.

We do not need to imagine an extraordinarily advanced artificial intelligence to understand the organizational consequences of such a system. Many companies are already made up of specialists who perform different tasks and coordinate their results through emails, documents, meetings, and management applications. If part of that coordination can take place between digital systems at vastly greater speed, the amount of time spent moving information between people could be reduced considerably.

Anthropic currently describes architectures ranging from single-agent systems to coordination models involving multiple agents, using sequential, parallel, and evaluation-based patterns. The goal is not simply to use the most complex architecture possible, but to find the one that provides enough value to justify the additional complexity.

This point is particularly important because the arrival of agents may also create a new form of technological enthusiasm: attempting to turn every imaginable process into an agent, even when conventional automation, or even a simple application, could solve the problem more reliably and economically.

Not Everything Needs an Agent

The ability of artificial intelligence to decide how to complete a task may seem automatically superior to a traditional process, but that is not always the case. Precisely because agents have greater freedom to choose their actions, they are also less predictable than a fully defined sequence.

If a company needs to copy exactly the same piece of data from one application to another every night, it probably does not need an agent to reason about the task. A conventional automated process can perform it more cheaply, quickly, and predictably. Additional intelligence begins to make sense when there are exceptions, unstructured information, decisions that depend on context, or paths that cannot be fully determined in advance.

Anthropic specifically recommends starting with the simplest solution and increasing complexity only when necessary. Agentic systems can provide greater flexibility and problem-solving ability, but that advantage usually also involves higher costs, longer execution times, and new difficulties in verifying that the system behaves correctly.

In other words, the question should not be “How can I turn this process into an agent?” but rather “Is there enough uncertainty or need for reasoning here for an agent to provide a real advantage?”

The Hybrid Company Is Beginning to Look Less Like Science Fiction

For years, we mainly talked about artificial intelligence as an individual tool. Each worker would have a personal assistant to help them write better, find information more quickly, or automate certain tasks. That stage will continue, but technology companies are beginning to envision a second phase in which agents stop being isolated personal tools and start becoming part of the organizational structure itself.

Microsoft’s 2025 Work Trend Index reported that 82% of surveyed business leaders expected to use “digital labor” to expand the capacity of their workforce over the following 12 to 18 months. Microsoft described an evolution from individual employees assisted by AI toward teams made up of humans and agents, and later toward organizations in which people set direction while digital systems execute an increasing proportion of the processes.

One year later, the 2026 Work Trend Index developed this idea further. Microsoft argues that, as agents take on a greater share of execution, the human role may gradually shift toward directing work, making decisions, and taking responsibility for outcomes.

This does not mean that offices will be empty in 2027 or that every company will replace its departments with autonomous systems. It means that a different structure is beginning to emerge, one in which we may need to stop counting only how many people are on a team and also begin considering how much digital capacity each of them has available.

A department of five people supported by twenty specialized agents does not operate in the same way as a traditional five-person department. Nor does it automatically mean that the department is equivalent to twenty-five workers. Human and digital capabilities are different. Nevertheless, the organization of work is inevitably beginning to change.

The Worker May Become a Director of Agents

This transformation may also change the meaning of certain professions. For much of our working lives, we have been the ones directly carrying out a large number of tasks. In an environment with agents, part of our work may begin to resemble managing a small team.

A marketing manager might set objectives while different agents research trends, analyze previous results, study competitors, prepare proposals, and generate different alternatives. An architect could request regulatory analysis, document comparisons, or initial explorations before personally reviewing the results. A sales manager might use systems that review clients, identify opportunities, prepare information before a meeting, and later update specific records.

This requires a different skill from simply knowing how to use a program. Directing an agent means learning how to define objectives correctly, provide context, establish limits, verify results, and decide when human intervention is necessary. An instruction that is too vague may produce useless results, while a system constrained by too many rules may lose precisely the flexibility that justified using an agent in the first place.

Over the coming years, a new form of professional literacy is likely to emerge around this capacity for delegation. It will not be enough to know how to “use AI.” We will need to learn which tasks are worth delegating, how much context a system needs, what level of autonomy is reasonable, and how to evaluate its work.

Autonomy Needs Limits

There is a fundamental difference between an artificial intelligence system that drafts text and one that can perform actions on our behalf. The first can produce an incorrect answer. The second can turn that incorrect answer into a real-world action.

An agent connected to email could send a message to the wrong person. One connected to company documentation could share confidential information. A system with excessive permissions could modify records it should not touch or execute a malicious instruction encountered on a webpage. The greater the ability to act, the greater the attention that must be paid to permissions, security, supervision, and traceability.

Anthropic noted in April 2026 that the very autonomy that makes agents useful also introduces new risks, because agents may misunderstand user intent or be manipulated through attacks such as prompt injection. The company identifies several fundamental principles, including keeping people in control, protecting privacy, securing agent interactions, and ensuring sufficient transparency around their actions.

OpenAI similarly emphasizes the need for safeguards that restrict available actions, request confirmation for certain operations, and maintain human oversight in sensitive activities.

The central idea is simple. Delegating a task does not mean granting unlimited authority. In the same way that a company does not give every employee access to all of its accounts, documents, and systems, it would make little sense to give an agent more permissions than it needs to perform its function.

The Goal Is Not to Remove Humans From the Process

When autonomous agents are discussed, it is easy to imagine that the ultimate goal is to eliminate human involvement altogether. Yet the most useful transformation is probably something different. In many activities, we do not need to disappear from the process; we simply need to intervene only at those moments when we genuinely add value.

If a system can analyze one hundred documents, we do not necessarily need to read all one hundred. We can review the exceptions it has identified. If it can compare twenty suppliers, we do not need to visit twenty websites ourselves. We can study the three most interesting candidates. If it can prepare different financial scenarios, we do not need to perform every calculation manually, but we still have to decide what level of risk we are willing to accept.

The most productive relationship may therefore consist of distributing work according to the strengths of each side. Machines can analyze large quantities of information, execute repetitive processes, maintain continuous attention over certain systems, and generate numerous alternatives. People remain responsible for setting priorities, interpreting consequences, negotiating, understanding values, building relationships, and deciding which outcomes are truly acceptable.

That is why the company of the immediate future will probably not simply be an automated company, but a hybrid company.

From Software as a Tool to Software as a Collaborator

For decades, our relationship with computers followed a relatively consistent principle. We opened a program and told it exactly what we wanted to do. We selected a tool, clicked a button, changed a parameter, and observed the result. Even the most sophisticated automations generally operated within processes that someone had designed in advance.

Agents are beginning to introduce a different relationship. Instead of specifying every action, we begin to describe objectives. Instead of continuously controlling the procedure, we define boundaries and review outcomes. Instead of using software only as a tool, we can begin to use certain systems as specialized digital collaborators.

This change will probably be gradual and full of errors, exaggerations, and experiments that do not work. Many processes currently presented as fully autonomous will continue to require human supervision for quite some time. Some companies will discover that they have delegated too much, while others will find that certain tasks can be automated far more extensively than they expected.

Nevertheless, the overall direction is becoming difficult to ignore. We have moved from computers that executed instructions to systems capable of interpreting language. Now we are moving from systems that interpret language to systems that can use it to act in the digital world.

The important question will no longer be only what an artificial intelligence can answer, but what we are willing to allow it to do on our behalf.

And when that question becomes part of the everyday organization of a company, we may stop thinking of AI simply as a program we use from time to time. We may begin to see it as a new layer of digital labor that works alongside us, carries out tasks, coordinates processes, and gradually changes the way we understand an organization. The real leap, therefore, is not about having a smarter chatbot. It is about moving from an artificial intelligence we ask what we should do to an artificial intelligence capable of helping us do it. And that seemingly small difference may ultimately transform the way we work.

De ChatGPT a los empleados digitales: por qué los agentes de IA pueden cambiar la forma en que trabajamos

Tue, 25 Aug 2026 12:31:39 GMT

De ChatGPT a los empleados digitales.

por qué los agentes de IA pueden cambiar la forma en que trabajamos

Durante los primeros años de la inteligencia artificial generativa nos acostumbramos a una relación relativamente sencilla con estas herramientas. Abríamos una aplicación, formulábamos una pregunta y esperábamos una respuesta. Podíamos pedir que redactara un correo, resumiera un documento, explicara un concepto, tradujera un texto o escribiera algunas líneas de código, pero seguíamos siendo nosotros quienes controlábamos prácticamente todo el proceso. Elegíamos el archivo, copiábamos la información, formulábamos la instrucción, recibíamos el resultado, decidíamos qué hacer con él y, finalmente, ejecutábamos la acción correspondiente.

Ese modelo continúa siendo extraordinariamente útil, pero representa solamente una primera etapa de lo que está ocurriendo. La siguiente transformación consiste en pasar de inteligencias artificiales que simplemente responden a sistemas capaces de actuar, utilizar herramientas, consultar diferentes fuentes de información, tomar determinadas decisiones dentro de unos límites establecidos y continuar trabajando hasta alcanzar un objetivo. Es aquí donde aparece uno de los conceptos que probablemente tendrá mayor importancia durante los próximos años: el agente de inteligencia artificial.

La diferencia puede parecer inicialmente pequeña. Después de todo, tanto un chatbot como un agente utilizan modelos de inteligencia artificial. Sin embargo, desde el punto de vista de la organización del trabajo existe una diferencia enorme. Cuando utilizamos un chatbot, nosotros seguimos siendo el sistema que coordina cada paso. Cuando utilizamos un agente, comenzamos a delegar no solamente una respuesta, sino una parte del proceso necesario para conseguir un resultado.

Un chatbot responde, un agente actúa

Imaginemos algo tan cotidiano como gestionar el correo electrónico. Podemos pedirle a una inteligencia artificial que redacte una respuesta a un mensaje que acabamos de recibir. Para hacerlo, nosotros buscamos el correo, copiamos su contenido, explicamos qué queremos responder, revisamos el texto generado, localizamos al destinatario y finalmente enviamos el mensaje. La IA nos ha ayudado, posiblemente nos ha ahorrado algunos minutos, pero seguimos controlando prácticamente toda la secuencia.

Ahora imaginemos una instrucción diferente. Podríamos pedir a un agente que revise periódicamente nuestro correo, clasifique los mensajes que no requieren atención, identifique aquellos que necesitan una decisión, consulte información relacionada cuando sea necesario, prepare borradores de respuesta y nos muestre únicamente los asuntos en los que realmente necesitamos intervenir. Algunas categorías podrían requerir siempre nuestra autorización antes de enviar una respuesta, mientras otras acciones rutinarias podrían ejecutarse automáticamente.

En ambos casos utilizamos inteligencia artificial, pero el modelo de trabajo es completamente diferente. En el primero utilizamos una herramienta cada vez que necesitamos algo. En el segundo hemos definido una responsabilidad y hemos permitido que un sistema gestione una parte del trabajo dentro de unos límites previamente establecidos.

OpenAI describe actualmente un agente como un sistema que combina un desencadenante, un proceso que puede incorporar habilidades especializadas y herramientas o sistemas a los que puede conectarse. Una tarea puede comenzar porque la inicia una persona, porque llega un determinado evento o porque se ejecuta según un horario. A partir de ahí, el agente puede consultar información, evaluar lo que encuentra y utilizar herramientas autorizadas para completar el trabajo.

La diferencia fundamental podría resumirse de una manera sencilla: cuando utilizamos un chatbot delegamos una respuesta; cuando utilizamos un agente comenzamos a delegar un objetivo.

Del asistente personal al empleado digital

El término «empleado digital» puede parecer exagerado y, evidentemente, una inteligencia artificial no es un empleado en el sentido jurídico, social o humano de la palabra. Sin embargo, la comparación resulta útil para comprender el cambio que se está produciendo. Un programa tradicional suele ejecutar una función determinada cuando alguien lo utiliza. Un agente, en cambio, puede recibir una responsabilidad relativamente amplia, disponer de las herramientas necesarias para desarrollarla y regresar al usuario únicamente cuando necesita una decisión, encuentra una excepción o termina el trabajo.

Pensemos en una pequeña empresa que necesita encontrar un nuevo proveedor. Actualmente alguien puede dedicar varias horas a buscar empresas, revisar páginas web, solicitar presupuestos, organizar la información en una hoja de cálculo, comparar precios, comprobar plazos de entrega y preparar un resumen para que otra persona tome la decisión. Cada una de estas actividades puede parecer pequeña, pero juntas representan una cantidad considerable de tiempo.

Un agente podría recibir un objetivo más general: buscar proveedores que cumplan unos requisitos determinados, descartar aquellos que no trabajan en la región necesaria, comparar precios y condiciones, identificar posibles riesgos y presentar tres alternativas razonables con sus ventajas e inconvenientes. Si además dispone de acceso autorizado al correo electrónico, podría incluso preparar las solicitudes de presupuesto; si tiene acceso al calendario, podría proponer fechas para una reunión con los finalistas, y si puede consultar documentación interna, podría comprobar qué requisitos utiliza normalmente la empresa.

En ese momento dejamos de hablar simplemente de una herramienta que ayuda a escribir y empezamos a aproximarnos a algo parecido a un colaborador digital especializado en una función determinada.

La verdadera revolución está en conectar la inteligencia con herramientas

Un modelo de lenguaje aislado puede saber mucho y razonar sobre grandes cantidades de información, pero su capacidad de transformar realmente el trabajo es limitada si no puede interactuar con los sistemas donde ese trabajo ocurre. Una inteligencia artificial puede explicarnos perfectamente cómo organizar una reunión, pero si no puede consultar nuestro calendario, comprobar la disponibilidad de los participantes o crear el evento, somos nosotros quienes todavía debemos completar todo el proceso.

Por eso los agentes necesitan herramientas. Estas herramientas pueden permitirles consultar información, leer documentos, buscar en bases de datos, acceder a sistemas empresariales o realizar determinadas acciones. OpenAI distingue, por ejemplo, entre herramientas que permiten obtener datos, herramientas que permiten actuar sobre otros sistemas y mecanismos mediante los cuales un agente puede incluso utilizar a otros agentes especializados para completar una tarea más compleja.

La consecuencia es importante porque transforma la naturaleza de la inteligencia artificial. Un modelo sin acceso al entorno puede decirnos lo que deberíamos hacer. Un sistema conectado puede empezar a hacerlo.

Esta transición explica también por qué durante los últimos años se ha prestado tanta atención a las conexiones entre modelos de inteligencia artificial y aplicaciones empresariales. Correo electrónico, calendarios, documentos, bases de datos, sistemas de gestión de clientes, herramientas de diseño, aplicaciones internas y servicios en la nube contienen precisamente la información y las acciones que permiten convertir una respuesta inteligente en trabajo ejecutado.

Automatizar un procedimiento no es lo mismo que delegar un objetivo

La automatización no nació con la inteligencia artificial. Durante décadas las empresas han utilizado macros, scripts y diferentes sistemas para reducir tareas repetitivas. Más recientemente, plataformas como Zapier, Make o n8n popularizaron la posibilidad de conectar aplicaciones y construir flujos de trabajo sin necesidad de desarrollar grandes cantidades de software.

El principio tradicional de automatización es relativamente sencillo. Si ocurre una determinada cosa, ejecutamos una acción previamente establecida. Cuando llega un formulario, guardamos los datos en una tabla; cuando aparece una nueva factura, la copiamos en una carpeta; cuando un cliente realiza una compra, enviamos un determinado correo. El recorrido ha sido diseñado previamente por una persona y el sistema simplemente lo ejecuta.

Los agentes introducen una diferencia fundamental porque una parte del recorrido puede decidirse durante la ejecución. Anthropic distingue precisamente entre los flujos de trabajo, en los que modelos y herramientas siguen caminos definidos previamente mediante código, y los agentes, en los que el propio modelo determina dinámicamente cómo utilizar las herramientas y qué pasos realizar para alcanzar el objetivo.

Esto significa que, si una fuente de información no está disponible, un agente puede intentar encontrar otra; si encuentra datos contradictorios, puede compararlos; si falta información indispensable, puede solicitarla; y si una determinada acción no produce el resultado esperado, puede modificar su estrategia. No sigue necesariamente una única secuencia rígida, sino que trabaja dentro de un espacio de posibilidades permitido.

La diferencia conceptual es enorme. La automatización tradicional consiste principalmente en programar un procedimiento. Los agentes permiten comenzar a delegar un resultado.

Cuando un agente utiliza a otros agentes

El siguiente paso resulta todavía más interesante. Si un agente puede utilizar herramientas, nada impide que una de esas herramientas sea otro agente especializado. En lugar de construir un único sistema encargado de comprender absolutamente todas las partes de un problema, podemos imaginar pequeños equipos digitales en los que diferentes agentes desempeñan funciones distintas.

Un agente principal podría recibir un proyecto y dividirlo en diferentes actividades. Uno de los agentes podría investigar proveedores, otro analizar el presupuesto, otro consultar documentación jurídica, otro revisar el calendario y otro preparar la presentación final. El coordinador reuniría después la información, detectaría inconsistencias y mostraría al responsable humano únicamente las decisiones que necesitan aprobación.

No es necesario imaginar una inteligencia artificial extraordinariamente avanzada para comprender las consecuencias organizativas de este sistema. Muchas empresas ya están formadas por especialistas que realizan tareas diferentes y coordinan sus resultados mediante correos, documentos, reuniones y aplicaciones de gestión. Si una parte de esa coordinación puede realizarse entre sistemas digitales a una velocidad enormemente superior, la cantidad de tiempo dedicada a mover información entre personas puede reducirse considerablemente.

Anthropic describe actualmente arquitecturas que van desde sistemas de un solo agente hasta modelos de coordinación entre múltiples agentes, utilizando patrones secuenciales, paralelos y de evaluación de resultados. La elección no consiste simplemente en utilizar la arquitectura más compleja posible, sino en encontrar aquella que aporte suficiente valor para justificar la complejidad adicional.

Este último punto es especialmente importante porque la llegada de los agentes puede provocar también una nueva forma de entusiasmo tecnológico: intentar convertir en agente cualquier proceso imaginable aunque una automatización convencional, o incluso una simple aplicación, pudiera resolverlo de manera más fiable y económica.

No todo necesita un agente

La capacidad de una inteligencia artificial para decidir cómo completar una tarea puede parecer automáticamente superior a un proceso tradicional, pero no siempre lo es. Precisamente porque los agentes tienen mayor libertad para escoger sus acciones, también son menos predecibles que una secuencia completamente definida.

Si una empresa necesita copiar exactamente el mismo dato desde una aplicación hacia otra cada noche, probablemente no necesite un agente que razone sobre la tarea. Un proceso automatizado convencional puede realizarla de manera más barata, rápida y predecible. La inteligencia adicional empieza a tener sentido cuando existen excepciones, información no estructurada, decisiones que dependen del contexto o caminos que no pueden determinarse completamente de antemano.

Anthropic recomienda precisamente comenzar por la solución más sencilla y aumentar la complejidad solamente cuando sea necesario. Los sistemas agénticos pueden ofrecer mayor flexibilidad y capacidad de resolución, pero esa ventaja suele implicar también mayores costes, más tiempo de ejecución y nuevas dificultades para comprobar que el sistema se comporta correctamente.

En otras palabras, la pregunta no debería ser «¿cómo puedo convertir este proceso en un agente?», sino «¿existe aquí suficiente incertidumbre o necesidad de razonamiento como para que un agente aporte una ventaja real?».

La empresa híbrida empieza a dejar de parecer ciencia ficción

Durante años hablamos de inteligencia artificial principalmente como una herramienta individual. Cada trabajador tendría su asistente personal para escribir mejor, buscar información más rápidamente o automatizar algunas tareas. Esa etapa continuará, pero las empresas tecnológicas están empezando a plantear una segunda fase en la que los agentes dejan de ser herramientas personales aisladas y comienzan a formar parte de la propia estructura organizativa.

El Work Trend Index de Microsoft de 2025 indicaba que el 82 % de los responsables empresariales encuestados esperaba utilizar «trabajo digital» para ampliar la capacidad de sus plantillas durante los siguientes 12 a 18 meses. Microsoft describía una evolución desde empleados individuales asistidos por IA hacia equipos formados por humanos y agentes y, posteriormente, organizaciones en las que las personas establecen la dirección mientras sistemas digitales ejecutan una parte creciente de los procesos.

Un año después, el Work Trend Index 2026 profundizó precisamente en esa idea. Microsoft sostiene que, a medida que los agentes asumen una mayor parte de la ejecución, la función humana puede desplazarse progresivamente hacia dirigir el trabajo, tomar decisiones y asumir los resultados.

No significa que en 2027 las oficinas vayan a estar vacías ni que cada empresa vaya a sustituir sus departamentos por sistemas autónomos. Significa que comienza a aparecer una estructura diferente, en la que debemos dejar de contar únicamente cuántas personas forman un equipo y empezar a considerar también cuánta capacidad digital tiene disponible cada una de ellas.

Un departamento de cinco personas acompañado por veinte agentes especializados no funciona de la misma manera que un departamento tradicional de cinco personas. Tampoco significa que equivalga automáticamente a veinticinco trabajadores. Las capacidades humanas y digitales son diferentes. Sin embargo, la organización del trabajo empieza inevitablemente a cambiar.

El trabajador puede convertirse en director de agentes

Esta transformación también puede modificar el significado de algunas profesiones. Durante buena parte de nuestra vida laboral hemos sido nosotros quienes ejecutábamos directamente una gran cantidad de tareas. En un entorno con agentes, parte de nuestro trabajo puede comenzar a parecerse más a dirigir un pequeño equipo.

Un responsable de marketing podría establecer objetivos mientras diferentes agentes investigan tendencias, analizan resultados anteriores, estudian competidores, preparan propuestas y generan diferentes alternativas. Un arquitecto podría solicitar análisis normativos, comparaciones de documentación o primeras exploraciones antes de estudiar personalmente los resultados. Un responsable comercial podría disponer de sistemas que revisen clientes, identifiquen oportunidades, preparen información antes de una reunión y actualicen posteriormente determinados registros.

Esto exige una habilidad diferente a simplemente saber utilizar un programa. Dirigir un agente implica aprender a definir correctamente objetivos, proporcionar contexto, establecer límites, comprobar resultados y decidir cuándo debemos intervenir. Una instrucción demasiado vaga puede conducir a resultados inútiles, mientras que un sistema con demasiadas restricciones puede perder precisamente la flexibilidad que justificaba utilizar un agente.

Es probable que durante los próximos años aparezca una nueva forma de alfabetización profesional relacionada con esta capacidad de delegación. No bastará con saber «usar IA». Tendremos que aprender qué tareas merece la pena delegar, cuánto contexto necesita el sistema, qué nivel de autonomía resulta razonable y cómo evaluar su trabajo.

La autonomía necesita límites

Existe una diferencia fundamental entre una inteligencia artificial que redacta un texto y una inteligencia artificial capaz de realizar acciones en nuestro nombre. El primer sistema puede producir una respuesta incorrecta. El segundo puede convertir esa respuesta incorrecta en una acción real.

Un agente conectado al correo podría enviar un mensaje a la persona equivocada. Uno conectado a documentación empresarial podría compartir información confidencial. Un sistema con permisos excesivos podría modificar registros que no debía tocar o ejecutar una instrucción maliciosa encontrada en una página web. Cuanto mayor sea la capacidad de actuar, mayor tendrá que ser también la atención dedicada a permisos, seguridad, supervisión y trazabilidad.

Anthropic señalaba en abril de 2026 que precisamente la autonomía que hace útiles a los agentes introduce nuevos riesgos, porque pueden malinterpretar la intención del usuario o ser manipulados mediante ataques como la prompt injection. La compañía plantea como principios fundamentales mantener a las personas en control, proteger la privacidad, asegurar las interacciones de los agentes y garantizar suficiente transparencia sobre sus acciones.

OpenAI plantea de manera semejante la necesidad de utilizar barreras de seguridad que limiten las acciones disponibles, soliciten confirmación para determinadas operaciones y mantengan supervisión humana en actividades sensibles.

La idea central es sencilla. Delegar una tarea no significa entregar autoridad ilimitada. Del mismo modo que una empresa no concede a todos sus empleados acceso a todas sus cuentas, documentos y sistemas, tampoco tendría sentido conceder a un agente más permisos de los necesarios para cumplir su función.

El objetivo no es eliminar al ser humano del proceso

Cuando se habla de agentes autónomos, es fácil imaginar que el objetivo final consiste en eliminar completamente la intervención humana. Sin embargo, probablemente la transformación más útil sea otra. En muchas actividades no necesitamos desaparecer del proceso, sino intervenir únicamente en aquellos momentos en los que realmente aportamos valor.

Si un sistema puede analizar cien documentos, no necesitamos leer necesariamente los cien. Podemos revisar las excepciones que haya encontrado. Si puede comparar veinte proveedores, no necesitamos visitar personalmente veinte páginas web. Podemos estudiar los tres candidatos más interesantes. Si puede preparar diferentes escenarios financieros, no necesitamos realizar manualmente cada cálculo, pero seguimos teniendo que decidir qué nivel de riesgo estamos dispuestos a asumir.

La relación más productiva puede consistir precisamente en distribuir el trabajo según las fortalezas de cada parte. Las máquinas pueden analizar grandes cantidades de información, ejecutar procesos repetitivos, mantener atención continua sobre determinados sistemas y generar numerosas alternativas. Las personas continúan siendo responsables de establecer prioridades, interpretar consecuencias, negociar, comprender valores, construir relaciones y decidir qué resultados son realmente aceptables.

Por eso la empresa del futuro inmediato probablemente no será simplemente una empresa automatizada, sino una empresa híbrida.

Del software como herramienta al software como colaborador

Durante décadas nuestra relación con los ordenadores ha seguido un principio relativamente constante. Abríamos un programa y le indicábamos exactamente qué queríamos hacer. Elegíamos una herramienta, pulsábamos un botón, modificábamos un parámetro y observábamos el resultado. Incluso las automatizaciones más sofisticadas funcionaban generalmente dentro de procesos que alguien había diseñado previamente.

Los agentes empiezan a introducir una relación diferente. En lugar de especificar cada acción, comenzamos a describir objetivos. En lugar de controlar continuamente el procedimiento, definimos límites y revisamos resultados. En lugar de utilizar el software solamente como herramienta, podemos comenzar a utilizar algunos sistemas como colaboradores digitales especializados.

Ese cambio probablemente será progresivo y estará lleno de errores, exageraciones y experimentos que no funcionarán. Muchos procesos que hoy se anuncian como completamente autónomos seguirán necesitando supervisión humana durante bastante tiempo. Algunas empresas descubrirán que han delegado demasiado, mientras otras comprobarán que determinadas tareas pueden automatizarse mucho más de lo que esperaban.

Sin embargo, la dirección general empieza a ser difícil de ignorar. Hemos pasado de ordenadores que ejecutaban instrucciones a sistemas capaces de interpretar lenguaje. Ahora estamos pasando de sistemas que interpretan lenguaje a sistemas que pueden utilizarlo para actuar sobre el mundo digital.

La pregunta importante ya no será únicamente qué puede responder una inteligencia artificial, sino qué estamos dispuestos a permitirle hacer en nuestro nombre.

Y cuando esa pregunta comience a formar parte de la organización cotidiana de una empresa, quizá dejemos de pensar en la IA simplemente como un programa que utilizamos de vez en cuando. Comenzaremos a verla como una nueva capa de trabajo digital que convive con nosotros, ejecuta tareas, coordina procesos y modifica progresivamente la forma en que entendemos una organización.

El verdadero salto, por tanto, no consiste en tener un chatbot más inteligente. Consiste en pasar de una inteligencia artificial a la que preguntamos qué deberíamos hacer a una inteligencia artificial capaz de ayudarnos a hacerlo. Y esa diferencia, aparentemente pequeña, puede terminar cambiando por completo la manera en que trabajamos.

AI Isn’t Coming to Take Your Job, But...

Tue, 25 Aug 2026 09:29:31 GMT

AI Isn’t Coming to Take Your Job, but It Is Coming to Change How Many People Are Needed to Do It

For decades, when we talked about automation, we mainly imagined factories, assembly lines, robotic arms moving parts, and machines performing repetitive physical tasks. As those technologies began transforming industry, people who worked in front of a computer could observe that revolution from a relatively comfortable position. Lawyers, architects, engineers, designers, programmers, administrative staff, journalists, consultants, and accountants seemed to belong to a different category. Machines could replace physical strength and repeat movements with precision, but knowledge, reasoning, and creativity still appeared to be fundamentally human domains.

Generative artificial intelligence is now challenging that distinction. For the first time, some of the tasks machines can perform most easily are not found in a factory, but inside a computer. Reading documents, comparing contracts, analysing a spreadsheet, writing an email, searching for information, preparing a report, summarising a meeting, generating code, organising data, or creating a presentation are tasks that, until very recently, necessarily required human involvement and can now be performed, at least partially, by artificial intelligence systems.

This does not mean that all these professions are about to disappear. The transformation may be more gradual and, precisely for that reason, much deeper. The truly important question may not be whether artificial intelligence can completely replace a lawyer, an architect, or a programmer, but what happens when a significant share of the tasks they perform can be completed in a fraction of the time they once required. If ten people can begin producing what previously required twenty, the economic structure of many organisations starts to change even if no profession disappears entirely.

The Problem Is Not That AI Can Do Your Entire Job

One of the questions that has been repeated most often since the emergence of ChatGPT and other generative systems seems straightforward: “Can artificial intelligence do my job?” Yet this is probably too limited a way of understanding what is happening, because virtually no profession consists of a single, perfectly defined activity.

An architect does not simply draw plans. They also interpret regulations, speak with clients, coordinate engineers, explore alternatives, visit construction sites, identify problems, and make decisions that depend on context. A lawyer does not simply draft legal documents, but evaluates risks, interprets ambiguous situations, develops strategies, and assumes responsibility for the advice they provide. The same is true of doctors, engineers, designers, consultants, and programmers. In all these professions, some relatively structured tasks can be automated, while others depend on experience, judgement, human relationships, or responsibility.

For that reason, replacing an entire profession may be far more difficult than automating some of the tasks within it. From an economic perspective, however, that distinction does not necessarily protect the current number of jobs. If a company today needs ten people to handle a particular combination of analysis, documentation, communication, coordination, and administration, and a few years from now those same tasks can be carried out by six people assisted by artificial intelligence, the profession will still exist, but the number of professionals required will have changed.

The opposite could also happen. A company might keep those ten employees and use the increase in productivity to take on more projects, enter new markets, reduce costs, or create services it could not previously afford to offer. Technology does not automatically determine which of these paths will be taken. That will depend on competition, economic conditions, business decisions, and the speed at which each sector adopts these tools.

What is genuinely new is that a relationship that once seemed almost inevitable is beginning to break down: producing substantially more intellectual work no longer necessarily requires hiring substantially more people.

The Office Has Become One of the First Frontiers of Automation

For years, it was assumed that manual jobs would be the first to be affected by advanced automation. Yet there is a very simple reason why office work is undergoing such rapid transformation: artificial intelligence already exists in the same environment in which millions of professionals work.

An AI model does not need to learn how to walk in order to open a document, nor does it need to develop a robotic hand capable of using a keyboard. It does not need to move physically in order to analyse a thousand emails, compare hundreds of contracts, or examine a spreadsheet. That entire world already exists in digital form and is therefore far more accessible to a system capable of processing language, images, data, and code.

This becomes even more important when we look at how a modern working day is actually distributed. Research published by Microsoft in 2023 showed that the average worker studied spent approximately 57% of their digital activity on meetings, emails, and chats, while around 43% was devoted to creating documents, spreadsheets, and presentations.

That figure raises a possibility far more interesting than simply using artificial intelligence to write an email faster. Perhaps the real transformation will not consist of producing the same presentations, documents, and messages in less time, but in discovering that a significant proportion of them are no longer necessary.

A large part of the activity within a modern company exists simply to coordinate the work of one person with another. Someone requests information, another person prepares a document, someone reviews the budget, a question arises, an email is sent, a meeting is scheduled, the document is subsequently revised, a new version is prepared, and finally someone creates a presentation to explain what has been decided. None of those people is necessarily working inefficiently. The problem is simply that coordinating human beings requires an enormous amount of communication.

If different AI agents could consult documents, check budgets, review calendars, analyse alternatives, and return to the person in charge only those decisions that genuinely require human approval, a considerable part of that coordination could disappear. In such a scenario, productivity would not increase merely because we could write twenty emails more quickly. It would increase because perhaps those twenty emails would no longer need to be written at all.

Layoffs Are Already Part of the Conversation, but the Reality Is More Complex

This transformation has inevitably become intertwined with news about workforce reductions. In January 2026, Amazon confirmed approximately 16,000 additional corporate job cuts as part of a broader restructuring while the company continued to increase its investment in artificial intelligence and automation. The case was immediately interpreted as a sign of what might happen across many large companies over the coming years.

However, it would be a mistake to treat every layoff that occurs during this technological revolution as a direct consequence of AI. Companies reduce their workforces for many reasons, including changes in demand, internal restructuring, mergers, cost-cutting, new business strategies, or changes in relationships with major customers. UPS, for example, announced significant workforce reductions during 2026, but much of that decision was related to the deliberate reduction of the delivery volume it handled for Amazon.

Klarna provides an especially interesting example because it shows that the story is not simply about replacing workers with machines. For a time, the company became one of the most frequently cited examples of aggressive AI adoption in customer service and other areas. It later acknowledged that some of its cost-cutting measures had gone too far and began restoring greater human involvement in certain parts of its customer service operation.

The lesson is important because it reminds us of something that can easily be lost amid technological enthusiasm: the fact that an activity can be automated does not necessarily mean that it should be automated completely. A machine may perform a task more cheaply and still create a worse customer experience, make errors that are difficult to detect, or remove a human relationship whose value had initially been underestimated.

A New Industrial Revolution, but With One Fundamental Difference

Comparing artificial intelligence with the Industrial Revolution may seem exaggerated, but there is a reason the comparison appears so often. The major technologies of history have expanded different human capabilities. The steam engine multiplied our physical strength, electricity transformed our industrial capacity, computers expanded our ability to process information, and the Internet multiplied our ability to communicate. Artificial intelligence introduces a different possibility: beginning to reduce the cost and dramatically increase the scale of certain forms of intellectual work.

Until now, if an organisation wanted to significantly increase its intellectual capacity, it essentially had one solution: hire more people. A consultancy that needed to conduct ten times as much analysis required many more analysts; a software company that wanted to produce substantially more code had to expand its development team; and an architectural practice seeking to manage more projects needed to hire more architects, draughtspeople, and other specialists.

Artificial intelligence may weaken that relationship between the number of employees and the amount of output. A professional assisted by systems capable of conducting research, analysing documents, generating alternatives, and producing first drafts can perform activities that previously would have required several people working together. Likewise, a small team can manage quantities of information and levels of operational complexity that only a few years ago would have required entire departments.

This does not necessarily mean the end of large companies, but it may encourage the emergence of much smaller and extraordinarily productive businesses. We can imagine organisations made up of only a handful of experienced people, supported by a strong brand, specialised knowledge, and a commercial network, while numerous digital agents take responsibility for research, organisation, analysis, document preparation, and the coordination of different processes.

A ten-person company capable of producing what once required a hundred employees could be just as economically disruptive as a fully automated company, and it is probably a far more realistic scenario for the years immediately ahead.

The Surprising Advantage That Experience May Provide

This transformation also creates an interesting paradox. For a long time, we assumed that younger generations would automatically enjoy a technological advantage because they grew up surrounded by new tools. In some respects that will remain true, but artificial intelligence is beginning to reduce the distinctive value of certain technical skills while simultaneously increasing the value of something acquired primarily over time: professional context.

Building a simple website is a good example. Until recently, it was necessary to learn different languages and technologies before being able to create even a relatively basic prototype. Today, there are tools that allow someone to describe an application in natural language and obtain an initial functional version within minutes. This does not automatically turn anyone into a software engineer, because a business application still requires security, architecture, testing, maintenance, scalability, and a deep understanding of the problem. It does, however, partially reduce the barrier between knowing what we want to build and knowing exactly how to program it.

As that barrier falls, experience may become extraordinarily valuable. An architect who has worked for twenty years knows which problems tend to emerge during construction and can recognise solutions that work perfectly on paper but fail in practice. An experienced salesperson can sense when a client is losing interest even before they say so. A lawyer knows about ambiguous situations that are rarely explained completely in a textbook, while an engineer may recognise a technically correct solution that will ultimately be too expensive, too complicated, or too difficult to maintain.

Artificial intelligence can possess enormous quantities of information, but possessing information is not the same as understanding which problem is actually worth solving. In that environment, an experienced specialist who learns to work with AI may become an especially powerful figure. They may not be the best programmer or the person who knows the most commands, but rather the person who understands what should be built, why it should be built and, above all, how to determine whether the result actually makes sense.

The Biggest Problem May Appear Precisely Among Those Who Are Just Starting Out

This advantage of experience leads, however, to another and much more difficult question. How does a new generation of professionals acquire experience if precisely the tasks through which that experience was traditionally gained begin to disappear?

For decades, many professions have operated through a kind of ladder. Younger employees began with relatively simple activities: preparing documents, searching for information, organising data, checking results, and producing first drafts. These were not necessarily the most interesting tasks, but they allowed people to observe how experienced specialists worked, make relatively small mistakes, and gradually understand how the profession actually functioned.

Many of those entry-level activities are precisely the tasks that artificial intelligence can automate most easily. If we eliminate them completely, we may find ourselves facing a difficult paradox within a few years: companies will still need experienced specialists, but there will be fewer opportunities for anyone to become one.

For that reason, the way we train new professionals will probably also have to change. Instead of spending years carrying out routine tasks before being allowed to participate in important problems, younger workers may need to become involved much earlier in real processes of analysis, supervision, decision-making, and verification. Part of professional training may consist precisely of learning how to review work produced by artificial intelligence systems, understand why an apparently correct answer may nevertheless be wrong, and identify which elements of context the machine has failed to consider.

Knowing how to use AI is not simply a matter of knowing how to ask a good question. It also means knowing when we should not trust the answer.

The Easier It Becomes to Generate an Answer, the More Valuable It Becomes to Know How to Evaluate It

During the early years of generative artificial intelligence, one apparently logical idea emerged repeatedly: if anyone can ask an AI a question and receive a sophisticated answer, perhaps specialists will become less important. In some sectors, exactly the opposite may happen.

When producing a first version of something becomes extremely cheap, value may shift from production toward evaluation. Generating a contract may become increasingly simple, but determining whether that contract actually protects our interests will continue to require legal expertise. Creating a plan may take only minutes, while knowing whether it can be built safely and efficiently remains another matter entirely. Generating thousands of lines of code may become easy; determining whether that code contains vulnerabilities, can be maintained, or genuinely solves the problem will become far more important.

Artificial intelligence can dramatically reduce the cost of producing alternatives, but it does not automatically remove the responsibility of deciding between them. The more content we are able to generate, the greater the need for people capable of distinguishing what is correct from what merely appears plausible, and those two things are not always the same.

The Professional Who Knows How to Work With AI

A phrase has been repeated constantly in recent years: “AI won’t replace you; someone who knows how to use AI will.” It is an oversimplification, because an economic transformation of this scale can hardly be reduced to a single sentence, but it contains an important insight.

Over the coming years, productivity differences between professionals with similar levels of knowledge are likely to increase significantly. One person may continue carrying out all their activities exactly as before, while another uses artificial intelligence to conduct research, prepare first drafts, compare alternatives, automate repetitive tasks, identify inconsistencies, and analyse large quantities of information.

That does not mean we all need to become artificial intelligence engineers. In the same way that we use computers today without understanding the internal workings of a processor, most professionals will probably use these systems without knowing the mathematical details of the models behind them.

What we will need to learn is what can be delegated, what must be verified, what information should not be shared, where human authorisation needs to remain in place, and which decisions make no sense to hand over completely to a machine. Working with artificial intelligence may become a form of basic professional literacy comparable to learning how to use a computer or the Internet. It will not necessarily be a profession in itself, but a cross-disciplinary capability embedded in many existing professions.

Will There Be Fewer Jobs?

It is almost inevitable that some activities will disappear and that other professions will change considerably. New occupations will also emerge, just as they did during every previous major technological transformation. The World Economic Forum’s Future of Jobs Report 2025 estimated that, taking artificial intelligence together with other major economic and demographic transformations, around 92 million jobs could disappear by 2030 while approximately 170 million new jobs could be created, resulting in an overall positive balance.

However, aggregate figures can hide the problem that truly matters. For a person who loses their job, it is of little comfort that an international statistic indicates that new jobs are simultaneously being created in another sector, another country, or for workers with completely different skills. Economies can readjust over time, but people need to learn, adapt, pay their bills, and find opportunities while that adjustment is taking place.

For that reason, perhaps the greatest difficulty will not be determining whether there will be more or fewer jobs in absolute terms twenty years from now. The immediate challenge will be managing the transition from one employment structure to another, particularly if change occurs faster than educational systems, companies, and governments are able to adapt.

The Question We Should Start Asking

As the capabilities of artificial intelligence continue to grow, many people will inevitably watch new demonstrations and once again ask whether a machine can do their job. Yet there is probably a much more useful question: which parts of my work can a machine do better, and which parts become even more valuable precisely because they require a human being?

Preparing and classifying information can increasingly be automated, while choosing objectives remains a decision. Generating alternatives can become extraordinarily cheap, but accepting responsibility for choosing one of them still belongs to someone. Responding to messages can be automated, while building a relationship based on trust is far more complex. Analysing millions of data points may be an ideal task for a machine, but determining which result deserves our attention depends on priorities, experience, and values.

The artificial intelligence revolution will probably not arrive in the spectacular way we often imagine. We will not walk into the office one morning and discover a robot sitting in our chair. The transformation will be much more gradual. First, a task that once required twenty minutes will be completed in two. Then the same will happen with another. Later, an entire process may become automated and, some time after that, a company may discover that a team of five people can manage an activity that previously required fifteen.

At that point, we will understand that the true transformation was never exclusively about replacing human beings with machines. It was about changing the relationship between work, knowledge, time, and productivity.

Artificial intelligence does not need to learn how to perform absolutely every part of our jobs in order to transform our professions. It only needs to perform a sufficiently important share of the tasks that make them up. That is why the best preparation for the years ahead will probably not consist of trying to compete with machines at the activities they can perform faster, but rather of learning how to use them to expand our own capabilities while strengthening those that continue to depend on experience, judgement, responsibility, and human understanding.

Perhaps, then, the truly interesting question will no longer be “Can artificial intelligence do my job?” but something far more useful:

What might I be capable of doing when I have an artificial intelligence capable of working alongside me?

La IA no viene a quitarte el trabajo, pero...

Tue, 25 Aug 2026 09:02:10 GMT

La IA no viene a quitarte el trabajo, pero sí viene a cambiar cuántas personas hacen falta para hacerlo

Durante décadas, cuando hablábamos de automatización imaginábamos sobre todo fábricas, cadenas de montaje, brazos mecánicos desplazando piezas y robots realizando actividades físicas repetitivas. Mientras esas máquinas comenzaban a transformar la industria, quienes trabajaban delante de un ordenador podían observar aquella revolución desde una posición relativamente cómoda. Abogados, arquitectos, ingenieros, diseñadores, programadores, administrativos, periodistas, consultores o contables parecían formar parte de una categoría diferente. Las máquinas podían sustituir fuerza física y repetir movimientos con precisión, pero el conocimiento, el razonamiento y la creatividad seguían pareciendo territorios fundamentalmente humanos.

La inteligencia artificial generativa está cuestionando precisamente esa división. Por primera vez, algunas de las actividades que una máquina puede realizar con mayor facilidad no se encuentran en una fábrica, sino dentro de un ordenador. Leer documentos, comparar contratos, analizar una hoja de cálculo, escribir un correo, buscar información, preparar un informe, resumir una reunión, generar código, organizar datos o crear una presentación son tareas que hasta hace muy poco requerían necesariamente intervención humana y que hoy pueden ser realizadas, al menos parcialmente, por sistemas de inteligencia artificial.

Esto no significa que todas esas profesiones estén a punto de desaparecer. La transformación puede ser más gradual y, precisamente por eso, mucho más profunda. La cuestión realmente importante quizá no sea si una inteligencia artificial puede sustituir completamente a un abogado, un arquitecto o un programador, sino qué ocurre cuando una parte considerable de las tareas que realizan puede resolverse en una fracción del tiempo que requería anteriormente. Si diez personas pueden empezar a producir lo que antes necesitaba veinte, la estructura económica de muchas organizaciones comienza a cambiar aunque ninguna profesión desaparezca por completo.

El problema no es que la IA pueda hacer todo tu trabajo

Una de las preguntas que más se repiten desde la aparición de ChatGPT y otros sistemas generativos es aparentemente sencilla: «¿Puede una inteligencia artificial hacer mi trabajo?». Sin embargo, probablemente sea una manera demasiado limitada de entender lo que está ocurriendo, porque prácticamente ninguna profesión consiste en una única actividad perfectamente definida.

Un arquitecto no se limita a dibujar planos. También interpreta normativas, habla con clientes, coordina ingenieros, estudia alternativas, visita obras, reconoce errores y toma decisiones que dependen del contexto. Un abogado no se limita a redactar documentos jurídicos, sino que evalúa riesgos, interpreta situaciones ambiguas, construye estrategias y asume responsabilidad por las recomendaciones que ofrece. Algo semejante ocurre con médicos, ingenieros, diseñadores, consultores o programadores. En todas esas profesiones existen tareas relativamente estructuradas que pueden ser automatizadas y otras que dependen de experiencia, juicio, relaciones humanas o responsabilidad.

Por eso la sustitución completa de una profesión puede ser mucho más difícil que la automatización de una parte de sus tareas. Sin embargo, desde el punto de vista económico, esa diferencia no necesariamente protege el número actual de puestos de trabajo. Si una empresa necesita hoy diez personas para realizar una determinada combinación de análisis, documentación, comunicación, coordinación y administración, y dentro de unos años esas mismas tareas pueden realizarse con seis personas asistidas por inteligencia artificial, la profesión seguirá existiendo, pero la cantidad de profesionales necesarios habrá cambiado.

También puede suceder lo contrario. Una empresa podría mantener a esas diez personas y utilizar el aumento de productividad para aceptar más proyectos, entrar en nuevos mercados, reducir costes o crear servicios que anteriormente no podía permitirse. La tecnología no determina automáticamente cuál de esos caminos será elegido. Dependerá de la competencia, de la economía, de las decisiones empresariales y de la velocidad con la que cada sector adopte estas herramientas.

Lo verdaderamente nuevo es que empieza a romperse una relación que durante mucho tiempo parecía casi inevitable: para producir mucho más trabajo intelectual era necesario contratar muchas más personas.

La oficina se ha convertido en uno de los primeros territorios de automatización

Durante años se asumió que los trabajos manuales serían los primeros afectados por una automatización avanzada. Sin embargo, existe una razón muy sencilla por la que el trabajo de oficina está experimentando una transformación tan rápida: la inteligencia artificial ya se encuentra en el mismo entorno donde trabajan millones de profesionales.

Un modelo de IA no necesita aprender a caminar para abrir un documento ni desarrollar una mano robótica capaz de utilizar un teclado. Tampoco necesita desplazarse físicamente para analizar mil correos, comparar cientos de contratos o estudiar una hoja de cálculo. Todo ese mundo ya existe en formato digital y, por tanto, resulta mucho más accesible para un sistema capaz de procesar lenguaje, imágenes, datos y código.

Esta circunstancia adquiere todavía más importancia cuando observamos cómo se distribuye realmente una jornada laboral moderna. Una investigación de Microsoft ya señalaba en 2023 que el trabajador medio estudiado dedicaba aproximadamente un 57 % de su actividad digital a reuniones, correos y chats, mientras que alrededor del 43 % estaba relacionado con la creación de documentos, hojas de cálculo y presentaciones.

Ese dato invita a plantear una posibilidad mucho más interesante que simplemente utilizar inteligencia artificial para escribir un correo más rápidamente. Quizá la gran transformación no consista en producir las mismas presentaciones, documentos y mensajes en menos tiempo, sino en descubrir que una parte significativa de ellos ya no es necesaria.

Buena parte de la actividad de una empresa moderna existe para coordinar el trabajo de unas personas con otras. Una persona solicita información, otra prepara un documento, alguien revisa el presupuesto, aparece una duda, se envía un correo, se organiza una reunión, posteriormente se modifica el documento, se prepara una nueva versión y finalmente alguien crea una presentación para explicar al resto qué se ha decidido. Ninguna de esas personas está necesariamente trabajando mal. El problema es simplemente que coordinar seres humanos requiere una enorme cantidad de comunicación.

Si diferentes agentes de inteligencia artificial pudieran consultar documentos, comprobar presupuestos, revisar calendarios, analizar alternativas y devolver al responsable humano únicamente aquellas decisiones que realmente necesitan aprobación, una parte considerable de esa coordinación podría desaparecer. En ese escenario, la productividad no aumentaría simplemente porque escribimos veinte correos más rápidamente. Aumentaría porque quizá ya no sería necesario escribir esos veinte correos.

Los despidos ya forman parte de la conversación, pero la realidad es más compleja

Esta transformación ha comenzado inevitablemente a mezclarse con las noticias sobre reducción de plantillas. Amazon confirmó en enero de 2026 aproximadamente 16.000 nuevos recortes de puestos corporativos dentro de una reorganización más amplia mientras la compañía continuaba incrementando sus inversiones en inteligencia artificial y automatización. El caso fue interpretado inmediatamente como una señal de lo que podría ocurrir en muchas grandes empresas durante los próximos años.

Sin embargo, sería un error convertir cualquier despido que ocurra durante esta revolución tecnológica en una consecuencia directa de la IA. Las empresas reducen plantillas por numerosas razones, entre ellas cambios en la demanda, reestructuraciones internas, fusiones, reducción de costes, nuevas estrategias comerciales o cambios en la relación con sus principales clientes. UPS, por ejemplo, anunció importantes reducciones de puestos durante 2026, pero buena parte de esa decisión estaba relacionada con la disminución deliberada del volumen de entregas realizado para Amazon.

Klarna ofrece un ejemplo especialmente interesante porque muestra que la historia tampoco consiste simplemente en reemplazar trabajadores por máquinas. La compañía se convirtió durante un tiempo en uno de los ejemplos más citados de adopción agresiva de inteligencia artificial en atención al cliente y otras funciones. Posteriormente reconoció que algunos procesos de reducción de costes habían ido demasiado lejos y volvió a incorporar mayor intervención humana en determinadas áreas.

La lección es importante porque recuerda algo que a veces se pierde en el entusiasmo tecnológico: que una actividad pueda automatizarse no significa necesariamente que sea conveniente automatizarla completamente. Una máquina puede realizar una tarea de manera más barata y, sin embargo, producir una experiencia peor para el cliente, cometer errores difíciles de detectar o eliminar una relación humana que tenía más valor del que inicialmente se había calculado.

Una nueva Revolución Industrial, pero con una diferencia fundamental

Comparar la inteligencia artificial con la Revolución Industrial puede parecer exagerado, pero existe una razón por la que esa comparación aparece continuamente. Las grandes tecnologías de la historia han ampliado diferentes capacidades humanas. La máquina de vapor multiplicó nuestra fuerza física, la electricidad transformó nuestra capacidad industrial, el ordenador amplificó la capacidad de procesar información e Internet multiplicó nuestra capacidad para comunicarnos. La inteligencia artificial introduce una posibilidad diferente: comenzar a abaratar y escalar determinadas formas de trabajo intelectual.

Hasta ahora, si una organización quería multiplicar significativamente su capacidad intelectual, tenía fundamentalmente una solución: contratar más personas. Una consultora que necesitaba realizar diez veces más análisis necesitaba muchos más analistas; una empresa de software que quería producir considerablemente más código tenía que ampliar su equipo de desarrolladores; un estudio de arquitectura que quería gestionar más proyectos necesitaba incorporar arquitectos, delineantes y otros especialistas.

La inteligencia artificial puede debilitar esa relación entre número de empleados y cantidad de producción. Un profesional asistido por sistemas capaces de investigar, analizar documentos, generar alternativas y producir primeras versiones puede realizar actividades que anteriormente habrían necesitado la colaboración de varias personas. Del mismo modo, un equipo pequeño puede gestionar una cantidad de información y una complejidad operativa que hace pocos años habría requerido departamentos completos.

Esto no implica necesariamente el final de las grandes empresas, pero sí puede favorecer el nacimiento de compañías mucho más pequeñas y extraordinariamente productivas. Es posible imaginar organizaciones formadas por unas pocas personas con experiencia, una buena marca, conocimiento especializado y una red comercial, apoyadas por numerosos agentes digitales encargados de investigar, organizar, analizar, preparar documentos o coordinar diferentes procesos.

La empresa de diez empleados capaz de producir lo que antes necesitaba cien puede ser económicamente tan disruptiva como la empresa completamente automatizada, y probablemente sea mucho más realista durante los próximos años.

La sorprendente ventaja que puede proporcionar la experiencia

Esta transformación genera además una paradoja interesante. Durante mucho tiempo hemos asumido que las generaciones más jóvenes tendrían automáticamente una ventaja tecnológica porque crecen rodeadas de nuevas herramientas. En determinados aspectos seguirá siendo así, pero la inteligencia artificial está empezando a reducir el valor diferencial de algunas habilidades técnicas y, simultáneamente, puede aumentar el valor de algo que se adquiere principalmente con el paso de los años: el contexto profesional.

Crear una página web sencilla ofrece un buen ejemplo. Hasta hace poco era necesario aprender diferentes lenguajes y tecnologías antes de poder construir incluso un prototipo relativamente básico. Actualmente existen herramientas que permiten describir mediante lenguaje natural una aplicación y obtener en pocos minutos una primera versión funcional. Esto no convierte automáticamente a cualquier persona en ingeniero de software, porque una aplicación empresarial continúa necesitando seguridad, arquitectura, pruebas, mantenimiento, escalabilidad y comprensión profunda del problema. Sin embargo, sí reduce parcialmente la barrera entre saber qué queremos construir y conocer exactamente cómo programarlo.

Cuando esa barrera disminuye, la experiencia puede adquirir un valor extraordinario. Un arquitecto que lleva veinte años trabajando sabe qué problemas suelen aparecer durante una obra y puede reconocer soluciones que funcionan perfectamente sobre el papel pero fracasan en la práctica. Un vendedor experimentado puede detectar cuándo un cliente está perdiendo interés aunque todavía no lo haya expresado. Un abogado conoce situaciones ambiguas que rara vez aparecen explicadas de manera completa en un manual, y un ingeniero puede reconocer una solución técnicamente correcta que será demasiado cara, complicada o difícil de mantener.

La inteligencia artificial puede disponer de cantidades enormes de información, pero disponer de información no equivale automáticamente a comprender qué problema merece realmente ser resuelto. En ese punto, el especialista experimentado que aprende a utilizar IA puede convertirse en una figura especialmente poderosa. Quizá no sea quien mejor programa ni quien conoce más comandos, sino quien entiende qué construir, por qué hacerlo y, sobre todo, cómo determinar si el resultado obtenido tiene sentido.

El gran problema puede aparecer precisamente entre quienes comienzan

Esta ventaja de la experiencia conduce, sin embargo, a otra cuestión mucho más complicada. ¿Cómo adquiere experiencia una nueva generación de profesionales si comienzan a desaparecer precisamente las tareas que tradicionalmente permitían adquirirla?

Durante décadas muchas profesiones han funcionado mediante una especie de escalera. Los trabajadores más jóvenes comenzaban realizando las actividades relativamente sencillas, preparaban documentos, buscaban información, organizaban datos, comprobaban resultados y elaboraban primeras versiones. No eran necesariamente las tareas más interesantes, pero permitían observar cómo trabajaban los especialistas más experimentados, cometer errores relativamente pequeños y comprender progresivamente cómo funcionaba realmente la profesión.

Precisamente muchas de esas tareas iniciales son las que la inteligencia artificial puede automatizar con mayor facilidad. Si las eliminamos completamente, podemos encontrarnos dentro de algunos años con una paradoja difícil de resolver: las empresas seguirán necesitando especialistas experimentados, pero existirán menos oportunidades para que alguien llegue a convertirse en uno de ellos.

Por eso probablemente también tendrá que cambiar la manera en que formamos a los nuevos profesionales. En lugar de pasar años realizando únicamente tareas rutinarias antes de participar en problemas importantes, quizá sea necesario introducirlos mucho antes en procesos reales de análisis, supervisión, decisión y comprobación. Una parte del aprendizaje profesional podría consistir precisamente en aprender a revisar el trabajo producido por sistemas de inteligencia artificial, comprender por qué una respuesta aparentemente correcta puede ser equivocada y reconocer qué elementos del contexto la máquina no ha considerado.

Saber utilizar una IA no consiste simplemente en formular una buena pregunta. También implica saber cuándo no deberíamos confiar en su respuesta.

Cuanto más fácil sea generar una respuesta, más valioso será saber evaluarla

Durante los primeros años de la inteligencia artificial generativa apareció con frecuencia una idea aparentemente lógica: si cualquier persona puede preguntar a una IA y obtener una respuesta sofisticada, quizá los especialistas pierdan importancia. Es posible que ocurra exactamente lo contrario en determinados sectores.

Cuando producir una primera versión de algo se vuelve extremadamente barato, el valor puede desplazarse desde la producción hacia la evaluación. Generar un contrato puede resultar cada vez más sencillo, pero determinar si ese contrato protege realmente nuestros intereses continuará requiriendo conocimiento jurídico. Crear un plano puede convertirse en cuestión de minutos, mientras que saber si puede construirse de forma segura y eficiente seguirá siendo otra cuestión. Generar miles de líneas de código será fácil; determinar si ese código contiene vulnerabilidades, si puede mantenerse o si resolverá correctamente el problema será mucho más importante.

La inteligencia artificial puede reducir extraordinariamente el coste de producir alternativas, pero no elimina automáticamente la responsabilidad de decidir entre ellas. Cuanto más contenido podamos generar, mayor será la necesidad de personas capaces de distinguir lo correcto de lo plausible, y esas dos cosas no siempre coinciden.

El profesional que sabe trabajar con IA

Existe una frase que se repite continuamente desde hace algunos años: «La IA no te sustituirá; te sustituirá alguien que sepa utilizar IA». Es una simplificación, porque una transformación económica de esta magnitud difícilmente puede reducirse a una sola frase, pero contiene una intuición importante.

Es probable que durante los próximos años aumenten considerablemente las diferencias de productividad entre profesionales con conocimientos semejantes. Una persona puede continuar realizando todas sus actividades exactamente como lo hacía antes, mientras otra utiliza inteligencia artificial para investigar, preparar primeras versiones, comparar alternativas, automatizar tareas repetitivas, detectar inconsistencias y analizar grandes cantidades de información.

Eso no significa que todos tengamos que convertirnos en ingenieros de inteligencia artificial. Del mismo modo que hoy utilizamos ordenadores sin comprender el funcionamiento interno de un procesador, la mayoría de profesionales probablemente utilizará estos sistemas sin conocer los detalles matemáticos de los modelos que existen detrás.

Lo que sí tendremos que aprender es qué podemos delegar, qué debemos verificar, qué información no deberíamos proporcionar, dónde necesitamos mantener autorización humana y qué decisiones no tendría sentido entregar completamente a una máquina. Trabajar con inteligencia artificial puede convertirse en una forma de alfabetización profesional comparable a aprender a utilizar un ordenador o Internet. No será necesariamente una profesión específica, sino una capacidad transversal integrada en muchas profesiones existentes.

¿Habrá menos trabajos?

Es prácticamente inevitable que algunas actividades desaparezcan y que otras profesiones cambien considerablemente. También aparecerán nuevas ocupaciones, igual que ocurrió durante todas las grandes transformaciones tecnológicas anteriores. El Future of Jobs Report 2025 del Foro Económico Mundial estimaba que, considerando la inteligencia artificial junto con otras transformaciones económicas y demográficas, alrededor de 92 millones de puestos podrían desaparecer hasta 2030 mientras se crearían aproximadamente 170 millones de nuevos empleos, lo que produciría un saldo global positivo.

Sin embargo, las cifras agregadas pueden ocultar el problema verdaderamente importante. Para una persona que pierde su puesto de trabajo, importa relativamente poco que una estadística internacional indique que al mismo tiempo se están creando empleos diferentes en otro sector, en otro país o para trabajadores con otras capacidades. Las economías pueden reajustarse con el paso del tiempo, pero las personas necesitan aprender, adaptarse, pagar sus facturas y encontrar oportunidades mientras ese reajuste ocurre.

Por eso quizá la mayor dificultad no sea determinar si dentro de veinte años existirá más o menos empleo en términos absolutos. El desafío inmediato será gestionar la transición entre una estructura laboral y otra, especialmente si el cambio ocurre con mayor rapidez que la capacidad de los sistemas educativos, las empresas y las administraciones para adaptarse.

La pregunta que deberíamos empezar a hacernos

A medida que las capacidades de la inteligencia artificial continúen aumentando, muchas personas observarán nuevas demostraciones y volverán inevitablemente a preguntarse si una máquina puede hacer su trabajo. Sin embargo, existe una pregunta probablemente mucho más útil: ¿qué partes de mi trabajo puede hacer mejor una máquina y qué partes adquieren todavía más valor precisamente porque necesitan una persona?

Preparar y clasificar información puede automatizarse cada vez más, mientras que elegir objetivos continúa siendo una decisión. Generar alternativas puede resultar extraordinariamente barato, pero asumir las consecuencias de escoger una de ellas sigue siendo responsabilidad de alguien. Responder mensajes puede automatizarse, mientras que construir una relación de confianza es un fenómeno mucho más complejo. Analizar millones de datos puede ser una tarea perfecta para una máquina, pero determinar qué resultado merece nuestra atención depende de prioridades, experiencia y valores.

La revolución de la inteligencia artificial probablemente no llegará de la manera espectacular que muchas veces imaginamos. No llegaremos una mañana a la oficina para descubrir un robot sentado en nuestra silla. La transformación será mucho más progresiva. Primero una tarea que anteriormente requería veinte minutos podrá completarse en dos. Después ocurrirá lo mismo con otra. Más tarde un proceso entero podrá resolverse de forma automática y, algún tiempo después, una empresa descubrirá que un equipo de cinco personas puede gestionar una actividad que anteriormente requería quince.

En ese momento comprenderemos que la verdadera transformación nunca consistió exclusivamente en sustituir seres humanos por máquinas. Consistía en modificar la relación entre trabajo, conocimiento, tiempo y productividad.

La inteligencia artificial no necesita aprender a realizar absolutamente todo nuestro trabajo para transformar nuestras profesiones. Basta con que pueda realizar una parte suficientemente importante de las tareas que las componen. Por eso la mejor preparación para los próximos años probablemente no consista en intentar competir con una máquina en aquellas actividades que puede hacer más rápido, sino en aprender a utilizarla para ampliar nuestras propias capacidades mientras reforzamos aquellas que continúan dependiendo de experiencia, criterio, responsabilidad y comprensión humana.

Quizá, entonces, la pregunta verdaderamente interesante deje de ser «¿puede la inteligencia artificial hacer mi trabajo?» y pase a convertirse en otra mucho más útil: ¿Qué puedo llegar a hacer cuando dispongo de una inteligencia artificial capaz de trabajar conmigo?

Parametric Door Block – Case #004

Fri, 14 Aug 2026 09:17:00 GMT

Parametric Door Block – Case #004

As you can see, this is an intelligent block whose behavior can be modified using different parameters and controls. In ARES Commander , this type of element is called a Custom Block , as it is in DraftSight , while in AutoCAD , it is known as a Dynamic Block .

Although there are some minor differences between these programs, the steps and concepts explained in this tutorial can be applied in virtually the same way to all of them. If you don't have a license for any of these programs, you can download the trial version of ARES Commander and put everything you learn here into practice. Download ARES Commander

https://www.graebert.com/cad-software/download/ares-commander/

Note : ARES Commander is available for Windows, Mac, and Linux.

You can also find more tutorials and similar examples on my feed and on my website, www.miltonchanes.de, in the BLOG section.

In this tutorial, we will start with the block we created in a previous tutorial. If you haven't watched it yet, I recommend starting with that one, as it will help you follow the steps we will cover here more easily. It is available in several languages. Just make sure to select the tutorial identified as Case #003 : https://www.linkedin.com/pulse/door-block-automatically-cuts-walls-case-003-milton-chanes-giolf/

The tutorial begins by editing the existing block, which already includes a WIPEOUT . This element allows us to visually hide the wall behind the block, creating the effect that the door automatically cuts through the wall when placed over it.

The WIPEOUTFRAME variable allows us to control the visibility of the WIPEOUT boundary using the values 0 and 1. In this case, we need the frame to be visible so that we can identify it and work with it while editing the block.

I’m going to avoid going over the basic concepts and focus only on what is important for this particular example.

In this case, I have created four door sizes. The frame maintains the same proportions and adapts to each one, while the door leaves have widths of 72 , 82 , 92 and 102 cm. If you look closely at the frame, you will notice that it has a small 1 cm “tooth” on each side. This means that the resulting widths of the closed doors are 70, 80, 90 and 100 cm, respectively. These are standard dimensions commonly used in Southern Europe.

In the image, you can also see that, for now, we have only one WIPEOUT created: the one that was originally part of the block developed in the Case #003 tutorial mentioned above.

Door Block that Automatically Cuts Walls – Case #003

https://www.linkedin.com/pulse/door-block-automatically-cuts-walls-case-003-milton-chanes-giolf/

In the video, I start with a very simple task: changing the color of the arcs that represent the swing of the door leaves to gray. The idea is simply to show that, within a block, entities behave practically the same way as when we work with them outside the block.

We know that we are inside the Block Editor of ARES Commander because the EDIT BLOCK tab is activated, and the background of the drawing area also changes to the characteristic gray color of the block editing environment.

The first important task in this tutorial will be to create the Visibility States. Since we have four different door sizes, we will need to create four visibility states .

Pay close attention to the objects I select in the video. You will notice that I deliberately leave one of the frames unselected. This is because that frame can remain common to all Visibility States , so we don't need to include a different version of it in each state, at least in this example.

Pasos para crear los Visibility States

After selecting Elements, we select a grip that we will use to control the visibility states.
Next, we select all the entities that will participate in these states. This selection can be modified later if necessary. In this example, notice that I leave some of the frames out because we don't need them to be part of the Visibility States.
From the Visibility States dialog box, we create the four states corresponding to the four door sizes.
We select one of the states and begin hiding the entities that should not be visible in that particular state. We repeat the same process for each of the four states.Después de elegir Elements, seleccionamos un grip que utilizaremos para controlar los estados de visibilidad.

Remember also the function of the three main icons:

A) Show all entities from all Visibility States simultaneously.

B) Make an entity visible in the current state.

C) Hide an entity in the current state.

In this way, each Visibility State will display only the corresponding door, while the common entities can remain visible in all states.

Once the entities have been assigned to each Visibility State , we can delete those that we no longer need to keep. In the video, you will see that I am mainly referring to the additional frames, which are no longer necessary.

Next, we need to place each door in its final position. To do this, we simply use the Move command. While performing this task, we need to switch from one Visibility State to another so that we can correctly position each of the four doors.

At the end, all the doors will be positioned over the same frame. Depending on the Visibility State we select, we will see one door or another.

In the video, I close the block after saving the changes simply to show the current state of the exercise. At this point, we have still kept an additional Visibility State that allows us to see all the doors simultaneously. This state can be useful while we are working on and testing the block, but it is only temporary and should eventually be deleted.

The first thing we will see in the next video is the removal of the additional Visibility State that we had temporarily kept so that we could view all the doors at the same time.

As we already confirmed in the previous video, switching between the different door sizes works correctly, but a problem appears: the WIPEOUT does not automatically adapt to the new size.

I should mention that there are other ways to solve this situation, especially when working with doors or windows whose size we want to modify using grips . However, that will be the subject of another tutorial. In this case, we are working with four specific sizes, so the simplest solution is to use a different WIPEOUT for each door size.

Therefore, we need four WIPEOUTS .

Since the difference between each door size is 10 cm, in the video you will see that I copy the existing WIPEOUT and use Stretch to progressively create the different variants.

The next step is to assign each WIPEOUT to its corresponding Visibility State . To do this, we will use the selection icon that appears next to the activity name, in this case Visibility 1 . Basically, we just need to follow the same steps shown in the video. Once this stage is complete, we need to move each WIPEOUT to its final position and, very importantly, make sure to place it behind all the other entities in the block.

In the video, I save the changes and test the result. Now, every time we change the door size, the opening that hides the wall adapts correctly. However, we can still see the WIPEOUT boundary. To solve this, we use the WIPEOUTFRAME variable again and change its value to 0, so that the boundary is no longer visible.

Note: It is true that I have not yet performed this final step in the video. The reason is simply that we still need to add more actions, and for that, we need the WIPEOUT to remain visible. If you have already hidden it, you will need to make it visible again by setting the WIPEOUTFRAME variable back to 1.

Now we are going to make the door capable of flipping to the opposite side.

To do this, we use the element Mirror, which allows us to define a symmetry axis using two points. Then, under Activities, we must also select Mirror. Although both are called Mirror, they are actually two different things: one defines the behavior, while the other executes the action. We will explain the reason for this distinction in another tutorial. Once the activity has been selected, we need to choose the entities that will participate in the mirror operation. At this point, it is important to keep in mind that, in principle, we should include all the entities that make up the door.

However, you might decide to leave out the element Visibility, for example, if you prefer its grip to remain in the same position at all times. In this example, we also want the element Visibility to be mirrored together with the rest of the block.

Note: Remember to enable the display of all Visibility States before selecting the entities. This way, you can correctly include all the objects that need to participate in the action.

Now it’s time to create a mirror operation in the opposite direction.

For this, we will use the fixed side of the door as the reference. It is important to point out that, in a different scenario, if we needed to perform the mirror operation using the center of the door as the axis in the Y direction of our example, some additional issues would arise that we are not going to address in this video. The general logic would be similar, but the solution would have to be approached differently and would require some additional steps.

We will cover that specific case in another tutorial.

What did you think of this new tutorial? Were you familiar with this possibility?

This type of solution can be applied in many architectural situations. For example, we can use WIPEOUT with trees, vehicles, or other elements to automatically hide whatever is behind them, without the need to use Trim. It can also be useful in engineering when working with parts that need to be placed on top of one another.

Give it a try!

And remember that you can download ARES Commander and experiment with these features to create your own intelligent Custom Blocks. Download ARES Commander

https://www.graebert.com/cad-software/download/ares-commander/

Bloque Paramétrico de Puerta – Caso #004

Fri, 14 Aug 2026 08:43:27 GMT

bloque paramétrico de puerta - caso #004

Como pueden ver, se trata de un bloque inteligente cuyo comportamiento puede modificarse mediante diferentes parámetros y controles. En ARES Commander , este tipo de elemento se denomina Custom Block , al igual que en DraftSight , mientras que en AutoCAD se conoce como Dynamic Block .

Aunque existen algunas pequeñas diferencias entre estos programas, los pasos y conceptos que explico en este tutorial pueden aplicarse prácticamente de la misma manera en todos ellos.

Si no disponen de una licencia de ninguno de estos programas, pueden descargar la versión de prueba de ARES Commander y poner en práctica todo lo que aprenderán aquí. https://www.graebert.com/cad-software/download/ares-commander/

Nota: ARES Commander está disponible para Windows, Mac y Linux .

También pueden encontrar más tutoriales y ejemplos similares en mi feed y en mi página web, www.miltonchanes.de , dentro de la sección BLOG .

En este tutorial partiremos del bloque que ya creamos en un tutorial anterior. Si todavía no lo han visto, les recomiendo comenzar por él, ya que les ayudará a seguir mejor los pasos que veremos aquí. Lo encontrarán disponible en varios idiomas. Solo asegúrense de seleccionar el tutorial identificado como Case #003 , https://www.linkedin.com/pulse/door-block-automatically-cuts-walls-case-003-milton-chanes-giolf/ ya que este tutorial corresponde al Case #004 .

El tutorial comienza editando el bloque existente, que ya incorpora un WIPEOUT . Este elemento nos permite ocultar visualmente el muro situado detrás del bloque, creando el efecto de que la puerta lo corta automáticamente al colocarla sobre él.

La variable WIPEOUTFRAME nos permite controlar la visibilidad del contorno del WIPEOUT mediante los valores 0 y 1. En este caso necesitamos que el marco sea visible para poder identificarlo y trabajar con él durante la edición del bloque.

Voy a evitar detenerme en conceptos básicos y centrarme únicamente en lo importante para este ejemplo.

En este caso he creado cuatro tamaños de puerta. El marco mantiene las mismas proporciones y se adapta a cada una de ellas, mientras que las hojas tienen anchos de 72, 82, 92 y 102 cm. Si observan el marco con atención, verán que incorpora un pequeño “diente” de 1 cm a cada lado. De esta manera, las medidas resultantes de las puertas cerradas son de 70, 80, 90 y 100 cm, respectivamente. Se trata de dimensiones estándar utilizadas habitualmente en el sur de Europa.

En la imagen también pueden ver que, por el momento, solo tenemos un WIPEOUT creado: el que formaba parte originalmente del bloque desarrollado en el tutorial Case #003 , mencionado anteriormente. https://www.linkedin.com/pulse/door-block-automatically-cuts-walls-case-003-milton-chanes-giolf/

En el video comienzo con una tarea muy sencilla: cambiar a gris el color de los arcos que representan el giro de las hojas de las puertas. La idea es simplemente mostrar que, dentro de un bloque, las entidades se comportan prácticamente de la misma manera que cuando trabajamos con ellas fuera del bloque.

Sabemos que estamos dentro del Block Editor de ARES Commander porque se activa la pestaña EDIT BLOCK y, además, el fondo del área de dibujo cambia al característico color gris del entorno de edición de bloques. La primera tarea importante de este tutorial será crear los Visibility States . Como tenemos cuatro tamaños diferentes de puerta, necesitaremos crear cuatro estados de visibilidad.

Presten especial atención a los objetos que selecciono en el video. Verán que deliberadamente dejo uno de los marcos sin seleccionar. Esto se debe a que ese marco puede permanecer común a todos los Visibility States , por lo que no necesitamos incluir una versión diferente de él en cada estado, al menos en este ejemplo.

Pasos para crear los Visibility States

Después de elegir Elements, seleccionamos un grip que utilizaremos para controlar los estados de visibilidad.
A continuación, seleccionamos todas las entidades que participarán en estos estados. Esta selección puede modificarse posteriormente si es necesario. En este ejemplo, observen que dejo fuera algunos marcos porque no necesitamos que formen parte de los Visibility States.
Desde el cuadro de Visibility States, creamos los cuatro estados correspondientes a los cuatro tamaños de puerta.
Seleccionamos uno de los estados y comenzamos a ocultar aquellas entidades que no deberían ser visibles en ese estado concreto. Repetimos el mismo proceso con cada uno de los cuatro estados.

Recuerden también la función de los tres iconos principales:

A) Mostrar simultáneamente las entidades de todos los Visibility States .

B) Hacer visible una entidad en el estado actual.

C) Ocultar una entidad en el estado actual.

De esta forma, cada Visibility State mostrará únicamente la puerta correspondiente, mientras que las entidades comunes podrán permanecer visibles en todos los estados. Una vez asignadas las entidades a cada Visibility State , podemos eliminar aquellas que ya no nos interesa conservar. En el video verán que me refiero principalmente a los marcos adicionales, que ya no son necesarios.

A continuación debemos colocar cada puerta en su posición final. Para ello utilizamos simplemente el comando Move.

Mientras realizamos esta tarea debemos cambiar de un Visibility State a otro, de manera que podamos posicionar correctamente cada una de las cuatro puertas.

Al finalizar, todas las puertas quedarán ubicadas sobre el mismo marco. Dependiendo del Visibility State que seleccionemos, veremos una puerta u otra.

En el video cierro el bloque después de guardar los cambios simplemente para mostrar el estado actual del ejercicio.

En ese momento todavía hemos mantenido un Visibility State adicional que permite ver todas las puertas simultáneamente. Este estado puede resultar útil mientras estamos trabajando y comprobando el bloque, pero es únicamente temporal y finalmente debemos eliminarlo.

Lo primero que veremos en el siguiente video es la eliminación de ese Visibility State adicional que habíamos mantenido temporalmente para poder visualizar todas las puertas al mismo tiempo.

Como ya comprobamos en el video anterior, cambiar entre los distintos tamaños de puerta funciona correctamente, pero aparece un problema: el WIPEOUT no se adapta automáticamente al nuevo tamaño.

Debo decir que existen otras formas de resolver esta situación, especialmente cuando trabajamos con puertas o ventanas cuyo tamaño queremos modificar mediante grips . Sin embargo, ese será un tema para otro tutorial. En este caso estamos trabajando con cuatro tamaños específicos , por lo que la solución más sencilla es utilizar un WIPEOUT diferente para cada tamaño de puerta .

Por lo tanto, necesitamos cuatro WIPEOUTS .

Como la diferencia entre cada tamaño de puerta es de 10 cm , en el video verán que copio el WIPEOUT existente y utilizo Stretch para crear progresivamente las distintas variantes.

El siguiente paso consiste en asignar cada WIPEOUT a su Visibility State correspondiente .

Para hacerlo utilizaremos el icono de selección que aparece junto al nombre de la actividad, en este caso Visibility 1 . Básicamente, solo hay que seguir los mismos pasos que se muestran en el video.

Una vez completada esta etapa, debemos mover cada WIPEOUT hasta su posición final y, muy importante, asegurarnos de colocarlo detrás de las demás entidades del bloque .

En el video guardo los cambios y pruebo el resultado. Ahora, cada vez que cambiamos el tamaño de la puerta, el hueco que oculta el muro se adapta correctamente. Sin embargo, todavía podemos ver el contorno del WIPEOUT. Para solucionarlo volvemos a utilizar la variable WIPEOUTFRAME y cambiamos su valor a 0 , de manera que el marco deje de ser visible.

Nota: es cierto que todavía no hago este último paso en el video. La razón es simplemente que debemos continuar agregando más acciones y, para ello, necesitamos que el WIPEOUT permanezca visible. Si ya lo han desactivado, tendrán que volver a hacerlo visible estableciendo nuevamente la variable WIPEOUTFRAME en 1.

Ahora vamos a hacer que la puerta pueda voltearse hacia el lado opuesto.

Para ello utilizamos el elemento Mirror , que nos permite definir un eje de simetría mediante dos puntos. Después, dentro de Activities , debemos seleccionar también Mirror . Aunque ambos se llaman Mirror , se trata en realidad de dos cosas diferentes: uno define el comportamiento y el otro ejecuta la acción. El motivo de esta diferencia lo explicaremos en otro tutorial. Una vez seleccionada la actividad, debemos elegir las entidades que participarán en la operación de simetría.

En este punto es importante tener en cuenta que, en principio, debemos incluir todas las entidades que forman parte de la puerta.

Sin embargo, podrían decidir dejar fuera el elemento Visibility , por ejemplo, si prefieren que su grip permanezca siempre en la misma posición. En este ejemplo también queremos que el elemento Visibility se simetrice junto con el resto del bloque.

Nota: recuerden activar la visualización de todos los Visibility States antes de seleccionar las entidades. De esta manera podrán incluir correctamente todos los objetos que deben participar en la acción.

Ahora toca crear una simetría en el otro sentido.

Para ello utilizaremos como referencia el lado fijo de la puerta. Es importante señalar que, en un caso diferente, si necesitáramos realizar la simetría utilizando como eje el centro de la puerta en el sentido Y de nuestro ejemplo, aparecerían algunos problemas adicionales que no vamos a tratar en este video. La lógica general sería similar, pero la solución tendría que plantearse de otra manera y requeriría algunos pasos adicionales.

Veremos ese caso específico en otro tutorial.

¿Qué les ha parecido este nuevo tutorial? ¿Conocían esta posibilidad?

Este tipo de solución puede aplicarse en muchas situaciones arquitectónicas. Por ejemplo, podemos utilizar WIPEOUT con árboles, vehículos u otros elementos para ocultar automáticamente aquello que queda detrás, sin necesidad de utilizar Trim.

También puede resultar útil en ingeniería cuando trabajamos con piezas que necesitamos colocar unas sobre otras.

¡Pruébenlo!

Y recuerden que pueden descargar ARES Commander y experimentar con estas funciones para crear sus propios Custom Blocks inteligentes. https://www.graebert.com/cad-software/download/ares-commander/

Bloque de puerta que corta automáticamente los muros. - Case #003

Thu, 13 Aug 2026 08:16:49 GMT

Bloque de puerta que corta automáticamente los muros - Caso #003

El siguiente será un poco más complejo, pero por ahora vamos a centrarnos en un caso práctico —y extremadamente útil—. Bueno, al menos así lo veo yo. ¡Cuéntame qué te parece!

Este tutorial puede aplicarse exactamente de la misma manera en ARES Commander —como en el ejemplo—, DraftSight y AutoCAD, al menos.

Nota: Custom Blocks es el nombre que reciben los bloques paramétricos en ARES Commander y DraftSight, mientras que en AutoCAD se denominan Dynamic Blocks. Los pasos explicados en este tutorial para crear un Custom Block paramétrico en ARES Commander son, en esencia, los mismos que se siguen en AutoCAD para crear un Dynamic Block.

Para muchos de vosotros, la primera parte de este vídeo puede parecer algo que simplemente podéis saltaros. Solo estoy mostrando cómo he creado un muro, que básicamente es un rectángulo de 300 × 15, y una puerta abatible que después convierto en un bloque.

Al final de esta primera parte veréis que, por el momento, el bloque no se comporta como esperaríamos. Así que muevo el bloque y lo coloco sobre el muro, pero, por supuesto, todo simplemente se superpone.

Un usuario habitual de CAD podría decir: «Bueno, necesitamos crear algunas líneas auxiliares, recortar la geometría o utilizar una operación de estiramiento», entre muchas otras posibles soluciones, para crear el hueco en el muro. Pero en este tutorial vamos a ir un paso más allá y mostrar un enfoque más avanzado.

VIDEO 1

VIDEO 2

Edita el bloque haciendo doble clic sobre él. Podríamos añadir parámetros que nos permitieran invertirlo a derecha/izquierda, hacia dentro/hacia fuera, mostrarlo abierto o cerrado, e incluso cambiarlo a diferentes tamaños, pero dejaremos eso para otro tutorial. Por ahora, vamos a centrarnos en cómo “cubrir” el muro.

Para ello, utilizaremos el comando WIPEOUT, que nos permite crear una forma que hará exactamente lo que necesitamos.

En este caso, el orden es importante, y debemos enviar el WIPEOUT detrás de la puerta; de lo contrario, también cubrirá la geometría de la propia puerta.

Pero hay otra opción que debemos tener en cuenta. De forma predeterminada, el marco del WIPEOUT es visible. Si queremos ocultarlo, podemos utilizar la opción FRAME, a la que podemos acceder escribiendo nuevamente el comando WIPEOUT. Como alternativa, también podemos utilizar directamente el comando WIPEOUTFRAME.

Guardamos los cambios y comprobamos cómo funciona.

¿Qué te parece? ¿Conocías esta opción?

Puedes aplicarla en muchas situaciones de arquitectura, por ejemplo, con árboles o coches, sin necesidad de utilizar TRIM. También puede ser muy útil en ingeniería, cuando trabajas con piezas que quieres colocar unas sobre otras.

¡Pruébalo! Y recuerda que puedes descargar ARES Commander y experimentar con estas funciones para crear tus propios bloques inteligentes.

https://www.graebert.com/cad-software/download/ares-commander/

Vamos a ver un caso que abre un enorme abanico de posibilidades más complejas, especialmente cuando se combina con los parámetros que hemos visto en tutoriales anteriores.

Door block that automatically cuts the walls - Case #003

Thu, 13 Aug 2026 08:08:05 GMT

door block that automatically cuts the walls - Case #003

The next one will be a little more complex, but for now, let’s focus on a practical—and extremely useful—case. Well, that’s how I see it, anyway. Let me know what you think!

This tutorial can be applied in exactly the same way in ARES Commander (as in the example), DraftSight, and AutoCAD, at least.

For many of you, the first part of this video may seem like something you can simply skip. I’m just showing how I created a wall, which is basically a 300 × 15 rectangle, and a swing door that I then convert into a block.

At the end of this first part, you’ll see that, for the moment, the block doesn’t behave the way we would expect. So, I move the block and place it on top of the wall—but, of course, everything simply overlaps.

A typical CAD user might say, “Well, we need to create some construction lines, trim the geometry, or use a stretch operation,” among many other possible solutions, in order to create the opening in the wall. But in this tutorial, we’re going to take things a step further and show you a more advanced approach.

VIDEO 1

VIDEO 2

Edit the block by double-clicking it. We could add parameters to allow us to flip it right/left, inside/outside, open or closed, and change it to different sizes, but we’ll leave that for another tutorial. For now, we’re going to focus on how to “cover” the wall.

To do this, we’ll use the WIPEOUT command, which allows us to create a shape that will do exactly what we need.

In this case, the order is important, and we need to send it behind the door; otherwise, it will cover the door as well.

But there’s another option we need to keep in mind. By default, the WIPEOUT frame is visible. If we want it to be invisible, we can use the FRAME option, which we can access by typing the WIPEOUT command again. Alternatively, we can use the direct shortcut WIPEOUTFRAME.

Save the changes, and we can check how it works.

What do you think? Did you know about this option?

You can apply it in many architectural situations, for example, with trees or cars, without needing to use Trim. It can also be useful in engineering, when working with parts that you want to place on top of one another.

Give it a try! And remember, you can download ARES Commander and experiment with these features to create your own smart blocks.

https://www.graebert.com/cad-software/download/ares-commander/

We’re going to look at a case that opens up a huge range of more complex possibilities, especially when combined with the parameters we’ve covered in previous tutorials.

Bloque paramétrico - Caso #002

Wed, 12 Aug 2026 09:35:55 GMT

BLOQUE PARAMÉTRICO - Caso 2

Los Custom Blocks de ARES Commander permiten crear elementos inteligentes cuyo tamaño, posición o geometría pueden modificarse mediante grips, parámetros y acciones. Lo que hace esto especialmente interesante es que la lógica de creación es prácticamente la misma que la utilizada para los Dynamic Blocks de AutoCAD. Por lo tanto, aprender este proceso nos permite trabajar con ambas plataformas.

Tenemos un dibujo de una puerta corredera que necesitamos convertir en un bloque.

Lo primero que hacemos es comprobar las unidades del dibujo. En este ejemplo, están configuradas en centímetros.

El comando UNITS nos permite comprobarlo y ajustar las unidades si es necesario.

VIDEO 1

VIDEO 2

Este paso no es necesario, pero aprovecharé para explicarlo.

Para que las líneas se vean mejor en el vídeo, voy a asignar un grosor de línea a la capa “0” , que es donde se encuentran las entidades existentes. Esto se hace únicamente para mejorar su visibilidad en el vídeo.

ARES Commander permite activar o desactivar fácilmente la visualización de los grosores de línea. Modifico esta propiedad desde la paleta Properties , en este caso para la única capa existente. Recuerda que, siempre que sea posible, se recomienda crear las entidades de un bloque en la capa “0” . Existen algunas excepciones, pero las veremos en otro tutorial.

Al hacer doble clic sobre el bloque simple, este se abre en el Editor de bloques, donde podemos editarlo. En este caso, queremos mover las tres formas a su posición final. Como mencionamos antes, por ahora aparecerán superpuestas una sobre otra, por eso elegimos formas sencillas, para que sigan siendo fáciles de identificar y manipular.

VIDEO 3

Ahora seleccionamos el elemento Visibility. Hacemos clic para indicar dónde queremos colocar este grip. En el menú desplegable, seleccionamos 1 para que sea visible y, a continuación, seleccionamos las entidades correspondientes.

El siguiente paso es abrir Visibility States , un cuadro de diálogo que nos permite crear tantos estados como necesitemos.

En este ejemplo, necesitamos tres estados de visibilidad, que llamaremos:

Option 1
Option 2
Option 3

Estos tres iconos son muy importantes, ya que nos permiten controlar si los objetos seleccionados están visibles u ocultos.

El primer icono nos permite mostrar todos los estados de visibilidad al mismo tiempo, independientemente de que los objetos estén configurados como visibles u ocultos.

Los otros iconos se utilizan para mostrar u ocultar elementos específicos en función del estado de visibilidad seleccionado.

Consulta el vídeo para ver el proceso completo.

Básicamente, con Option 1 seleccionada, por ejemplo, elegimos qué elementos queremos mostrar y cuáles queremos ocultar.

En este ejemplo, mantuve un cuarto estado de visibilidad en el que se pueden ver todos los elementos al mismo tiempo. Esto puede resultar muy útil en situaciones más complejas, al menos mientras el bloque todavía se está definiendo y ajustando. Una vez que hayamos comprobado que todo funciona como esperamos, podemos eliminar este estado de visibilidad adicional.

VIDEO 5

¿No tienes ARES Commander, DraftSight o AutoCAD? No te preocupes. Puedes descargar ARES Commander gratis y probarlo aquí. Si ya eres usuario de AutoCAD y nunca has probado ARES Commander, no te preocupes: apenas notarás la diferencia.

https://www.graebert.com/cad-software/download/ares-commander/

En este caso, he dibujado tres formas que se utilizarán para representar los tres tipos diferentes de tiradores empotrados en el marco de aluminio. Podrían ser simplemente tres rectángulos. En este ejemplo, los tres son rectángulos con un radio de empalme de 5 mm, y el más pequeño incluye además un detalle adicional creado con una línea extra.

En definitiva, representan tres estados diferentes. En el vídeo verás cómo los coloco en su posición final. Una vez ubicadas, las tres formas quedarán superpuestas una sobre otra. Cuando tenemos todos los elementos preparados, creamos un bloque simple.

VIDEO 4

Tenemos un dibujo de una puerta corredera que necesitamos convertir en un bloque.

En el siguiente video verán cual es la idea de este tutorial.

A partir de este punto, vamos a añadir parámetros que nos permitan modificar el ancho y el alto de la puerta.

Ya mostramos ejemplos de cómo configurar estos parámetros en el Caso 1 . La única diferencia aquí es que, si queremos que los elementos controlados mediante Visibility se muevan como parte de otro parámetro, también debemos seleccionar el parámetro Visibility junto con los elementos asociados a él.

Nota: Si todavía no has visto el ejemplo anterior (Caso 1), haz clic en el siguiente enlace para seguir el proceso paso a paso: https://www.miltonchanes.de/parametric-block-case-1

Como se muestra en el vídeo, es importante asegurarse de que todos los elementos de los distintos estados de visibilidad estén visibles al añadirlos a una acción. Si lo hacemos mientras solo se muestra un estado de visibilidad , los elementos pertenecientes a los demás estados no se incluirán en la acción. Puede haber situaciones en las que esto sea precisamente lo que buscamos, pero no es el caso en este ejemplo.

VIDEO 6

Parametric Block - Case #002

Tue, 11 Aug 2026 20:21:51 GMT

paramEtric BloCK - CasE 2

ARES Commander Custom Blocks make it possible to create intelligent elements whose size, position, or geometry can be modified through grips, parameters, and actions.

What makes this especially interesting is that the creation logic is practically the same as the one used for AutoCAD dynamic blocks . Learning this process therefore allows us to work with both platforms.

Note: Custom Blocks is the name given to parametric blocks in ARES Commander and DraftSight, while in AutoCAD they are called Dynamic Blocks. The steps explained in this tutorial for creating aparametric Custom Block in ARES Commander are essentially the same as those followed inAutoCAD to create a Dynamic Block.

We have a drawing of a sliding door that we need to convert into a block.

The first thing we do is check the drawing units. In this example in centimeters.

1. Create the Base Block

To create an intelligent block, we first need to create a conventional block.

We begin by drawing the elements that represent a two-panel sliding door: the frame, the door panels, the central lines, and the arrows indicating the opening direction. To do this, we can use basic drawing and editing tools such as lines, polylines, rectangles, Trim, Extend, and others. Do not forget to check the drawing units. This is extremely important.

The UNITS command allows us to check this and adjust the units if necessary.

VIDEO 1

VIDEO 2

This step is not necessary, but I’ll take the opportunity to explain it.

To make the lines easier to see in the video, I’m going to assign a lineweight to layer “0” , which is where the existing entities are located. This is only to improve their visibility in the video.

ARES Commander allows you to easily turn the display of lineweights on or off. I change this property from the Properties palette , in this case for the only existing layer. Remember that, whenever possible, it is recommended to create the entities of a block on layer “0” . There are some exceptions, but we’ll cover those in another tutorial.

By double-clicking the simple block, it opens in the Block Editor , where we can edit it.

In this case, we want to move the three shapes to their final position. As mentioned earlier, for now they will appear superimposed on top of one another , which is why we chose simple shapes so that they remain easy to identify and work with.

VIDEO 3

Now we select the Visibility element.

We click to specify where we want to place this grip.

From the drop-down menu, we select 1 so that it is visible, and then select the corresponding entities.

After saving the changes, we can test the block. See the video. The width and height now change correctly, although the behaviour of some other elements still needs to be improved.

In this example, we need three visibility states , which we will name:

Option 1
Option 2
Option 3

These three icons are very important because they allow us to control whether the selected objects are visible or hidden.

The first icon lets us display all visibility states at the same time , regardless of whether the objects are currently set as visible or hidden.

The other icons are used to show or hide specific elements depending on the selected visibility state .

See the video for the full process.

Basically, with Option 1 selected, for example, we choose which elements we want to show and which ones we want to hide .

In this example, I kept a fourth visibility state where all the elements can be seen at the same time.

This can be very useful in more complex situations, at least while the block is still being defined and adjusted. Once we have checked that everything works as expected, we can delete this extra visibility state .

VIDEO 5

From this point on, we are going to add parameters that allow us to modify the width and height of the door .

We already showed examples of how to configure these parameters in Case 1 . The only difference here is that, if we want the visibility-controlled elements to move as part of another parameter, we also need to select the Visibility parameter together with the elements associated with it.

Note: If you have not seen the previous example yet ( Case 1 ), click the link below to follow the process step by step: https://www.miltonchanes.de/parametric-block-case-1

As shown in the video, it is important to make sure that all elements from the different visibility states are displayed when adding them to an action.

If you do this while only one visibility state is shown, the elements belonging to the other states will not be included in the action .

There may be situations where this is exactly what you want, but that is not the case in this example.

VIDEO 6

You don’t have ARES Commander, DraftSight, or AutoCAD? Don’t worry, you can download ARES Commander for free and try it out here. If you’re already an AutoCAD user and have never tried ARES Commander before, don’t worry—you’ll hardly notice the difference.

https://www.graebert.com/cad-software/download/ares-commander/

In this case, I have drawn three shapes that will be used to represent the three different types of pull handles recessed into the aluminum frame.

Ultimately, they represent three different states . In the video, you will see how I place them in their final position. Once positioned, the three shapes will be superimposed on top of one another .

Once we have all the elements ready, we create a simple block .

VIDEO 4

Parametric Block - Case #001

Tue, 11 Aug 2026 16:04:45 GMT

paramEtric BloCK - CasE 1

ARES Commander Custom Blocks make it possible to create intelligent elements whose size, position, or geometry can be modified through grips, parameters, and actions.

In this example, we will create a two-panel aluminium sliding door whose width and height can be modified directly through grips or from the Properties palette.

1. Create the Base Block

To create an intelligent block, we first need to create a conventional block.

2. Add the Width and Height Parameters

We add two linear parameters:

One to control the width of the door.
Another to control its height.

It is advisable to assign clear names to these parameters, such as Width and Height . This allows us to identify them easily in the Properties palette and enter exact values whenever necessary. Pay attention to the fact that we select the element called Linear and configure it so that it has only one grip. This keeps one side of the block fixed.

Once the geometry is complete, we create the block and open it in the Block Editor.

When creating the block, we assign a name and a description, define its insertion point, select all the entities that belong to it, and specify the correct units.

This ensures that when the block is inserted into another drawing that uses a different unit system, it will be scaled automatically.

VIDEO 1

VIDEO 2

Once the block has been created, we need to edit it. We can open it directly in the Block Editor by enabling the Edit in Block Editor option, or simply double-click the block after creating it.

The Linear element does nothing by itself. It simply defines a vector that can be used to control one or more actions.

It may have no grips at all when used for nested actions, or it may contain one or two grips. Two grips could be useful, for example, when we want to stretch an element in both directions.

In this example, we will use only one grip.

VIDEO 3

3. Configure the Stretch Action

There are many ways to add intelligence to a block, but we will begin with a simple operation: Stretch .

The Stretch action can be found in the Activities drop-down menu inside the Block Editor. See the video.

After selecting this action, we need to follow a series of steps. This requires becoming familiar with the command line, where the program requests each part of the process.

First, select the Linear element that we added previously. Because this element has two endpoints, we need to indicate which endpoint will control the action. Since we enabled only one grip, pressing Enter will automatically select the correct one.

Next, we must define:

The area of the geometry that will be affected by the Stretch action. See the video.
The entities that will participate in the Stretch action. See the video.

We repeat the same procedure for both the width and the height. See the video.

Actions associated with a parameter are represented by an icon.

When several actions are assigned to the same parameter, the corresponding icons appear next to one another. Each action can also be given a specific name, making it easier to remember what it does. See the video.

After saving the changes, we can test the block. See the video. The width and height now change correctly, although the behaviour of some other elements still needs to be improved.

This is also a good opportunity to see that the values can be edited directly from the Properties palette. Because we assigned meaningful names such as Height and Width , the parameters are easy to identify and modify.

However, we can see that other elements, such as the central mullion and the opening arrows, have not moved. We will improve this next.

Note: The Reset Block option, which appears when right-clicking a selected block, simply returns that block instance to its original form before any changes were made using its grips. Each block instance is independent.

4. Keep the Arrows Centred

When we modify the width of the door, the arrows indicating the opening direction should also move so that they remain centred.

There is more than one way to achieve this. We could use Stretch, for example, but that would make the explanation more confusing. Instead, we will use the Move action because it is easier to understand.

In this case, we will associate a Move action with the grip that controls the horizontal dimension. We need the same grip to perform two actions at the same time:

The Stretch action configured previously.
The new Move action. See the video.

The process is as follows:

Select the Move action.
Select the relevant parameter, in this case the one controlling the horizontal dimension.
Press Enter so that the action point is placed at the same location as the existing grip.
Select the entities that need to move, in this case the two arrows.

VIDEO 4

Did you watch the video? We have a problem.

When the grip moves by 100 units, the arrows also move by 100 units. However, we need them to move by only 50% of that distance.

Fortunately, there is a simple solution.

The solution can be found in the properties of the Move action. To access them, simply select the action by clicking its corresponding icon.

VIDEO 5

The properties of the Move action allow us to make several adjustments. Is the action name important? When you have several Move actions, they will automatically be called Move1, Move2, Move3, and so on. It can therefore become difficult to identify them. Assigning a descriptive name makes each action easier to recognise. This may not always seem necessary, but in a company where content is created for other people to reuse, it is better to be very strict and consistent with these details.

The property that is particularly important, and that you should remember, is Distance Multiplier . This property appears in many actions and solves a wide range of common problems.

In this case, we need to change its value to:

0.50

This means that when the grip moves by 100 units, this action will move the arrows by only 50 units because we have applied a multiplication factor of 0.50. As a result, the arrows will always remain centred relative to the total width of the door.

We test the block again, and the arrows now behave as expected.

5. Apply the Same Logic to the Height

We can repeat the same procedure for the height.

In some door blocks, arrows like these may remain at a fixed distance from the base.

However, in this example, we want them to remain vertically centred as well.

We therefore add another Move action associated with the height parameter and configure its Distance Multiplier as 0.50 .

When the height of the door changes, the arrows will move by half the distance travelled by the grip, regardless of the direction in which the grip is moved.

VIDEO 6

6. Adjust the Central Section of the Door

We still need to configure the central section of the door correctly, particularly the mullion area.

In this case, using a Move action would not be appropriate because parts of the entities need to be stretched. It is therefore preferable to use another Stretch action, since the geometry needs to adapt to the new dimensions of the block.

Could we have used the original Stretch action?

The answer is no.

As with the arrows, the central section must respond to only 50% of the distance applied through the grip. We select the corresponding stretch area and the entities that need to be modified. Pay attention to the fact that some entities are selected using a Window selection and others using a Crossing selection. You can experiment with both selection methods and compare the results. After assigning the action, we select it and modify its Distance Multiplier property to 0.50 , for the reasons explained previously.

The logic is the same: the central section must change by only half the distance travelled by the grip so that it remains correctly positioned and proportioned within the door.

Final Result

We can modify its width and height using the grips or by entering exact values in the Properties palette. The arrows remain centred, and the internal geometry adapts correctly to the new dimensions. This is a simple example, but it demonstrates one of the most important concepts when working with intelligent blocks:

A single grip movement can activate several actions at the same time.

When moving a grip, we can:

Stretch part of the geometry.
Move other elements.
Apply different distance multipliers.
Keep components centred or aligned.

The same steps and logic can be used to create a dynamic block in AutoCAD.

In addition, dynamic blocks created in AutoCAD can be used in ARES Commander, which makes it easier to work across both platforms.

Using this principle, we can develop windows, doors, furniture, profiles, construction details, and many other CAD elements capable of adapting automatically to different dimensions and situations.

We can also define minimum and maximum distances, as well as specific increments. For example, a block could increase in steps of 5 cm, or users could select from a list of predefined sizes such as 120, 130, and 140 when a manufacturer offers only those options. These are only a few of the many possibilities available.

https://www.graebert.com/cad-software/download/ares-commander/

VIDEO 8

VIDEO 7

Inside the editor, we will find the tools that allow us to add a certain level of intelligence to the block.

This is, incidentally, the same basic concept used in software such as Revit when creating a parametric family.

Kōdōkan – Its History

Thu, 06 Aug 2026 14:07:39 GMT

The Kōdōkan: Where Judo Became a Way and Karate Found Its Gateway to Japan

In 1922, when Gichin Funakoshi first crossed the threshold of the Kōdōkan in Tokyo, he was not simply entering a dojo. That place represented a new way of understanding the martial arts: not merely as methods of combat, but also as instruments of education, discipline, and character development.

For a master arriving from Okinawa, carrying an art that was still largely unknown throughout Japan, appearing before Jigorō Kanō and the country’s leading judoka meant subjecting karate to one of its most important tests. Yet, to fully understand the significance of that encounter, it is first necessary to understand what the Kōdōkan truly was and why it had been founded.

The first Kōdōkan, founded in 1882 within the Eishōji Temple, was a small dōjō of twelve tatami mats. The buildings from that period were destroyed in the fires that followed the Great Kantō Earthquake of 1923. The temple still exists today, rebuilt, and preserves a monument marking the birthplace of the Kōdōkan.
The Kōdōkan that Funakoshi knew in 1922 was the Shimotomisaka dōjō, in Koishikawa. It operated between 1894 and 1933 (the building later disappeared in the bombings of 1945, just as the Shōtōkan dōjō did) and became one of the largest training centers in Japan. That building no longer exists, and the area was later transformed. It is very likely that the photograph above shows the dōjō that Funakoshi knew and visited, although it could also depict another jūdō dōjō. In any case, it should not be confused with the Shōtōkan dōjō. What can be stated with confidence is that the image shows a jūdō dōjō, and most probably the Shimotomisaka dōjō.
The current Kōdōkan is located in Kasuga, in Tokyo’s Bunkyō ward. It is a modern multi-story complex dedicated to training, research, as well as the library and museum of jūdō.

Note: In addition, the color version is an AI-generated recreation. The colors, textures, and some small details were interpreted, so it should not be presented as an exact documentary colorization.

The Birth of the Kōdōkan

The Kōdōkan was founded by Jigorō Kanō in May 1882. It did not begin in a grand building, but in a small training hall established within the Buddhist temple of Eishōji, in Tokyo’s Shitaya district. Traditional accounts describe a space of barely twelve tatami mats and only a small group of students.

Kanō was twenty-one years old at the time and had studied primarily under two classical schools of jūjutsu: Tenjin Shin’yō-ryū and Kitō-ryū. Drawing upon these traditions, as well as his study of other combat systems, he selected techniques, revised training methods, and developed a structure suited to the needs of a Japanese society undergoing rapid modernization.

His purpose was not merely to establish yet another school of jūjutsu. Kanō sought to transform martial training into an educational system capable of strengthening the body, exercising the intellect, and helping to form individuals who could contribute positively to society.

For this reason, he replaced the term jutsu, associated with technique or practical skill, with dō, meaning “the way.” Jūjutsu thus became jūdō: the “way of flexibility” or the “way of adaptation”.

The name he chose for his institution expressed the same idea. Kōdōkan —講道館— may be understood as “the place where the way is taught or studied.” From the beginning, therefore, it was not conceived merely as a hall in which students learned how to throw or immobilize an opponent. It was a school dedicated to human development and self-improvement.

What Was It Created For?

Kanō believed that the old martial schools contained valuable knowledge, but he also thought that this knowledge needed to be organized and adapted so that it could be practised systematically and with a reasonable degree of safety.

Training at the Kōdōkan combined two fundamental methods. Kata preserved principles and techniques through predetermined sequences. Randori, by contrast, allowed practitioners to experiment freely against a partner who also offered resistance. To make this kind of practice possible, it was necessary to restrict certain techniques, or reserve for kata those that could cause serious injury.

The ultimate purpose went far beyond defeating an opponent. Kanō summarized his philosophy through two major principles:

Seiryoku zen’yō — the most effective use of physical and mental energy.
Jita kyōei — mutual welfare and prosperity.

According to Kanō’s own teaching, what was learned through kata and randori should be applied to everyday life. Jūdō could serve as self-defence, physical education, and mental discipline, but also as a guide for interacting with others and contributing to the progress of the community.

From a Small Training Hall to a National Institution

The growth of the Kōdōkan forced it to relocate several times. Its different headquarters were established in places such as Fujimi-chō, Shimotomisaka, and Suidobashi, before it eventually moved into its present building in Kasuga, in Tokyo’s Bunkyō ward.

Each relocation reflected the increasing number of students and the growing influence of jūdō. What had begun in a room inside a temple gradually became an institution with training halls, teaching departments, archives, a library, a museum, and an international grading system.

Kanō was not only the founder of jūdō. He was also an important educator, the principal of the Tokyo Higher Normal School, a promoter of modern physical education, and, from 1909, the first Asian member of the International Olympic Committee. The expansion of the Kōdōkan was closely connected to this educational and international vision.

The Challenges Against the Traditional Schools of Jūjutsu

The consolidation of the Kōdōkan was not immediate. During its early years, its practitioners took part in matches and challenges against representatives of traditional jūjutsu schools. The favourable results achieved by students such as Shirō Saigō, Tsunejirō Tomita, Yoshitsugu Yamashita, and Sakujiro Yokoyama helped strengthen the reputation of the new system.

However, an important historical clarification is necessary. Many popular accounts describe a single police tournament held in 1886, in which the Kōdōkan is said to have achieved thirteen victories and two draws. More recent research suggests that several encounters probably took place between 1885 and 1888, and that the surviving records are incomplete. It is therefore more accurate to state that Kōdōkan representatives achieved favourable results against various schools of jūjutsu, without treating any specific score as an unquestionable historical fact.

These encounters were important, but they do not by themselves explain the success of jūdō. Its expansion was also due to Kanō’s ability to organize instruction, train teachers, introduce jūdō into educational institutions, and present its practice as a modern system of education.

A Place of Research and Exchange

The Kōdōkan was not merely the administrative centre of jūdō. It also became a place for research into the martial arts.

Kanō showed an interest in combat systems other than his own. He studied Western boxing, observed other disciplines, and welcomed practitioners from different traditions. Documents even show that he had already come into contact with representatives of Okinawan karate before meeting Funakoshi in person.

In April 1911, for example, a group of young Okinawan instructors visited Kanō. They spoke with him about jūdō and karate, practised joint-locking techniques, and gave a board-breaking demonstration. This episode shows that Kanō’s interest in the Okinawan art did not suddenly begin in 1922.

The Arrival of Gichin Funakoshi

In 1922, Gichin Funakoshi travelled from Okinawa to Tokyo to take part in a physical education exhibition promoted by the Ministry of Education. His presentation of Tōde attracted public attention, and particularly that of Jigorō Kanō.

Shortly afterwards, Kanō invited him to give a demonstration at the Kōdōkan before a large audience of jūdō practitioners. Funakoshi asked for the assistance of Shinkin Gima, a young Okinawan who was studying in Tokyo and who also had experience in jūdō.

According to the Japan Karate Association, the audience filled the dōjō and the demonstration was received with great interest. Later accounts state that Funakoshi performed the kata Kūsankū—later known in Shotokan as Kankū—while Gima presented Naihanchi. They also demonstrated applications and answered questions from Kanō and his students.

That encounter should not be interpreted as a simple exhibition intended to entertain the judoka. Funakoshi was presenting, before one of Japan’s most prestigious martial institutions, an art that was still largely regarded as a regional practice from Okinawa.

Kanō, for his part, did not merely observe the demonstration out of courtesy. Gima’s testimony recalls his enthusiasm, his questions, and his interest in understanding how karate techniques worked. An academic study on Kanō’s relationship with other forms of combat also emphasizes the importance of the support he gave Funakoshi during those early years.

The Encounter That Helped Change the History of Karate

The visit to the Kōdōkan was not karate’s first appearance on the main islands of Japan, nor did it by itself transform Funakoshi into the founder of a new discipline. Nevertheless, it represented a decisive moment.

The approval of a figure as respected as Jigorō Kanō gave Funakoshi a degree of legitimacy that would have been difficult for a virtually unknown Okinawan master to obtain in Tokyo. The success of the demonstration led to further invitations and encouraged many people to ask him to remain in the capital.

Funakoshi had originally intended to return to Okinawa after fulfilling his commitment at the exhibition. Instead, he began teaching at the Meiseijuku, a residence for Okinawan students, and published his first book on the art that same year. During the years that followed, karate began to spread through Japanese universities and to adopt an educational structure that was more readily understood by the society of mainland Japan.

The Kōdōkan did not create Funakoshi’s karate, but it offered him something essential: a place from which it could be observed, evaluated, and recognized by representatives of Japanese budō.

The Legacy of the Kōdōkan

Over the decades, the Kōdōkan became the international centre of jūdō. From there, its kata were studied and preserved, instructors were trained, and the grades of practitioners from numerous countries were officially registered.

In 1964, jūdō was included in the Olympic programme during the Tokyo Games. By then, the small school founded by Kanō in 1882 had given rise to a discipline practised throughout the world. Yet its deepest legacy does not lie in competition alone. The Kōdōkan continues to represent the idea that a martial practice can become a path of education, responsibility, and personal improvement.

This is also why Funakoshi’s visit was so significant. In that dōjō, two men from different traditions came together, united by the same conviction: that the martial arts should serve a purpose greater than simply defeating another person.

The Day Funakoshi Entered the Kōdōkan

Historical documents allow us to know the essential facts: Kanō’s invitation, the presence of Shinkin Gima, the kata that were performed, and the favourable reception of those in attendance. But documents cannot always convey the human weight of such a moment.

What might Funakoshi have felt as he entered the most prestigious martial institution in Tokyo? Was he aware that the demonstration could determine the future of karate in Japan? How might Kanō have regarded that Okinawan master presenting a system based on strikes, kicks, body movement, and kata that were unfamiliar to most of those present?

In my historical novel Walking Upright, I reconstruct that day through the eyes of Gichin Funakoshi: his arrival at the Kōdōkan, his meeting with Jigorō Kanō, the tension before the demonstration, and the moment when Okinawan karate was presented before some of the most influential figures in Japanese budō.

History tells us that Funakoshi entered as a guest. The novel attempts to show why he left as the bearer of a mission that would no longer allow him to return to the life he had left behind in Okinawa.

WALKING UPRIGHT — The Novel

In my novel, I recount the moment when Gichin Funakoshi prepares to give his demonstration at the Kōdōkan.

Walking Upright is the first novel in the trilogy of the same name.

A NOVEL INSPIRED BY TRUE EVENTS · PUBLISHED

Walking Upright

Karate-Dō · The story of Gichin Funakoshi

A fictional novel inspired by real events. Not a manual of techniques but an essay in lived ethics: how the Okinawan path of karate-dō became a discipline for the body, the mind, and the way we move through the world. A meditation on lineage, dignity and the quiet decision to walk upright.

Walking Upright Trilogy - Book 1 .

YEAR

2025

DOWNLOAD PDF SAMPLE ↓

PAPERBACK · HARDCOVER · KINDLE eBOOK

FORMATS

PAGES

+620

LANGUAGES

AVAILABLE IN

Kōdōkan - Su historia

Thu, 06 Aug 2026 13:41:33 GMT

El Kōdōkan: el lugar donde el judo se convirtió en un camino y el karate encontró una puerta hacia Japón

En 1922, cuando Gichin Funakoshi cruzó por primera vez la entrada del Kōdōkan de Tokio, no estaba entrando simplemente en un dojo. Aquel lugar representaba una nueva manera de comprender las artes marciales: no solo como métodos de combate, sino también como instrumentos de educación, disciplina y formación del carácter.

Para un maestro llegado desde Okinawa, portador de un arte todavía desconocido para buena parte de Japón, presentarse ante Jigorō Kanō y los principales judokas del país significaba someter el karate a una de sus pruebas más importantes. Sin embargo, para comprender la trascendencia de aquel encuentro es necesario conocer primero qué era realmente el Kōdōkan y por qué había sido creado.

El primer Kōdōkan , fundado en 1882 dentro del templo Eishōji , era un pequeño dōjō de doce tatamis. Los edificios de aquella época fueron destruidos por los incendios posteriores al Gran Terremoto de Kantō de 1923. El templo existe actualmente, reconstruido, y conserva un monumento que señala el lugar de nacimiento del Kōdōkan.
El Kōdōkan que conoció Funakoshi en 1922 era el dojo de Shimotomisaka , en Koishikawa. Funcionó entre 1894 y 1933 (el edificio desapareció en los bombarderos de 1945 al igual que el dōjō Shōtōkan) y llegó a ser uno de los mayores centros de entrenamiento de Japón. Ese edificio desapareció y la zona fue transformada posteriormente. Es muy probable que la foto de arriba sea ese Dōjō que Funakoshi conoció y visitó, o podría ser otro dōjō de Judō. En cualquier caso, no debe confundirse con el dōjō Shōtōkan. El de la foto se puede afirmar que se trata de un dōjō de Judō, y probablemente el dōjō de Shimotomisaka.
El Kōdōkan actual se encuentra en Kasuga, en el distrito tokiota de Bunkyō. Es un complejo moderno de varios pisos dedicado al entrenamiento, la investigación, la biblioteca y el museo del judō.

Nota: Además, la versión en color es una recreación realizada mediante inteligencia artificial . Los colores, texturas y algunos pequeños detalles fueron interpretados, por lo que no debe presentarse como una colorización documental exacta.

El nacimiento del Kōdōkan

El Kōdōkan fue fundado por Jigorō Kanō en mayo de 1882. No nació como el gran edificio, sino como una pequeña sala de entrenamiento instalada en el templo budista Eishōji, en el distrito de Shitaya. Las historias tradicionales hablan de apenas doce tatamis y un reducido grupo de alumnos.

Kanō tenía entonces veintiún años y había estudiado principalmente dos escuelas clásicas de jūjutsu: Tenjin Shin’yō-ryū y Kitō-ryū. A partir de ellas, y de su estudio de otros sistemas de combate, seleccionó técnicas, revisó métodos de entrenamiento y desarrolló una estructura adaptada a las necesidades de una sociedad japonesa que estaba modernizándose rápidamente.

Su propósito no consistía únicamente en fundar otra escuela de jūjutsu. Kanō quería transformar el entrenamiento marcial en un sistema educativo que fortaleciera el cuerpo, ejercitara la inteligencia y ayudara a formar personas útiles para la sociedad.

Por ese motivo sustituyó el término jutsu, relacionado con la técnica o la habilidad práctica, por dō, el camino. El jūjutsu se convirtió así en jūdō: el «camino de la flexibilidad» o el «camino de la adaptación».

El nombre elegido para su institución expresaba la misma idea. Kōdōkan —講道館— puede entenderse como «el lugar donde se enseña o se estudia el camino». Desde el principio, por tanto, no fue concebido únicamente como una sala donde aprender a proyectar o inmovilizar a un adversario. Era una escuela destinada al perfeccionamiento humano.

¿Para qué fue creado ?

Kanō consideraba que las antiguas escuelas marciales contenían conocimientos valiosos, pero pensaba que debían ser organizados y adaptados para que pudieran practicarse de manera sistemática y relativamente segura.

El entrenamiento del Kōdōkan combinó dos métodos fundamentales. El kata preservaba principios y técnicas mediante secuencias previamente establecidas. El randori, en cambio, permitía experimentar libremente contra un compañero que también ofrecía resistencia. Para hacer posible esta práctica, fue necesario limitar o reservar para los kata aquellas técnicas que podían causar lesiones graves.

La finalidad última iba mucho más allá de vencer a un adversario. Kanō resumió su pensamiento mediante dos grandes principios:

Seiryoku zen’yō , el empleo más eficaz de la energía física y mental.
Jita kyōei , el bienestar y la prosperidad mutuos.

Según la enseñanza del propio Kanō, lo aprendido mediante el kata y el randori debía trasladarse a la vida cotidiana. El judō podía ser defensa personal, educación física y disciplina mental, pero también una guía para relacionarse con los demás y contribuir al progreso de la comunidad.

De una pequeña sala a una institución nacional

El crecimiento del Kōdōkan obligó a trasladarlo varias veces. Sus diferentes sedes estuvieron en lugares como Fujimi-chō , Shimotomisaka y Suidobashi , antes de establecerse en el actual edificio de Kasuga, en el distrito de Bunkyō.

Cada traslado reflejaba el aumento del número de alumnos y la creciente influencia del judō. Lo que había comenzado en una habitación de un templo se convirtió progresivamente en una institución con salas de entrenamiento, departamentos de enseñanza, archivos, biblioteca, museo y un sistema internacional de grados.

Kanō no fue solamente el fundador del judō. También fue un importante educador, director de la Escuela Normal Superior de Tokio, impulsor de la educación física moderna y, desde 1909, el primer miembro asiático del Comité Olímpico Internacional. La expansión del Kōdōkan estuvo estrechamente vinculada a esa visión pedagógica e internacional.

Los desafíos contra las antiguas escuelas de jūjutsu

La consolidación del Kōdōkan no fue inmediata. Durante sus primeros años, sus practicantes participaron en encuentros y desafíos contra representantes de escuelas tradicionales de jūjutsu. Los buenos resultados obtenidos por alumnos como Shirō Saigō, Tsunejirō Tomita, Yoshitsugu Yamashita y Sakujiro Yokoyama contribuyeron a fortalecer la reputación del nuevo sistema.

No obstante, es necesario introducir una precisión histórica. Muchas narraciones populares presentan un único torneo policial celebrado en 1886 en el que el Kōdōkan habría conseguido trece victorias y dos empates. Las investigaciones más recientes señalan que probablemente se produjeron varios encuentros entre 1885 y 1888 y que los registros disponibles son incompletos. Por ello, resulta más riguroso afirmar que los representantes del Kōdōkan obtuvieron resultados favorables frente a diferentes escuelas de jūjutsu, sin considerar como indiscutible una puntuación concreta.

Esos enfrentamientos tuvieron importancia, pero no explican por sí solos el triunfo del judo. Su expansión se debió también a la capacidad de Kanō para organizar la enseñanza, formar instructores, introducir el judo en centros educativos y presentar su práctica como un sistema moderno de educación.

Un lugar de investigación y encuentro

El Kōdōkan no fue únicamente el centro administrativo del judo. También se convirtió en un espacio de investigación sobre las artes marciales.

Kanō mostraba interés por sistemas de combate diferentes del suyo. Estudió el boxeo occidental, observó otras disciplinas y recibió a practicantes de distintas tradiciones. Existen incluso documentos que demuestran que ya había tenido contacto con representantes del karate de Okinawa antes de conocer personalmente a Funakoshi.

En abril de 1911, por ejemplo, un grupo de jóvenes instructores okinawenses visitó a Kanō. Conversaron con él sobre judo y karate, practicaron técnicas articulares y realizaron una demostración de rompimiento de tablas. Este episodio demuestra que el interés de Kanō por el arte de Okinawa no comenzó repentinamente en 1922.

La llegada de Gichin Funakoshi

En 1922, Gichin Funakoshi viajó desde Okinawa hasta Tokio para participar en una exposición de educación física promovida por el Ministerio de Educación. Su presentación del Tode despertó la atención del público y, especialmente, la de Jigorō Kanō.

Poco después, Kanō lo invitó a realizar una demostración en el Kōdōkan ante numerosos practicantes de judo. Funakoshi pidió la colaboración de Shinkin Gima, un joven okinawense que estudiaba en Tokio y que también tenía experiencia en judo.

La Japan Karate Association dice que la asistencia llenó el dojo y que la demostración fue recibida con enorme interés. Según testimonios posteriores, Funakoshi ejecutó el kata Kūsankū —más tarde conocido en Shotokan como Kankū—, mientras que Gima presentó Naihanchi. También mostraron aplicaciones y respondieron a las preguntas de Kanō y de sus alumnos.

Aquel encuentro no debe interpretarse como una simple exhibición destinada a entretener a los judokas. Funakoshi estaba presentando ante una de las instituciones marciales más prestigiosas de Japón un arte que todavía era visto como una práctica regional procedente de Okinawa.

Kanō, por su parte, no se limitó a observarlo con cortesía. El testimonio de Gima recuerda su entusiasmo, sus preguntas y su interés por comprender cómo funcionaban las técnicas del karate. Un estudio académico sobre la relación de Kanō con otras formas de combate destaca además la importancia del apoyo que prestó a Funakoshi durante aquellos primeros años.

El encuentro que ayudó a cambiar la historia del karate

La visita al Kōdōkan no fue la primera aparición del karate en las islas principales de Japón, ni convirtió por sí sola a Funakoshi en el fundador de una nueva disciplina. Sin embargo, sí representó un momento decisivo.

La aprobación de una figura tan respetada como Jigorō Kanō concedió a Funakoshi una legitimidad difícil de obtener para un maestro okinawense prácticamente desconocido en Tokio. El éxito de la demostración contribuyó a que recibiera nuevas invitaciones y a que numerosas personas le pidieran permanecer en la capital.

Funakoshi había pensado regresar a Okinawa después de cumplir con su compromiso en la exposición. Finalmente comenzó a enseñar en el Meiseijuku, una residencia para estudiantes okinawenses, y publicó ese mismo año su primer libro sobre el arte. En los años siguientes, el karate comenzó a extenderse por las universidades japonesas y a adoptar una estructura educativa más comprensible para la sociedad del Japón continental.

El Kōdōkan no creó el karate de Funakoshi, pero le ofreció algo fundamental: un espacio desde el cual podía ser contemplado, evaluado y reconocido por representantes del budō japonés.

El legado del Kōdōkan

Con el paso de las décadas, el Kōdōkan se convirtió en el centro internacional del judo. Desde allí se investigaron y preservaron sus kata, se formaron instructores y se registraron grados de practicantes procedentes de numerosos países.

En 1964, el judo fue incorporado al programa olímpico durante los Juegos de Tokio. Para entonces, la pequeña escuela fundada por Kanō en 1882 había dado origen a una disciplina practicada en todo el mundo. Sin embargo, su legado más profundo no reside únicamente en la competición. El Kōdōkan continúa representando la idea de que una práctica marcial puede convertirse en un camino de educación, responsabilidad y mejoramiento personal.

También por eso la visita de Funakoshi resulta tan significativa. En aquel dojo se encontraron dos hombres que, desde tradiciones diferentes, compartían una misma convicción: las artes marciales debían servir para algo más que derrotar a otra persona.

El día en que Funakoshi entró en el Kōdōkan

Los documentos históricos nos permiten conocer los hechos fundamentales: la invitación de Kanō, la presencia de Shinkin Gima, los kata ejecutados y la favorable recepción de los asistentes. Pero los documentos no siempre pueden transmitir el peso humano de aquel momento.

¿Qué pudo sentir Funakoshi al entrar en la institución marcial más prestigiosa de Tokio? ¿Era consciente de que aquella demostración podía decidir el futuro del karate en Japón? ¿Cómo contemplaría Kanō a aquel maestro okinawense que presentaba un sistema basado en golpes, patadas, desplazamientos y kata desconocidos para la mayoría de los presentes?

En mi novela histórica Walking Upright, reconstruyo aquel día desde la mirada de Gichin Funakoshi: su llegada al Kōdōkan, el encuentro con Jigorō Kanō, la tensión previa a la demostración y el instante en que el karate de Okinawa fue presentado ante algunos de los hombres más influyentes del budō japonés.

La historia nos dice que Funakoshi entró allí como invitado. La novela intenta mostrar por qué salió convertido en el portador de una misión que ya no le permitiría regresar a la vida que había dejado en Okinawa.

CAMINAR ERGUIDO (la novela)

En mi novela hablo del momento en que GIchin Funakoshi va a realizar la demostración en el Kodokan. Caminar erguido es la primera novela de la trilogía del mismo nombre.

A NOVEL INSPIRED BY TRUE EVENTS · PUBLISHED

Walking Upright

Karate-Dō · The story of Gichin Funakoshi

Walking Upright Trilogy - Book 1 .

YEAR

2025

DOWNLOAD PDF SAMPLE ↓

PAPERBACK · HARDCOVER · KINDLE eBOOK

FORMATS

PAGES

+620

LANGUAGES

AVAILABLE IN

Bloque paramétrico - Caso #001

Wed, 05 Aug 2026 16:03:06 GMT

BLOQUE paramétrico - Caso 1

Los Custom Blocks de ARES Commander permiten crear elementos inteligentes cuyo tamaño, posición o geometría pueden modificarse mediante controles, parámetros y acciones. Lo interesante es que la lógica de creación es prácticamente la misma que se utiliza con los bloques dinámicos de AutoCAD . Por eso, aprender este procedimiento nos permite trabajar en ambas plataformas.

Nota: Custom Blocks es el nombre que reciben los bloques paramétricos en ARES Commander y DraftSight , mientras que en AutoCAD se denominan Dynamic Blocks (Bloques dinámicos). Los pasos explicados en este tutorial para crear un Custom Block paramétrico en ARES Commander son esencialmente los mismos que se siguen en AutoCAD para crear un Dynamic Block .

En este ejemplo vamos a crear una puerta corredera de aluminio de dos hojas, cuyo ancho y alto podrán modificarse directamente mediante grips o desde la paleta de propiedades.

1. Crear el bloque base

Para crear un bloque inteligente, primero necesitamos crear un bloque convencional.

Comenzamos dibujando los elementos que representan una puerta corredera de dos hojas: el marco, las hojas, las líneas centrales y las flechas que indican el movimiento de apertura. Para ello contamos con funciones básicas como líneas, polilíneas, rectangulos, recortar, extender, etc. No hay que olvidar de revisar las unidades del dibujo. Esto es muy importante.

2. Agregar los parámetros de ancho y alto

Añadimos dos parámetros lineales:

Uno para controlar el ancho de la puerta.
Otro para controlar su altura.

Es recomendable asignar nombres claros a estos parámetros, como Ancho y Alto . De esta manera, podremos identificarlos fácilmente en la paleta de propiedades e introducir valores exactos cuando sea necesario.

Si prestan atención elegimos el elemento llamado "LINEAR", y establecemos que solo tenga un grips, manteniendo así un lado fijo. Presten atención al vídeo.

Una vez terminada la geometría, creamos el bloque y accedemos al editor de Bloques.

Al crear el bloque asignamos un nombre, descripción, además de punto de inserción, evidentemente seleccionar todos los elementos que pertenecen al bloque, y no olvidar de asignar las unidades. Así, cuando utilicemos este bloque en otro dibujo que contenga otro sistema de unidades se escalará automáticamente.

VIDEO 1

VIDEO 2 - Crear el bloque (de momento bloque simple)

Una vez creado el bloque debemos editarlo. Podemos entrar directamente al editor de bloques si habilitamos la casilla "EDIT IN BLOCK EDITOR", o simplemente hacemos doble clic en él, una vez creado.

El elemento LINEAR por si sólo no hace nada. Simplemente indica la existencia de un vector que servirá para indicar una o más acciones. Puede no tener ningún grips, para acciones anidadas, o contener uno o dos grips, en el caso por ejemplo de querer estirar un elemento en ambas direcciones. En este ejemplo solo usaremos un grip.

VIDEO 3

3. Configurar la acción Stretch

Existen muchas posibilidades para añadir inteligencia a un bloque, pero comenzaremos con una operación sencilla: Stretch .

Stretch está en el desplegable ACTIVITIES (dentro del editor de bloques) (ver vídeo).

Al seleccionar esta actividad hay que realizar una serie de pasos, que implica familiarizarse con la línea de comandos donde se van solicitando acciones.

Primero seleccionar el elemento "LINEAR" que agregamos antes. Como este elemento tiene dos extremos hay que indicar donde lo queremos, por defecto como solo activamos un grip si pulsamos enter lo indicara correctamente.

A continuación, debemos definir:

El área de la geometría que será afectada por el stretch ( ver vídeo).
Los elementos que participarán en la acción del stretch (ver vídeo).

Repetimos el mismo procedimiento para el ancho y para la altura. (ver vídeo).

Las actividades asociadas a un elemento se manifiestan con un ícono. Si se asignan más actividades se hará una lista de todas ellas a través de diferentes íconos uno al lado de otra. Cada actividad puede tener un nombre asociado, para que sea más fácil recordar que hace cada una (ver vídeo).

Después de guardar los cambios, podemos probar el bloque (ver vídeo). El ancho y el alto ya se modifican correctamente, aunque todavía debemos mejorar el comportamiento de algunos elementos.

Aprovechamos para ver que se puede editar le valor directamende desde la paleta de propiedades y gracias a haber asignado un nombre propio (altura y anchura) resulta muy fácil modificarlos.

Sin embargo vemos que otros elementos como el parante medio y las flechas no se han movido del lugar, así que vamos a mejorar este aspecto.

Nota: La opción RESET BLOCK que aparece al pulsar el botón derecho sobre un bloque seleccionado, simplemente vuelve a su forma original antes de hacer los cambios con los grips. Cada instancia de bloque es independiente.

4. Mantener centradas las flechas

Al modificar el ancho de la puerta, las flechas que indican la apertura también deberían desplazarse para permanecer siempre en el centro. Para conseguirlo podemos usar más de una solución (por ejemplo Stretch, pero generaría confusión el procedimiento por eso vamos a utilizar Move que será más fácil entenderlo).

En este caso utilizaremos la actividad Move asociado al grip que desplaza en horizontal. Necesitamos que el mismo grip realiza dos acciones a la vez, stretch (configurado antes y move) (ver vídeo).

El proceso es el siguiente.

Seleccionamos la actividad MOVE
Seleccionamos el elemento (en este caso el parámetro que modifica en horizontal)
Pulsamos ENTER para que se agregue el punto de la acción en el mismo lugar del grip existente.
Seleccionamos los elementos que deberían moverse (en este caso las dos flechas)

VIDEO 4

¿Has visto el vídeo? Tenemos un problema. Si movemos el grip 100 unidades, las flechas se mueven 100 unidades. Y necesitamos que se muevan el 50% de cualquier distancia.

Esto tiene una solución sencilla.

La solución se encuentra en las propiedades de la actividad Move, que podemos ver simplemente seleccionando la actividad sobre el ícono correspondiente.

VIDEO 5

En las propiedades de la actividad MOVE podemos hacer pequeños ajustes. ¿Es importante el nombre? cuando tengas muchas actividades MOVE se llamarán Move1, Move2, Move3 y te será dificil reconocerlas. Es mas fácil si agregas un nombre que te ayude a reconocerla. A veces no es necesario, es verdad, pero en una empresa donde se crea contenido que otros pueden reutilizar es mejor ser muy estrictos en los detalles.

El parámetro que si es importante y que debes recordar es DISTANCE MULTIPLIER porque aparece en muchas actividades y resuelve muchos de los problemas con los que vas a encontrar. Aqui es donde le tenemos que cambiar el valor a 0.50 . De esta manera si el grip se mueve 100 unidades, esta actividad se moverá un 50% menos, ya que hemos puesto un factor de multiplicación de 0.50. Así permanecerán siempre centradas respecto al ancho total de la puerta.

Probamos nuevamente el bloque y ahora el comportamiento de las flechas es el esperado.

5. Aplicar la misma lógica en altura

Podemos repetir este procedimiento para la altura. En algunos bloques que representan puertas como éstas, las flechas pueden permanecer a una distancia fija respecto a la base. Sin embargo, en este ejemplo queremos que también se mantengan centradas verticalmente. Por eso, añadimos otra acción Move asociada al parámetro de altura y configuramos igualmente un multiplicador de distancia de 0.50 .

Al modificar la altura de la puerta, las flechas se desplazarán ahora la mitad del recorrido realizado por el grip, tanto en un sentido como en el otro.

VIDEO 6

6. Ajustar la parte central de la puerta

Todavía debemos configurar correctamente la parte central de la puerta, la zona del parante me refiero.

En este caso, no conviene desplazarla mediante una acción Move ya partes de las entidades que deben estirarse. Por ello es preferible utilizar otra acción Stretch , ya que necesitamos que la geometría se adapte al nuevo tamaño del bloque. ¿Podríamos haber utilizado el primer Stretch? La respuesta es no, porque como ocurre con las fechas solo se pueden mover al 50% de la distancia aplicada con el grip.

Seleccionamos el área correspondiente y los elementos que deben estirarse. Presten atención a que selecciono algunas entidades con selcción "window" y otras con "crossing", pueden probar usar la que deseen y ver el resultado.

Despues de asignada la actividad, podemos seleccionarla y en las propiedades modificar el fector de multiplicador a 0.50 por lo que explique antes.

La razón es la misma: la parte central debe modificarse solamente la mitad de la distancia recorrida por el grip para conservar su posición y proporción dentro de la puerta.

Resultado final

El bloque paramétrico ya está resuelto.

Ahora podemos modificar su ancho y su altura utilizando los grips o introduciendo valores exactos desde la paleta de propiedades. Las flechas permanecen centradas y la geometría interior se adapta correctamente a las nuevas dimensiones.

Este ejemplo es sencillo, pero muestra una de las ideas más importantes al trabajar con bloques inteligentes: una misma modificación puede activar varias acciones al mismo tiempo .

Al mover un grip podemos:

Estirar una parte de la geometría.
Desplazar otros elementos.
Aplicar diferentes multiplicadores de distancia.
Mantener componentes centrados o alineados.

Los mismos pasos y la misma lógica pueden utilizarse para crear un bloque dinámico en AutoCAD. Además, los bloques dinámicos creados en AutoCAD pueden utilizarse en ARES Commander, lo que facilita el trabajo entre ambas plataformas.

A partir de este principio podemos desarrollar ventanas, puertas, mobiliario, perfiles, detalles constructivos y muchos otros elementos CAD capaces de adaptarse automáticamente a diferentes medidas y situaciones.

También se pueden aplicar distancias mínimas y máximas, incluso incrementos específicos para que crezca cada 5 cm, o bien, para elegir de una lista variantes de 120, 130 y 140 en caso que un fabricante solo haga estas opciones, además de múltiples otras posibilidades.

No tienes ARES Commander, Draftsight o AutoCAD. No te preocupes, puedes descargar de manera gratuita ARES Commander y hacer las pruebas aquí. Si ya eres usuario de AutoCAD y nunca habías probado ARES Commander antes, no te preocupes, casi no te darás cuenta de la diferencia.

https://www.graebert.com/cad-software/download/ares-commander/

VIDEO 8

VIDEO 7

Dentro, encontraremos las funciones que nos permiten asignar cierta inteligencia. Por cierto, es la misma idea que está dentras de un programa como Revit para crear una familia paramétrica.

The Story of Gigō Funakoshi: Karate as Reconstruction

Sun, 02 Aug 2026 08:48:26 GMT

Karate as Personal Reconstruction

In Walking Upright , the first novel in the trilogy, I experiment with telling a story across two different timelines. The narrative present is set in 1945, after the bombing of Tokyo. From within that devastated world, the parallel chapters begin to reconstruct the past. The present of 1945 helps the reader travel backwards in order to understand how everything came to that point. Because that present is not our own either: it too must be discovered, interpreted, and understood.

In this way, the novel explores some of the most important moments in the life of Gichin Funakoshi. Some are historically documented. Others belong to stories passed down through generations, to the memories of his students, or to the legends that eventually grew around his figure. Still others belong to fiction—not to replace history, but to try to narrate what probably happened, even though we can no longer know exactly how it occurred.

The second book, Bushi: The Guardian of Shuri, dedicated to Matsumura Sōkon, was born from the same idea.

In this case, the journey takes us to a much less thoroughly documented Okinawa—a world in which history, oral tradition, and legend are constantly intertwined. This lack of certainty makes it possible to work with the surviving stories and construct a narrative about the final years of the Ryūkyū Kingdom.

Through Sakugawa and Matsumura Sōkon, the reader can observe how certain combat practices were transmitted, transformed, and adapted until Tōde eventually became one of the foundations of what, over time, would come to be known as Karate-dō.

And then we arrive at the third book: the story of Gigō Funakoshi.

It is important to make one thing clear from the beginning: Gigō did not create the Shōtōkan style. Neither did his father.

These novels are not about the “Shōtōkan style.” They are about real people who participated in the modernisation of karate and who were involved in the early stages of a much broader transformation.

When I speak of modernisation, I mean a process that began approximately a century ago. I am referring to what we now commonly consider traditional karate, not to its later development as a competitive sport.

Nevertheless, many of the questions that arose during that transformation remain open. Definitive answers do not always exist, but understanding the context in which those questions first appeared can help us better comprehend the karate that has reached us today.

A different novel

The novel about Gigō is different from the previous books in the trilogy.

The story begins from the perspective of a child who grows while trying to understand the world around him. First, he discovers his own body: its weaknesses, its limitations, and the illness that threatens to shorten his life. Later, he begins to understand that this body can also be trained, educated, and transformed.

Gigō first uses Tōde, and later karate, as a form of self-reconstruction.

Perhaps also as a cure.

Or perhaps simply as a path that might allow him to prolong his life for as long as possible, beyond what the doctors had predicted for him.

His relationship with karate does not arise solely from a desire to learn how to fight. It is born from the need to change himself—to strengthen a fragile body and find a discipline that will allow him to keep moving forward when illness seems to have already decided his fate.

And perhaps this story will feel familiar to many readers.

How many of you began practising karate because a doctor, a teacher, or your own parents thought it might help you?

Children who could never remain still.

Those who felt shy or insecure.

Those who suffered bullying.

Those who found it difficult to relate to other people.

Those who could never find their place in team sports.

Does any of this sound familiar?

Karate has always been this as well. Not merely a form of combat, but a tool for learning how to inhabit one’s own body, control fear, relate to others, and build a stronger version of oneself.

The story of Gigō Funakoshi is one of those stories.

The story of a child who received a diagnosis but refused to accept that it should completely determine who he would become.

The story of someone who transformed his fragility into the starting point of a profound transformation.

The story of a man who may not have defeated his illness, but who managed to live longer, create more, and leave a far deeper mark than anyone could have imagined.

I believe you are going to enjoy this novel. I am convinced of it.

I wrote the previous two novels in order to reach this story—a story much closer to all of us than you might imagine, one that goes beyond the particular style of karate you practise. It even goes beyond the martial art you practise.

Many martial arts today have been influenced, directly or indirectly, by what happened at this particular place and moment in history.

Oss.

La historia de Gigō Funakoshi: el karate como reconstrucción

Sun, 02 Aug 2026 08:17:37 GMT

el karate como reconstrucción personal

En Caminar Erguido , la primera novela de la trilogía, juego a contar una historia en dos tiempos.

El presente narrativo se sitúa en 1945, después de los bombardeos de Tokio. Desde ese mundo destruido, los capítulos paralelos comienzan a reconstruir el pasado. El presente de 1945 ayuda al lector a viajar hacia atrás para comprender cómo se llegó hasta allí. Porque ese presente tampoco es el nuestro: también necesita ser descubierto, interpretado y comprendido.

De este modo, la novela recorre algunos de los momentos más importantes de la vida de Gichin Funakoshi. Algunos están documentados. Otros pertenecen a las historias transmitidas durante generaciones, a los recuerdos de sus alumnos o a las leyendas que terminaron rodeando su figura. Y otros forman parte de la ficción, no para sustituir a la historia, sino para intentar narrar aquello que probablemente sucedió, aunque ya no podamos saber exactamente cómo.

Con esa misma idea nació el segundo libro "Bushi. El guardián de Shuri", dedicado a Matsumura Sōkon.

En este caso, el viaje nos conduce a una Okinawa mucho menos documentada. Un territorio en el que la historia, la tradición oral y la leyenda se entrelazan constantemente. Esa falta de certezas permite jugar con los relatos conocidos para construir una narración sobre los últimos tiempos del Reino de Ryūkyū. A través de Sakugawa y Matsumura Sōkon, el lector puede observar cómo determinadas prácticas de combate fueron transmitiéndose, transformándose y adaptándose hasta que el Tōde terminó convirtiéndose en una de las bases de aquello que, con el paso del tiempo, llegaría a llamarse Karate-dō .

Y entonces llegamos al tercer libro: la historia de Gigō Funakoshi.

Conviene aclararlo desde el principio: Gigō no creó el estilo Shōtōkan. Su padre tampoco.

Estas novelas no tratan sobre el «estilo Shōtōkan». Tratan sobre personas reales que participaron en la modernización del karate y que formaron parte de las primeras etapas de una transformación mucho más amplia.

Cuando hablo de modernización, hablo de un proceso iniciado hace aproximadamente un siglo. Hablo de aquello que hoy solemos considerar karate tradicional , no de su posterior desarrollo como deporte de competición. Sin embargo, muchas de las preguntas que surgieron durante aquella transformación continúan abiertas. No siempre existen respuestas definitivas, pero conocer el contexto en el que aparecieron nos ayuda a comprender mejor el karate que ha llegado hasta nosotros.

Una novela diferente

La novela sobre Gigō es distinta a las anteriores de la misma trilogía.

La historia comienza desde el punto de vista de un niño que va creciendo mientras intenta comprender el mundo que lo rodea. Primero descubre su propio cuerpo: sus debilidades, sus límites y la enfermedad que amenaza con acortar su vida. Después comienza a descubrir que ese cuerpo también puede ser trabajado, educado y transformado.

Gigō utiliza primero el Tōde y, más tarde, el karate como una forma de autorreconstrucción.

Quizá también como una cura.

O tal vez simplemente como un camino que le permita prolongar su vida todo lo posible, más allá de aquello que los médicos habían pronosticado para él.

Su relación con el karate no nace únicamente del deseo de aprender a luchar. Nace de la necesidad de cambiarse a sí mismo. De fortalecer un cuerpo frágil. De encontrar una disciplina que le permita avanzar cuando la enfermedad parece haber decidido su destino de antemano.

Y es posible que esta historia resulte familiar a muchos lectores.

¿Cuántos de ustedes comenzaron a practicar karate porque un médico, un maestro o sus propios padres pensaron que podía ayudarlos?

A los niños inquietos.

A quienes sentían vergüenza o inseguridad.

A quienes sufrían acoso.

A quienes tenían dificultades para relacionarse con los demás.

A quienes nunca encontraban su lugar en los deportes de equipo.

¿Les resulta conocido?

El karate también ha sido siempre eso. No solamente una forma de combate, sino una herramienta para aprender a habitar el propio cuerpo, controlar el miedo, relacionarse con los demás y construir una versión más fuerte de uno mismo.

La historia de Gigō Funakoshi es una de esas historias.

La historia de un niño que recibió un diagnóstico, pero se negó a aceptar que ese diagnóstico debía decidir por completo quién sería.

La historia de alguien que convirtió su fragilidad en el punto de partida de una transformación.

La historia de un hombre que quizá no logró vencer a la enfermedad, pero que consiguió vivir más, crear más y dejar una huella mucho más profunda de lo que nadie había imaginado.

Creo que esta novela les va a gustar. Estoy convencido de ello. He escrito las dos anteriores para llegar a esta historia, que es mucho más cercana a todos de los que pueden imaginar, y que va más allá del estilo de karate que practique. Incluso del arte marcial que practique. Aunque muchos, hoy día, están inspirados de manera directa o indirecta por lo que pasó en este lugar y momento de la historia.

Oss.

Die Genealogie von Gichin Funakoshi

Wed, 22 Jul 2026 14:38:06 GMT

Genealogy of the Funakoshi Family

Die fehlenden Söhne: die genealogische Lücke in der Familie Funakoshi

Jeder, der sich mit der Geschichte des modernen Karate beschäftigt, begegnet demselben bekannten Dreieck: Gichin Funakoshi, dem okinawanischen Schullehrer, der die Kunst nach Tokio brachte; Gigō, seinem dritten Sohn, dem früh verstorbenen Genie, das dem Karate größere Beweglichkeit und Distanz verlieh, bevor es im Alter von 39 Jahren an Tuberkulose starb; und dem Shōtōkan, dem Dōjō, das der eine errichtete und das Feuer des Krieges zerstörte.

Es ist eine gut erzählte Geschichte, mit gesicherten Daten und Quellen, die einander scheinbar lückenlos bestätigen. Doch sobald man versucht, den vollständigen Stammbaum der Familie Funakoshi zu rekonstruieren, beginnt diese gut erzählte Geschichte in den Händen zu zerfallen.

Was niemand bestreitet

Beginnen wir mit dem gesicherten Boden, denn den gibt es durchaus, und zwar mehr, als man zunächst vermuten könnte.

Gichin Funakoshi (1868–1957) war mit einer Frau namens Gozei verheiratet. Das ist keineswegs eine unbedeutende Einzelheit: In der spanischsprachigen Karatewelt kursieren seit Jahren die Variante „Machi“ und andere Namensformen. Die japanische Wikipedia formuliert es jedoch unmissverständlich:

妻、ゴゼイとの間に３男２女がある

„Mit seiner Ehefrau Gozei hatte er drei Söhne und zwei Töchter.“

Damit ist bereits der erste Hinweis auf das folgende Problem gegeben: Die maßgebliche japanischsprachige Quelle spricht von drei Söhnen. Diese Zahl sollte man sich merken.

Zwei dieser Söhne sind bis in die administrativen Einzelheiten hinein dokumentiert.

Giei, auch Yoshihide genannt, war der älteste Sohn. Er wurde 1900 geboren und starb 1961. Diese Angaben stammen nicht aus einem Amateurblog, sondern von der offiziellen Website des Shōtōkai, jener Organisation, die Funakoshi selbst gründete und deren Präsident Giei nach dem Tod seines Vaters in der zweiten Generation wurde. Wenn die Nachfolgeorganisation auf ihrer eigenen Website konkrete Lebensdaten veröffentlicht, verdienen diese ernsthafte Beachtung.

Gigō, auch Yoshitaka genannt, war der dritte und bei Weitem berühmteste Sohn. Er wurde am 21. Oktober 1906 geboren und starb am 24. November 1945. Diese Daten werden unabhängig voneinander durch die japanische und die englische Wikipedia, Wikidata und sogar durch neuere Projekte wie Grokipedia bestätigt. Dass vier voneinander unabhängige Quellen in denselben Angaben übereinstimmen, ist in der alltäglichen Geschichtsforschung beinahe ein Luxus.

Ebenso gesichert ist, dass er mit einer Frau namens Fujiko verheiratet war und einen Sohn namens Yukio hatte. Yukios Existenz wird durch die Bildbeschreibung einer Aufnahme von der Beerdigung im Jahr 1945 bestätigt, auf der er „das Porträt seines Vaters in den Händen hält“.

Nebenbei zwingt dies dazu, eine in bestimmten Kreisen verbreitete Überlieferung zu korrigieren, der zufolge Gigōs Ehefrau „Teruko“ geheißen habe: Es findet sich keine Quelle, die diesen Namen stützt.

Bis hierher passt alles zusammen. Das Problem beginnt in der Lücke zwischen Giei, dem ersten Sohn, und Gigō, dem dritten.

Der fehlende Sohn – oder die überzähligen Söhne

Wenn Giei der erste und Gigō der dritte Sohn war, verlangt bereits die einfachste Arithmetik nach einem zweiten Sohn irgendwo zwischen beiden. Genau an diesem Punkt beginnen die Quellen jedoch, einander nicht mehr zu bestätigen, sondern sich zu widersprechen.

Ein spanischsprachiger Fachblog, der offenbar auf angesehene englischsprachige Autoren wie Graham Noble und Steve Cattell zurückgreift oder deren Arbeiten übersetzt – beide gelten als ernsthafte Historiker des frühen Karate –, bietet folgende Genealogie:

„Im Jahr 1900 wurde sein erster Sohn Giei geboren … und 1901 kam eine Tochter namens Tsuruko, auch Oto genannt, zur Welt. Das Ehepaar Funakoshi sollte noch drei weitere Söhne bekommen: Giyu, auch Yoshio genannt; Gigo oder Giko, auch Yoshitaka genannt; und Giketsu.“

Dabei fällt ein Detail auf, das zugleich ein weiteres, kleineres Rätsel lösen könnte. Seit Jahren kursiert die Vorstellung, Funakoshi habe zwei Töchter namens „Tsuru“ und „Uto“ gehabt, wobei diese Namen in einigen Amateurforen getrennt aufgeführt werden. Die genannte Quelle legt jedoch nahe, dass es sich um ein und dieselbe Person handelte: Tsuruko, deren Name alternativ als Oto gelesen oder wiedergegeben wurde.

Das wäre ein klassischer Fall eines Kindes, das durch unterschiedliche Transliterationen versehentlich verdoppelt wurde – genau jene Art von Fehler, die entsteht, wenn eine Biografie von Okinawa nach Tokio, von Tokio in die Vereinigten Staaten und von dort in spanischsprachige Internetforen gelangt, wobei jede Station eine weitere Schicht an Ungenauigkeit hinzufügt.

Doch dieselbe Quelle, die scheinbar das Problem der Tochter löst, schafft ein neues Problem bei den Söhnen: Sie nennt vier Söhne statt drei – Giei, Giyu, Gigō und Giketsu.

Ein Diskussionsbeitrag aus dem Jahr 2009 im Fachforum e-budo.com erhöht die Gesamtzahl sogar auf „sechs Kinder“: vier Söhne und zwei Töchter, wobei Tsuru und Uto wiederum als zwei verschiedene Personen behandelt werden.

Der Verfasser stellt diese Angabe allerdings nicht als gesicherte Tatsache dar, sondern als Teil einer offenen Untersuchung. „I will keep digging!“, schreibt er – „Ich werde weiterforschen!“

Er spekuliert, dass die beiden unbekannten Söhne Giyu und Giketsu möglicherweise 1945 in der Schlacht um Okinawa ums Leben kamen, ohne jemals nach Japan auf die Hauptinseln gezogen zu sein. Das würde erklären, warum keine Quelle, die sich auf die Geschichte des Karate in Tokio konzentriert, einen von ihnen namentlich erwähnt.

Damit liegen drei miteinander unvereinbare Versionen vor:

Drei Söhne und zwei Töchter, laut der japanischen Wikipedia, wobei der zweite Sohn nicht namentlich genannt wird.
Vier Söhne und eine Tochter, laut dem spanischsprachigen Blog, der die scheinbare Verdoppelung der Tochter auflöst.
Vier Söhne und zwei Töchter, laut dem Fachforum, wobei diese Angabe ausdrücklich als spekulativ bezeichnet wird.

Keine dieser Quellen nennt ein Geburtsdatum, ein Todesdatum oder auch nur eine einzige überprüfbare Begebenheit zu „Giyu“ oder „Giketsu“. Sie existieren lediglich als Namen, die durch Genealogien aus zweiter Hand wandern, ohne einen erhaltenen dokumentarischen Anker.

Warum dies keine bloße antiquarische Besessenheit ist

Man könnte annehmen, dass die Suche nach dem Namen eines Sohnes, der vielleicht nicht einmal existierte, nur für besonders obsessive Forscher von Interesse sei. Doch der Fall Funakoshi vermittelt eine allgemeinere Lektion darüber, wie das historische Gedächtnis von Menschen entsteht, die außerhalb ihres ursprünglichen Umfeldes berühmt wurden – und wie dieses Gedächtnis verloren geht.

Alles, was wir mit Sicherheit über die Familie Funakoshi wissen, stammt aus einer einzigen Überlieferungskette: von jenen Familienmitgliedern, die Teil der dokumentierten Geschichte des Karate in Tokio wurden.

Giei blieb in Erinnerung, weil er Präsident des Shōtōkai wurde. Gigō blieb in Erinnerung, weil er die Karatetechnik veränderte und später Gegenstand eines Gedenkbandes wurde. Beide sind bekannt, weil eine Institution mit einem unmittelbaren Interesse an der Bewahrung ihrer Erinnerung – der Shōtōkai selbst – nach 1945 weiterbestand und weiterhin über sie schrieb.

Ein Sohn, der nicht Teil dieser Überlieferungskette wurde – weil er jung starb, in Okinawa blieb, kein Karate praktizierte oder das Jahr 1945 nicht überlebte –, hätte schlicht niemanden gehabt, der seine Erinnerung schriftlich bewahrte.

Es ist nicht unbedingt so, dass die Geschichte ihn aktiv vergessen hätte. Möglicherweise gelangte er nie in jenes System, das überhaupt historische Dokumente hervorbringt.

Zwischen April und Juni 1945 war Okinawa genau der Ort, an dem ein Mensch auf diese Weise besonders leicht verschwinden konnte. Die Schlacht, die die Insel verwüstete, tötete nach den häufig genannten Schätzungen etwa ein Drittel der Zivilbevölkerung. Mit diesen Menschen gingen auch Archive, Familienregister, Grabsteine und ganze Bestände persönlicher Erinnerungen verloren.

Sollten zwei Söhne Funakoshis dort gestorben sein, ohne jemals eine Rolle im Karate auf dem japanischen Festland gespielt zu haben, wäre es vollkommen plausibel, dass heute nicht einmal ein einziges Lebensdatum von ihnen erhalten ist.

Mit anderen Worten: Die Lücke in der Genealogie der Familie Funakoshi ist möglicherweise nicht nur das Ergebnis mangelhafter Forschung. Wahrscheinlich handelt es sich um eine echte Narbe der Geschichte – um den Leerraum, den ein Krieg hinterließ, der nicht nur Leben vernichtete, sondern auch die Möglichkeit, dass diese Leben jemals dokumentiert würden.

Eine kleinere Frage, die sich klären ließ – und warum das wichtig ist

Inmitten dieser größeren Unsicherheit ließ sich eine kleinere Frage mit einiger Klarheit beantworten: das genaue Datum der Zerstörung des Shōtōkan-Dōjō während der Luftangriffe von 1945.

Zwei Versionen waren im Umlauf. Die eine setzte die Zerstörung in den März, die andere in den April. Die miteinander verglichenen Hinweise – der dokumentierte Umzug der Familie nach Koshikawa „im Frühjahr 1945“ sowie eine Quelle, die den Luftangriff ausdrücklich auf den 29. April datiert – sprechen recht deutlich für den April.

Dies ist ein kleines, aber lehrreiches Beispiel für den Unterschied zwischen zwei Arten von Lücken, die bei der Erforschung weniger bekannter historischer Persönlichkeiten auftreten – oder, wie in diesem Fall, bei der Erforschung der Angehörigen einer bedeutenden historischen Persönlichkeit.

Manche Lücken lassen sich durch weitere Recherche schließen, weil die Information irgendwo in einem Archiv erhalten ist und lediglich gefunden und richtig mit anderen Angaben abgeglichen werden muss.

Andere werden sich möglicherweise niemals schließen lassen, weil das Dokument, das die Frage entscheiden könnte – sofern es jemals existierte –, zusammen mit den Menschen verschwand, die darin beschrieben wurden.

Das Buch, das die Antwort vermutlich enthält – und das fast niemand ohne Weiteres lesen kann

Ein letzter Punkt verdient Erwähnung, weil er die Grenzen offener Internetrecherche im Jahr 2026 besonders deutlich zeigt.

Es existiert ein Buch mit dem Titel Funakoshi Yoshitaka Tsuitōroku (船越義豪追悼録), ein vom Shōtōkai im Dezember 2004 herausgegebener Gedenkband anlässlich des sechzigsten Jahrestages von Gigōs Tod. Das Werk ist sowohl in der Japanischen Nationalen Parlamentsbibliothek als auch in der wissenschaftlichen Datenbank CiNii ordnungsgemäß katalogisiert.

Mit großer Wahrscheinlichkeit ist es genau jenes Dokument, das eine vollständige Familiengenealogie enthalten könnte, zusammengestellt von der Organisation, die nicht nur das größte Interesse an ihrer Bewahrung hatte, sondern auch den unmittelbarsten Zugang zu überlebenden Familienangehörigen besaß, von denen im Jahr 2004 noch einige lebten.

Gleichzeitig handelt es sich jedoch um eine Publikation mit eingeschränkter Verbreitung – hi-baihin, also „nicht zum Verkauf bestimmt“ –, die für die Mitglieder einer Vereinigung und nicht für die allgemeine Öffentlichkeit produziert wurde. In keinem frei zugänglichen Repositorium liegt eine digitalisierte Ausgabe vor.

Das Buch existiert. Es ist ordnungsgemäß katalogisiert. Doch wer keinen direkten Kontakt zum Shōtōkai besitzt und nicht persönlich eine Bibliothek in Japan aufsuchen kann, hat gegenwärtig kaum eine Möglichkeit, seinen Inhalt zu lesen.

So endet die Genealogie einer der am häufigsten erwähnten Familien in der Geschichte der Kampfkünste des 20. Jahrhunderts im Jahr 2026 genau dort, wo so viele familiengeschichtliche Mikrostudien enden: in einem Buch, das in einem Regal in Tokio steht und darauf wartet, dass jemand mit genügend Geduld – und der richtigen Reise – herausfindet, ob der zweite Sohn Gichin Funakoshis jemals einen Namen besaß, den jemand für erwähnenswert hielt.

Das Familienwappen der Familie Funakoshi

KI-generierte Rekonstruktion von Milton Chanes, basierend auf einem von Sensei Salvador Herraiz geteilten Bild.

The Genealogy of Gichin Funakoshi

Wed, 22 Jul 2026 13:37:05 GMT

Genealogy of the Funakoshi Family

The Missing Sons: The Genealogical Gap in the Funakoshi Family

Everyone who approaches the history of modern karate encounters the same familiar triangle: Gichin Funakoshi, the Okinawan schoolteacher who brought the art to Tokyo; Gigō, his third son, the short-lived genius who gave karate greater mobility and fighting distance before dying of tuberculosis at the age of thirty-nine; and the Shōtōkan, the building one of them created and the fires of war destroyed. It is a well-told story, supported by firm dates and sources that confirm one another without apparent contradiction. And then one tries to reconstruct the complete Funakoshi family tree, and that well-told story begins to fall apart in one’s hands.

What no one disputes

Let us begin with the firm ground, because it does exist, and there is more of it than might initially appear.

Gichin Funakoshi (1868–1957) married a woman named Gozei. This is not an insignificant detail: for years, the name “Machi,” along with other variations, has circulated within the Spanish-speaking karate world. The Japanese-language Wikipedia, however, states it unambiguously:

妻、ゴゼイとの間に３男２女がある

“With his wife Gozei, he had three sons and two daughters.”

That sentence already contains the first clue to the problem that follows: the most authoritative Japanese-language source says that there were three sons. Keep that number in mind.

Two of those sons are documented down to the administrative details.

Giei, also known as Yoshihide, was the eldest son, born in 1900 and deceased in 1961. This information does not come from an amateur blog. It appears on the official website of the Shōtōkai, the organization founded by Funakoshi himself and later presided over by Giei as its second-generation leader following his father’s death. When the successor institution publishes dates on its own website, those dates deserve serious consideration.

Gigō, also known as Yoshitaka, was the third son and by far the most famous. He was born on 21 October 1906 and died on 24 November 1945. These dates are independently confirmed by the Japanese and English versions of Wikipedia, Wikidata and even more recent projects such as Grokipedia. Four separate sources agreeing on the same information is a luxury in everyday historical research.

It is also firmly established that he married a woman named Fujiko and had a son named Yukio. Yukio’s existence is confirmed by the caption of a photograph taken at the 1945 funeral, in which he is described as “holding his father’s portrait.” Incidentally, this means that a tradition circulating in certain circles, according to which Gigō’s wife was named “Teruko,” must be corrected: no source has been found that supports that name.

Up to this point, everything fits together. The problem begins in the gap between Giei, the first son, and Gigō, the third.

The missing son—or the surplus sons

If Giei was the first son and Gigō the third, the simplest arithmetic demands the existence of a second son somewhere between them. This is where the sources, instead of confirming one another, begin to contradict each other.

A specialist Spanish-language blog—which appears to translate or draw upon respected English-language authors such as Graham Noble and Steve Cattell, both serious historians of early karate—offers the following genealogy:

“In 1900, his first son, Giei, was born… and in 1901 he had a daughter named Tsuruko, also known as Oto. The Funakoshi marriage would later have three more sons: Giyu, also known as Yoshio; Gigo or Giko, also known as Yoshitaka; and Giketsu.”

Notice the detail that may also solve another, smaller mystery. For years, the idea has circulated that Funakoshi had two daughters named “Tsuru” and “Uto,” names that appear separately in some amateur forums. This source suggests that they were actually the same person: Tsuruko, with Oto as an alternative reading or form of her name.

It would be a classic case of a child being accidentally duplicated through transliteration—the sort of error that proliferates when a biography travels from Okinawa to Tokyo, from Tokyo to the United States and from the United States to Spanish-language internet forums, with each stop adding another layer of noise.

Yet the same source that appears to solve the problem of the daughter creates a new one concerning the sons: it gives four sons, not three—Giei, Giyu, Gigō and Giketsu.

A discussion thread published in 2009 on the specialist forum e-budo.com raises the total to “six children”: four sons and two daughters, with Tsuru and Uto once again treated as two separate people. However, the author of the thread presents the matter as an open investigation rather than an established fact. “I will keep digging!” he writes.

He speculates that the two unknown sons, Giyu and Giketsu, may have died during the Battle of Okinawa in 1945 without ever having moved to mainland Japan. This would explain why sources focused on the history of karate in Tokyo never mention either of them by name.

We are therefore left with three incompatible versions:

Three sons and two daughters, according to the Japanese-language Wikipedia, although the second son is not named.
Four sons and one daughter, according to the Spanish-language blog, which resolves the apparent duplication of the daughter.
Four sons and two daughters, according to the specialist forum, although the claim is openly presented as speculative.

None of these sources provides a birth date, a date of death or a single verifiable anecdote concerning either “Giyu” or “Giketsu.” They exist merely as names floating through second-hand genealogies, unsupported by any surviving documentary anchor.

Why this is not merely an antiquarian obsession

One might assume that pursuing the name of a son who may not even have existed is the kind of scholarship that interests only the most obsessive researchers. Yet the Funakoshi case offers a broader lesson about how the historical memory of individuals who became famous outside their original context is created—and how it is lost.

Everything we know with certainty about the Funakoshi family comes through a single chain of transmission: those relatives who entered the recorded history of karate in Tokyo.

Giei is remembered because he became president of the Shōtōkai. Gigō is remembered because he transformed karate technique and later became the subject of a commemorative volume. They are known because an institution with a direct interest in preserving their memory—the Shōtōkai itself—continued to exist after 1945 and continued writing about them.

Any child who did not enter that chain of transmission—because he died young, remained in Okinawa, did not practise karate or failed to survive 1945—would simply have had no one to preserve his memory in writing.

It is not necessarily that history deliberately forgot him. He may never have entered the system that produces historical documents in the first place.

Between April and June 1945, Okinawa was precisely the kind of place where it was easiest for a person to disappear in this manner. The battle that devastated the island killed, according to commonly cited estimates, approximately one third of its civilian population. Along with those lives, archives, family records, gravestones and entire collections of personal memories were also destroyed.

If two of Funakoshi’s sons died there without ever having established themselves in mainland karate, it would be entirely plausible that not even a date survives for either of them.

In other words, the gap in the Funakoshi genealogy may not be merely the result of poor research. It is probably a genuine scar left by history—the void created by a war that destroyed not only lives, but also the very possibility that those lives would ever be recorded.

A smaller question that was resolved—and why it matters

Amid this greater uncertainty, one smaller question did produce a reasonably clear answer: the precise date on which the Shōtōkan dōjō was destroyed during the air raids of 1945.

Two versions had circulated, one placing the destruction in March and the other in April. The combined evidence—the documented relocation of the family to Koshikawa “in the spring of 1945,” together with a source that specifically dates the air raid to 29 April—tips the balance quite clearly in favour of April.

This is a small but instructive example of the difference between the two kinds of gaps that appear when researching lesser-known historical figures—or, in this case, the relatives of major historical figures.

Some gaps can be resolved through further investigation because the information survives somewhere in an archive and simply needs to be located and compared correctly.

Others may never be resolved because the document that could settle the matter—assuming that it ever existed—disappeared along with the people it described.

The book that probably contains the answer—and that almost no one can easily read

One final detail deserves mention because it clearly illustrates the limitations of conducting open online research in 2026.

There is a book titled Funakoshi Yoshitaka Tsuitōroku (船越義豪追悼録), a commemorative volume published by the Shōtōkai in December 2004 to mark the sixtieth anniversary of Gigō’s death. It is formally catalogued by both the National Diet Library of Japan and the academic database CiNii.

It is almost certainly the document most likely to contain a complete family genealogy, compiled by the organization that had both the greatest interest in preserving it and the most direct access to surviving members of the family, some of whom were still alive in 2004.

At the same time, however, it is a restricted-circulation publication—hi-baihin, meaning “not for sale”—produced for members of an association rather than for the general public. It has not been digitized in any open repository.

The book exists. It is properly catalogued. Yet anyone without direct contact with the Shōtōkai, or without the ability to visit a library in Japan in person, cannot currently read what it contains.

And so, in 2026, the genealogy of one of the most frequently cited families in the history of twentieth-century martial arts ends where so much family microhistory ends: inside a book that exists on a shelf in Tokyo, waiting for someone with sufficient patience—and the right journey—to discover whether Gichin Funakoshi’s second son ever had a name that someone thought to record.

The Funakoshi Family Crest

AI-generated recreation by Milton Chanes , based on an image shared by Sensei Salvador Herraiz .

La geneología de Gichin Funakoshi

Wed, 22 Jul 2026 13:04:22 GMT

Geneología de la familia funakoshi

Los hijos que faltan: el agujero genealógico de la familia Funakoshi

Todo el mundo que se acerca a la historia del karate moderno conoce el mismo triángulo: Gichin Funakoshi, el maestro de escuela okinawense que llevó el arte a Tokio; Gigō, su hijo tercero, el genio breve que le puso piernas y distancia al karate antes de morir de tuberculosis a los 39 años; y el Shōtōkan, la casa que uno construyó y el fuego de la guerra destruyó. Es una historia bien contada, con fechas sólidas y fuentes que se confirman unas a otras sin fisuras. Y entonces uno intenta reconstruir el árbol genealógico completo de la familia, y la historia bien contada se deshace en las manos.

Lo que nadie discute

Empecemos por el terreno firme, que también existe y es más de lo que parece.

Gichin Funakoshi (1868–1957) se casó con una mujer llamada Gozei . Esto no es un detalle menor: en el mundo hispanohablante del karate circula durante años la variante "Machi" u otras formas, pero la Wikipedia en japonés lo deja escrito sin ambigüedad —"妻、ゴゼイとの間に３男２女がある", "con su esposa Gozei tuvo tres hijos varones y dos hijas"—. Ahí queda ya sembrada la primera pista del problema que viene: la fuente más autorizada en japonés dice tres varones . Guárdense ese número.

De esos hijos, dos están documentados hasta el detalle administrativo:

Giei (Yoshihide) , el primogénito, nacido en 1900 y muerto en 1961. Esto no lo dice un blog de aficionados: lo dice la propia página oficial del Shōtōkai, la organización que fundó el propio Funakoshi y que Giei llegó a presidir en segunda generación tras la muerte de su padre. Cuando la institución heredera pone fechas en su propia web, hay que creérselas.

Gigō (Yoshitaka) , el tercer hijo, el célebre. Nacido el 21 de octubre de 1906, muerto el 24 de noviembre de 1945. Estas cifras las confirman de manera cruzada la Wikipedia japonesa, la inglesa, Wikidata y hasta creadores más recientes como Grokipedia —cuatro fuentes independientes cuadrando el mismo dato es, en historiografía de andar por casa, un lujo—. Se sabe también, con la misma solidez, que se casó con una mujer llamada Fujiko y tuvo un hijo, Yukio , cuya existencia queda confirmada por la descripción de una fotografía del funeral de 1945 en la que aparece "sujetando el retrato de su padre". Esto, dicho sea de paso, obliga a corregir una tradición difundida en ciertos círculos que llama "Teruko" a la esposa: no hay ninguna fuente que sostenga ese nombre.

Hasta aquí, todo cuadra. El problema empieza en el hueco entre Giei (el primero) y Gigō (el tercero).

El hijo que falta, o los hijos que sobran

Si Giei es el primero y Gigō el tercero, la aritmética más elemental exige un segundo hijo varón en algún punto de en medio. Y aquí es donde las fuentes, en lugar de confirmarse, empiezan a contradecirse.

Un blog especializado en español —que parece traducir a autores anglosajones de referencia como Graham Noble o Steve Cattell, historiadores serios del karate temprano— ofrece esta genealogía: "En 1900 nació su primer hijo, Giei... y en 1901 tuvo una hija que se llamó Tsuruko (Oto). El matrimonio Funakoshi tendría tres hijos varones más: Giyu (Yoshio), Gigo/Giko (Yoshitaka), y Giketsu."

Fíjense en el detalle que resuelve, de paso, otro misterio menor: durante años ha circulado la idea de que Funakoshi tuvo dos hijas, "Tsuru" y "Uto", nombres que aparecen por separado en algunos foros de aficionados. Esta fuente sugiere que es la misma persona: Tsuruko, con una lectura alternativa de su nombre, Oto. Un caso clásico de un hijo duplicado por accidente de transliteración —de esos que proliferan cuando una biografía viaja de Okinawa a Tokio, de Tokio a Estados Unidos, de Estados Unidos a foros de habla hispana, y cada escala añade una capa de ruido—.

Pero esa misma fuente, al resolver el problema de la hija, crea uno nuevo con los hijos: cuatro varones , no tres. Giei, Giyu, Gigō, Giketsu. Y un hilo de un foro especializado de 2009, e-budo.com, redondea la cifra a "seis hijos en total" —los cuatro varones más dos hijas, Tsuru y Uto tratadas ahora sí como personas distintas—, aunque el propio autor del hilo lo presenta como investigación abierta, no como dato cerrado: "I will keep digging!", escribe, y especula que los dos hijos varones desconocidos —Giyu y Giketsu— pudieron morir en la batalla de Okinawa de 1945 sin haber pisado nunca Japón, lo cual explicaría por qué ninguna fuente centrada en la historia del karate en Tokio los menciona jamás por nombre.

Así que tenemos tres versiones incompatibles sobre la mesa:

Tres varones, dos hijas (Wikipedia japonesa, sin nombrar al segundo hijo varón).
Cuatro varones, una hija (blog hispano, con la hija duplicada resuelta).
Cuatro varones, dos hijas (foro especializado, especulativo por su propia admisión).

Ninguna de las tres da fecha de nacimiento, fecha de muerte, ni una sola anécdota verificable de "Giyu" o "Giketsu". Existen como nombres flotando en genealogías de segunda mano, sin ancla documental que los sostenga.

Por qué esto no es un capricho de anticuario

Se podría pensar que perseguir el nombre de un hijo que quizá ni siquiera existió es la clase de erudición que solo interesa a los muy obsesivos. Pero el caso Funakoshi tiene una lección más general sobre cómo se fabrica —y se pierde— la memoria histórica de figuras que se volvieron célebres fuera de su contexto original.

Todo lo que sabemos con solidez sobre la familia Funakoshi proviene de una única correa de transmisión: los que se quedaron en la historia del karate de Tokio . Giei, que presidió el Shōtōkai. Gigō, que revolucionó la técnica y fue objeto de un libro conmemorativo. Son conocidos porque una institución con interés directo en preservar su memoria —el propio Shōtōkai— siguió existiendo después de 1945 y siguió escribiendo sobre ellos.

Cualquier hijo que no entrara en esa correa de transmisión —porque murió joven, porque se quedó en Okinawa, porque no practicó karate, porque no sobrevivió a 1945— simplemente no tiene quien lo recuerde por escrito. No es que la historia lo haya olvidado activamente: es que nunca entró en el circuito que genera documentos. Y Okinawa, entre abril y junio de 1945, fue precisamente el lugar del mundo donde más fácil era desaparecer de esa manera: la batalla que asoló la isla mató, según las cifras que se manejan, a un tercio de la población civil, y con ella se perdieron archivos, registros parroquiales, lápidas, memorias familiares enteras. Si dos hijos de Funakoshi murieron allí sin haber hecho carrera en el karate continental, es perfectamente coherente que hoy no exista de ellos ni una fecha.

Dicho de otro modo: el agujero en la genealogía de los Funakoshi no es (solo) un problema de mala investigación. Es, probablemente, una cicatriz real de la historia —el hueco que deja una guerra que se llevó por delante no solo vidas, sino la capacidad misma de que esas vidas quedaran registradas—.

Un dato menor que sí se resolvió, y por qué importa

En medio de esta incertidumbre mayor, hubo una pregunta menor que sí encontró respuesta clara: la fecha exacta de la destrucción del dōjō Shōtōkan en los bombardeos de 1945. Circulaban dos versiones, marzo y abril; la evidencia cruzada —el traslado documentado de la familia a Koshikawa "en la primavera de 1945" más una fuente que fecha el ataque aéreo específicamente el 29 de abril — inclina la balanza con bastante claridad hacia abril.

Es un ejemplo pequeño pero instructivo de la diferencia entre los dos tipos de laguna que aparecen al investigar a personajes históricos de segunda fila (o, en este caso, de familiares de personajes de primera fila): las que se resuelven con más búsqueda, porque el dato existe en algún archivo y solo hace falta cruzarlo bien; y las que no se resuelven nunca, porque el documento que las zanjaría —si existió— desapareció con las personas a las que describía.

El libro que probablemente lo sabe, y que nadie puede leer fácilmente

Hay un dato final que merece mención, porque ilustra bien los límites de investigar en abierto por internet en pleno 2026. Existe un libro: Funakoshi Yoshitaka tsuitōroku (船越義豪追悼録), un volumen conmemorativo editado por el propio Shōtōkai en diciembre de 2004, en el sexagésimo aniversario de la muerte de Gigō. Está catalogado con toda formalidad en la Biblioteca Nacional de la Dieta de Japón y en el catálogo académico CiNii. Es, casi con certeza, el documento que contendría la genealogía familiar completa, recopilada por la organización que más interés y más acceso directo tenía a los testimonios de la familia, todavía viva en 2004.

Y es, al mismo tiempo, un libro de circulación restringida —hi-baihin, "no está a la venta"—, pensado para los miembros de una asociación, no para el público general, y no digitalizado en ningún repositorio abierto. Existe. Está descrito. Nadie que no se desplace físicamente a una biblioteca en Japón o no tenga contacto directo con el Shōtōkai puede, hoy, leer lo que dice.

Así que la genealogía de una de las familias más citadas en la historia de las artes marciales del siglo XX termina, en 2026, exactamente donde termina tanta microhistoria familiar: en un libro que existe, en un estante de Tokio, esperando a que alguien con la paciencia adecuada y el viaje adecuado vaya a comprobar si el segundo hijo de Gichin Funakoshi tuvo, alguna vez, un nombre que alguien anotara.

Escudo familiar de los Funakoshi.

Diseño creado con AI por Milton Chanes, basado en una imagen compartida por Sensei Salvador Herraiz.

Yoshitaka Funakoshi

Sat, 18 Jul 2026 13:58:10 GMT

Gigo Funakoshi: The Young Master Who Sustained Karate Through Its Most Difficult Years

When the Funakoshi family is discussed, attention is usually focused almost entirely on Gichin Funakoshi, the Okinawan master who introduced karate to Japan and played a decisive role in its recognition within the world of budō. Yet beside him worked a much younger figure, marked by illness and by an extraordinarily short life: his son Yoshitaka Funakoshi, known within the family as Gigo and called Waka-sensei—the “young master”—by his students.

His story is not merely that of the son of a great master. It is the story of a man who became one of the greatest hopes for the karate of his time, even while knowing that his own body might fail him at any moment.

A Child Condemned by Illness

Gigo Funakoshi was born in 1906. When he was only seven years old, he was diagnosed with tuberculosis, an especially serious and difficult disease to treat during the early decades of the twentieth century.

Doctors reportedly believed that he would probably not live beyond the age of twenty.

Despite that prognosis, Gigo reached the age of thirty-nine.

The illness remained with him throughout his life. His adulthood, his professional work, and his practice of karate all developed under the constant awareness that his time might be limited.

It is impossible to know precisely how deeply this influenced his personality or his approach to training. Nevertheless, it is difficult to separate his development as a karateka from the disease that had accompanied him since childhood.

Gigo was not merely a sick man who practised karate. He became a respected technician, an instructor, and eventually the person in whom his father placed much of his hope for the future of his teaching.

Yoshitaka, Gigo, and Waka-sensei

The name that appears in many historical documents is Yoshitaka Funakoshi, although within the family he was known as Gigo.

Among the students, however, he was commonly addressed as Waka-sensei, an expression that may be translated as “young master.”

The name distinguished him from his father, Gichin Funakoshi, whom the students referred to as Rō-sensei, the “senior master” or “old master”.

In this way, both men could be clearly identified within the same teaching environment. Gichin represented the experienced master, while Gigo embodied the younger generation that was gradually assuming greater responsibility.

This distinction was not merely a question of age. It also reflected the coexistence of two generations within the same project.

Gichin Funakoshi brought experience, authority, and an understanding of karate deeply connected to moral education and the cultivation of character. Gigo, on the other hand, belonged to a generation educated in Japan, closely connected to university students, and confronted by a society undergoing profound and rapid change.

Waka-sensei did not remain in his father’s shadow as a simple assistant. He had to establish his own position as an instructor among students who, in many cases, had also received direct instruction from Gichin.

Over time, his technical ability and growing responsibilities allowed him to become a recognisable figure in his own right.

Before the Shōtōkan Dōjō

When the word Shōtōkan is used in relation to this period, an important distinction must be made.

At that time, Shōtōkan was not yet the formal name of a clearly defined karate style. It was the name given to the dōjō built for Gichin Funakoshi and his students.

Gigo had already been assisting his father long before that dōjō officially existed.

During the early expansion of karate in Tokyo, much of the teaching took place in university clubs, student residences, borrowed halls, and other temporary locations. These university groups became essential to the growth of karate in mainland Japan.

They were not simply places where students gathered to train. They became centres of transmission, experimentation, organisation, and the formation of future instructors.

Gigo participated in this university environment for years. He helped his father teach students and gradually developed direct relationships with the younger practitioners who would later contribute to the expansion of the art.

Many of those university students and former students would eventually help gather the money, support, and organisational resources needed to build a permanent training hall.

The opening of the Shōtōkan dōjō therefore did not mark the beginning of Gigo’s teaching activity. It represented the physical consolidation of work that had already been taking place for years.

The Original Meaning of Shōtōkan

To understand the origin of the name Shōtōkan, it is necessary to look beyond the meaning it acquired after the Second World War.

Before the word became internationally associated with a particular tradition or school of karate, Shōtōkan was first and foremost a physical place.

The dōjō stood on the same property as Gichin Funakoshi’s home.

From the street, students entered through a narrow passage that ran alongside the house. They walked past the family residence before reaching the training hall situated farther inside the grounds.

This physical arrangement helps us understand the name from a more immediate and human perspective.

The students were not travelling to the headquarters of a karate style officially called Shōtōkan. They were going to the place where Gichin Funakoshi lived and taught.

Gichin used the literary name Shōtō when writing poetry and practising calligraphy. The word kan may refer to a building, hall, institution, or place of learning.

Shōtōkan could therefore be understood as “Shōtō’s hall” or, in a more familiar sense, “Shōtō’s house.”

When the students spoke of going to Shōtōkan, they were referring to the place associated with Shōtō: the property where their teacher lived and where they gathered to practise.

The name did not originally identify a formal system separated from other forms of karate. It first identified a place and, by extension, the community that trained there.

Only later—particularly after the war, as the students of Funakoshi organised themselves into different groups and karate expanded internationally—did Shōtōkan acquire the much broader meaning it carries today.

The Construction of the Dōjō

The precise chronology of the dōjō’s construction remains difficult to establish.

Its official inauguration took place in 1939, although the planning, fundraising, and work that made the building possible had begun earlier.

Some accounts suggest that the project may have developed over a considerably longer period. The year 1933 has occasionally been proposed as a possible starting point, but there is not yet enough publicly available documentation to present that date as definitively established.

It is therefore more prudent to say that the project and its construction began before the official inauguration, while recognising that the exact sequence of events still requires further documentary confirmation.

The inauguration should not necessarily be understood as the first occasion on which the property or parts of the developing structure were used for training.

It is possible that students gathered, practised, or used parts of the site while the project was still under construction. However, until stronger documentary evidence emerges, this should be presented as a reasoned historical reconstruction rather than an unquestionable fact.

What can be stated more confidently is that the dōjō did not suddenly appear in 1939 as the beginning of a new teaching project.

It was the result of many years of instruction in universities and temporary locations, the growth of the student community around Gichin Funakoshi, the increasing contribution of Gigo, and the collective desire to create a permanent home for their practice.

The name Shōtōkan was probably strengthened by several factors that gradually converged:

Gichin Funakoshi’s literary name, the physical relationship between his house and the dōjō, the everyday language used by the students, their respect for their teacher, and the later decision to place the name above the entrance.

Before becoming the international name of one of the world’s most widely practised karate traditions, Shōtōkan was something far simpler and more personal:

the place where students went to train with Shōtō.

His Father’s Principal Assistant

During the first years of karate’s expansion in Tokyo, one of Gichin Funakoshi’s most prominent students was Takeshi Shimoda.

Shimoda’s premature death in 1934 left an important absence within the group.

From that point onwards, Gigo gradually assumed the role of his father’s principal assistant and became one of the main pillars supporting his teaching.

This responsibility initially developed within the university clubs, several years before the official inauguration of the Shōtōkan dōjō.

Karate was still attempting to establish itself within the Japanese martial world and depended heavily on relatively small groups of practitioners connected to universities.

These clubs became essential centres for spreading the art and training new instructors.

For Gichin, his son came to represent much more than occasional assistance. Gigo was the man to whom he could entrust an increasing part of the teaching and, perhaps, the future continuation of his work.

By the time the Shōtōkan dōjō officially opened its doors in 1939, Gigo was neither an improvised instructor nor a recent addition to his father’s work.

He already possessed years of teaching experience and had developed a direct relationship with many of the students who had helped karate take root in Tokyo.

The relationship between father and son must have contained a painful contradiction.

Gichin watched his son grow as a disciple, technician, instructor, and possible successor. At the same time, he knew that Gigo had carried since childhood an illness that could take him away before he was able to complete his task.

A Life Beyond the Dōjō

Although karate occupied a central place in his life, Gigo also had a profession.

He worked as an X-ray technician for the Ministry of Health at the Imperial University.

The detail is particularly striking because of his own pulmonary illness. At a time when radiology was still developing as a medical field, Gigo worked with technology directly connected to the diagnosis of diseases similar to the one that had shaped his life since childhood.

He also possessed a strong interest in photography.

Some of the surviving images in which he appears alongside karateka such as Shigeru Egami and Genshin Hironishi were produced within his photographic environment.

Through these photographs, postures, gestures, and moments from pre-war karate have been preserved that might otherwise have disappeared.

Photography reveals another side of Gigo.

He was not only the man standing before students to teach them. He was also someone who observed, framed, recorded, and preserved images.

In that sense, he helped leave behind a visual testimony of the martial world to which he belonged.

A Respected Technician, but Not an Invincible One

Surviving descriptions present Gigo as a relatively small man, approximately 155 centimetres tall and weighing around 55 kilograms.

Despite his physical size and fragile health, he became recognised as a highly skilled technician.

Some testimonies suggest that he was not particularly interested in free fighting. This detail helps move his story away from the idealised images that are sometimes constructed around historical masters.

Gigo should not be imagined as an invincible warrior surrounded by extraordinary victories. He was a real practitioner, with personal preferences, abilities, weaknesses, and limitations.

One account also recalls a defeat during an exchange with Nei Chu So, a student of Gōgen Yamaguchi within the Gōjū tradition.

Rather than diminishing Gigo’s importance, such an episode helps humanise him.

His historical value does not depend on whether he won every confrontation. It rests on the position he achieved within the teaching, transmission, and development of karate during his generation.

Understanding historical masters as human beings allows us to appreciate their true achievements more clearly. They were people who learned, experimented, made mistakes, encountered difficulties, and continued practising. Gigo Funakoshi belonged to that reality.

The Destruction of the Shōtōkan Dōjō

The final months of Gigo’s life coincided with one of the most devastating periods in Japanese history.

The Shōtōkan dōjō, officially inaugurated in 1939 after years of teaching and preparation, was destroyed during the bombing of Tokyo in 1945.

It is worth repeating that, in this context, Shōtōkan was the name of the building and the training place created for Gichin Funakoshi and his students. It was not yet the formal name of a standardised karate style in the sense in which the word would later be understood.

The building had represented the physical realisation of decades of work by Gichin and his students.

Its destruction was not merely the loss of a training hall. It meant the disappearance of the symbolic home of a community that had previously spent years moving between universities, residences, and borrowed spaces.

After the destruction of the dōjō, training continued under extremely precarious conditions.

Some classes were reportedly moved to Takada Dai Hachi Elementary School, which had been closed after its pupils were evacuated to rural areas.

At times, no more than four practitioners attended these sessions.

Within this landscape of ruins, scarcity, and defeat, Gigo remained one of his father’s greatest hopes.

Yet his health was deteriorating rapidly.

The destruction of the Shōtōkan dōjō and the physical decline of Gigo occurred almost simultaneously.

For Gichin, the end of the war did not represent only the collapse of the country in which he had built his new life. It also meant watching the disappearance, one after another, of the building that represented his work and the son in whom he had placed much of his hope for its continuation.

The Death of the Young Master

During 1945, Gigo began to succumb to the illness that had followed him since childhood.

Some versions leave open the possibility that his final condition involved more than tuberculosis alone. Nevertheless, the surviving descriptions agree that his lungs were barely functioning when he was admitted to hospital.

Gigo expressed his wish to die at home.

He died in November 1945, only a few months after the end of the war, in the Ochiai area of the former Yodobashi district of Tokyo, at a place known as Green Court.

He was thirty-nine years old.

Family members and some of his closest students attended the funeral.

The conditions of the immediate post-war period made travel extremely difficult, particularly from Okinawa. As a result, many people connected to the Funakoshi family and to karate were unable to be present.

His death came only months after the destruction of the Shōtōkan dōjō.

For Gichin Funakoshi, the loss must have been profound.

He had lost his son, his principal assistant, and the man in whom he had placed his trust for the future of his teaching.

The Man Behind the Family Name

It is tempting to define Gigo simply as “the son of Gichin Funakoshi”. That description, however, is not enough.

He was a sick child who survived many years beyond the expectations of his doctors.

He was an X-ray technician, a photographer, a karateka, and an instructor.

He began assisting his father within the university clubs before the Shōtōkan dōjō officially existed, and he assumed increasingly important responsibilities after the death of Takeshi Shimoda.

When the dōjō was officially inaugurated in 1939, Gigo had already spent years working alongside his father and interacting with the university groups that had helped karate grow in Tokyo.

He was also a physically fragile man who accepted enormous responsibilities during a period marked by militarisation, war, bombing, deprivation, and destruction.

His life did not end at the moment of karate’s greatest expansion. It ended when almost everything around him appeared to be collapsing.

Perhaps that is one reason why his figure remains so powerful.

Gigo Funakoshi did not live long enough to become the elderly master whom generations of students could consult for decades.

He did not witness the international expansion that karate would experience after the war.

He was unable to help rebuild the dōjō that had carried his father’s literary name.

He died before seeing how far the art to which he had dedicated his final years would travel.

Yet during the brief time available to him, he ceased to be merely the son of a master.

For those who trained with him, he was Waka-sensei, the young master, while his father was Rō-sensei, the senior master.

They belonged to different generations, but they worked within the same undertaking.

Gigo became a distinct, recognisable, and essential figure within the generation that attempted to keep karate alive while the world they had known was collapsing around them.

Discover the History Behind the Story

The story of Gigo Funakoshi, the original Shōtōkan dōjō, and the transformation of Okinawan Tōde into modern Karate-Dō forms part of the historical world explored in my books.

The Walking Upright Trilogy follows three generations connected to the preservation, development, and transmission of the Okinawan martial tradition:

Walking Upright is a historical novel inspired by the life of Gichin Funakoshi and his journey from Okinawa to mainland Japan.

Bushi: The Guardian of Shuri explores the life and world of Matsumura Sōkon during the final decades of the Ryūkyū Kingdom.

Waka-sensei: The Prince Who Never Reigned is inspired by the brief but remarkable life of Gigo Funakoshi and the generation that attempted to sustain karate through war, illness, and destruction.

The trilogy is accompanied by The Path of Karate-Dō , a historical essay that examines the people, places, terminology, documents, and cultural transformations behind the novels.

Find the English Editions on Amazon

Walking Upright — The Story of Gichin Funakoshi

Bushi: The Guardian of Shuri

The Path of Karate-Dō: A Historical Essay

Milton Chanes — Amazon Author Page

Explore the Books on the Official Website

Walking Upright — Book One

Bushi: The Guardian of Shuri — Book Two

Waka-sensei: The Prince Who Never Reigned — Book Three

The Path of Karate-Dō

On the official website, readers can discover the historical background of each book, read opening chapters, and access available PDF samples.

Karate-dō Kyōhan

Fri, 10 Jul 2026 11:41:05 GMT

Karate-dō Kyōhan (1935)

From the Lost 1922 Book to the Foundation of Modern Karate-Dō

In 1935, one of the most important books in the history of modern karate was published: 『空手道教範』 (Karate-dō Kyōhan), written by Funakoshi Gichin (1868–1957). However, this famous work was not the beginning of Funakoshi’s literary contribution. It was the result of more than a decade of effort dedicated to introducing Okinawan karate to mainland Japan.

The history of Funakoshi’s publications begins in 1922, the year when he traveled to Tokyo at the invitation of the Japanese Ministry of Education to participate in the First National Physical Education Exhibition held in Ochanomizu. This event marked a turning point, as it was the first official presentation of Okinawan martial art to a Japanese audience outside Okinawa.

Following this presentation, Funakoshi published his first book: 『琉球拳法唐手道』 (Ryūkyū Kenpō Karate-dō), commonly translated as Ryukyu Kempo: Karate-dō. This was the first major written work introducing the art of Okinawa to Japan. The book was carefully prepared with the support of people who helped Funakoshi during his early years in Tokyo, including assistance with its organization, design, and publication.

Unfortunately, this first edition had a very short life. In September 1923, the Great Kantō Earthquake devastated Tokyo and Yokohama, destroying countless buildings, documents, and cultural materials. Many of the original copies of Funakoshi’s 1922 book were lost, making surviving examples today extremely rare historical treasures.

Because of this loss, Funakoshi later prepared a new version of his work. In 1925, the book was republished under the title 『錬胆護身唐手術』 (Rentan Goshin Tōde-jutsu). This edition represented an evolution of his earlier ideas and allowed his teachings to continue spreading among Japanese practitioners. Additional copies and reproductions appeared in the following years, including editions from around 1926, helping preserve Funakoshi’s early explanations of karate.

However, it was not until 1935 that Funakoshi published the work that would become his most famous and influential book: 『空手道教範』 (Karate-dō Kyōhan), “The Master Text of the Way of the Empty Hand.”

Unlike his earlier publications, which were created during the challenging first years of introducing karate to Japan, Karate-dō Kyōhan reflected more than a decade of teaching experience in Tokyo. In this book, Funakoshi presented a more developed vision of karate as a Budō, a martial way dedicated not only to physical technique but also to personal cultivation.

The book includes explanations of fundamental techniques, stances, training methods, principles of combat, and detailed descriptions of kata. It also contains one of the most valuable photographic collections from the early history of karate, with Funakoshi himself demonstrating techniques. These images provide an extraordinary record of karate before many of the technical changes introduced by later generations.

The publication of Karate-dō Kyōhan also reflects the transformation from Okinawan Tōde into Japanese Karate-Dō. The adoption of the character 空手 (empty hand), the incorporation of the concept of Dō (道), and the development of karate within the Japanese educational and martial arts environment were essential steps in the creation of modern karate.

Only one year after the publication of the book, in 1936, the first dedicated Shōtōkan dōjō was officially opened in Tokyo. Therefore, Karate-dō Kyōhan can be seen as both a culmination of Funakoshi’s first fourteen years in Japan and a bridge toward the future development of the style that would later bear his name.

Today, nearly a century later, Karate-dō Kyōhan remains one of the most important historical documents for understanding Funakoshi’s karate. Yet its true story begins with the almost forgotten 1922 edition — a pioneering book that introduced Okinawan karate to Japan, disappeared in the tragedy of the Kantō Earthquake, and paved the way for all the works that followed.

The 1935 edition can be consulted online through Internet Archive:

Read Karate-dō Kyōhan by Gichin Funakoshi on Internet Archive:

https://archive.org/details/karate-do-kyohan

Studying these books allows us to follow the transformation of an Okinawan fighting art into Karate-Dō: a journey shaped by teachers, students, historical events, and the vision of a man who dedicated his entire life to transmitting the Way of the Empty Hand .

This image is an AI-enhanced reconstruction based on an original historical photograph of Gichin Funakoshi. The original picture was preserved with limited quality due to its age, so artificial intelligence was used to restore details, improve clarity, and recreate a more visually accessible version while keeping the original character and historical context of the photograph.

Please note that this is not a new photograph, but a digital reconstruction and enhancement of an existing historical image.

Kosugi Hōan’s Tiger: Born in 1922 or 1935?

Fri, 10 Jul 2026 09:05:48 GMT

Kosugi Hōan’s Tiger

A recent comment on one of my posts raised a question that I knew would eventually lead to debate:

Was Kosugi Hōan’s famous tiger really created for Funakoshi Gichin’s first book in 1922, or was it designed for Karate-Dō Kyōhan in 1935?

The most widely accepted version among karate practitioners today connects the famous tiger with Karate-Dō Kyōhan, published in 1935. There are good reasons for this association, and Japanese institutional sources explicitly connect Kosugi with a tiger design for that later work.

However, the story is not quite so simple.

Several very specific sources state that the tiger had already appeared in connection with Funakoshi’s first book, Ryūkyū Kempō: Karate, published in 1922.

Shotokai.com states directly that the tiger symbol was placed by Kosugi Hōan on the cover of Funakoshi’s first book in 1922. The World Shotokan Karate-dō Federation Australia gives the same account, stating that Kosugi designed the cover and that it displayed what is now known as the famous Shotokan tiger. Other Shotokan historical sources repeat this version and explicitly date the tiger’s first appearance to 1922.

According to this tradition, Kosugi encouraged Funakoshi to write the first book on karate and offered to take responsibility for its design. The tiger was linked to the expression tora no maki, meaning the definitive or authoritative text of an art. Since tora also means “tiger,” the image became a visual play on words: Funakoshi’s book was to be the tora no maki of karate.

But there is another side to the story.

The official chronology of the Kosugi Hōan Museum of Art confirms that Kosugi was involved with Funakoshi in 1922 and that Ryūkyū Kempō: Karate was published at his recommendation and with his artistic involvement in the book’s design. Yet the same institutional chronology explicitly records a tiger design in connection with Karate-Dō Kyōhan in 1935.

This creates an important historical question .

Did Kosugi create an earlier version of the tiger for the 1922 book and later produce another design for the 1935 publication? Did the symbol evolve over time? Or have later accounts projected the famous 1935 tiger backwards onto the first book?

The problem is made more difficult by the fate of the original 1922 publication. The printing materials associated with Funakoshi’s first book were lost following the Great Kantō Earthquake of 1923, which led to a later and substantially revised publication. The surviving evidence must therefore be examined carefully, especially when modern reproductions, later editions, and historical accounts are compared.

This is precisely why I mentioned 1922 in my original article.

It was not because I was unaware of the well-known association between the tiger and Karate-Dō Kyōhan. On the contrary, I knew that the statement would generate debate. I included it because several specific sources explicitly place the tiger in 1922, and I believe these sources deserve to be discussed rather than simply ignored.

At the same time, historical research requires caution. The existence of sources repeating the 1922 version does not automatically settle the question, just as the documented connection with the 1935 book does not necessarily prove that no earlier version of the tiger existed.

For now, the most accurate conclusion may be this:

Kosugi Hōan’s involvement with Funakoshi’s first book in 1922 is documented. Several specific karate sources state that the tiger appeared on that book. Japanese institutional sources, however, explicitly document a tiger design in connection with Karate-Dō Kyōhan in 1935.

The question therefore remains worthy of further investigation.

And perhaps that is the most interesting part of historical research: sometimes the familiar story is only the beginning of the discussion.

Sources

Sources supporting the 1922 version

Shotokai — The History of Master Funakoshi’s Personal Symbol
https://shotokai.com/tiger/

World Shotokan Karate-dō Federation Australia — The Tiger Symbol of Shotokan Karate
https://www.wskf.com.au/martial-arts-concepts/tiger-symbol-shotokan-karate/

Shotokan Karate CSL — The Shotokan Tiger
https://shotokankaratecsl.com/Info%20-%20Home%2002%20-%20Shotokan%20-%20Shotokan%20Tiger.html

Okuden Shotokan — The Shotokan Tiger
https://okuden-shotokan.club/the-shotokan-tiger/

Japanese institutional source

Kosugi Hōan Museum of Art — Official Biography and Chronology
https://www.khmoan.jp/khmoan/biography.html

Digitized 1922 publication record

Ryūkyū Kempō: Karate (1922), digitized from the National Diet Library of Japan
https://commons.wikimedia.org/wiki/File:NDL971654_唐手_-_琉球拳法_part1.pdf

For anyone who would like to consult the work directly, Gichin Funakoshi’s Rentan Goshin Tōde-jutsu, published in 1925, has been digitized by the Internet Archive. You can browse the entire book and examine its cover, photographs, and original content here:

https://archive.org/details/rentan-goshin-toudi-jutsu

It is important to clarify that this is the 1925 edition, not Funakoshi’s first book from 1922, whose original cover I have never seen.

This book can be read online for free through Archive.org. https://archive.org/details/rentan-goshin-toudi-jutsu/mode/2up

This is the Internet Archive catalog entry for Gichin Funakoshi’s Rentan Goshin Tōde-jutsu, where it can be seen that the book was published in 1925.

What exactly is that cover?

The cover shown in the screenshot—the fist over the blue-green panel, the spine bearing the inscription 錬膽護身唐手術・富名腰義珍著, and the crossed sai on the back cover—belongs to Rentan Goshin Tōde-jutsu (錬膽護身唐手術). The Internet Archive catalog entry itself lists its publication date as 1925.

At the bottom of the cover, the inscription 東京廣文堂發行 can be read, meaning that it was published by Kōbundō of Tokyo, the publisher of this second work.

The first book had been published by Bukyōsha (武侠社).

Why does this second book exist?

The first book, Ryūkyū Kenpō: Tōde (Karate), was published in November 1922 and was the first Japanese book on karate. Due to its great demand, it was republished in 1925 as Rentan Goshin Tōde-jutsu, replacing the original illustrations with photographs of Funakoshi.

The printing plates of the 1922 original were destroyed in the fire caused by the Great Kantō Earthquake of September 1923, making it necessary to recreate the work. It is therefore not merely a reprint, but a revised edition featuring new content and a new cover design.

Regarding the question of the tiger

It appears that Kosugi Hōan’s tiger did not originate in 1935 with Karate-dō Kyōhan, but was already present on the first book. The cover of the 1922 book was designed and illustrated by Kosugi Hōan and featured what is now known as the famous Shotokan tiger, while the interior illustrations were created by his disciple, Yamashiro Masatsuna.

Kosugi had promised Funakoshi that, if he wrote the book in 1922, he would design it and contribute a painting for the cover, playing on the expression tora no maki—literally “tiger scroll,” but also meaning a master text or authoritative manual.

The chronology would therefore be as follows:

1922 → Kosugi’s tiger on Ryūkyū Kenpō Tōde
1925/26 → fist and crossed sai, without the tiger, on Rentan Goshin Tōde-jutsu, the book shown in your screenshot
1935 → the tiger reappears, in a redrawn version, on Karate-dō Kyōhan

Original 1925 edition or later reprint?

Rentan Goshin Tōde-jutsu had an initial printing in 1925, followed by reprints in 1926. In fact, many scans circulating online are identified as “1926.”

To determine which printing is represented by the copy scanned on Archive.org, it would be necessary to examine the colophon, or okuzuke (奥付), found on the final pages of the scan. Japanese books from this period normally list the precise printing and publication dates there, as well as any later editions or reprints, using terms such as 発行 and 再版.

The cover design was identical for both printings, so the cover alone does not make it possible to distinguish between the 1925 original printing and the 1926 reprint.

Kosugi Hoan (1881–1964)

Thu, 09 Jul 2026 10:20:39 GMT

Kosugi Hoan (1881–1964)

In the spring of 1922, Gichin Funakoshi travelled to Tokyo at the invitation of the Japanese Ministry of Education to present the art of Okinawa at the First National Physical Education Exhibition, held in Ochanomizu. He was 53 years old at the time, and nothing suggested that this discreet Okinawan schoolteacher was about to change the history of Japanese martial arts forever.

For the occasion, he prepared three long scrolls containing ordered photographs of stances, kata, and hand and foot movements, and the demonstration proved to be a remarkable success. His intention, however, was to return to Okinawa as soon as the event was over. The first postponement came when Kanō Jigorō, founder of jūdō and president of the Kōdōkan, asked him to give a lecture and demonstration of his art.

After the demonstration, Funakoshi was once again preparing to return to Okinawa when he received a visit from the painter Kosugi Hoan (1881–1964) , a prominent figure in Tokyo’s artistic circles and president of the Tabata Poplar Club, a gathering of painters and poets. Kosugi was not unfamiliar with the Okinawan art: in 1913, during a journey to Europe, his ship had stopped in Okinawa, where he had his first encounter with Tōde, which left a deep impression on him.

Fascinated by that art, he asked Funakoshi to postpone his departure and teach the members of the club. Those first classes, together with the insistence of Kanō Jigorō and the kendō master Nakayama Hakudō, proved decisive in leading Funakoshi to remain permanently in the Japanese capital.

His relationship with Kosugi soon bore further fruit. It was Kosugi who encouraged Funakoshi to write the first book on karate, committing himself to take charge of the design. Thus Ryūkyū Kempō: Karate (1922) was born, the first karate book published in the world, whose cover already displayed the famous tiger painted by Kosugi.

The design played on the Japanese expression tora no maki — the definitive reference text of an art — since tora also means “tiger”: Funakoshi’s book would become the tora no maki of karate. That tiger would accompany the master’s later works, including Karate-Dō Kyōhan (1935), and would eventually become one of the most recognizable symbols of Shōtōkan.

Kosugi Hoan and the Shotokan Tiger: The Artist Behind Funakoshi’s First Karate Book.

Bushi: A Historical Novel About Sōkon Matsumura and the Origins of Karate-Dō

Wed, 08 Jul 2026 11:47:47 GMT

Walking Upright Trilogy - Book 2

Before karate was known as Karate-Dō, before it reached Japanese universities, and even before it became a discipline practiced throughout the world, there existed an ancient, silent art deeply connected to the history of Okinawa.

For generations, that art was known as Tōde.

And among the great names who shaped that tradition, one stands out with particular strength: Matsumura Sōkon.

Bushi was born from the desire to tell his story.

Matsumura Sōkon was not simply a martial arts master. He was a man shaped by a complex era, in which the Ryūkyū Kingdom existed between Chinese, Japanese, and Okinawan influences. His life unfolded in a world where diplomacy, loyalty, honor, and survival were all part of the same reality.

In the service of the kings of Ryūkyū, Matsumura became a respected figure not only for his physical skill, but also for his character, his discipline, and his deep understanding of the art. Tradition remembers him as an exceptional warrior, but also as a teacher capable of transmitting something far more important than technique: a way of facing life.

That is why the title Bushi does not speak only of a fighter. It speaks of an attitude. Of a way of being in the world. Of the inner firmness of someone who learns to control his strength, master his fear, and act with dignity even in difficult times.

The novel enters an Okinawa that existed before modern karate, when the art was still transmitted privately and the great masters were known more for their actions than for their words. In that context, Matsumura Sōkon represents a bridge between the warrior past of Ryūkyū and the later evolution of Tōde into what, many decades later, would be called Karate-Dō.

Bushi is not intended to be only a novel about martial arts. It is a story about identity, duty, tradition, and transformation. Through Matsumura’s life, the reader is brought closer to a world where every gesture carried meaning, where teaching could not be separated from character, and where true mastery began long before combat.

Within its pages are the echoes of the palaces of Shuri, the political tensions of the old kingdom, the influence of China, the presence of Japan, and the slow formation of a martial tradition that survived through transmission from master to disciple.

Matsumura Sōkon was one of the deepest roots of that tradition. His legacy would influence later generations and reach, directly or indirectly, fundamental figures such as Ankō Itosu, Ankō Asato, and Gichin Funakoshi. Without Matsumura, the history of karate could not be understood in the same way.

Within the trilogy, Bushi occupies an essential place. If Walking Upright follows the life of Gichin Funakoshi and the moment when the art of Okinawa began to make its way to Japan, Bushi looks further back, toward the roots. Toward the time when spirit, technique, and loyalty were still tied to the world of the old Ryūkyū.

The novel invites the reader to discover not only who Matsumura Sōkon was, but what he represented. Because behind the myth of the great master lies a deeper question: what does it truly mean to be a bushi?

The answer is not found only in strength, victory, or reputation. It is found in silent discipline, in loyalty to one’s principles, in respect for tradition, and in the ability to remain firm when history changes around us.

Bushi is a novel about origin. About the weight of inheritance. About a man who helped preserve an art that, over time, would transform the lives of millions of people.

Because before modern Karate-Dō, there were masters who walked in silence.

And among them, Matsumura Sōkon holds an immortal place.

Bushi: THE GUARDIAN OF SHURI

Walking Upright Trilogy - Book 2

Bushi is available on Amazon in several formats and languages, allowing readers around the world to discover the story of Matsumura Sōkon and the warrior spirit of Okinawa.

Whether in digital edition or print, this novel invites readers to explore the roots of Karate-Dō through a historical journey of loyalty, discipline, tradition, and personal transformation.

Walking Upright. The story of Gichin Funakoshi

miltonchanes.academy@gmail.com (Milton Chanes) — Tue, 07 Jul 2026 10:16:50 GMT

WalkinG Upright Trilogy - Book1

There are lives that cannot be explained solely by the events they contain, but by the quiet transformation they awaken in those who look upon them. The life of Gichin Funakoshi is one of them.

Walking Upright was born from that idea: to tell the story of a man who, long before becoming an essential figure in the spread of karate, was a frail child, a young man shaped by the traditions of Okinawa, and a teacher who found in the ancient art of Tōde much more than a method of self-defense. He found a way of life.

The novel is set in a time of profound change. Okinawa, once the heart of the Ryūkyū Kingdom, was caught between its own past and the growing influence of Japan. In that world, the art that would later be known as karate was still practiced discreetly, passed from master to student, far from the large dōjō, competitions, and modern image we know today.

Funakoshi grew up in that world. Under the guidance of masters such as Asato Ankō and Itosu Ankō, he came to understand that the value of the art lay not only in technique, but in the character it helped to shape. Training was not merely a sequence of strikes, blocks, and kata. It was an inner discipline. A way of learning to endure, to resist, to move forward, and ultimately, to stand tall. That is the heart of the novel.

Walking Upright is not intended to be only a story about karate. It is also a story about identity, humility, perseverance, and transmission. Through Funakoshi’s life, the reader is brought closer to an Okinawa where oral tradition, respect for teachers, and the cultivation of character formed part of a single vision of the world.

The novel follows Funakoshi from his early years to the moment when his destiny begins to change irreversibly. In 1922, he traveled to Tokyo at the invitation of the Japanese Ministry of Education to present the art of Okinawa at the First National Physical Education Exhibition. His intention was to return soon to his homeland, but that journey would mark a turning point. The insistence of figures such as Kanō Jigorō, Nakayama Hakudō, and Kosugi Hoan would lead him to remain in the Japanese capital and begin a task that would forever transform the history of martial arts.

But behind the recognized master there was always a quiet man. An Okinawan schoolteacher who taught with patience, who believed in courtesy, discipline, and personal improvement. A man who understood that karate should not be reduced to victory over another, but should become a path for shaping the human being.

That is why the title Walking Upright carries a symbolic meaning. It does not speak only of physical posture or bodily strength. It speaks of dignity. Of the ability to remain firm even when the world changes around us. Of walking with integrity, humility, and purpose.

The novel is part of a trilogy devoted to the great figures who helped shape modern karate. Walking Upright focuses on Gichin Funakoshi; Bushi explores the figure of Matsumura Sōkon; and Waka-sensei enters the life of Gigo Funakoshi, the master’s son and a fundamental figure in the technical evolution of Shōtōkan. Alongside them, the historical essay The Path of Karate-Dō offers a deeper understanding of how and why the ancient Tōde eventually evolved into Karate-Dō.

Writing Walking Upright was a way of looking back to the origin. Of trying to understand not only what happened, but what it meant. Because the karate we know today did not appear suddenly. It was the result of many lives, many decisions, and many sacrifices.

Among all of them, the life of Gichin Funakoshi holds a special place. His story reminds us that the true path does not always begin with strength. Sometimes it begins with fragility. With doubts. With a silent search. And, little by little, with the decision to rise and walk upright.

Walking Upright is available on Amazon in several formats and languages, allowing readers around the world to discover the inspiring story of Gichin Funakoshi, the Okinawan schoolteacher who helped transform the ancient art of Tōde into modern Karate-Dō.

Whether in digital edition or print, this novel invites readers to explore the origins of karate through a historical journey of humility, perseverance, discipline, and personal transformation.