DEV Community: Datalaria

MCP (Model Context Protocol): The Standard That Wants to Be the USB of Artificial Intelligence

Daniel — Sun, 28 Jun 2026 10:42:34 +0000

If you've ever tried building an AI agent system in production, you know the pain. During the construction of the agentic radar for Obsolescence, I faced the problem of connecting Gemini 2.5 with my Supabase database and an external API. I had to write custom code to adapt the tool schema (Tool Calling) to the exact format that Google demands.

If tomorrow I decided to migrate that exact same system to Anthropic's Claude or OpenAI's GPT-4o, I would have to rewrite the entire tool integration layer because each vendor uses its own JSON dialect and its own argument validation logic (Function Calling).

It's the same chaos we lived through in the late 90s with mobile phone chargers: every brand had its proprietary connector. Then USB arrived and unified everything. That is exactly the ambition behind MCP (Model Context Protocol): to become the USB of Artificial Intelligence.

What Exactly is the Model Context Protocol?

Initially proposed by Anthropic and rapidly adopted by a coalition of open-source companies, MCP is an open standard for connecting AI models with data sources and tools.

The design premise is elegantly simple, separating the architecture into two independent pieces:

MCP Hosts: Applications or frameworks where the LLM resides (for example, the Claude desktop app, a LangChain script, or your own Python application).
MCP Servers: Lightweight, small programs that expose data or tools to the Host following a strict standard contract (for example, an MCP server that reads your PostgreSQL database, another that reads your GitHub repository).

The magic happens in the middle. The Host (the LLM) tells the MCP Server: "What tools and resources do you have available?". The server responds in a universal format. From there, the LLM can read, write, or execute actions without the developer having had to write a proprietary integration between that specific model and that specific tool.

Comparison: MCP vs Native Tool Calling

On this blog, I have vehemently defended why Tool Calling is infinitely superior to traditional RAG for industrial applications that require precision. MCP does not replace Tool Calling; it standardizes it.

Let's look at the architectural difference:

Feature	Classic Tool Calling	MCP (Model Context Protocol)
Integration	1-to-1 (Specific Model ↔ Specific Tool)	N-to-M (Any Model ↔ Any MCP Server)
Format	Dictated by the LLM vendor (Google, OpenAI)	Standard, agnostic JSON-RPC 2.0
Discovery	Developer injects tools into the prompt	Host discovers tools dynamically
Portability	None. Migrating LLMs requires refactoring.	Total. You write the MCP server once.

Building an MCP Server: A Real Example

To illustrate why this changes the game for operations and backend engineers, let's imagine we want to expose a Supabase table (e.g., critical component inventory) to our LLM.

With a traditional CrewAI or Langchain approach, we would write a custom tool bound to that framework. With MCP, we write a universal Python server using the official SDK:

from mcp.server.fastmcp import FastMCP
import supabase

# Initialize the MCP server
mcp = FastMCP("Supabase_Inventory_Server")
db = supabase.create_client(URL, KEY)

@mcp.tool()
def get_critical_stock(part_number: str) -> str:
    """Fetches the stock level of a specific component."""
    response = db.table("inventory").select("stock").eq("pn", part_number).execute()

    if not response.data:
        return "Component not found."

    stock = response.data[0]['stock']
    return f"The current stock for {part_number} is {stock} units."

if __name__ == "__main__":
    # The server starts and listens for requests over stdio (JSON-RPC)
    mcp.run()

That code block is all you need. Once running, any MCP-compatible application (including Claude's official interface) can connect to this server, read the function's description (docstring), and decide when to call get_critical_stock with the correct arguments.

Opinion: Will MCP Be the Definitive Standard?

The history of software is littered with "universal standards" that only managed to add one more standard to the list of competing standards. Will MCP survive?

It has two massive advantages in its favor. The first is that it solves a real, acute pain point for corporate developers, who are sick of rewriting integrations every time a new model comes out. The second is the local-first approach. Standard MCP communication uses stdio (standard input/output), which means the MCP server runs locally on your machine or private network. This is a wet dream for industrial cybersecurity because the data never leaves your infrastructure until the LLM explicitly and authorizedly requests it.

However, MCP's success will depend on adoption by the dominant duopoly: Google and OpenAI. If Anthropic manages to create a large enough open-source ecosystem (like Kubernetes once did against proprietary clouds), the other giants will be forced to support it natively.

If you are designing the architecture for an Agentic Project Management Office or any system where you need to connect AI agents with legacy ERPs, PLMs, or document repositories, my recommendation is to bet on isolating your connectors. Today it might be through independent Python functions, and tomorrow, probably, wrapping those same functions in an MCP Server.

Just as USB killed hundreds of proprietary connectors, MCP has the potential to finally democratize LLM access to the "muscle" of enterprise data.

Sources of Interest:

MCP (Model Context Protocol): El Estándar que Quiere Ser el USB de la Inteligencia Artificial

Daniel — Sun, 28 Jun 2026 10:35:17 +0000

Si has intentado construir un sistema de agentes de IA en producción, conoces el dolor. Durante la construcción del radar agéntico para Obsolescencia, me enfrenté al problema de conectar a Gemini 2.5 con mi base de datos en Supabase y una API externa. Tuve que escribir código específico para adaptar el esquema de herramientas (Tool Calling) al formato exacto que exige Google.

Si mañana decidiera migrar ese mismo sistema a Claude de Anthropic o a GPT-4o de OpenAI, tendría que reescribir toda la capa de integración de herramientas porque cada proveedor usa su propio dialecto de JSON y su propia lógica de validación de argumentos (Function Calling).

Es el mismo caos que vivíamos a finales de los 90 con los cargadores de móviles: cada marca tenía su conector propietario. Luego llegó el USB y lo unificó todo. Esa es exactamente la ambición detrás de MCP (Model Context Protocol): convertirse en el USB de la Inteligencia Artificial.

¿Qué es exactamente el Model Context Protocol?

Propuesto inicialmente por Anthropic y rápidamente adoptado por una coalición de empresas de código abierto, MCP es un estándar abierto para conectar modelos de IA con fuentes de datos y herramientas.

La premisa de diseño es elegantemente simple, separando la arquitectura en dos piezas independientes:

MCP Hosts: Aplicaciones o frameworks donde reside el LLM (por ejemplo, la app de escritorio de Claude, un script de LangChain, o tu propia aplicación en Python).
MCP Servers: Pequeños programas ligeros que exponen datos o herramientas al Host siguiendo un contrato estándar estricto (por ejemplo, un servidor MCP que lee tu base de datos PostgreSQL, otro que lee tu repositorio de GitHub).

La magia ocurre en el medio. El Host (el LLM) le dice al Servidor MCP: "¿Qué herramientas y recursos tienes disponibles?". El servidor responde en un formato universal. A partir de ahí, el LLM puede leer, escribir o ejecutar acciones sin que el desarrollador haya tenido que escribir una integración propietaria entre ese modelo específico y esa herramienta específica.

Comparativa: MCP vs Tool Calling Nativo

En el blog he defendido vehementemente por qué el Tool Calling es infinitamente superior al RAG tradicional para aplicaciones industriales que requieren precisión. MCP no reemplaza al Tool Calling; lo estandariza.

Veamos la diferencia arquitectónica:

Característica	Tool Calling Clásico	MCP (Model Context Protocol)
Integración	1 a 1 (Modelo específico ↔ Herramienta específica)	N a M (Cualquier Modelo ↔ Cualquier Servidor MCP)
Formato	Dictado por el proveedor del LLM (Google, OpenAI)	Estándar JSON-RPC 2.0 agnóstico
Descubrimiento	El desarrollador inyecta las herramientas en el prompt	El Host descubre herramientas dinámicamente
Portabilidad	Nula. Migrar de LLM requiere refactorización.	Total. Escribes el servidor MCP una vez.

Construyendo un Servidor MCP: Un Ejemplo Real

Para ilustrar por qué esto cambia las reglas del juego para ingenieros de operaciones y backend, imaginemos que queremos exponer una tabla de Supabase (por ejemplo, el inventario de componentes críticos) a nuestro LLM.

Con un enfoque tradicional de CrewAI o Langchain, escribiríamos una herramienta personalizada atada a ese framework. Con MCP, escribimos un servidor universal en Python utilizando el SDK oficial:

from mcp.server.fastmcp import FastMCP
import supabase

# Inicializamos el servidor MCP
mcp = FastMCP("Supabase_Inventory_Server")
db = supabase.create_client(URL, KEY)

@mcp.tool()
def get_critical_stock(part_number: str) -> str:
    """Busca el nivel de stock de un componente específico."""
    response = db.table("inventory").select("stock").eq("pn", part_number).execute()

    if not response.data:
        return "Componente no encontrado."

    stock = response.data[0]['stock']
    return f"El stock actual para {part_number} es de {stock} unidades."

if __name__ == "__main__":
    # El servidor arranca y escucha peticiones sobre stdio (JSON-RPC)
    mcp.run()

Ese bloque de código es todo lo que necesitas. Una vez en ejecución, cualquier aplicación compatible con MCP (incluyendo la interfaz oficial de Claude) puede conectarse a este servidor, leer la descripción (docstring) de la función, y decidir cuándo llamar a get_critical_stock con los argumentos correctos.

Opinión: ¿Será MCP el Estándar Definitivo?

La historia del software está llena de "estándares universales" que solo lograron añadir un estándar adicional a la lista de estándares competidores. ¿Sobrevivirá MCP?

Tiene dos ventajas enormes a su favor. La primera es que resuelve un dolor real y agudo para los desarrolladores corporativos, que están hartos de reescribir integraciones cada vez que sale un nuevo modelo. La segunda es el enfoque local-first. La comunicación estándar de MCP utiliza stdio (entrada y salida estándar), lo que significa que el servidor MCP se ejecuta localmente en tu máquina o tu red privada. Esto es un sueño húmedo para la ciberseguridad industrial, porque los datos nunca abandonan tu infraestructura hasta que el LLM los solicita explícitamente y con autorización.

Sin embargo, el éxito de MCP dependerá de la adopción por parte del duopolio dominante: Google y OpenAI. Si Anthropic logra crear un ecosistema open-source lo suficientemente grande (como Kubernetes hizo en su día contra las nubes propietarias), los demás gigantes se verán obligados a soportarlo de forma nativa.

Si estás diseñando la arquitectura de un Project Management Office Agéntico o cualquier sistema donde necesites conectar agentes de IA con ERPs heredados, PLMs o repositorios documentales, mi recomendación es apostar por aislar tus conectores. Hoy puede ser mediante funciones de Python independientes, y mañana, probablemente, envolviendo esas mismas funciones en un Servidor MCP.

Al igual que el USB mató a cientos de conectores propietarios, MCP tiene el potencial de democratizar finalmente el acceso de los LLMs a la "musculatura" de los datos empresariales.

Fuentes de Interés:

Claude Shannon: The Man Who Turned the World into Bits and Defined the Future of AI

Daniel — Sun, 21 Jun 2026 08:20:29 +0000

There are historical figures who discover continents, and there are figures who invent the underlying physics that allow the ships to exist. In the realm of technology and data, Claude Shannon unequivocally belongs to the latter category. If you can read this article on your screen today, if your smartphone can compress a 12-megapixel photo, and if Multiverse Computing can compress a massive LLM into an edge chip, it is because Shannon dictated the mathematical laws of information more than 75 years ago.

While Abraham Wald taught us to read the silence of missing data and W. Edwards Deming systematized industrial quality, Shannon did something even more fundamental: he isolated the concept of 'information' from the physical meaning of the message.

The Birth of the Bit: Bell Labs, 1948

To understand Shannon's titanic achievement, you have to understand the chaos of communication in the early 20th century. The telegraph, telephone, radio, and television were considered distinct physical phenomena. Engineers improved transmission by reducing electrical noise in cables, but there was no unified theory.

In 1948, working at the mythical Bell Labs, Shannon published "A Mathematical Theory of Communication". In its pages, Shannon introduced for the first time in print the word "bit" (a contraction of binary digit, suggested by his colleague John Tukey).

Shannon proved mathematically that all information — whether text, audio, image, or video — could be encoded into a sequence of 1s and 0s. The human meaning of the message was irrelevant to the engineering problem of transmitting it. By decoupling meaning from mechanics, Shannon unified all communication media under a single mathematical framework.

Information Entropy: Measuring the Unpredictable

The most revolutionary concept Shannon borrowed from thermodynamics was Entropy. In physics, entropy measures the degree of disorder in a system. Shannon adapted the term to measure the uncertainty or surprise in a data message.

Imagine I send you a predictable message: "The sun rises in the east". That message has very low entropy; it gives you no new information. Now imagine a message containing the access password to a critical database. That message has incredibly high entropy; it is pure surprise and informational value.

Shannon formulated that the amount of information in a message is inversely proportional to its probability. This idea is the cornerstone of:

Data Compression: If a piece of data is highly predictable, we can omit or compress it. This is the principle governing ZIP, MP3, and JPEG formats. It is the exact same math that today allows deep-tech startups to use tensor networks to "squeeze" the redundancy out of LLMs.
Cryptography: During World War II, Shannon worked alongside Alan Turing exchanging ideas on cryptography. A perfectly encrypted message must look like pure random noise; meaning, it must have maximum entropy to an interceptor.
The Shannon Limit: He calculated the theoretical maximum speed at which data can be transmitted without errors over a noisy channel. Today, 5G and Wi-Fi 6 operate astonishingly close to that mathematical limit drawn decades ago.

The Link to Modern AI and Industry 4.0

Shannon's influence didn't stop at telecommunications. Today, Information Theory is the connective tissue of the industrial data architectures and artificial intelligence systems we build and operate.

When in the S&OP Engineering series we use Prophet to extract the "signal" of demand from the "noise" of seasonality and dirty data anomalies, we are directly applying Shannon's principles of channel and noise. Separating signal from noise is the foundational problem of predictive analytics.

When cybersecurity platforms like Devo ingest petabytes of network telemetry looking for the anomaly that betrays a lateral attack, what they are really doing is looking for unexpected entropy spikes in a channel that should behave predictably. The attacker generates entropy; the analyst detects it.

The Legacy of the Solitary Genius

Unlike other contemporary tech giants who sought fame or founded corporate empires, Shannon was a playful academic. He spent his free time building chess machines, juggling robots, a mechanical mouse named Theseus (one of the first Machine Learning experiments capable of solving mazes), and an "Ultimate Machine" that, when turned on, simply popped a hand out of a box to turn itself off.

Claude Shannon's legacy is the ultimate demonstration of First Principles Thinking. Instead of trying to build a better telephone cable, Shannon retreated to the chalkboard and asked: What is information?

By answering that fundamental question, he didn't build a better tool; he invented the entire ecosystem in which all our tools operate. All the software, all the cloud infrastructure, and all the autonomous AI agents we deploy today live, breathe, and communicate within the mathematical universe that Shannon imagined in 1948.

Sources of Interest:

Claude Shannon: El Hombre que Convirtió el Mundo en Bits y Definió el Futuro de la IA

Daniel — Sun, 21 Jun 2026 08:15:17 +0000

Hay figuras históricas que descubren continentes, y hay figuras que inventan la física subyacente que permite que existan los barcos. En el mundo de la tecnología y los datos, Claude Shannon pertenece inequívocamente a la segunda categoría. Si hoy puedes leer este artículo en tu pantalla, si tu smartphone puede comprimir una foto de 12 megapíxeles, y si Multiverse Computing puede comprimir un LLM masivo en un chip periférico, es porque Shannon dictó las leyes matemáticas de la información hace más de 75 años.

Mientras Abraham Wald nos enseñaba a leer el silencio de los datos ausentes y W. Edwards Deming sistematizaba la calidad industrial, Shannon hizo algo aún más fundamental: aisló el concepto de 'información' del significado físico del mensaje.

El Nacimiento del Bit: Bell Labs, 1948

Para entender el logro titánico de Shannon, hay que entender el caos que era la comunicación a principios del siglo XX. El telégrafo, el teléfono, la radio y la televisión se consideraban fenómenos físicos distintos. Los ingenieros mejoraban la transmisión reduciendo el ruido eléctrico en los cables, pero no existía una teoría unificada.

En 1948, trabajando en los míticos laboratorios Bell, Shannon publicó "Una Teoría Matemática de la Comunicación". En sus páginas, Shannon introdujo por primera vez en la historia impresa la palabra "bit" (una contracción de binary digit, sugerida por su colega John Tukey).

Shannon demostró matemáticamente que toda información —ya sea texto, audio, imagen o video— podía codificarse en una secuencia de 1s y 0s. El significado humano del mensaje era irrelevante para el problema de la ingeniería de transmitirlo. Al desacoplar el significado de la mecánica, Shannon unificó todos los medios de comunicación bajo un mismo marco matemático.

La Entropía de la Información: Midiendo lo Impredecible

El concepto más revolucionario que Shannon tomó prestado de la termodinámica fue la Entropía. En física, la entropía mide el grado de desorden de un sistema. Shannon adaptó el término para medir la incertidumbre o sorpresa en un mensaje de datos.

Imagina que te envío un mensaje predecible: "El sol sale por el este". Ese mensaje tiene muy baja entropía; no te aporta información nueva. Ahora imagina un mensaje que contiene la contraseña de acceso a una base de datos crítica. Ese mensaje tiene una entropía altísima; es pura sorpresa y valor informativo.

Shannon formuló que la cantidad de información en un mensaje es inversamente proporcional a su probabilidad. Esta idea es la piedra angular de:

La Compresión de Datos: Si un dato es altamente predecible, podemos omitirlo o comprimirlo. Es el principio que rige los formatos ZIP, MP3 y JPEG. Es la misma matemática que hoy permite a startups deep-tech usar redes de tensores para "exprimir" la redundancia de los LLMs.
La Criptografía: Durante la Segunda Guerra Mundial, Shannon trabajó junto a Alan Turing cruzando ideas sobre criptografía. Un mensaje perfectamente cifrado debe parecer ruido aleatorio puro; es decir, debe tener máxima entropía para un interceptor.
El Límite de Shannon: Calculó la velocidad máxima teórica a la que se pueden transmitir datos sin errores sobre un canal ruidoso. Hoy, el 5G y el Wi-Fi 6 operan asombrosamente cerca de ese límite matemático trazado hace décadas.

El Eslabón con la IA Moderna y la Industria 4.0

La influencia de Shannon no se quedó en las telecomunicaciones. Hoy, la Teoría de la Información es el tejido conectivo de las arquitecturas de datos industriales y de inteligencia artificial que construimos y operamos.

Cuando en la serie de Ingeniería S&OP utilizamos Prophet para extraer la "señal" de la demanda del "ruido" estacional y las anomalías de los datos sucios, estamos aplicando directamente los principios de canal y ruido de Shannon. Separar la señal del ruido es el problema fundacional del análisis predictivo.

Cuando plataformas de ciberseguridad como Devo ingieren petabytes de telemetría de red buscando la anomalía que delate un ataque lateral, lo que realmente están haciendo es buscar picos de entropía inesperados en un canal que debería tener un comportamiento predecible. El atacante genera entropía; el analista la detecta.

El Legado del Genio Solitario

A diferencia de otros gigantes tecnológicos contemporáneos que buscaron la fama o fundaron imperios corporativos, Shannon era un académico juguetón. Pasaba su tiempo libre construyendo máquinas de ajedrez, malabares robotizados, un ratón mecánico llamado Theseus (uno de los primeros experimentos de Machine Learning capaz de resolver laberintos) y una "Máquina Definitiva" que, al encenderse, simplemente sacaba una mano de una caja para apagarse a sí misma.

El legado de Claude Shannon es la demostración definitiva del Pensamiento desde los Primeros Principios (First Principles Thinking). En lugar de intentar construir un cable telefónico mejor, Shannon se retiró al pizarrón y se preguntó: ¿Qué es la información?

Al responder a esa pregunta fundamental, no construyó una herramienta mejor; inventó el ecosistema entero en el que todas nuestras herramientas operan. Todo el software, toda la infraestructura cloud, y todos los agentes de IA autónomos que desplegamos hoy, viven, respiran y se comunican dentro del universo matemático que Shannon imaginó en 1948.

Fuentes de Interés:

The Hidden Economics of AI: What It Actually Costs to Run LLMs in Production (With Real Data)

Daniel — Sun, 14 Jun 2026 08:13:27 +0000

There is an inconvenient truth the artificial intelligence industry prefers to whisper rather than proclaim: the real cost of putting an LLM into production almost never matches the API invoice. It's like buying a car and discovering that the dealership price didn't include the wheels, the insurance, or the fuel. The label says "$0.15 per million input tokens." What it doesn't say is how many millions of tokens your agent will burn in a delegation loop that spirals out of control at 3 AM.

I know this because it happened to me. Over the past six months I've operated autonomous agent systems in real production: the Autopilot Project (9 installments) to automate content distribution across social media, and the Obsolescence Engineering series (7 installments) with a 24/7 agentic radar to monitor supply chain risks. This article is not a theoretical exercise: it is an X-ray of my real invoices, my mistakes, and my lessons learned.

The Iceberg: What the API Invoice Doesn't Tell You

The most dangerous mistake when budgeting a generative AI project is confusing the API cost with the total system cost. It's like measuring the cost of a restaurant only by the price of the ingredients. In my experience operating these systems, the API represents roughly 15-25% of the real cost. The rest is the submerged iceberg:

Cost Layer	What It Includes	Typical %
LLM API	Input/output tokens, context caching	15-25%
Infrastructure	GitHub Actions (minutes), Netlify Functions, Supabase	25-35%
Engineer Time	Agent debugging, prompt tuning, defensive programming	30-40%
Silent Costs	Retries on failures, infinite loops, token overconsumption	10-15%

The third block — engineer time — is where most projects die. As I documented in the Autopilot post-mortem, models are stochastic: you run the same pipeline ten times and get ten different results. This means you can't test an AI agent the way you test a conventional microservice. You need defensive programming, output validation with JSON Schemas, and retries with exponential backoff. Every hour invested in that engineering has a cost.

The Comparison No One Makes: Gemini vs GPT-4o vs Claude in Real Production

The LLM comparisons flooding the internet typically measure academic benchmarks: MMLU, HumanEval, logical reasoning. That's fine for research papers, but in production what matters is the cost-quality-reliability equation per specific task. Here is my operational experience with the three main models:

Criterion	Gemini 2.5 Flash	GPT-4o	Claude Sonnet 4
Input Cost (per 1M tokens)	$0.15	$2.50	$3.00
Output Cost (per 1M tokens)	$0.60	$10.00	$15.00
Average latency (complete response)	~2.1s	~3.8s	~4.5s
JSON reliability (structured output)	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
System prompt adherence	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Creativity / "personality"	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

The price difference between Gemini Flash and its competitors is not a percentage: it's an order of magnitude. For high-volume, low-creativity tasks — classification, structured data extraction, email parsing — Gemini Flash is unbeatable. That's exactly why I chose it as the engine for the obsolescence agentic radar: I needed to run hundreds of analyses per month without the bill spiraling out of control.

However, when the task demands nuance, personality, or complex reasoning, the quality difference justifies the price. In the Autopilot Project, the agent writing LinkedIn posts with a "corporate" tone and the one writing tweets with a "cynical" tone (Part 3) performed significantly better with premium-tier models. The lesson: there is no "best model," there is the right model for each task in your pipeline.

Anatomy of a Real Invoice: The Autopilot Project

Let's break down the actual costs of operating the Autopilot Project during a typical month. This system analyzes each new blog post, generates optimized content for Twitter and LinkedIn in two languages (ES/EN), runs a quality audit, and publishes automatically with human approval.

Item	Monthly Cost	Notes
Gemini API (Flash + Pro)	~€1.20	~4 executions/month, ~50K tokens per execution
GitHub Actions (CI/CD minutes)	€0.00	Free tier: 2,000 min/month (more than enough)
Brevo (Newsletter)	€0.00	Free tier: 300 emails/day
Netlify (Functions + Hosting)	€0.00	Free tier: 125K invocations/month
Supabase (PostgreSQL)	€0.00	Free tier: 500MB, 2 projects
Domain (datalaria.com)	~€1.50	Monthly prorated
Engineer time	¿?	The real hidden cost
Total infrastructure	~€2.70/month

Yes, you read that right: less than 3 euros per month to operate a complete AI agent system with automated social media publishing, newsletter, and CI/CD. The key lies in three deliberate architectural decisions:

Gemini Flash as the main engine: At $0.15/M input tokens, the cost per execution is cents, not euros.
Aggressive free tiers: GitHub Actions, Netlify, Supabase, and Brevo offer generous free plans that comfortably cover an individual project or early-stage startup.
On-demand execution: The pipeline doesn't run 24/7 — it only triggers on each new post (event-driven), avoiding the cost of always-on servers.

The Loop Trap: When Your Agent Burns Money on Its Own

But the invoice isn't always that friendly. In the Autopilot post-mortem I documented a critical failure every engineer should know about: CrewAI's infinite delegation loops. When an agent can't find the expected answer, it can re-delegate the task to itself in a loop that consumes tokens exponentially until GitHub Actions kills the process on timeout (SIGTERM at 60 minutes).

In a single failed execution, that loop can consume more tokens than an entire month of normal operation. It's the digital equivalent of leaving a tap running overnight. The solution is brutally simple, yet nobody implements it by default:

max_iter and max_execution_time on every CrewAI agent
Output validation with Pydantic before passing to the next agent
Cost alerts configured in the Google Cloud console
Circuit breakers that kill execution if consumption exceeds a threshold

The 10x Rule: When It's Worth Paying More

After six months operating these systems, I've distilled a pragmatic rule I call the 10x Rule: a more expensive model is only justified if it produces a result at least 10 times better on the metric that matters for your use case. What does "10 times better" mean?

In classification: 10x fewer classification errors
In content generation: 10x fewer human correction iterations
In data extraction: 10x fewer verifiable hallucinations
In latency: 10x faster on the user's critical path

If the improvement is 20-30%, stick with the cheap model. If it's 2x-3x, evaluate. If it's 10x, don't think twice. This rule led me to use Gemini Flash for 90% of tasks and reserve premium models only for creative content generation.

Looking Ahead: The Deflation of Intelligence

There is a macro trend every engineer needs to have on their radar: the cost per token is falling at a brutal pace. Gemini Flash in June 2025 cost $0.35/M input tokens. One year later, it costs $0.15 — a 57% drop in 12 months. If this trend holds (and everything suggests it will accelerate with competition from open-source models like Llama and Mistral), in two years we'll be talking about API costs that are essentially free for most use cases.

That doesn't mean AI will be free. It means the cost will definitively shift from the API to the engineer: the ability to design robust systems, implement defensive programming, and orchestrate complex pipelines will be the true competitive differentiator. The model will be a commodity; the architecture will be the moat.

As W. Edwards Deming — to whom I dedicated a full article — put it: "It is not enough to do your best; you must first know what to do." In the hidden economics of AI, knowing which model to use, when to use it, and when not to use it is the most valuable skill you can develop.

Sources of Interest:

La Economía Oculta de la IA: Cuánto Cuesta Realmente Usar LLMs en Producción (Con Datos Reales)

Daniel — Sun, 14 Jun 2026 08:06:44 +0000

Hay una verdad incómoda que la industria de la inteligencia artificial prefiere susurrar en lugar de proclamar: el coste real de poner un LLM en producción casi nunca coincide con la factura de la API. Es como comprar un coche y descubrir que el precio del concesionario no incluía ni las ruedas, ni el seguro, ni la gasolina. La etiqueta dice "0,15$ por millón de tokens de entrada". Lo que no dice es cuántos millones de tokens quemará tu agente en un bucle de delegación que se descontrola a las 3 de la madrugada.

Lo sé porque me ha pasado. Durante los últimos seis meses he operado sistemas de agentes autónomos en producción real: el Proyecto Autopilot (9 entregas) para automatizar la distribución de contenido en redes sociales, y la serie de Ingeniería de la Obsolescencia (7 entregas) con un radar agéntico 24/7 para monitorear riesgos en la cadena de suministro. Este artículo no es un ejercicio teórico: es una radiografía de mis facturas reales, mis errores y mis lecciones aprendidas.

El Iceberg: Lo que la Factura de la API No te Cuenta

El error más peligroso al presupuestar un proyecto de IA generativa es confundir el coste de la API con el coste total del sistema. Es como medir el coste de un restaurante solo por el precio de los ingredientes. En mi experiencia operando estos sistemas, la API representa aproximadamente un 15-25% del coste real. El resto es el iceberg sumergido:

Capa de Coste	Qué Incluye	% Típico
API del LLM	Tokens de entrada/salida, caché de contexto	15-25%
Infraestructura	GitHub Actions (minutes), Netlify Functions, Supabase	25-35%
Tiempo de Ingeniero	Debugging de agentes, prompt tuning, programación defensiva	30-40%
Costes Silenciosos	Reintentos por fallos, bucles infinitos, sobre-consumo de tokens	10-15%

El tercer bloque —el tiempo de ingeniero— es donde la mayoría de los proyectos mueren. Como documenté en el post-mortem del Autopilot, los modelos son estocásticos: ejecutas el mismo pipeline diez veces y obtienes diez resultados diferentes. Eso significa que no puedes testear un agente IA como testeas un microservicio convencional. Necesitas programación defensiva, validación de output con JSON Schemas, y reintentos con backoff exponencial. Cada hora invertida en esa ingeniería tiene un coste.

La Comparativa que Nadie Hace: Gemini vs GPT-4o vs Claude en Producción Real

Las comparativas de LLMs que abundan online suelen medir benchmarks académicos: MMLU, HumanEval, razonamiento lógico. Eso está bien para papers de investigación, pero en producción lo que importa es la ecuación coste-calidad-fiabilidad por tarea concreta. Aquí va mi experiencia operativa con los tres modelos principales:

Criterio	Gemini 2.5 Flash	GPT-4o	Claude Sonnet 4
Coste Input (por 1M tokens)	$0,15	$2,50	$3,00
Coste Output (por 1M tokens)	$0,60	$10,00	$15,00
Latencia media (respuesta completa)	~2,1s	~3,8s	~4,5s
Fiabilidad JSON (structured output)	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Respeto de instrucciones de sistema	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Creatividad / "personalidad"	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

La diferencia de precio entre Gemini Flash y sus competidores no es un porcentaje: es un orden de magnitud. Para tareas de alto volumen y baja creatividad —clasificación, extracción de datos estructurados, parsing de emails— Gemini Flash es imbatible. Es exactamente por eso que lo elegí como motor del radar agéntico de obsolescencia: necesitaba ejecutar cientos de análisis al mes sin que la factura se disparara.

Sin embargo, cuando la tarea exige matiz, personalidad o razonamiento complejo, la diferencia de calidad justifica el precio. En el Proyecto Autopilot, el agente que escribía posts para LinkedIn con tono "corporativo" y el que escribía tweets con tono "cínico" (Parte 3) rendían significativamente mejor con modelos de gama alta. La lección: no existe el "mejor modelo", existe el modelo correcto para cada tarea de tu pipeline.

Anatomía de una Factura Real: El Proyecto Autopilot

Desglosemos los costes reales de operar el Proyecto Autopilot durante un mes típico. Este sistema analiza cada nuevo post del blog, genera contenido optimizado para Twitter y LinkedIn en dos idiomas (ES/EN), pasa por una auditoría de calidad, y publica automáticamente con aprobación humana.

Concepto	Coste Mensual	Notas
Gemini API (Flash + Pro)	~1,20 €	~4 ejecuciones/mes, ~50K tokens por ejecución
GitHub Actions (CI/CD minutes)	0,00 €	Free tier: 2.000 min/mes (sobra para esto)
Brevo (Newsletter)	0,00 €	Free tier: 300 emails/día
Netlify (Functions + Hosting)	0,00 €	Free tier: 125K invocaciones/mes
Supabase (PostgreSQL)	0,00 €	Free tier: 500MB, 2 proyectos
Dominio (datalaria.com)	~1,50 €	Prorrateado mensual
Tiempo de ingeniero	¿?	El verdadero coste oculto
Total infraestructura	~2,70 €/mes

Sí, has leído bien: menos de 3 euros al mes para operar un sistema completo de agentes IA con publicación automatizada en redes sociales, newsletter y CI/CD. La clave está en tres decisiones arquitectónicas deliberadas:

Gemini Flash como motor principal: A $0,15/M tokens de entrada, el coste por ejecución es de céntimos, no de euros.
Free tiers agresivos: GitHub Actions, Netlify, Supabase y Brevo ofrecen generosos planes gratuitos que cubren sobradamente un proyecto individual o una startup temprana.
Ejecución bajo demanda: El pipeline no corre 24/7, solo se activa con cada nuevo post (evento), evitando el coste de servidores siempre encendidos.

La Trampa de los Bucles: Cuando tu Agente Quema Dinero Solo

Pero la factura no siempre es tan amable. En el post-mortem del Autopilot documenté un fallo crítico que todo ingeniero debería conocer: los bucles de delegación infinita de CrewAI. Cuando un agente no encuentra la respuesta esperada, puede re-delegarse la tarea a sí mismo en un bucle que consume tokens exponencialmente hasta que GitHub Actions mata el proceso por timeout (SIGTERM a los 60 minutos).

En una sola ejecución fallida, ese bucle puede consumir más tokens que un mes entero de operación normal. Es el equivalente digital de dejar un grifo abierto toda la noche. La solución es brutalmente simple pero nadie la implementa de serie:

max_iter y max_execution_time en cada agente CrewAI
Validación de output con Pydantic antes de pasar al siguiente agente
Alertas de coste configuradas en la consola de Google Cloud
Circuit breakers que matan la ejecución si el consumo supera un umbral

La Regla del 10x: Cuándo Merece la Pena Pagar Más

Después de seis meses operando estos sistemas, he destilado una regla pragmática que llamo la Regla del 10x: un modelo más caro solo se justifica si produce un resultado al menos 10 veces mejor en la métrica que importa para tu caso de uso. ¿Qué significa "10 veces mejor"?

En clasificación: 10x menos errores de clasificación
En generación de contenido: 10x menos iteraciones humanas de corrección
En extracción de datos: 10x menos alucinaciones verificables
En latencia: 10x más rápido en la ruta crítica del usuario

Si la mejora es de un 20-30%, quédate con el modelo barato. Si es de un 2x-3x, evalúa. Si es de un 10x, no lo pienses. Esta regla me llevó a usar Gemini Flash para el 90% de las tareas y reservar modelos premium solo para la generación creativa de contenido.

Mirando al Futuro: La Deflación de la Inteligencia

Hay una tendencia macro que todo ingeniero debe tener en el radar: el coste por token está cayendo a un ritmo brutal. Gemini Flash en junio de 2025 costaba $0,35/M tokens de entrada. Un año después, cuesta $0,15 — una caída del 57% en 12 meses. Si esta tendencia se mantiene (y todo indica que se acelerará con la competencia de modelos open-source como Llama y Mistral), en dos años estaremos hablando de costes de API que serán esencialmente gratuitos para la mayoría de los casos de uso.

Eso no significa que la IA será gratis. Significa que el coste se desplazará definitivamente de la API al ingeniero: la capacidad de diseñar sistemas robustos, implementar programación defensiva, y orquestar pipelines complejos será el verdadero diferencial competitivo. El modelo será un commodity; la arquitectura será el moat.

Como bien decía W. Edwards Deming —al que dediqué un artículo completo— : "No basta con hacer lo mejor que puedas; primero debes saber qué hacer". En la economía oculta de la IA, saber qué modelo usar, cuándo usarlo y cuándo no usarlo es la habilidad más valiosa que puedes desarrollar.

Fuentes de Interés:

Devo: How a Self-Taught Chemist from Madrid Built the Data Engine That Defends the U.S. Air Force

Daniel — Sun, 07 Jun 2026 21:55:59 +0000

On the cyber battlefield, where a state-sponsored attacker can compromise credentials and move laterally through a military network in just 18 minutes and 49 seconds, every second of detection delay can mean the difference between defending critical infrastructure or losing it. Yet for years, the cybersecurity industry accepted as normal that its analytics tools took up to 15 minutes to process a single security log.

This is the story of Devo, the chronicle of how a self-taught chemist from Madrid identified that absurd gap in the trenches of a Spanish bank, founded a startup that investors tried to wrestle away from him, and ended up building the real-time data engine that today protects the networks of the United States Air Force. A journey from the operational chokepoints of the financial sector to unicorn status at a $1.9 billion valuation.

The Origin: A Phishing Attack and an Obsession with Speed

Devo's seed didn't germinate in a Silicon Valley garage, but in the crisis room of Bankinter in 2003. Pedro Castillo doesn't fit the mold of the conventional tech entrepreneur. A graduate in Chemical Sciences from the Universidad Complutense de Madrid, he discovered his true calling by chance when he stumbled upon a Silicon Graphics computer in his faculty, sparking a fascination that led him to learn programming entirely on his own.

In the mid-1990s, when the internet was still the exclusive domain of universities and government agencies, Castillo was already providing advanced IT services to corporations like El Corte Inglés, Spain's largest department store chain. That early experience culminated in the founding of Webline in 1996, his first cybersecurity company, which opened the doors to Spain's financial sector. Bankinter, one of the country's most innovative banks, recruited him and eventually elevated him to Director of Technology Security.

It was precisely in those banking trenches where everything changed. In 2003, a sophisticated phishing attack struck Bankinter. Castillo and his team hit a paralyzing obstacle: the tools of the era were incapable of ingesting and correlating the massive volumes of data generated by servers, firewalls, and network traffic fast enough to stop the attack before fraud was committed. Existing solutions imposed an impossible choice: pay exorbitant costs to store everything, or filter the data and create "blind spots" that attackers would inevitably exploit.

Obsessed with unlocking the value of raw data, Castillo left his comfortable executive position and founded Logtrust in Madrid in 2011. His philosophy was radical: while other startups rushed to conferences and press coverage, he and his team entrenched themselves in software development, building a database engine from scratch. A product that was, in his own words, "absolutely differential."

The Technological Revolution: HyperStream and Zero Latency

Why did Devo manage to dethrone giants like Splunk in multiple bids? The answer lies in a radical reengineering of security data processing.

The industry standard, dominated by Splunk, relied on index-on-ingest: data had to be parsed, normalized, and structured into a massive index before being stored. This design created three critical weaknesses:

Lethal delay: In high-volume environments, events took over 15 minutes to become available to the analyst.
Resource contention: Index reading and writing shared CPU resources, degrading performance precisely when speed was most urgent.
Prohibitive costs: Maintaining petabyte-scale indexes forced executives to create "blind spots," leaving up to a third of their systems unmonitored.

Devo completely discarded traditional indexing and built HyperStream, a proprietary streaming analytics technology based on opposing principles:

Ingest without normalization: Data is stored in its original format. The platform applies the schema at query time (schema-on-read), not at ingestion.
Immutable micro-indexes: Instead of a global index, HyperStream creates a daily micro-index per data source that, once generated, is never rewritten. The result: 10:1 compression and massive parallelization.
Zero latency: Telemetry is available for alerts and searches at the exact millisecond it hits disk.

The convergence of these innovations enabled an unprecedented achievement: maintaining 400 days of "always-hot" data, queryable in sub-seconds. While competitors archived old data in cold, inaccessible storage, a forensic analyst using Devo could investigate a year-old intrusion with the same speed as if it had occurred five minutes ago.

The Trial by Fire: Defending U.S. Air Force Networks

HyperStream's definitive validation came in July 2020, when Devo was awarded a $9.5 million contract with the United States Air Force to deploy its technology as the central SIEM for the Enterprise Cyberspace Security & Defense program.

The situation was critical: cyber squadrons operated on a SIEM dating back to 1999 that aggregated up to 70 disconnected applications, generating over 8 million daily alerts with no automated correlation capability. The operational environment was, as senior commanders described it, analogous to a cockpit where the pilot had to press 40 different buttons just to fire a single missile. The military's "12N12" initiative demanded a drastic but necessary consolidation: replacing those 70 chaotic applications with approximately 12 functional tools within 12 months.

The results of Devo's deployment were transformative:

A single pane of glass that eliminated operational fragmentation.
Over 20,000 human hours saved in manual threat triage.
Reorientation of cyber analysts from repetitive tasks to proactive threat hunting against state-sponsored actors.

The Venture Capital Crucible: From Boardroom Battles to Unicorn Status

Devo's financial journey was as intense as its engineering. In early 2017, the first $11 million round brought what Castillo described as a "terrible situation": investors attempted to force his removal as CEO to install an external corporate profile. The intervention of Insight Partners, which led a $35 million Series B, stabilized governance and backed the founder's technical vision.

In 2018, coinciding with the Series C, Logtrust was rebranded as Devo (a contraction of "Data Evolution") and relocated its headquarters to Cambridge/Boston, Massachusetts—establishing its commercial epicenter in the world's most competitive tech market—while keeping its engineering heart in Madrid. The name change was no mere marketing exercise: Devo was no longer just a log repository but a true data operations platform capable of unifying historical and streaming data from applications, IT operations, security, IoT, and industrial machines. The hypergrowth that followed was explosive: 80% year-over-year revenue growth and an astonishing 136% client growth by 2021.

Round	Date	Capital	Lead Investor(s)	Milestone
Venture Round	Jan 2017	$11M	Kibo Ventures, Atlantic Bridge	Initial expansion
Series B	Sep 2017	$35M	Insight Partners	Leadership stabilization
Series C	Jun 2018	$25M	Insight Partners, Kibo Ventures	Devo rebrand; HQ to Boston
Series D	Sep 2020	$60M	Georgian, Bessemer Venture	Marc van Zadelhoff, new CEO
Series E	Oct 2021	$250M	TCV, General Atlantic, Eurazeo	Unicorn: $1.5B
Series F	Jun 2022	$100M	TCV, Insight, Bessemer	Valuation: $1.9B

The Future: Agentic AI and Strike48

But massive ingestion isn't enough if the organization cannot respond to findings with equal speed. The contemporary Security Operations Center (SOC) suffers from a systemic ailment: alert fatigue. An average corporate SOC receives over 4,400 daily alerts from more than 28 different security tools, and 53% of those alerts are false positives that consume irretrievable time. With a global shortage estimated at 4.8 million cybersecurity professionals, automation has ceased to be a luxury and become an existential necessity.

In 2026, Devo leaped forward into Agentic Artificial Intelligence with the launch of Strike48. Instead of copilots that passively assist the analyst, Strike48 deploys a squadron of autonomous micro-agents that execute complex investigations: correlating alerts, identifying "patient zero," collecting forensic evidence, and building visual evidence trees, stopping only for human approval of irreversible actions.

The architecture also solves a devastating problem: companies monitor only 66% of their systems due to budget constraints imposed by legacy SIEMs. Strike48's connectors query data directly where it resides—AWS buckets, data lakes, existing Splunk installations—without duplicating storage, granting the AI agents the omniscient visibility needed to detect what previously lurked in the shadows. In early trial deployments, this model reduced Mean Time to Detection (MTTD) to under eight minutes, uncovering stealthy campaigns that legacy tools had completely missed.

As a final note in this trajectory: having consolidated Devo as an undisputed titan, Pedro Castillo proved his serial-entrepreneur credentials by founding Onum in 2023, a platform to reduce data pipeline noise by 80%. The validation was swift: in August 2025, it was acquired by CrowdStrike.

Conclusion: Engineering Against Dogma

The story of Devo demonstrates that transformational change doesn't spring from bold commercial strategies, but from the stubborn engineering conviction to question accepted dogma. While the entire industry kept building bigger indexes, a self-taught chemist from Madrid asked: "What if the index is the problem?"

That question, answered through a decade of obsessive engineering and the resilience to survive venture capital power plays, produced an engine capable of protecting everything from a Spanish bank to the most demanding military cyberspace on the planet. Pedro Castillo's journey—from a chemistry lab at the Complutense to the innovation hubs of Massachusetts, through the banking trenches of Madrid—is a powerful reminder that, in the age of Big Data, battles aren't won with more ammunition, but with faster weapons. And in that arena, the machine-speed processing that Devo has mastered may well be the only reliable defense against threats that operate at that very same speed.

Sources of Interest:

Devo: Cómo un Químico Autodidacta Construyó desde Madrid el Motor de Datos que Defiende a la Fuerza Aérea de EE.UU.

Daniel — Sun, 07 Jun 2026 21:51:21 +0000

En el campo de batalla del ciberespacio, donde un atacante patrocinado por un estado puede comprometer credenciales y moverse lateralmente a través de una red militar en apenas 18 minutos y 49 segundos, cada segundo de retraso en la detección puede significar la diferencia entre defender una infraestructura crítica o perderla. Sin embargo, durante años, la industria de la ciberseguridad aceptó como normal que sus herramientas de análisis tardaran hasta 15 minutos en procesar un simple registro de seguridad.

Esta es la historia de Devo, la crónica de cómo un químico madrileño autodidacta identificó esa brecha absurda en las trincheras de un banco español, fundó una startup que los inversores intentaron arrebatarle, y terminó construyendo el motor de datos en tiempo real que hoy protege las redes de la Fuerza Aérea de los Estados Unidos. Un viaje desde la asfixia operativa del sector financiero hasta el estatus de unicornio valorado en 1.900 millones de dólares.

El Origen: Un Ataque de Phishing y una Obsesión por la Velocidad

La semilla de Devo no germinó en un garaje de Silicon Valley, sino en la sala de crisis de Bankinter en 2003. Pedro Castillo no responde al arquetipo del emprendedor tecnológico convencional. Licenciado en Ciencias Químicas por la Universidad Complutense de Madrid, descubrió su verdadera vocación de forma fortuita al encontrar un ordenador Silicon Graphics en su facultad, lo que despertó una fascinación que le llevó a aprender a programar de manera completamente autodidacta.

A mediados de los años noventa, cuando Internet era aún territorio exclusivo de universidades y organismos gubernamentales, Castillo ya prestaba servicios informáticos avanzados a corporaciones como El Corte Inglés. Esa experiencia temprana culminó con la fundación de Webline en 1996, su primera empresa de ciberseguridad, que le abrió las puertas del sector financiero español. Bankinter, una de las entidades más innovadoras del país, lo reclutó hasta convertirlo en Director de Seguridad Tecnológica.

Fue precisamente en esas trincheras bancarias donde todo cambió. En 2003, un sofisticado ataque de phishing golpeó a Bankinter. Castillo y su equipo se encontraron con un obstáculo paralizante: las herramientas de la época eran incapaces de ingerir y correlacionar los volúmenes masivos de datos generados por servidores, cortafuegos y tráfico de red a la velocidad necesaria para detener el ataque antes de que se consumara el fraude. Las soluciones existentes imponían una elección imposible: pagar costes exorbitantes para almacenarlo todo, o filtrar los datos y crear «puntos ciegos» que los atacantes explotarían inevitablemente.

Obsesionado con liberar el valor del dato en bruto, Castillo abandonó su cómoda posición ejecutiva y fundó Logtrust en Madrid en 2011. Su filosofía fue radical: mientras otras startups corrían a las conferencias y a la prensa, él y su equipo se atrincheraron en el desarrollo de software, construyendo un motor de base de datos desde cero. Un producto, en sus propias palabras, «absolutamente diferencial».

La Revolución Tecnológica: HyperStream y la Latencia Cero

¿Por qué Devo logró desbancar a gigantes como Splunk en múltiples licitaciones? La respuesta reside en una reingeniería radical del procesamiento de datos de seguridad.

El estándar de la industria, dominado por Splunk, dependía de la indexación durante la ingesta (index-on-ingest): los datos debían ser analizados, normalizados y estructurados en un índice masivo antes de almacenarse. Este diseño creaba tres debilidades críticas:

Retraso letal: En entornos de alto volumen, los eventos tardaban más de 15 minutos en estar disponibles para el analista.
Contención de recursos: La lectura y escritura del índice compartían CPU, degradando el rendimiento justo cuando más urgía la velocidad.
Costes prohibitivos: Mantener índices de petabytes obligaba a los directivos a crear «puntos ciegos», dejando de monitorizar hasta un tercio de sus sistemas.

Devo descartó por completo la indexación tradicional y construyó HyperStream, una tecnología propietaria de análisis en streaming basada en principios opuestos:

Ingesta sin normalización: Los datos se almacenan en su formato original. La plataforma aplica el esquema en el momento de la consulta (schema-on-read), no al guardar el dato.
Micro-índices inmutables: En lugar de un índice global, HyperStream crea un micro-índice diario por fuente de datos que, una vez generado, nunca se reescribe. Resultado: compresión 10:1 y paralelización masiva.
Latencia cero: La telemetría está disponible para alertas y búsquedas en el milisegundo exacto en que toca el disco.

La convergencia de estas innovaciones permitió un logro sin precedentes: mantener 400 días de datos «siempre calientes», consultables en sub-segundos. Mientras los competidores archivaban los datos antiguos en almacenamiento frío e inconsultable, un analista forense con Devo podía investigar una intrusión de hace un año con la misma velocidad que si hubiera ocurrido hace cinco minutos.

La Prueba de Fuego: Defender las Redes de la Fuerza Aérea de EE.UU.

La validación definitiva de HyperStream llegó en julio de 2020, cuando Devo se adjudicó un contrato de 9,5 millones de dólares con la Fuerza Aérea de los Estados Unidos para desplegar su tecnología como SIEM central del programa de Ciberdefensa Empresarial.

La situación era crítica: los escuadrones cibernéticos operaban con un SIEM de 1999 que aglomeraba hasta 70 aplicaciones inconexas, generando más de 8 millones de alertas diarias sin capacidad de correlación automatizada. La iniciativa militar «12N12» exigía consolidar ese caos en 12 herramientas funcionales en 12 meses.

Los resultados del despliegue de Devo fueron transformadores:

Un panel de control unificado que eliminó la fragmentación operativa.
Más de 20.000 horas humanas ahorradas en triaje manual de amenazas.
Reorientación de los analistas cibernéticos de tareas repetitivas hacia la caza proactiva de amenazas contra actores estatales.

El Crisol del Capital Riesgo: De la Batalla en la Junta al Estatus de Unicornio

El camino financiero de Devo fue tan intenso como su ingeniería. A principios de 2017, la primera ronda de 11 millones de dólares trajo consigo lo que Castillo describió como una «situación terrible»: los inversores intentaron forzar su destitución como CEO para imponer un perfil corporativo externo. La intervención de Insight Partners, que lideró una Serie B de 35 millones de dólares, estabilizó la gobernanza y respaldó la visión técnica del fundador.

En 2018, coincidiendo con la Serie C, Logtrust se rebautizó como Devo (contracción de «Data Evolution») y trasladó su sede a Boston, manteniendo la ingeniería en Madrid. El hipercrecimiento que siguió fue explosivo: 80% de crecimiento interanual en ingresos y 136% en clientes hacia 2021.

Ronda	Fecha	Capital	Inversores Principales	Hito
Venture Round	Ene 2017	$11M	Kibo Ventures, Atlantic Bridge	Expansión inicial
Serie B	Sep 2017	$35M	Insight Partners	Estabilización del liderazgo
Serie C	Jun 2018	$25M	Insight Partners, Kibo Ventures	Rebranding a Devo; sede a Boston
Serie D	Sep 2020	$60M	Georgian, Bessemer Venture	Marc van Zadelhoff, nuevo CEO
Serie E	Oct 2021	$250M	TCV, General Atlantic, Eurazeo	Unicornio: $1.500M
Serie F	Jun 2022	$100M	TCV, Insight, Bessemer	Valoración: $1.900M

El Futuro: IA Agentística y Strike48

Pero la ingesta masiva no es suficiente si la organización no puede responder a los hallazgos con igual celeridad. El Centro de Operaciones de Seguridad (SOC) contemporáneo padece un mal sistémico: la fatiga de alertas. Un SOC corporativo promedio recibe más de 4.400 alertas diarias procedentes de más de 28 herramientas de seguridad diferentes, y el 53% de esas alertas son falsos positivos que consumen un tiempo irrecuperable. Con una escasez global estimada en 4,8 millones de profesionales de ciberseguridad, la automatización dejó de ser un lujo para convertirse en una necesidad existencial.

En 2026, Devo dio el salto hacia la Inteligencia Artificial Agentística con el lanzamiento de Strike48. En lugar de copilotos que asisten pasivamente al analista, Strike48 despliega un escuadrón de micro-agentes autónomos que ejecutan investigaciones complejas: correlacionan alertas, identifican al «paciente cero», recopilan evidencia forense y construyen árboles de evidencia visuales, deteniéndose únicamente para la aprobación humana de acciones irreversibles.

La arquitectura resuelve además un problema devastador: las empresas monitorizan apenas un 66% de sus sistemas por restricciones presupuestarias de los SIEM legados. Los conectores de Strike48 interrogan los datos directamente donde residen —buckets de AWS, lagos de datos, instalaciones de Splunk— sin duplicar almacenamiento, otorgando a los agentes de IA la visión omnisciente necesaria para detectar lo que antes quedaba en la sombra. En las implementaciones de prueba tempranas, este modelo redujo el Tiempo Medio de Detección (MTTD) a menos de ocho minutos, descubriendo campañas sigilosas que las herramientas legadas habían pasado completamente por alto.

Como nota final de esta trayectoria: habiendo consolidado a Devo como un titán indiscutible, Pedro Castillo demostró su condición de emprendedor en serie fundando Onum en 2023, una plataforma para reducir el ruido de los pipelines de datos en un 80%. La validación fue fulminante: en agosto de 2025, fue adquirida por CrowdStrike.

Conclusión: Ingeniería Contra Dogma

La historia de Devo es la demostración de que los cambios transformacionales no nacen de estrategias comerciales audaces, sino de la terquedad ingenieril de cuestionar los dogmas aceptados. Mientras la industria entera construía índices cada vez más grandes, un químico autodidacta de Madrid se preguntó: «¿Y si el índice es el problema?».

Esa pregunta, respondida con una década de ingeniería obsesiva y con la resiliencia de sobrevivir a las maniobras del capital riesgo, generó un motor capaz de proteger desde un banco español hasta el ciberespacio militar más exigente del planeta. El trayecto de Pedro Castillo —desde un laboratorio de química en la Complutense hasta los centros de innovación de Massachusetts, pasando por las trincheras bancarias de Madrid— es un recordatorio potente de que, en la era del Big Data, las batallas no se ganan con más munición, sino con armas más rápidas. Y en ese terreno, la velocidad de máquina que Devo ha logrado dominar es, quizás, la única defensa fiable contra las amenazas que operan a esa misma velocidad.

Fuentes de Interés:

W. Edwards Deming: The Father of Total Quality Who Predicted the Future of AI

Daniel — Sun, 31 May 2026 13:54:54 +0000

The contemporary industrial landscape demands robust management frameworks in the face of extreme volatility. At the epicenter of this organizational and analytical architecture stands the monumental philosophy of W. Edwards Deming. Conceived in the early decades of the 20th century, his theoretical approach has transcended the factory floor to become the undisputed foundation of Sales and Operations Planning (S&OP) and the management of complex value networks.

Deming's fundamental premise postulates that quality is not achieved through massive end-of-line inspection, which is reactive and costly. True quality is born from reducing variation in the underlying processes.

The System of Profound Knowledge and Statistical Control

Deming proposed a radical managerial paradigm: the System of Profound Knowledge. This system requires that we optimize the "whole" (the interconnected network) rather than maximizing departmental silos. He taught us that variation is inherent to any activity, but the key to leadership lies in differentiating "chronic variation" (common causes) from "anomalies" (special causes) through Statistical Process Control (SPC).

One of his most destructive insights toward traditional management was the concept of Tampering or over-adjustment. When management (for example, in monthly S&OP meetings) reacts to normal statistical variations as if they were systemic crises by drastically adjusting the plan, it paradoxically amplifies the disaster and increases instability. This is the root cause of why a fearful sales forecast breeds the infamous Bullwhip Effect in the supply chain.

Toyota and the Data-Driven Revolution

Deming's impact was most forcefully seen in the miraculous industrial reconstruction of post-war Japan. Toyota embraced his doctrine, instituting the famous PDCA (Plan-Do-Check-Act) cycle.

Before Deming, decisions depended on instinct. Afterwards, Toyota engineers understood that planning S&OP or designing plant capacity without statistically reliable data was equivalent to walking blindly toward obsolescence. Thanks to him, Toyota eradicated the philosophy of final inspection in favor of "building quality into the process," cementing what the world would later know as Lean Manufacturing.

The Technological Horizon: AI and Concept Drift

Perhaps the most astonishing proof of the immortality of Deming's mathematics is its current application at the frontier of Artificial Intelligence and corporate automation.

The golden rule of modern robotics is: "Stabilize before you automate, always". AI cannot infer precise causalities from a chaotic human workflow or noisy data. Deming's principles of standardization are inescapable prerequisites for any Machine Learning initiative.

Even more profound is how modern data science uses Statistical Process Control to audit AI models themselves. When a real-world predictive model begins to fail due to unforeseen macroeconomic changes (a phenomenon known as Concept Drift), engineers resort to multivariate control charts—essentially, Deming's statistical engine—to mathematically identify when the model is facing a "Special Cause" and requires retraining.

Conclusion

Deming's legacy warns us against blind faith in technology: the only way to tame AI, mitigate global disruptions, and optimize S&OP in our era is to subordinate the overwhelming raw computing power to the inexorable dictates of process stability and variance reduction. Statistical Control is not dead; in fact, today it orchestrates the algorithms that run the world.

References and Further Reading

Deming, W. E. (1993). The New Economics for Industry, Government, Education.
The W. Edwards Deming Institute
History of the Toyota Production System (TPS)

W. Edwards Deming: El Padre de la Calidad Total que Predijo el Futuro de la IA

Daniel — Sun, 31 May 2026 13:51:07 +0000

El panorama industrial contemporáneo exige marcos de gestión robustos frente a la extrema volatilidad. En el epicentro de esta arquitectura organizativa y analítica se encuentra la filosofía monumental de W. Edwards Deming. Concebido en las primeras décadas del siglo XX, su enfoque teórico ha trascendido la planta de producción para convertirse en el cimiento indiscutible de la Planificación de Ventas y Operaciones (S&OP) y la gestión de redes de valor complejas.

La premisa fundamental de Deming postula que la calidad no se logra mediante la inspección masiva al final, que es reactiva y costosa. La verdadera calidad nace de reducir la variación en los procesos subyacentes.

El Sistema de Conocimiento Profundo y el Control Estadístico

Deming proponía un paradigma gerencial radical: el Sistema de Conocimiento Profundo (System of Profound Knowledge). Este sistema requiere que optimicemos el "todo" (la red interconectada) en lugar de maximizar silos departamentales. Nos enseñó que la variación es inherente a cualquier actividad, pero que la clave del liderazgo radica en diferenciar la "variación crónica" (causas comunes) de las "anomalías" (causas especiales) mediante el Control Estadístico de Procesos (SPC).

Uno de sus insights más destructivos hacia la gestión tradicional fue el concepto de Tampering o sobre-ajuste. Cuando la gerencia (por ejemplo, en las reuniones mensuales de S&OP) reacciona a variaciones estadísticas normales como si fueran crisis sistémicas ajustando el plan drásticamente, paradójicamente amplifica el desastre y aumenta la inestabilidad. Esta es la raíz de por qué un pronóstico de ventas asustadizo engendra el infame Efecto Látigo en la cadena de suministro.

Toyota y la Revolución Impulsada por Datos

El impacto de Deming se vio con mayor contundencia en la milagrosa reconstrucción industrial del Japón de la posguerra. Toyota abrazó su doctrina, instaurando el famoso ciclo PDCA (Planificar-Hacer-Verificar-Actuar).

Antes de Deming, las decisiones dependían del instinto. Después, los ingenieros de Toyota comprendieron que planificar el S&OP o diseñar capacidad de planta sin datos estadísticamente fiables equivalía a caminar a ciegas hacia la obsolescencia. Gracias a él, Toyota erradicó la filosofía de inspección final en favor de "construir la calidad dentro del proceso", cimentando lo que más tarde el mundo conocería como Lean Manufacturing.

El Horizonte Tecnológico: IA y Concept Drift

Quizás la prueba más asombrosa de la inmortalidad de las matemáticas de Deming es su aplicación actual en la frontera de la Inteligencia Artificial y la automatización corporativa.

La regla fundamental de la robótica moderna es: "Estabilizar antes de automatizar, siempre". La IA no puede inferir causalidades precisas a partir de un flujo de trabajo humano caótico o datos ruidosos. Los principios de estandarización de Deming son requisitos ineludibles para cualquier iniciativa de Machine Learning.

Aún más profundo es cómo la ciencia de datos moderna utiliza el Control Estadístico de Procesos para vigilar a los propios modelos de IA. Cuando un modelo predictivo en el mundo real comienza a fallar debido a cambios macroeconómicos imprevistos (un fenómeno conocido como Concept Drift o Deriva de Concepto), los ingenieros recurren a gráficos de control multivariantes—esencialmente, el motor estadístico de Deming—para identificar matemáticamente cuándo el modelo está enfrentando una "Causa Especial" y requiere ser reentrenado.

Conclusión

El legado de Deming nos advierte frente a la fe ciega en la tecnología: la única forma de domar la IA, mitigar las disrupciones globales y optimizar el S&OP en nuestra era es subordinar la abrumadora potencia de cálculo a los inexorables dictámenes de la estabilidad del proceso y la reducción de la varianza. El Control Estadístico no ha muerto; de hecho, hoy orquesta a los algoritmos que mueven el mundo.

Fuentes de interés

Deming, W. E. (1993). The New Economics for Industry, Government, Education.
The W. Edwards Deming Institute
Historia del Sistema de Producción Toyota (TPS)

Leonid Kantorovich: The Mathematician Who Challenged Stalin with Linear Programming

Daniel — Sun, 24 May 2026 15:19:47 +0000

The history of mathematical economics and data science is bound to a fundamental human need: the optimal allocation of scarce resources to maximize performance. At the epicenter of this revolution stands Leonid Vitaliyevich Kantorovich, the Soviet mathematician whose pioneering work laid the foundations for linear programming.

Today, tools like PuLP or SciPy in Python handle optimization algorithms as everyday occurrences. But in 1938, formulating these mathematics under the watchful eye of Joseph Stalin required both intellectual genius and sheer bravery.

The Plywood Trust Challenge

Leonid Kantorovich was a prodigy. At 22, he was already a full professor at Leningrad University. However, the birth of linear programming happened in an accidental and pragmatic way.

In 1938, the Plywood Trust approached Kantorovich with a problem: how should they optimally allocate their limited resources (machinery and different woods) to maximize production while meeting strict State quotas?

Traditional analysis required exhaustively comparing all production combinations, a brute-force approach that was impossible to compute. Kantorovich realized he was facing a "very special extreme problem" and developed the "method of resolving multipliers".

He classified resources in order of their productive advantage, managing to increase the Trust's joint production from 77 to 86 units without a single extra worker or new machine. Modern resource optimization was born.

The Shadow Price and the Schism with Orthodoxy

The most revolutionary aspect of Kantorovich's work was the discovery of Duality Theory. His multipliers acted as dual variables that measured the "marginal rate of change" upon adding one extra unit of a restrictive resource. In the West, this would be known as the Shadow Price.

But in the Stalinist USSR, this was heresy.

The Soviet economy was inflexibly based on Marx's Labor Theory of Value: the value of a good is 100% the human labor used to produce it. Kantorovich demonstrated mathematically that value also emanated from resource scarcity and opportunity cost. His calculations gave price to inert machinery and land.

When Kantorovich submitted his findings to Gosplan (the state economic planning agency) in 1943, he was met with absolute institutional condemnation. His work was forcibly shelved for defying Marxist dogma.

From Industrial Sabotage to the Nobel Prize

Kantorovich proceeded tactically by applying his methods to local engineering. In 1948, he optimized steel sheet stamping in a train car factory, reducing waste (scrap) by an astounding 50%.

But in the Soviet central economy, that inefficiency was already planned: adjacent smeltering plants needed that scrap as an input. By becoming efficient, Kantorovich collapsed the local supply chain. He was summoned by the Communist Party on charges of "industrial sabotage", a sentence that could mean the Gulag or the firing squad.

History tells that he was secretly saved by the Soviet military high command. The military desperately needed his optimizing genius for tactical logistics and atomic development.

After Stalin's death and the "Khrushchev Thaw," Kantorovich's work finally saw international light in 1956, connecting with the independent discoveries of George Dantzig (creator of the Simplex Algorithm) and Tjalling Koopmans.

Finally, history did him justice. In 1975, Leonid Kantorovich received the Nobel Memorial Prize in Economic Sciences alongside Tjalling Koopmans, for their invaluable contributions to the theory of optimum allocation of resources.

The Architecture of Efficiency

The next time you import an optimization library in Python or run a linear solver to plan your company's logistics, remember Leonid Kantorovich. His algorithm doesn't just solve matrices; it is a testament to how the rigor of data and pure mathematics can penetrate the thickest iron curtains in history.

References and Further Reading

Kantorovich, L. V. (1939). Mathematical Methods of Organizing and Planning Production.
Leonid Kantorovich - Biographical (Nobel Prize)
History of Operations Research (INFORMS)

Leonid Kantorovich: El Matemático que Desafió a Stalin con la Programación Lineal

Daniel — Sun, 24 May 2026 15:07:51 +0000

La historia de la economía matemática y la ciencia de datos está ligada a una necesidad humana fundamental: la asignación óptima de recursos escasos para maximizar el rendimiento. En el epicentro de esta revolución se encuentra Leonid Vitaliyevich Kantorovich, el matemático soviético cuyo trabajo pionero sentó las bases de la programación lineal.

Hoy en día, herramientas como PuLP o SciPy en Python asumen algoritmos de optimización como algo cotidiano. Pero en 1938, formular estas matemáticas bajo la mirada de Iósif Stalin requería tanto genio intelectual como valentía pura.

El Desafío del Trust de la Madera Contrachapada

Leonid Kantorovich era un prodigio. A los 22 años ya era profesor titular en la Universidad de Leningrado. Sin embargo, el nacimiento de la programación lineal ocurrió de forma accidental y pragmática.

En 1938, el Trust de la Madera Contrachapada se acercó a Kantorovich con un problema: ¿cómo asignar de manera óptima sus recursos limitados (maquinaria y diferentes maderas) para maximizar la producción, cumpliendo las cuotas del Estado?

El análisis tradicional requería comparar exhaustivamente combinaciones de producción, un enfoque de fuerza bruta imposible de calcular. Kantorovich comprendió que estaba ante un "problema extremo especial" y desarrolló el "método de los multiplicadores resolventes".

Clasificó los recursos en orden de su ventaja productiva, logrando que el Trust pasara de producir 77 a 86 unidades conjuntas sin un solo trabajador extra o nueva maquinaria. Había descubierto la optimización de recursos moderna.

El Precio Sombra y el Cisma con la Ortodoxia

El aspecto más revolucionario del trabajo de Kantorovich fue el descubrimiento de la Teoría de la Dualidad. Sus multiplicadores actuaban como variables duales que medían la "tasa de cambio marginal" al añadir una unidad extra de un recurso restrictivo. En Occidente, a esto se le llamaría el Precio Sombra.

Pero en la URSS estalinista, esto era una herejía.

La economía soviética se basaba inflexiblemente en la Teoría del Valor-Trabajo de Marx: el valor de un bien es 100% el trabajo humano usado para producirlo. Kantorovich demostraba matemáticamente que el valor también emanaba de la escasez del recurso y el costo de oportunidad. Sus cálculos daban precio a la maquinaria inerte y a la tierra.

Cuando Kantorovich envió sus descubrimientos al Gosplan (la agencia estatal de planificación) en 1943, fue recibido con una condena institucional absoluta. Su trabajo fue archivado a la fuerza por desafiar el dogma marxista.

Del Sabotaje Industrial al Premio Nobel

Kantorovich procedió tácticamente aplicándose a la ingeniería local. En 1948, optimizó el troquelado de láminas de acero en una fábrica de vagones de tren, reduciendo el desperdicio (chatarra) en un asombroso 50%.

Pero en la economía central soviética, esa ineficiencia ya estaba planificada: las plantas de fundición adyacentes necesitaban esa chatarra como insumo. Al volverse eficiente, Kantorovich colapsó el suministro local. Fue citado por el Partido Comunista bajo acusación de "sabotaje industrial", una condena que podía significar el Gulag o el paredón.

Cuenta la historia que fue salvado en secreto por el alto mando militar soviético. El ejército necesitaba desesperadamente su genio optimizador para la logística táctica y el desarrollo atómico.

Tras la muerte de Stalin y el "Deshielo de Jruschov", el trabajo de Kantorovich por fin vio la luz internacional en 1956, conectándose con los descubrimientos independientes de George Dantzig (creador del Algoritmo Simplex) y Tjalling Koopmans.

Finalmente, la historia le hizo justicia. En 1975, Leonid Kantorovich recibió el Premio Nobel de Ciencias Económicas junto a Tjalling Koopmans, por sus inestimables contribuciones a la teoría de asignación óptima de recursos.

La Arquitectura de la Eficiencia

La próxima vez que importes una librería de optimización en Python o ejecutes un solver lineal para planificar la distribución logística de tu empresa, recuerda a Leonid Kantorovich. Su algoritmo no solo resuelve matrices; es un testamento de cómo el rigor de los datos y las matemáticas puras pueden atravesar las cortinas de hierro más densas de la historia.

Fuentes de interés

Kantorovich, L. V. (1939). Métodos Matemáticos de Organización y Planificación de la Producción.
Leonid Kantorovich - Biografía (Premio Nobel)
Historia de la Investigación de Operaciones (INFORMS)