DEV Community: Khavel

Evaluación RAG en producción: métricas, datasets y gates antes de cambiar tu pipeline

Khavel — Mon, 06 Jul 2026 09:18:12 +0000

Un RAG que responde bonito puede estar fallando justo donde importa: recuperar evidencia, citar contexto correcto y no inventar. Esta guía baja la evaluación RAG a ingeniería operable.

Evaluación RAG en producción significa medir por separado recuperación, generación, groundedness, completitud, coste y regresiones. Si solo miras si la respuesta suena bien, estás evaluando una demo, no un sistema.

TL;DR

La keyword principal es evaluación RAG producción. La intención de búsqueda en español es práctica: construir un set de pruebas, elegir métricas y poner gates antes de cambiar embeddings, chunking, reranking, prompts o modelos.

Mi postura: el primer dashboard de RAG no debería ser bonito. Debería decirte qué pregunta falló, qué documentos recuperó, qué evidencia faltó, qué parte inventó el modelo y qué cambio del pipeline lo provocó.

Qué problema resuelve la evaluación RAG

RAG promete respuestas con fuentes, pero esa promesa se rompe en varias capas. Puede fallar el chunking, el embedding, el filtro por permisos, el reranker, el prompt, el modelo o el formato de citas. La respuesta final puede sonar razonable aunque la evidencia recuperada sea pobre.

Por eso evaluar RAG como una sola caja negra es cómodo y peligroso. Necesitas separar al menos dos preguntas: ¿recuperé el contexto correcto? y ¿el modelo usó ese contexto sin inventar?. Si mezclas ambas, arreglarás prompts cuando el problema era retrieval, o tocarás embeddings cuando el modelo estaba ignorando fuentes buenas.

La evaluación seria no intenta demostrar que el RAG funciona. Intenta encontrar dónde deja de funcionar antes que tus usuarios.

El pipeline sano mide componentes, no solo respuestas: dataset, retrieval, generación, jueces, umbrales, trazas y revisión humana de fallos.

La arquitectura mental: dataset, pipeline, jueces y gates

Un sistema de evaluación RAG tiene cuatro piezas. Primero, un dataset con preguntas reales, respuestas esperadas y, cuando se pueda, documentos relevantes. Segundo, una forma reproducible de ejecutar el pipeline contra esas preguntas. Tercero, evaluadores que midan retrieval y respuesta. Cuarto, gates que bloqueen cambios cuando hay regresión.

El dataset no tiene que empezar grande. Prefiero 40 preguntas bien elegidas a 1.000 preguntas sintéticas que nadie revisó. Debe mezclar casos frecuentes, preguntas ambiguas, consultas con permisos, preguntas sin respuesta, cambios recientes y ejemplos donde el RAG haya fallado en producción.

Los gates no deberían exigir perfección. Deberían exigir que no empeores lo que ya funcionaba y que los fallos importantes queden visibles. Un umbral imperfecto con trazas revisables gana a una promesa manual de que alguien revisará respuestas de vez en cuando.

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import Faithfulness, AnswerRelevancy, ContextPrecision, ContextRecall

rows = [
    {
        "question": "¿Cómo se rota una clave de API en producción?",
        "answer": run_rag("¿Cómo se rota una clave de API en producción?").answer,
        "contexts": run_rag("¿Cómo se rota una clave de API en producción?").contexts,
        "ground_truth": "Rotar clave, desplegar secreto nuevo, invalidar el anterior y auditar uso.",
    },
]

dataset = Dataset.from_list(rows)
result = evaluate(
    dataset,
    metrics=[Faithfulness(), AnswerRelevancy(), ContextPrecision(), ContextRecall()],
)

print(result)

MIN_SCORES = {
    "faithfulness": 0.85,
    "answer_relevancy": 0.80,
    "context_precision": 0.70,
    "context_recall": 0.75,
}

for metric, minimum in MIN_SCORES.items():
    score = float(result[metric])
    if score < minimum:
        raise SystemExit(f"RAG regression: {metric}={score:.2f} < {minimum}")

Métricas que sí separan el problema

Context precision pregunta si los chunks recuperados eran útiles para responder. Es la métrica que castiga meter basura en el prompt. Un top-k lleno de documentos vagamente parecidos puede parecer generoso, pero baja precisión y encarece cada respuesta.

Lo que conviene comprobar

Context recall pregunta si recuperaste la evidencia necesaria. Es la métrica que detecta el fallo contrario: el modelo responde mal porque el dato correcto nunca llegó al contexto. Si recall cae, tocar el prompt rara vez arregla el fondo.

Faithfulness o groundedness mide si la respuesta está soportada por el contexto. Es el antídoto contra la alucinación con fuentes decorativas. Answer relevancy mide si la respuesta contesta la pregunta. Factual correctness o response completeness comparan contra una referencia cuando existe ground truth.

Dataset: empieza pequeño, pero con dientes

Un dataset útil para RAG debe guardar query, expected_answer, expected_sources o qrels, usuario/tenant cuando hay permisos, categoría de pregunta, dificultad y notas de fallo. Si solo guardas pregunta y respuesta, no podrás saber si falló retrieval o generación.

Incluye preguntas negativas: no lo sé, documentos inexistentes, términos parecidos, permisos cruzados y datos obsoletos. Un RAG que siempre contesta es más peligroso que uno que sabe negarse.

Cada incidente real debería producir al menos un caso de evaluación. Si soporte reporta una respuesta falsa, no lo cierres solo cambiando prompt. Añade una prueba que falle antes del fix y pase después. Ese hábito convierte producción en fuente de evals, no en un sitio donde repetir errores.

Retrieval: mide ranking, no solo similitud

El retrieval no termina en embeddings. También importan filtros, permisos, búsqueda híbrida, reranking, deduplicación, ventanas de contexto y orden final. Un cambio de top_k=5 a top_k=12 puede mejorar recall y empeorar faithfulness porque mete ruido que el modelo no sabe ignorar.

Cuando tienes documentos relevantes etiquetados, usa métricas de ranking como recall@k, MRR o NDCG. Cuando no los tienes, usa jueces LLM para estimar relevancia del contexto, pero conserva ejemplos revisables. Un juez sin auditoría puede esconder errores sistemáticos.

Mi regla práctica: antes de cambiar embeddings o reranker, congela 30 consultas y compara exactamente qué documentos entran en el prompt. Si no puedes explicar diferencias de retrieval, todavía no estás haciendo optimización; estás tocando knobs.

Generación: groundedness no es lo mismo que utilidad

Una respuesta puede ser grounded y mala: cita el contexto correcto, pero no ayuda al usuario. Otra puede ser útil y peligrosa: contesta perfecto, pero añade una afirmación que no estaba en las fuentes. Por eso necesitas varias métricas, no una nota final.

Groundedness mira precisión contra contexto: no inventar fuera de la evidencia. Completeness mira recall contra una respuesta esperada: no omitir partes críticas. Relevance mira si contestas la pregunta. Correctness mira si el contenido coincide con ground truth.

Para decisiones de producto, muestra los fallos con trazas: pregunta, chunks, respuesta, score, razón del juez y diff contra versión anterior. Un número agregado sirve para ver tendencia; el ejemplo concreto sirve para arreglar.

Jueces LLM: útiles, pero no oráculos

Los evaluadores basados en LLM son prácticos porque muchas respuestas no tienen una única cadena exacta. OpenAI Evals, LangSmith, Ragas, LlamaIndex, Microsoft Foundry y DeepEval convergen en la misma idea: define criterios, pasa ejemplos y usa jueces para puntuar dimensiones concretas.

Pero un juez LLM también es un modelo. Debes fijar modelo, temperatura, prompt del juez, versión del dataset y umbrales. Si cambias el juez al mismo tiempo que cambias el RAG, no sabrás si mejoró el sistema o cambió la regla de medición.

Reserva revisión humana para muestras de alto impacto: respuestas con baja confianza, discrepancias entre jueces, cambios grandes en ranking y preguntas de seguridad, privacidad o cumplimiento. La automatización reduce volumen; no elimina responsabilidad.

Cómo poner gates sin bloquear todo el equipo

Divide los gates en tres niveles. En PR, ejecuta un subset pequeño y barato: smoke tests, preguntas críticas y regresiones recientes. En nightly, ejecuta dataset completo con métricas y comparación contra baseline. En producción, monitoriza muestras, feedback de usuario, coste y drift de recuperación.

No uses un único umbral global. Un RAG legal, financiero o de soporte interno puede exigir groundedness muy alta. Un buscador exploratorio puede tolerar más ruido si cita fuentes y deja claro el nivel de confianza.

Los gates deben fallar con información accionable. faithfulness baja no basta. El informe debe decir qué pregunta, qué respuesta, qué chunks y qué cambio introdujo la regresión.

Coste, latencia y evaluación continua

Evaluar también cuesta. Si cada cambio dispara cien llamadas a un juez caro, el equipo acabará saltándose evals. Usa capas: métricas deterministas para retrieval cuando hay qrels, jueces baratos para smoke tests y jueces más fuertes para releases importantes.

Lo que conviene comprobar

Mide coste por dimensión. Retrieval puede degradar por latencia antes de degradar calidad. Un reranker puede subir relevancia y duplicar coste. Un modelo generador mejor puede ocultar retrieval mediocre durante un tiempo. Sin costes por paso, la optimización queda incompleta.

En producción, guarda traces suficientes: query normalizada, filtros aplicados, documentos candidatos, documentos finales, prompt, modelo, respuesta, scores y feedback. Sin trazas, cada bug de RAG se convierte en una discusión subjetiva.

Errores comunes que veo en equipos

Evaluar solo diez preguntas felices porque son las que salen bien en demo.
Cambiar chunking, embedding, reranker y prompt en el mismo PR.
Medir respuesta final sin guardar documentos recuperados.
Usar un juez LLM sin versionar su prompt ni revisar ejemplos fallidos.
Optimizar answer relevancy mientras context recall está roto.
No incluir preguntas sin respuesta, permisos, datos caducados y casos hostiles.
Tratar las citas como HTML bonito en vez de evidencia verificable.

Plan de adopción en cinco días

Día 1: exporta 40 preguntas reales y clasifícalas por tipo, riesgo y frecuencia.
Día 2: añade expected answer y fuentes esperadas para los casos donde tengas ground truth.
Día 3: ejecuta tu pipeline actual y guarda respuesta, chunks, modelo, coste y latencia.
Día 4: calcula context precision, context recall, faithfulness y answer relevancy; revisa manualmente los diez peores casos.
Día 5: crea un gate de CI con subset crítico y un informe nightly con dataset completo.

Conclusión

La evaluación RAG no va de encontrar la métrica perfecta. Va de crear una máquina de aprendizaje técnico: cada fallo produce un caso, cada cambio compara contra baseline y cada release sabe qué ganó y qué perdió.

Mi recomendación es empezar menos ambicioso y más disciplinado: dataset pequeño, trazas completas, métricas separadas, gates modestos y revisión humana de fallos. Cuando eso funcione, amplía corpus, jueces y monitorización. El orden contrario produce dashboards bonitos y RAG frágil.

Preguntas frecuentes

¿Qué es evaluación RAG?

Evaluación RAG es el proceso de medir si un sistema retrieval-augmented generation recupera evidencia relevante y genera respuestas correctas, completas y fieles al contexto.

¿Qué métricas usar para RAG en producción?

Empieza con context precision, context recall, faithfulness o groundedness, answer relevancy, correctness cuando tengas referencia, coste y latencia por paso.

¿Necesito ground truth para evaluar RAG?

No siempre. Puedes evaluar relevancia y groundedness con query, contexto y respuesta, pero los casos con ground truth permiten medir recall, completitud y regresiones con más precisión.

¿Ragas, LangSmith, LlamaIndex o DeepEval?

Elige según stack. Lo importante es versionar dataset, criterios, juez y baseline; la herramienta concreta importa menos que la disciplina de evaluación.

¿Cuántas preguntas necesito para empezar?

Con 30-50 preguntas reales y bien etiquetadas puedes detectar fallos importantes. Después amplía con incidentes, logs de búsqueda y casos sintéticos revisados.

¿La evaluación automática reemplaza revisión humana?

No. Reduce volumen y detecta regresiones, pero los fallos de alto impacto siguen necesitando revisión humana y trazas auditables.

Cómo montar una evaluación RAG mínima en producción

Inventariar casos. Reúne preguntas reales, incidentes, consultas frecuentes, preguntas sin respuesta y casos con permisos.
Etiquetar evidencia. Añade respuesta esperada y documentos relevantes cuando exista ground truth; marca categoría y riesgo.
Capturar trazas. Guarda query, filtros, chunks candidatos, chunks finales, prompt, modelo, respuesta, coste y latencia.
Medir retrieval. Calcula context precision, context recall y ranking cuando tengas documentos relevantes etiquetados.
Medir respuesta. Evalúa groundedness, answer relevancy, completeness y correctness según el tipo de pregunta.
Crear baseline. Fija versión de dataset, prompt, modelo, judge y umbrales antes de optimizar.
Bloquear regresiones. Ejecuta un subset crítico en PR y el dataset completo en nightly o antes de release.
Cerrar el bucle. Convierte cada fallo real en una prueba nueva y revisa manualmente los casos de alto riesgo.

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

¿Te sirve esto? Cada semana resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos, en español y sin ruido. Suscríbete gratis a DevAI Semanal.

Fuentes y referencias

Claude Opus 4.8 vs GPT-5.5 — the actual 2026 price and context numbers

Khavel — Sun, 05 Jul 2026 11:43:29 +0000

"Claude or GPT" is still the first question every team building on an LLM API asks, and the answer usually arrives as vibes. Here are the numbers instead. I maintain a catalog of model prices and lifecycles, so this is the current frontier-flagship comparison, pulled from each provider's own pricing page.

The two flagships, side by side

	Claude Opus 4.8 (Anthropic)	GPT-5.5 (OpenAI)
Input / 1M tokens	$5.00	$5.00
Output / 1M tokens	$25.00	$30.00
Cached input / 1M	$0.50	$0.50
Context window	1,000,000	1,050,000
Status	GA	GA

The input price and the cached-input price are identical ($5.00 and $0.50). The context windows are effectively tied at ~1M tokens. The one number that differs is output: GPT-5.5 charges 20% more ($30 vs $25 per 1M).

Where that 20% actually matters

Output-heavy vs input-heavy workloads land in different places, so a single "which is cheaper" verdict is wrong. Two concrete monthly examples:

Input-heavy (RAG / long-context Q&A) — say 10M input + 2M output:

Claude Opus 4.8: (10 × $5) + (2 × $25) = $100/mo
GPT-5.5: (10 × $5) + (2 × $30) = $110/mo

Output-heavy (agents / code generation) — say 2M input + 8M output:

Claude Opus 4.8: (2 × $5) + (8 × $25) = $210/mo
GPT-5.5: (2 × $5) + (8 × $30) = $250/mo

So they're within ~10% on retrieval-style traffic, but Claude is ~16% cheaper once your workload is dominated by generated tokens — which is exactly the shape of agentic coding and long-form generation. If you're input-heavy, it's close enough that other factors (tokenizer, tool-use reliability, latency) decide it.

One caveat that trips everyone up: tokens aren't a shared unit

Price-per-token comparisons quietly assume both models count tokens the same way. They don't. Anthropic and OpenAI use different tokenizers, so the same paragraph of English can be a different number of tokens on each. A 5–15% difference in token count for the same text is normal, and it moves the real bill in the same direction as the price difference. Treat these figures as the starting point, then measure your own prompts on both.

The third option people skip: Google undercuts both

If you're anchored on "Claude vs GPT," you're comparing the two most expensive frontier options and ignoring the cheapest-per-quality tier:

Model	Input / 1M	Output / 1M	Status
Gemini 3.1 Pro	$2.00	$12.00	Preview
Gemini 3.5 Flash	$1.50	$9.00	GA
Gemini 3.1 Flash-Lite	$0.25	$1.50	GA

On that same input-heavy 10M-in/2M-out workload, Gemini 3.5 Flash costs ~$33/mo — roughly a third of either flagship — and Gemini 3.1 Flash-Lite is ~$5.50/mo. They won't match Opus 4.8 or GPT-5.5 on the hardest reasoning, but for classification, extraction, summarization, and most chat, paying frontier prices is a choice, not a requirement.

And if raw cost is the only axis, open-weight and Chinese-lab models go lower still — DeepSeek-V4-Flash is ~$0.14/$0.28, Llama 3.1 8B ~$0.02/$0.03.

The short version

Input-heavy work: Opus 4.8 and GPT-5.5 are within ~10% — pick on capability/ergonomics, not price.
Output-heavy work (agents, code): Claude Opus 4.8 is ~16% cheaper thanks to the $25 vs $30 output rate.
Cost-sensitive work: don't default to either flagship — Gemini Flash is ~3× cheaper, and the value tier below that is another order of magnitude down.
Always re-measure token counts on your own prompts; the per-token price is only half the bill.

I keep the full side-by-side (and every other pair) updated here: aimodelwatch.dev/compare/claude-opus-4-8-vs-gpt-5-5. Prices change and models get deprecated without much warning — there's a free email alert on the site if you want a heads-up when a model you use changes price or gets a retirement date.

Numbers verified 2026-07-05 against platform.openai.com and ai.google.dev. Spot a figure that's drifted? Tell me — accuracy is the whole point.

Vercel AI SDK: cómo montar agentes en Next.js con streaming, tools y MCP

Khavel — Sat, 04 Jul 2026 09:20:36 +0000

Vercel AI SDK no es solo una librería de chat. Bien usado, es la capa TypeScript que conecta UI, streaming, tools, MCP, salida estructurada, agentes y observabilidad sin casarte con un único proveedor de modelos.

Vercel AI SDK es un toolkit TypeScript para construir productos de IA con streaming, chat UI, tool calling, salida estructurada, agentes y proveedores intercambiables. Su valor real aparece cuando dejas de tratarlo como un wrapper de fetch y lo usas como contrato entre frontend, backend, tools y observabilidad.

TL;DR

La keyword principal es Vercel AI SDK agentes Next.js. La intención de búsqueda en español es práctica: montar un chat o agente en Next.js que pueda transmitir tokens, llamar herramientas, validar JSON, integrarse con MCP y medirse en producción.

Mi postura: AI SDK encaja muy bien si tu producto ya vive en TypeScript/Next.js y necesitas velocidad de iteración. No sustituye una arquitectura de permisos, persistencia ni evaluación; solo hace que la parte LLM tenga menos pegamento accidental.

Qué es Vercel AI SDK y qué no es

Vercel AI SDK es una capa común para hablar con modelos, producir streams, definir tools, validar entradas y salidas, renderizar mensajes en UI y conectar proveedores. Su promesa no es que el modelo razone mejor, sino que tu aplicación tenga una interfaz estable para cambiar de modelo, añadir herramientas y operar el flujo sin reescribir media app.

No es una base de datos, no es un sistema de permisos y no es una cola duradera. Si el agente necesita memoria, auditoría, trazabilidad de negocio o jobs largos, debes diseñar esas piezas aparte. El SDK puede orquestar llamadas y streams; la responsabilidad del producto sigue siendo tuya.

El error habitual es empezar por el chat visual. El orden profesional es distinto: caso de uso, contrato de mensajes, tools permitidas, política de aprobación, límites de coste, persistencia, métricas y solo después UI.

Arquitectura mínima para llevar Vercel AI SDK de demo a producto: UI de chat, route handler, agente, tools tipadas, MCP, datos y métricas.

Arquitectura mínima en Next.js

El patrón base en App Router es sencillo: el cliente usa useChat, el servidor expone un route.ts, el handler convierte mensajes de UI a mensajes de modelo, streamText genera la respuesta y el resultado vuelve como stream compatible con la UI. Esa cadena parece trivial, pero define el contrato de producción.

En el cliente, no trates messages como texto plano. AI SDK trabaja con partes: texto, tool calls, aprobaciones, errores y metadatos. Si renderizas solo message.content, perderás estados importantes. En aplicaciones reales, la UI debe saber si una herramienta está esperando aprobación, si falló o si produjo salida utilizable.

En el servidor, la frontera importante es el route handler. Ahí defines modelo, system prompt, tools, límites de pasos, timeouts, abort signals, logging y tags de coste. Si esa lógica queda repartida entre componentes, server actions y helpers ocultos, luego no podrás auditar por qué el agente hizo algo.

app/api/chat/route.ts

import { convertToModelMessages, streamText, stepCountIs, tool } from "ai";
import { z } from "zod";

const tools = {
  buscarDocs: tool({
    description: "Busca documentación interna del producto",
    inputSchema: z.object({ query: z.string().min(3) }),
    outputSchema: z.object({ resumen: z.string(), fuentes: z.array(z.string()) }),
    execute: async ({ query }) => searchDocs(query),
  }),
};

export async function POST(req: Request) {
  const { messages } = await req.json();
  const result = streamText({
    model: "openai/gpt-4.1",
    system: "Responde como asistente técnico. Cita fuentes internas cuando uses tools.",
    messages: await convertToModelMessages(messages),
    tools,
    stopWhen: stepCountIs(5),
  });

  return result.toUIMessageStreamResponse();
}

Salida estructurada con Zod

import { generateText, Output } from "ai";
import { z } from "zod";

const { output } = await generateText({
  model: "openai/gpt-4.1",
  output: Output.object({
    schema: z.object({
      riesgo: z.enum(["bajo", "medio", "alto"]),
      motivo: z.string(),
      acciones: z.array(z.string()),
    }),
  }),
  prompt: "Evalua este cambio antes de permitir que el agente lo aplique...",
});

Streaming: dónde se gana y dónde se rompe

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

El streaming mejora percepción de velocidad, pero también cambia cómo piensas estados. Un endpoint clásico falla o responde. Un stream puede empezar bien, llamar una tool, pedir aprobación, emitir texto parcial, fallar en una tool y aun así dejar una conversación recuperable.

Lo que conviene comprobar

Para un chat de soporte interno, streaming de texto basta. Para un agente que ejecuta herramientas, necesitas mostrar estados de tool, no solo palabras. El usuario debe entender si el agente está buscando, esperando permiso, ejecutando una acción o resumiendo resultados.

Mi regla: cualquier tool que tarde más de dos segundos debe producir estado visible. Cualquier tool que cambie datos debe dejar rastro. Cualquier salida que se use en automatización debe validarse con schema antes de aceptarla.

Tools: contratos pequeños, permisos explícitos

Las tools son la frontera de seguridad del agente. En AI SDK se definen con inputSchema y, cuando tiene sentido, outputSchema. Eso obliga a describir qué puede pedir el modelo y qué devuelve tu sistema. Si una tool acepta string libre para ejecutar acciones, no tienes una tool: tienes un agujero con buena DX.

Empieza con tools de lectura: buscar documentación, consultar tickets, recuperar métricas. Después añade mutaciones pequeñas: crear borrador, abrir issue, proponer patch. Las acciones irreversibles necesitan aprobación humana o una política automática muy estrecha.

Las herramientas deben ser aburridas. Una tool buena hace una cosa, valida input, aplica permisos del usuario real, registra llamada, devuelve salida acotada y falla con errores interpretables. El modelo no debería decidir permisos por contexto conversacional.

MCP sin convertirlo en barra libre

AI SDK puede consumir tools de servidores MCP, lo cual es útil si ya tienes conectores estandarizados. Pero MCP no elimina el problema de confianza. Un servidor remoto puede exponer muchas capacidades y el agente puede combinarlas de formas que no habías previsto.

Para producción prefiero allowlists de tools, scopes por entorno y separación entre lectura y escritura. Un agente que resume documentación no necesita la misma superficie que un agente que abre pull requests o toca datos de cliente.

La buena arquitectura trata MCP como un catálogo de capacidades, no como permiso universal. Descubrir herramientas dinámicamente es cómodo; aprobar cuáles entran en producción sigue siendo una decisión de ingeniería.

Agentes: ToolLoopAgent no arregla un mal proceso

El salto de streamText a un agente aparece cuando quieres varios pasos: pensar, llamar tools, observar resultados, decidir si continuar y terminar. En AI SDK, el patrón de agente evita que escribas tú el bucle manual, pero no decide por ti cuándo parar ni qué acciones son seguras.

Define stopWhen con intención. Un límite de pasos demasiado alto puede consumir coste y tiempo sin mejorar respuesta. Un límite demasiado bajo corta workflows legítimos. Para empezar, usa pocos pasos, mide trayectorias reales y sube solo si hay evidencia.

No llames agente a cualquier chat con tools. Un agente de producto debe tener objetivo, herramientas, estado observable, política de error, evaluación y dueño. Si no puedes explicar esos puntos, lo que tienes es una demo con autonomía estética.

Structured output: cuándo validar JSON

Salida estructurada es la pieza que más rápido mejora calidad cuando el resultado alimenta otro sistema. Si el modelo decide prioridad, riesgo, campos de una tarea, clasificación o acciones siguientes, no aceptes markdown: pide objeto validado con schema.

Esto no garantiza verdad, pero sí garantiza forma. La verdad se verifica con datos, tests o revisión. La forma se valida con Zod y tipos. Mezclar ambas cosas es una fuente clásica de bugs: un JSON válido puede ser una decisión equivocada.

Úsalo para contratos internos: decision, confidence, citations, next\_actions, requires\_approval. Si el objeto no pasa schema, la app debe pedir aclaración o degradar, no inventar campos.

Observabilidad y coste

El valor de AI SDK en producción aumenta cuando lo conectas con métricas: modelo, tokens, latencia, tool calls, pasos, errores, finish reason, usuario, feature y coste estimado. Sin eso, solo sabrás que el chat 'a veces va lento' o que la factura subió.

Vercel AI Gateway puede ayudar con routing, visibilidad y control de proveedores si tu despliegue ya está en Vercel. LiteLLM o gateways propios encajan mejor cuando necesitas una capa multi-cloud o políticas internas más fuertes. La decisión no es religiosa: elige el punto donde puedes medir y gobernar mejor.

La métrica de negocio no es tokens por respuesta. Es tareas resueltas con intervención aceptable. Un agente barato que obliga a revisar todo puede salir caro. Un agente caro que elimina una hora semanal de trabajo repetitivo puede ser rentable.

Checklist de producción

Define una keyword técnica interna para cada flujo: soporte, análisis, extracción, copilot interno o agente de operaciones.
Separa rutas de chat humano, generación estructurada y ejecución de acciones.
Usa schemas para tool input, tool output y objetos que consumirá otro sistema.
Aplica permisos fuera del prompt: usuario, tenant, recurso y acción.
Añade aprobación para tools de escritura, pagos, despliegues, borrados o datos sensibles.
Registra modelo, coste, latencia, pasos, tools, errores y usuario.
Persistencia: guarda mensajes y eventos importantes, no solo el texto visible.
Evalúa conversaciones reales antes de subir límites de pasos o tools.
Documenta fallback: modelo alternativo, modo lectura, respuesta parcial o escalado humano.

Cuándo elegir AI SDK frente a OpenAI Agents SDK, LangGraph o Cloudflare Agents SDK

Elige Vercel AI SDK si tu producto está en TypeScript/Next.js y quieres integrar UI, streaming, tools y proveedores con baja fricción. Es especialmente fuerte cuando el frontend y el backend del producto se mueven juntos.

Elige OpenAI Agents SDK si priorizas un stack centrado en OpenAI con tracing, guardrails y handoffs muy integrados. Elige LangGraph si necesitas orquestación explícita de grafos, checkpoints y workflows complejos en Python. Elige Cloudflare Agents SDK si el problema principal es runtime stateful con Durable Objects, WebSockets y scheduling cerca de la edge.

La comparación honesta: AI SDK es probablemente la vía más directa para productos web TypeScript. No es necesariamente la mejor para workflows duraderos, agentes con estado complejo o entornos donde el frontend no importa.

Plan de adopción en cinco días

Día 1: monta un chat mínimo con useChat y un route handler, sin tools. Mide latencia y errores.
Día 2: añade una sola tool de lectura con inputSchema, permisos y logging.
Día 3: introduce salida estructurada para una decisión que hoy parseas desde texto.
Día 4: añade una tool con needsApproval y diseña la UI de aprobación.
Día 5: conecta métricas de coste, pasos y errores; decide si necesitas MCP, gateway o agente multi-step.

Conclusión

Vercel AI SDK merece atención porque resuelve una parte concreta del problema: unir aplicaciones TypeScript con modelos, streams, tools y UI sin escribir pegamento distinto para cada proveedor. Eso es mucho, pero no es todo.

La guía corta es esta: usa AI SDK para acelerar la capa de interacción con modelos; diseña tú la seguridad, persistencia, observabilidad y evaluación. Si esas cuatro piezas no existen, el SDK solo hará que llegues más rápido a una demo difícil de operar.

Preguntas frecuentes

¿Qué es Vercel AI SDK?

Vercel AI SDK es un toolkit TypeScript para construir aplicaciones y agentes de IA con generación de texto, streaming, chat UI, tool calling, salida estructurada y múltiples proveedores de modelos.

¿Vercel AI SDK sirve solo para Next.js?

No. Tiene integración muy buena con Next.js, pero el core puede usarse en otros entornos TypeScript y frameworks compatibles.

¿Cuándo usar streamText?

Usa streamText para experiencias interactivas donde el usuario necesita ver progreso, chat o respuesta incremental, especialmente en UI web.

¿Cuándo usar salida estructurada?

Usa salida estructurada cuando otro sistema vaya a consumir el resultado: clasificaciones, decisiones, extracción de datos, acciones siguientes o contratos de automatización.

¿AI SDK reemplaza a MCP?

No. MCP expone herramientas y contexto; AI SDK puede consumir esas tools y conectarlas al flujo de la app, pero sigues necesitando permisos, allowlists y observabilidad.

¿Necesito AI Gateway?

No siempre. Es útil si quieres routing, observabilidad y control de proveedores en Vercel. Si ya tienes gateway propio, evalúa si añade valor o duplica capas.

Cómo llevar Vercel AI SDK a producción en Next.js

Elegir el flujo. Decide si estás construyendo chat, extracción estructurada, agente multi-step o automatización con aprobación humana.
Crear el route handler. Centraliza modelo, mensajes, tools, límites de pasos, timeouts y logging en un endpoint revisable.
Diseñar tools pequeñas. Define inputSchema, outputSchema, permisos reales y errores interpretables para cada tool.
Añadir streaming UI. Renderiza partes de mensaje, estados de tool y aprobaciones; no trates la respuesta como texto plano.
Validar contratos. Usa salida estructurada para decisiones que alimentan código, base de datos o workflows.
Integrar MCP con allowlist. Conecta solo tools necesarias y separa lectura de escritura por entorno y permiso.
Medir operación. Registra coste, latencia, pasos, tool calls, errores y resultado de negocio antes de ampliar autonomía.

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

OpenAI Agents SDK: MCP, guardrails y tracing MCP outputSchema y structuredContent LiteLLM Proxy: gateway IA, costes y modelos Cloudflare Agents SDK: agentes stateful LangGraph: agentes Python con estado

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

Cursor Background Agents: cómo preparar entornos remotos sin regalar tu repo

Khavel — Fri, 03 Jul 2026 09:17:29 +0000

Cursor Background Agents cambia el flujo de trabajo: agentes remotos, ramas propias y comandos automáticos. La parte difícil es diseñar permisos, entorno y revisión.

Cursor Background Agents no es solo una función cómoda para lanzar tareas mientras haces otra cosa. Es un cambio de arquitectura: el agente trabaja en una máquina remota, clona un repositorio, ejecuta comandos, empuja una rama y deja un cambio revisable. Eso puede ahorrar contexto humano, pero también mueve permisos, secretos y ejecución fuera del portátil del desarrollador.

La idea duradera

La lectura evergreen es clara: cualquier equipo que adopte agentes remotos necesita tratar el entorno como CI/CD con capacidad de edición, no como un chat más del editor. Si el agente tiene acceso a GitHub, internet y terminal auto-run, el control real no está en escribir mejores prompts. Está en configurar el repositorio, el entorno, los permisos y el proceso de revisión.

Qué hace distinto a un background agent

Según la documentación de Cursor, los Background Agents crean agentes asíncronos que editan y ejecutan código en un entorno remoto. El flujo normal es conectar GitHub, elegir repositorio y rama base, lanzar una tarea y revisar después la rama o el PR resultante. También hay entrada desde web, móvil y API, lo que abre casos de uso de automatización más allá del editor de escritorio.

Ese patrón cambia tres supuestos. Primero, el agente no depende de que tu portátil tenga todas las dependencias instaladas. Segundo, puede iterar con comandos de terminal sin pedir aprobación para cada paso como ocurre en algunos flujos foreground. Tercero, el trabajo queda preparado para handoff, revisión y colaboración.

La contrapartida es que ya no basta con confiar en el entorno local. Tienes que decidir qué repos puede clonar la app, qué comandos puede lanzar el entorno, qué secretos llegan a la máquina y quién revisa el diff antes de mezclarlo.

El archivo environment.json como contrato

Cursor documenta .cursor/environment.json como la pieza que describe cómo preparar la máquina: comando de instalación, procesos persistentes y terminales que deben estar vivos durante la sesión. Es tentador meter ahí todo lo que hace funcionar el proyecto, pero conviene verlo como un contrato reproducible y mínimo.

El comando install debe ser idempotente. Si cada ejecución instala dependencias de forma distinta o depende de estado manual, el agente producirá bugs difíciles de reproducir. Los terminals deben levantar servicios necesarios para validar cambios, no procesos auxiliares con acceso amplio a datos internos. Si necesitas Docker, Cursor permite preparar ese arranque, pero no conviene convertir la máquina en una réplica completa de producción.

Un buen environment.json se parece más a una receta de CI que a las notas personales de un desarrollador. Debe instalar lo necesario, arrancar lo justo y evitar pasos que descarguen binarios o scripts no fijados por versión sin revisión.

Permisos de GitHub: empieza pequeño

Background Agents necesitan permisos de lectura y escritura sobre los repositorios donde van a trabajar. Ese permiso es potente: permite clonar, crear ramas y empujar cambios. La decisión correcta no es conectar toda la organización por comodidad, sino empezar con repositorios concretos y tareas acotadas.

Para un piloto, limita el agente a repos de bajo riesgo o a mirrors sin secretos. Usa ramas base específicas, reglas de protección, revisiones obligatorias y checks de CI. Si el agente abre un PR, el merge debe seguir el mismo estándar que un cambio humano: tests, linters, revisión de seguridad y dueño técnico.

El acceso a dependencias privadas y submódulos merece revisión aparte. Dar acceso a un monorepo puede implicar acceso transitivo a más código del que la tarea necesita. Si el objetivo es arreglar documentación, no debería requerir permisos sobre servicios críticos.

Auto-run no es magia, es superficie de ataque

La documentación de Cursor advierte que los background agents ejecutan comandos de terminal automáticamente para iterar sobre tests, y que eso introduce riesgo de exfiltración si una instrucción maliciosa consigue influir en el agente. Este punto es el centro de la guía: el problema no es que el agente pueda equivocarse, sino que un README, issue, fixture, log o dependencia puede intentar darle instrucciones hostiles.

El mitigante práctico es reducir lo que un comando puede ver y enviar. No inyectes secretos de producción en el entorno. Usa tokens efímeros y con scope mínimo. Evita que tests de agente dependan de bases de datos reales. Bloquea publicación de artefactos sensibles en logs. Y trata cualquier salida generada por fuentes no confiables como datos, no como instrucciones.

Si necesitas que el agente ejecute comandos peligrosos, el diseño debe cambiar: crea una tarea manual, exige aprobación humana o mueve esa validación a CI con credenciales controladas. Auto-run debe validar, no desplegar producción.

Privacidad y retención

Cursor indica que Background Agents están disponibles con Privacy Mode, pero también que el código se conserva temporalmente para ejecutar el agente y que la ejecución ocurre en infraestructura remota. Eso no es necesariamente incompatible con un equipo serio, pero sí requiere una decisión explícita de privacidad.

Lo que conviene comprobar

El checklist mínimo debería preguntar: qué repositorios pueden salir al entorno remoto, cuánto tiempo queda accesible la máquina, qué prompts y resúmenes se guardan, qué secretos se pasan, qué canales externos reciben notificaciones y qué ocurre si se desactiva Privacy Mode al iniciar una ejecución.

La regla operativa es sencilla: no uses background agents para repositorios donde no puedas explicar el ciclo de vida del código y los secretos durante la ejecución. Si legal, seguridad o compliance no entienden el flujo, todavía no es un flujo listo para datos sensibles.

API y automatización

La API de Background Agents permite crear y gestionar agentes programáticamente. Esto encaja con flujos como responder feedback, corregir bugs pequeños, actualizar documentación o generar PRs repetitivos. También abre el riesgo de crear una fábrica de cambios de baja calidad si no hay cola, límites y owners.

Antes de automatizar, define qué tareas son aptas para agente remoto: issues con reproducción clara, cambios de documentación, refactors mecánicos, tests faltantes o migraciones pequeñas. No metas de entrada incidentes, seguridad crítica, cambios de billing o migraciones de datos.

La API debe vivir detrás de presupuestos: número máximo de agentes activos, repos permitidos, etiquetas de issue admitidas, modelos autorizados, coste por tarea y revisión obligatoria. Si cualquier webhook puede lanzar un agente caro sobre cualquier repo, el problema no tardará en aparecer.

Checklist de adopción

Crea un repositorio piloto sin secretos de producción.
Conecta solo el repo necesario y revisa permisos de la app de GitHub.
Define .cursor/environment.json como receta mínima, reproducible e idempotente.
Usa ramas protegidas y exige PR antes de mezclar cualquier cambio.
Prohíbe secretos largos o de producción en el entorno del agente.
Separa validación automática de despliegue real.
Revisa logs para detectar comandos inesperados, descargas raras o salidas sensibles.
Documenta qué fuentes del repo son instrucciones confiables y cuáles son datos.
Mide coste por tarea, tasa de PR aceptado, tiempo de revisión y fallos de CI.
Aumenta permisos solo cuando el piloto demuestre valor y control.

Cuándo no usarlo

No usaría Background Agents para tareas donde el agente necesite explorar datos de clientes, secretos de producción o incidentes activos sin supervisión. Tampoco lo pondría a ejecutar migraciones destructivas, cambios de infraestructura o rotación de credenciales directamente desde el entorno remoto.

El patrón sí encaja para tareas con frontera clara: arreglar tests rotos, preparar upgrades pequeños, actualizar docs, crear casos de prueba, refactorizar módulos aislados o investigar bugs reproducibles. Cuanto más claro sea el input y más barato sea revertir, mejor encaja el flujo.

Si la tarea requiere juicio de producto, negociación con stakeholders o entender contexto no escrito, el background agent puede preparar evidencia, pero no debería cerrar la decisión.

Conclusión

Cursor Background Agents es una pieza útil porque convierte trabajo de agente en ramas revisables y entornos remotos reproducibles. Pero esa utilidad aparece cuando el equipo lo trata como automatización de ingeniería, no como un permiso ilimitado para que el editor haga cosas en segundo plano.

La secuencia responsable es simple: repo piloto, permisos mínimos, entorno reproducible, cero secretos de producción, PR obligatorio y medición. Después puedes abrir más casos de uso. Si empiezas conectando toda la organización y confiando en que los prompts sean suficientes, estás confundiendo productividad con ausencia de controles.

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

Recibe una lectura semanal de herramientas IA para devs. Cada martes: Claude Code, Cursor, Copilot, MCP, agentes y herramientas nuevas. En espanol y sin ruido. Suscribete gratis

Publicado originalmente en devaisemanal.com.

15 AI models hit end-of-life in the next 90 days — the full table

Khavel — Thu, 02 Jul 2026 15:59:44 +0000

If you build on hosted LLM APIs, model retirements are the quiet breakage: a model ID keeps working right up until the day it returns a 404, and the deprecation notice was a line in a changelog you didn't read.

I maintain a catalog of model lifecycles, so here's a concrete, dated snapshot: 15 models across 6 providers are scheduled to hit end-of-life within the next 90 days (by 2026-09-30). Dates and replacements are from each provider's own docs.

The table

Retires	Provider	Model (API id)	Official replacement
2026-07-23	OpenAI	`o3-deep-research`	`gpt-5.5-pro`
2026-07-23	OpenAI	`computer-use-preview`	`gpt-5.4-mini`
2026-07-23	OpenAI	`gpt-5-codex`	`gpt-5.5`
2026-07-24	DeepSeek	`deepseek-chat` (legacy alias)	`deepseek-v4-flash`
2026-07-24	DeepSeek	`deepseek-reasoner` (legacy alias)	`deepseek-v4-flash`
2026-07-31	Mistral	`mistral-small-3-2`	`mistral-small-2603`
2026-07-31	Mistral	`mistral-nemo`	`ministral-3-8b-latest`
2026-08-05	Anthropic	`claude-opus-4-1`	`claude-opus-4-8`
2026-08-31	Mistral	`mistral-medium-3-1`	`mistral-medium-latest`
2026-09-08	Alibaba	`qwen3-max`	`qwen3.7-max`
2026-09-08	Alibaba	`qwen3-max-preview`	`qwen3.7-max`
2026-09-08	Alibaba	`qwen3-6-max-preview`	`qwen3.7-max`
2026-09-14	Amazon	`amazon-nova-premier`	`amazon.nova-2-lite-v1:0`
2026-09-24	OpenAI	`sora-2`	— (no drop-in successor)
2026-09-24	OpenAI	`sora-2-pro`	— (no drop-in successor)

A few things worth flagging

The DeepSeek ones are aliases, not models. deepseek-chat and deepseek-reasoner are pointers; after 2026-07-24 they resolve to deepseek-v4-flash. If you pinned the alias expecting stable behavior, the behavior changes under you — pin the concrete snapshot instead.
claude-opus-4-1 → claude-opus-4-8 is not a free swap. The 4.7-generation tokenizer counts roughly 30–35% more tokens for the same text, so your per-request cost and context math shift even if the price-per-token looks similar.
Sora 2 / Sora 2 Pro have no listed drop-in replacement. If a video pipeline depends on them, that's a migration to scope now, not in September.

How to not get surprised by this

The durable fix is to treat model lifecycle as a dependency you monitor, the same way you watch for CVEs or deprecated framework APIs:

Pin concrete model snapshots, never floating aliases, in anything you can't hotfix fast.
Keep a list of the model IDs you actually call in production, and check their retirement dates on a schedule.
Test the named replacement before the retirement date — pricing, tokenizer, and output format can all move.

I keep the full, dated deprecation list (all providers, not just the next 90 days) updated here: aimodelwatch.dev/deprecations. If you want a heads-up when a model you use gets a retirement date, there's a free email alert on the site.

Data pulled 2026-07-02 from provider docs. If you spot a date that's drifted, tell me — accuracy is the whole point.

Cloudflare Agents SDK: cómo crear agentes con estado en Durable Objects

Khavel — Thu, 02 Jul 2026 09:11:24 +0000

Cloudflare Agents SDK no es otro wrapper de prompts. Es un runtime TypeScript para agentes persistentes: cada instancia vive en un Durable Object con SQL, estado sincronizado, WebSockets, tareas programadas y herramientas MCP.

Cloudflare Agents SDK es un runtime TypeScript para crear agentes de IA persistentes sobre Cloudflare Workers y Durable Objects. La diferencia importante frente a un endpoint serverless normal es que cada agente tiene identidad duradera, SQL local, estado sincronizado, conexiones WebSocket, tareas programadas y una ruta natural hacia MCP, Workflows y herramientas del ecosistema Cloudflare.

Plan de despliegue. TL;DR La keyword principal es Cloudflare Agents SDK. La intención de búsqueda en español es práctica: entender qué es, cuándo usarlo frente a un backend propio o un framework de agentes Python, y cómo diseñar una arquitectura mínima sin convertir el agente en un servicio opaco. Mi postura: merece la pena cuando el producto necesita sesiones vivas, memoria por usuario o equipo, eventos, WebSockets, scheduling y acciones largas. Para una llamada aislada al modelo, es demasiada plataforma; usa una API directa y guarda la complejidad para cuando el agente tenga ciclo de vida real.

Qué es Cloudflare Agents SDK y qué no es

Una definición citable: Cloudflare Agents SDK es una capa de runtime para agentes stateful donde una clase Agent encapsula estado, conexiones, métodos invocables, llamadas a modelos, herramientas, errores y tareas programadas, ejecutándose sobre Durable Objects.

No es un modelo, no es un prompt mágico y no reemplaza la disciplina de producto. El SDK te da primitivas para que un agente recuerde, despierte, reciba eventos, coordine trabajo y hable con clientes en tiempo real. La calidad sigue dependiendo de tus tools, permisos, evals, límites y diseño del workflow.

La lectura práctica es esta: Cloudflare intenta convertir el problema de dónde vive mi agente en infraestructura gestionada. En lugar de reconstruir sesión, memoria, WebSocket, cola y cron en piezas separadas, puedes colgarlo de una instancia direccionable por nombre.

Briefing. El modelo mental: agente como micro-servidor duradero Cada instancia de agente se parece más a un pequeño servidor con identidad que a una función stateless. Si el agente representa a un usuario, una sala, un ticket, un repositorio o un tenant, el mismo identificador devuelve la misma instancia. Eso elimina mucho pegamento: no tienes que sincronizar manualmente memoria conversacional entre Lambda, Redis, base de datos y WebSocket gateway. El coste conceptual es que debes diseñar fronteras de instancia. Un agente por usuario facilita privacidad y preferencias. Un agente por equipo facilita colaboración. Un agente por repositorio facilita automatización de desarrollo. Mezclar todo en un agente global suele acabar en permisos borrosos y estado difícil de auditar.

La pregunta buena no es ¿puedo hacer un chatbot?. La pregunta buena es: ¿qué entidad del producto necesita recordar, recibir eventos, ejecutar tareas y mantener conexiones? Esa entidad debería mapearse a una instancia de agente.

La idea sana: el modelo razona dentro de un runtime con identidad, estado y límites; no dentro de un endpoint que olvida todo al devolver la respuesta.

Arquitectura mínima que sí desplegaría

La versión mínima seria tiene seis piezas. Primero, una clase Agent<Env, State> con un estado pequeño y serializable. Segundo, routeAgentRequest para enrutar peticiones a instancias por nombre. Tercero, una política explícita de nombres: usuario, equipo, sala, ticket o repositorio. Cuarto, SQL local solo para datos que pertenecen a esa instancia. Quinto, WebSockets o SSE solo cuando el usuario necesita ver progreso. Sexto, observabilidad y límites antes de tools mutantes.

No empezaría conectando Browser, MCP, pagos, email y Workflows el día uno. Empezaría con una tarea de lectura, una tool controlada y un estado mínimo. Cuando eso sea observable, añadiría scheduling. Cuando scheduling no baste para trabajo largo con reintentos, movería esa parte a Workflows.

La arquitectura debe dejar claro qué vive en el agente y qué vive fuera. Preferencias, progreso y memoria local encajan en el agente. Datos de negocio compartidos, billing, permisos corporativos y auditoría de largo plazo suelen pertenecer a sistemas externos que el agente consulta con credenciales limitadas.

Código mínimo: estado, routing y RPC

import { Agent, callable, routeAgentRequest } from "agents";

type State = {
  lastTask: string | null;
  completed: number;
};

export class RepoAgent extends Agent<Env, State> {
  initialState: State = { lastTask: null, completed: 0 };

  @callable()
  async summarizeRepo(task: string) {
    this.setState({ ...this.state, lastTask: task });

    // Aqui llamarias a un modelo y a tools de lectura con permisos limitados.
    const summary = `Resumen pendiente para: ${task}`;

    this.setState({ ...this.state, completed: this.state.completed + 1 });
    return { summary, completed: this.state.completed };
  }
}

export default {
  async fetch(request: Request, env: Env) {
    return (await routeAgentRequest(request, env)) ??
      new Response("Not found", { status: 404 });
  },
} satisfies ExportedHandler<Env>;

Lo que conviene comprobar

El detalle que importa no es la sintaxis del contador. Es el contrato: estado pequeño, método invocable, actualización explícita y routing que devuelve siempre la misma instancia cuando el nombre coincide. Eso hace posible reanudar trabajo sin inventarte otro session store.

Configurar Durable Objects sin olvidar migraciones

Agents SDK depende de Durable Objects. En wrangler.jsonc, cada clase de agente necesita binding y migración SQLite. Si cambias el nombre de la clase o creas otro tipo de agente, trátalo como cambio de infraestructura, no como refactor inocente.

{
  "durable_objects": {
    "bindings": [
      { "name": "RepoAgent", "class_name": "RepoAgent" }
    ]
  },
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["RepoAgent"] }
  ]
}

Mi regla: versiona la configuración junto al agente y revisa migraciones en PR. Un agente con memoria persistente no se comporta como una función desechable; si rompes identidad o esquema, rompes continuidad para usuarios reales.

Estado: cuándo usar `setState` y cuándo usar SQL

Usa setState para el estado pequeño que el cliente necesita ver sincronizado: fase actual, progreso, última acción, preferencias simples o bandera de aprobación. Es persistente, se guarda en SQLite y se sincroniza en tiempo real con clientes conectados.

Usa this.sql para historial, filas consultables, eventos, resultados intermedios o datos que no quieres enviar enteros a cada cliente. La tentación de meter todo en state es fuerte porque funciona rápido; también es la forma más fácil de crear payloads enormes y acoplar UI con almacenamiento interno.

Estado de agente no es memoria infinita para el LLM. Si usas estado como contexto del modelo, resume y selecciona. Poner transcripciones completas en cada turno dispara coste, latencia y riesgo de prompt injection acumulada.

Briefing. Scheduling: agentes que despiertan sin usuario El scheduling es una de las razones reales para usar este runtime. Puedes programar una tarea con retraso, fecha concreta, cron o intervalo, y la tarea sobrevive reinicios porque queda persistida. Por debajo, Cloudflare usa Durable Object alarms para despertar la instancia.

export class DigestAgent extends Agent<Env, { runs: number }> { initialState = { runs: 0 }; async onRequest(request: Request) { await this.schedule("0 8 * * *", "dailyDigest", { audience: "dev-team", }); return new Response("Digest scheduled"); } async dailyDigest(payload: { audience: string }) { this.setState({ runs: this.state.runs + 1 }); // Generar resumen, consultar fuentes y enviar notificacion. } }

No usaría scheduling para procesos de horas con reintentos complejos y compensaciones. Ahí entran Workflows. Scheduling es ideal para recordatorios, polling prudente, reintentos simples, digest diarios y mantenimiento de una instancia concreta.

Lectura práctica. Workflows: cuándo sacar trabajo del turno interactivo Un turno de chat debería mantenerse explicable. Si el agente necesita investigar durante minutos, coordinar pasos con reintentos o garantizar ejecución aunque se corte la conexión, separa el trabajo en Workflows. El agente puede iniciar el workflow, persistir estado visible y recibir resultado o progreso. La diferencia mental: el agente conserva identidad y conversación; Workflows ejecuta procesos duraderos. Juntos sirven para casos como análisis de repositorios, informes programados, procesamiento de tickets, migraciones asistidas o tareas que deben sobrevivir despliegues. El error frecuente es meter todo en el método onChatMessage. Eso produce demos espectaculares y producción frágil. Si una operación tiene fases, presupuesto y retry policy, dale forma de workflow o de tarea programada, no de respuesta improvisada.

MCP: conectar herramientas sin abrir toda la cuenta

Cloudflare Agents puede consumir MCP y también servir herramientas mediante MCP. Eso encaja muy bien con agentes internos: el agente mantiene sesión y permisos locales, mientras MCP expone capacidades concretas a modelos o clientes compatibles.

Pero MCP no es una licencia para conectar toda tu infraestructura. Usa OAuth o credenciales por ámbito, separa lectura de escritura, registra tool calls y limita qué servidores puede usar cada tipo de agente. Si el agente opera sobre Cloudflare, GitHub o sistemas internos, el blast radius lo define tu política de tools, no el SDK.

Para DevAI, la pauta sería: MCP para capacidades bien acotadas, output estructurado para resultados auditables y revisión humana para acciones irreversibles. Sin esas tres cosas, solo has creado una consola de administración con lenguaje natural.

WebSockets y cliente React: progreso sin polling torpe

El cliente puede conectarse al agente con useAgent o useAgentChat. Eso permite leer estado sincronizado, invocar métodos y mostrar progreso sin montar un gateway WebSocket separado. Para UIs de chat, AIChatAgent y useAgentChat añaden persistencia de mensajes y recuperación de streams.

Lo que conviene comprobar

No pondría todo el producto dentro del hook. La UI debe tratar el agente como runtime de interacción, no como base de datos global. El patrón limpio es: estado visible en el agente, datos de negocio en APIs normales, y eventos largos como progreso o milestones.

Si el usuario cierra la pestaña o se cae la conexión, la promesa del runtime es que pueda volver a la misma instancia. Diseña la UI para esa realidad: muestra última fase, último error, siguiente acción disponible y si hay aprobación humana pendiente.

Seguridad y permisos: el agente no es el perímetro

Cloudflare te da identidad duradera del agente, pero eso no equivale a autorización de negocio. Comprueba usuario, tenant y permisos en cada acción sensible. El nombre de instancia ayuda a enrutar; no debería ser el único control de acceso.

Separa secrets por entorno, scope y tool. Un agente de soporte no necesita credenciales de despliegue. Un agente de repositorio no necesita escribir en billing. Un agente que genera resúmenes no necesita ejecutar acciones mutantes. Lo aburrido sigue siendo lo correcto: mínimo privilegio, allowlists, logs y revisión humana.

También vigilaría prompt injection persistente. Un agente que recuerda instrucciones, páginas visitadas o resultados de tools puede acumular datos hostiles. Resume, etiqueta procedencia y evita que contenido recuperado se convierta en instrucciones del sistema.

Observabilidad y coste

Mide por instancia y por tipo de trabajo: turnos, tools, modelo, tokens, duración, reintentos, errores, tareas programadas y workflows iniciados. Si usas AI Gateway, aprovecha caching, rate limits, fallback y logs para ver consumo real en vez de adivinarlo por factura.

La métrica que más me interesa no es mensajes respondidos. Es decisiones útiles completadas sin intervención peligrosa. Un agente que contesta mucho pero dispara workflows innecesarios, llama tools caras o requiere revisión manual constante no está ahorrando tiempo.

Para producción pondría presupuestos por agente, por usuario y por acción. Cuando un agente cruza umbral, debe degradar: modelo más barato, menos contexto, cola asíncrona o pedir aprobación. Sin degradación, el primer incidente será coste o permisos.

Briefing. Cuándo elegir Cloudflare Agents SDK frente a LangGraph, ADK u OpenAI Agents SDK Elige Cloudflare Agents SDK si el problema principal es runtime: identidad duradera, WebSockets, estado por instancia, scheduling, Workers, Durable Objects, Workflows y herramientas cerca de la edge. Encaja especialmente en productos web que necesitan agentes vivos por usuario, equipo, canal o recurso. Elige LangGraph si el núcleo del problema es orquestación explícita de estados y grafos complejos en Python. Elige Google ADK si tu stack está en Google Cloud y quieres sesiones, evals y despliegue dentro de ese ecosistema. Elige OpenAI Agents SDK si priorizas handoffs, guardrails y tracing alrededor de modelos OpenAI.

La comparación honesta: Cloudflare no gana por tener el mejor loop de razonamiento. Gana cuando quieres dejar de fabricar infraestructura alrededor del loop. Si tu equipo ya tiene backend robusto, colas, WebSockets y cron bien resueltos, el valor incremental baja.

Lectura práctica. Checklist de producción Define la entidad que representa cada instancia de agente: usuario, equipo, sala, ticket, repo o proceso. Mantén state pequeño, serializable y visible; usa SQL para historial y eventos consultables. Configura Durable Object bindings y migraciones como parte revisada del despliegue. Separa tools de lectura y escritura; aplica credenciales de mínimo privilegio. Usa scheduling para tareas simples y Workflows para procesos largos con reintentos. Instrumenta turnos, tools, tokens, latencia, errores, tareas y workflows por instancia. Añade revisión humana para acciones irreversibles o con coste relevante. Protege el agente contra prompt injection persistente: procedencia, resumen y límites de contexto. Prueba reconexión, hibernación, despliegue y recuperación antes de anunciarlo como producción.

Plan de adopción en cinco días

Día 1: elige una entidad clara, por ejemplo repo-agent/<owner>/<repo> o support-agent/<ticket-id>, y crea un agente sin tools mutantes.
Día 2: añade estado mínimo, SQL para eventos y una UI que muestre fase, último error y progreso.
Día 3: conecta un modelo y una sola tool de lectura. Mide tokens, latencia y errores por instancia.
Día 4: añade scheduling para una tarea real, como digest diario, revisión de cola o reintento con backoff.
Día 5: decide si necesitas MCP, Workflows o ambos. Si no puedes explicar permisos y recuperación, no añadas más herramientas todavía.

Conclusión

Cloudflare Agents SDK es interesante porque ataca una parte poco glamourosa de los agentes: dónde viven, cómo recuerdan, cómo se reconectan, cómo despiertan y cómo ejecutan trabajo duradero. Eso no convierte cualquier chatbot en producto, pero sí reduce mucha infraestructura accidental.

Lo que conviene comprobar

Mi recomendación es usarlo cuando el agente tenga vida propia: sesiones, estado, eventos, scheduling, progreso y tools. Si solo necesitas transformar un input en JSON, no lo compliques. Pero si estás construyendo un agente que acompaña a un usuario o equipo durante horas o días, Durable Objects como runtime empiezan a tener mucho sentido.

Preguntas frecuentes

¿Qué es Cloudflare Agents SDK?

Cloudflare Agents SDK es un SDK TypeScript para crear agentes de IA persistentes sobre Workers y Durable Objects, con estado, SQL local, WebSockets, scheduling, Workflows y soporte MCP.

¿Cloudflare Agents SDK requiere Durable Objects?

Sí. El modelo de identidad, estado persistente, SQL y conexiones del agente se apoya en Durable Objects y sus bindings de configuración.

¿Puedo usar OpenAI o Anthropic con Cloudflare Agents SDK?

Sí. El runtime puede usar Workers AI o proveedores externos como OpenAI, Anthropic y Gemini; la elección del modelo no es lo mismo que la elección del runtime.

¿Cuándo usar scheduling y cuándo Workflows?

Usa scheduling para tareas simples en una instancia: retrasos, cron, intervalos y reintentos ligeros. Usa Workflows para procesos largos, multi-paso, con reintentos y garantías más fuertes.

¿Cloudflare Agents SDK reemplaza a MCP?

No. MCP es una interfaz de herramientas y contexto. Agents SDK puede consumir o servir MCP, pero sigues necesitando permisos, allowlists y observabilidad.

¿Es mejor que LangGraph o Google ADK?

No universalmente. Cloudflare Agents SDK destaca como runtime stateful para productos web; LangGraph destaca en grafos de ejecución; Google ADK encaja en el ecosistema Google; OpenAI Agents SDK encaja en orquestación OpenAI.

Cómo llevar un agente Cloudflare Agents SDK a producción

Elegir la entidad de instancia. Decide si cada agente representa un usuario, equipo, sala, ticket, repositorio o proceso programado.
Crear la clase Agent. Define Agent<Env, State> con estado pequeño, métodos invocables y una política clara de nombres.
Configurar Durable Objects. Añade bindings y migraciones SQLite en wrangler.jsonc y revísalos como infraestructura.
Separar estado y datos. Usa setState para estado visible y SQL o APIs externas para historial y datos compartidos.
Añadir tools con permisos mínimos. Empieza por lectura, registra llamadas y exige aprobación humana para acciones irreversibles.
Programar trabajo duradero. Usa schedule para tareas simples y Workflows para procesos largos con reintentos y recuperación.
Verificar recuperación. Prueba reconexión WebSocket, hibernación, despliegue, errores de modelo y reanudación antes de exponerlo a usuarios.

Cierre editorial. Regla operativa Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

¿Te sirve esto? Cada semana resumo herramientas de IA para devs (agentes, MCP, seguridad, workflows) en un email de 5 minutos, en español. Suscríbete gratis.

Publicado originalmente en devaisemanal.com.

Claude Code para .NET y C#: guía práctica para developers (2026)

Khavel — Tue, 30 Jun 2026 09:15:17 +0000

Claude Code es un agente de IA que trabaja desde la terminal sobre tu repositorio. Para quien programa en C# y .NET encaja sorprendentemente bien, pero conviene configurarlo con criterio antes de soltarlo sobre una solución grande.

Claude Code es la herramienta de línea de comandos de Anthropic: un agente que vive en tu terminal, lee tu repositorio, ejecuta comandos y propone cambios revisables como un diff. No es un autocompletado dentro del editor; es un compañero que razona sobre el proyecto entero y trabaja por tareas.

La versión corta

Para quien programa en C# y .NET la pregunta no es si funciona, sino cómo configurarlo para que entienda una solución con varios proyectos, dependencias y convenciones propias. Bien preparado, Claude Code es muy eficaz en .NET; mal preparado, se pierde entre archivos y propone cambios que no compilan.

Por qué Claude Code encaja bien con .NET

El ecosistema .NET es muy estructurado: una solución (.sln) que agrupa proyectos (.csproj), convenciones claras de nombres, tipado fuerte y un compilador estricto. Esa estructura es justo lo que un agente de código aprovecha: hay señales fuertes para entender qué hace cada parte y un compilador que verifica de inmediato si un cambio es válido.

El tipado fuerte de C# y el feedback rápido de dotnet build y dotnet test cierran el bucle entre propuesta y verificación. Claude Code puede editar, compilar, leer el error y corregir sin que tú intervengas en cada paso. En lenguajes dinámicos ese bucle es más frágil; en .NET el compilador hace de red de seguridad.

¿Funciona Claude Code en Windows?

Sí. Claude Code funciona en Windows, y la vía más cómoda para la mayoría de developers .NET es ejecutarlo dentro de WSL (Windows Subsystem for Linux), aunque también puede usarse en PowerShell. El SDK de .NET, dotnet, MSBuild y las herramientas de test funcionan igual; Claude Code solo necesita poder ejecutar esos comandos en tu terminal.

Si trabajas con Visual Studio, lo habitual es mantener Visual Studio para depurar y diseñar, y usar Claude Code en una terminal paralela para tareas de agente: refactors, generación de tests, migraciones mecánicas o exploración de un módulo desconocido.

Cómo configurar Claude Code para una solución C

Instala el SDK de .NET y comprueba que dotnet build y dotnet test funcionan en tu solución antes de abrir Claude Code.

Crea un archivo CLAUDE.md en la raíz del repo con lo esencial: estructura de la solución, proyectos principales, comando de build, comando de test y convenciones que no son obvias.

Indica las restricciones reales: versión de .NET objetivo, nullable habilitado, analizadores activos y reglas de estilo que deben respetarse.

Limita el alcance al principio: trabaja en una rama, no le des permisos amplios sobre el sistema y revisa cada diff antes de integrarlo.

Añade los servidores MCP que de verdad aporten valor (por ejemplo acceso a documentación o a tu issue tracker) en lugar de conectarlo todo.

Cómo es el flujo de trabajo en la práctica

El patrón que mejor funciona es por tareas concretas y verificables. En vez de pedir "mejora el proyecto", pides algo acotado: "añade validación al endpoint X y un test que lo cubra". Claude Code lee el contexto, propone el cambio, ejecuta dotnet test y te entrega un diff.

Lo que conviene comprobar

Para una migración mecánica (por ejemplo, mover de un patrón antiguo a uno nuevo en varios archivos), describe el cambio una vez, deja que lo aplique en bucle y revisa el resultado compilado. La clave es que el compilador y los tests sean la fuente de verdad, no la confianza en el modelo.

Para explorar un módulo que no conoces, pídele primero un resumen de cómo está organizado y dónde vive cada responsabilidad antes de tocar nada. Eso evita cambios a ciegas en código que aún no entiendes.

Claude Code vs Cursor vs GitHub Copilot para .NET

GitHub Copilot brilla como autocompletado y asistente dentro del editor, integrado de forma nativa en Visual Studio y VS Code. Es lo más cómodo para escribir código línea a línea y resolver dudas sin salir del IDE.

Cursor es un editor completo centrado en IA, con un buen equilibrio entre edición asistida y agentes; encaja si quieres un IDE moderno orientado a IA como herramienta principal.

Claude Code es la opción más "agente de terminal": razona sobre el repositorio entero y trabaja por tareas largas con verificación mediante build y tests. Muchos equipos .NET acaban combinando los tres: Copilot para el día a día en el editor, Claude Code para tareas de agente y revisión humana obligatoria para lo que toca seguridad o datos.

Cuánto cuesta

Claude Code se factura por uso de modelo a través de la API de Anthropic o mediante los planes de suscripción de Claude que incluyen Claude Code. El coste real depende de cuántas tareas largas ejecutes, qué modelo uses y cuánto contexto arrastre cada sesión.

Para controlar el gasto, aplica la misma disciplina que con cualquier herramienta de IA para devs: tareas acotadas, contexto justo, y revisar el consumo tras un par de semanas. Si te interesa el detalle de costes de herramientas de IA, lo tratamos a fondo en nuestras guías sobre AI credits y comparativas de asistentes.

Preguntas frecuentes

¿Claude Code funciona en Windows con .NET?

Sí. Funciona en Windows, normalmente vía WSL aunque también en PowerShell. El SDK de .NET, dotnet, MSBuild y las herramientas de test se ejecutan igual; Claude Code solo necesita poder lanzar esos comandos desde la terminal.

¿Hace falta abandonar Visual Studio para usar Claude Code?

No. Lo habitual es mantener Visual Studio para depurar y diseñar, y usar Claude Code en una terminal paralela para tareas de agente como refactors, generación de tests o migraciones mecánicas.

¿Por qué Claude Code encaja bien con C#?

Porque .NET es muy estructurado y C# tiene tipado fuerte: la estructura de la solución da señales claras al agente y el compilador verifica de inmediato cada cambio, cerrando el bucle entre propuesta y verificación.

¿Cómo controlo lo que puede hacer en mi repositorio?

Trabaja en una rama, no le des permisos amplios sobre el sistema, revisa cada diff antes de integrarlo y exige revisión humana en los cambios que tocan seguridad, autenticación o datos.

Cómo poner a punto Claude Code en un proyecto .NET

Verificar el entorno .NET. comprueba que dotnet build y dotnet test funcionan en tu solución antes de abrir Claude Code.
Escribir un CLAUDE.md. documenta estructura de la solución, proyectos clave, comando de build, comando de test y convenciones no obvias.
Declarar restricciones. indica versión de .NET, nullable, analizadores y reglas de estilo que deben respetarse.
Empezar acotado. trabaja en una rama, pide tareas concretas y verificables, y revisa el diff antes de integrar.
Cerrar el bucle con tests. deja que el agente ejecute dotnet test y corrija a partir del error en lugar de confiar a ciegas en la salida.

Conclusión

Claude Code es una de las mejores formas de aplicar un agente de código a proyectos .NET, precisamente porque C# y el compilador le dan la estructura y la verificación que necesita. La diferencia entre que sea útil o caótico está casi siempre en la preparación: un CLAUDE.md honesto, tareas acotadas y revisión humana donde importa.

Medida útil

La compactación funciona si conserva la decisión técnica que tomaría una persona con el log completo delante.

Fuentes y referencias

Cada semana resumo herramientas de IA para developers (agentes, MCP, seguridad, workflows) en un email de 5 minutos, en español y sin ruido. Suscríbete gratis a DevAI Semanal

LangGraph: cómo crear agentes Python con estado, checkpoints y revisión humana

Khavel — Mon, 29 Jun 2026 09:12:07 +0000

LangGraph no es otra capa bonita para llamar a un LLM. Su valor aparece cuando un agente necesita estado duradero, rutas explícitas, checkpoints, interrupciones humanas y una forma razonable de depurar ejecuciones largas.

LangGraph es un framework de orquestación para agentes con estado. La idea central no es escribir prompts más largos, sino declarar un grafo de ejecución donde cada nodo lee y devuelve estado, las aristas deciden el siguiente paso y un checkpointer permite pausar, reanudar y auditar runs.

Plan de despliegue

Resumen práctico

La keyword principal es LangGraph agentes Python. La intención de búsqueda en español es práctica: entender qué es LangGraph, cuándo usarlo frente a una llamada directa al modelo o un SDK de agentes, y cómo montarlo sin convertir producción en una demo imposible de depurar.

Mi postura: LangGraph merece la pena cuando el workflow tiene estado, bifurcaciones, herramientas, aprobación humana o duración larga. Para un chatbot simple o una única llamada con structured output, probablemente es demasiada maquinaria.

Checklist

Qué problema resuelve LangGraph

Un agente real no falla solo porque el modelo responda mal. Falla porque pierde estado entre pasos, llama tools en orden incorrecto, no se sabe qué decidió antes de actuar, reintenta sin criterio o necesita una persona justo cuando la ejecución ya está a medias.

LangGraph ataca ese problema bajando el agente a una estructura explícita: StateGraph, nodos, edges, estado tipado, checkpointers, streaming e interrupciones humanas. Eso no hace que el modelo sea más listo; hace que el sistema sea más observable y recuperable.

La diferencia importante frente a un script lineal es que el grafo conserva intención. Puedes decir: primero clasifica, luego busca, después decide si llama una tool o pide revisión humana, y finalmente responde o ejecuta. Esa forma se puede razonar, probar y explicar en revisión.

Briefing

Conceptos que debes entender antes de copiar código

State: contrato compartido de la run. Normalmente contiene mensajes, datos recuperados, decisiones, errores, contadores y cualquier campo que necesites para decidir el siguiente paso.

Node: función que recibe estado y devuelve un parche de estado. Un nodo debería tener una responsabilidad concreta: recuperar contexto, decidir tool, validar salida, pedir aprobación o sintetizar respuesta.

Edge: transición entre nodos. Puede ser fija o condicional. Las aristas condicionales son donde aparece la lógica de workflow: si hay tool call, ejecuta tool; si hay riesgo, pausa; si la respuesta está completa, termina.

Checkpointer: capa que guarda snapshots por thread_id. Sin esto, human-in-the-loop y durable execution son frágiles. En desarrollo puedes usar memoria; en producción necesitas almacenamiento externo.

Interrupt: mecanismo para pausar la ejecución y esperar input humano. Es útil para aprobar queries, cambios en repos, emails salientes, acciones sobre infraestructura o cualquier operación que no quieras delegar ciegamente.

La frontera sana: el LLM decide dentro de un grafo, pero el equipo controla estado, persistencia, revisión humana y runtime observable.

Código mínimo con StateGraph

from typing_extensions import TypedDict
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import InMemorySaver

class AgentState(TypedDict):
    task: str
    draft: str
    needs_review: bool

def plan(state: AgentState) -> dict:
    return {"draft": "Plan para: " + state["task"], "needs_review": True}

def human_gate(state: AgentState) -> dict:
    # En produccion, aqui usarias interrupt() o una cola de aprobacion.
    return state

def route_after_plan(state: AgentState) -> str:
    return "human_gate" if state["needs_review"] else END

builder = StateGraph(AgentState)
builder.add_node("plan", plan)
builder.add_node("human_gate", human_gate)
builder.add_edge(START, "plan")
builder.add_conditional_edges("plan", route_after_plan)
builder.add_edge("human_gate", END)

graph = builder.compile(checkpointer=InMemorySaver())
result = graph.invoke(
    {"task": "preparar un PR de documentacion", "draft": "", "needs_review": False},
    {"configurable": {"thread_id": "demo-1"}},
)

Este ejemplo no pretende ser producción. Sirve para ver la forma mental: estado explícito, nodos pequeños, routing condicional y un thread_id que permite asociar checkpoints a una ejecución. La parte seria empieza cuando sustituyes memoria local por un checkpointer persistente y defines qué acciones requieren aprobación.

Dónde está la decisión de arquitectura

La decisión no es LangGraph sí o no. La decisión real es cuánto control necesitas sobre la trayectoria del agente. Si tu flujo solo genera una respuesta tipada, Pydantic AI u OpenAI Agents SDK pueden bastar. Si necesitas bucles, pausa humana, recuperación tras error y una ruta auditable, LangGraph empieza a justificar su complejidad.

Puntos a revisar

Lo que conviene comprobar

Tampoco usaría LangGraph para esconder lógica de negocio dentro de prompts. Justo al revés: lo usaría para sacar decisiones del prompt y convertirlas en nodos, edges, validadores y checkpoints que el equipo pueda revisar.

Un buen diseño de LangGraph se parece más a un workflow de software que a un chat: entradas claras, estado versionable, pasos nombrados, errores manejables y criterios de salida. Si el grafo solo llama al modelo cinco veces sin contratos, no has ganado arquitectura; has ganado una forma más larga de tener una demo.

Checklist

Checkpoints: desarrollo no es producción

El error normal es quedarse con InMemorySaver porque el tutorial funciona. En memoria está bien para notebooks, tests y ejemplos locales. En producción, si el proceso muere, pierdes la run; si necesitas escalar workers, no compartes estado; si debes auditar, no tienes una historia fiable.

Para producción necesitas un checkpointer externo: Postgres, Redis, DynamoDB u otra capa que encaje con tu infraestructura. Lo importante no es el proveedor, sino las propiedades: persistencia, concurrencia, retención, cifrado, backups y capacidad de buscar por thread o usuario.

AWS publicó un patrón de checkpointing con DynamoDB precisamente porque el checkpointer pasa a ser infraestructura. Esa es la lectura correcta: en agentes duraderos, el estado ya no es un detalle interno del código; es parte de la superficie operativa.

Checklist

Human-in-the-loop sin teatro

Human-in-the-loop no significa que una persona lea todo. Significa que el sistema sabe cuándo debe detenerse. Una aprobación humana útil aparece antes de acciones irreversibles: enviar un email externo, ejecutar una query destructiva, abrir un PR grande, tocar infraestructura, gastar presupuesto o publicar contenido.

La mala versión es pedir aprobación para cada paso y convertir al agente en un formulario lento. La buena versión es clasificar riesgo: lectura sin aprobación, escritura reversible con logs, escritura sensible con interrupción y acciones críticas fuera del alcance del agente.

En LangGraph, interrupt() tiene sentido cuando el estado ya contiene suficiente contexto para que la persona decida. Si el humano tiene que reconstruir toda la run, el grafo no está explicando su propio trabajo.

Briefing

Observabilidad y evals

Para evaluar un agente LangGraph, no midas solo la respuesta final. Mide trayectoria: nodos visitados, tools llamadas, argumentos, reintentos, interrupciones, duración, coste, errores y cambios entre versiones de prompt o modelo.

Una batería mínima debería incluir casos felices, inputs ambiguos, datos hostiles, fallo de tool, timeout, salida inválida, aprobación humana y reanudación desde checkpoint. Si solo pruebas el happy path, justo estás ignorando la razón por la que LangGraph existe.

El logging debe conservar thread_id, versión del grafo, versión de prompts, modelo, tools disponibles y resultado de cada nodo. Sin esa evidencia, depurar un agente duradero se convierte en leer una novela escrita por un modelo con mala memoria.

Lectura práctica

Plan de adopción en cinco días

Día 1: elige un caso con estado real, como triage de tickets, revisión de PRs, generación de reportes o asistente interno con tools.

Día 2: define el State antes de escribir prompts. Si no sabes qué estado existe, no sabes qué estás orquestando.

Día 3: crea un grafo con tres o cuatro nodos y un checkpointer local. Añade logging por nodo desde el principio.

Día 4: cambia a checkpointer persistente y añade un punto de interrupción humana para la acción más sensible.

Día 5: crea evals de trayectoria y prueba reanudación tras fallo. Si no puedes explicar una run fallida, todavía no lo despliegues.

Errores que veo venir

Meter toda la lógica en un nodo gigante llamado agent. Si todo ocurre dentro de un prompt, LangGraph no te está ayudando a operar el sistema.
Persistir estado sin política de retención. Los checkpoints pueden contener datos sensibles, prompts, resultados de tools y decisiones intermedias.
Confundir memory del agente con memoria de usuario. El estado de ejecución no es necesariamente una preferencia duradera del usuario.
Abrir todas las tools desde el primer día. Empieza con lectura, observa trayectorias y añade mutaciones con aprobación.
Desplegar sin versionar prompts y grafo. Cambiar el routing o el prompt principal sin evals hace que los checkpoints antiguos sean más difíciles de interpretar.

Cuándo no usaría LangGraph

No lo usaría para un endpoint simple que recibe input, llama al modelo una vez y devuelve JSON validado. Ahí una llamada estructurada o un SDK más directo será más barato de mantener.

Puntos a revisar

Lo que conviene comprobar

No lo usaría si el equipo no tiene todavía tests, logs ni dueño técnico del workflow. Un framework de orquestación no arregla una operación inmadura; la hace más visible.

Tampoco lo usaría para simular autonomía donde en realidad quieres una automatización determinista. Si el proceso se puede escribir como reglas normales, escribe reglas normales y reserva el LLM para partes ambiguas.

Checklist

Conclusión

LangGraph es valioso cuando aceptas una premisa incómoda: un agente de producción es un sistema distribuido pequeño, no un prompt con marketing. Tiene estado, fallos parciales, decisiones intermedias, permisos, observabilidad y usuarios esperando una respuesta explicable.

Mi recomendación es empezar con un grafo pequeño, estado explícito, checkpointer persistente, una sola interrupción humana y evals de trayectoria. Si eso funciona, amplía. Si no funciona, el problema no era falta de nodos; era falta de diseño.

Preguntas frecuentes

¿Qué es LangGraph?

LangGraph es un framework para construir agentes y workflows con estado usando grafos: defines estado, nodos, edges, persistencia, streaming e interrupciones humanas.

¿LangGraph reemplaza a LangChain?

No. LangGraph forma parte del ecosistema LangChain, pero se centra en orquestación de agentes stateful y workflows duraderos.

¿Cuándo conviene usar LangGraph?

Conviene cuando el agente necesita varios pasos, routing condicional, tools, checkpoints, recuperación, human-in-the-loop u observabilidad de trayectoria.

¿InMemorySaver sirve para producción?

No como base seria. Es útil para desarrollo y pruebas, pero producción necesita un checkpointer persistente y operable.

¿LangGraph es mejor que Pydantic AI o Google ADK?

No universalmente. LangGraph destaca en control de workflow y estado; Pydantic AI destaca en contratos Python tipados; Google ADK encaja mejor si priorizas el stack Google.

¿Qué debo medir en un agente LangGraph?

Mide respuesta final, nodos visitados, tool calls, argumentos, reintentos, interrupciones humanas, latencia, coste y éxito de reanudación desde checkpoints.

Cómo llevar un agente LangGraph a producción

Definir el estado. Escribe el contrato de State con mensajes, contexto, decisiones, errores y metadatos mínimos antes de crear nodos.
Separar nodos. Divide planificación, recuperación, decisión, tool calls, validación y síntesis en nodos pequeños y observables.
Persistir checkpoints. Sustituye memoria local por un checkpointer externo con retención, cifrado, backups y búsqueda por thread.
Añadir revisión humana. Usa interrupciones solo para acciones sensibles y entrega al humano un estado suficiente para decidir rápido.
Evaluar trayectorias. Crea casos que verifiquen nodos recorridos, tools llamadas, errores, reintentos y reanudación tras fallo.
Desplegar con límites. Publica el runtime con logging, límites de coste, timeouts, versionado de prompts y rollback claro.

Cierre editorial

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

También te puede interesar

Cada semana resumo herramientas de IA para developers (agentes, MCP, seguridad, workflows) en un email corto en español. Suscríbete gratis.

Publicado originalmente en devaisemanal.com.

Tabnine vs Cursor: privacidad enterprise frente a editor agéntico

Khavel — Sun, 28 Jun 2026 13:55:22 +0000

Cursor y Tabnine pertenecen a la misma conversación de IA para programar, pero resuelven problemas distintos: uno rediseña el editor; el otro prioriza control enterprise.

Tabnine vs Cursor parece una comparación directa entre asistentes de código, pero el producto base es distinto. Cursor es un editor centrado en IA, diseñado para chat, edición multiarchivo, contexto de repo y flujos agénticos dentro de una experiencia propia. Tabnine se integra en IDEs existentes y vende más fuerte privacidad, control y adopción enterprise.

No compiten igual

Si tu pregunta es qué herramienta cambia más mi forma de programar, Cursor suele tener ventaja. Si la pregunta es qué herramienta puedo desplegar con más control en una organización sensible, Tabnine gana puntos.

Experiencia de desarrollo

Cursor funciona mejor cuando aceptas vivir dentro de su editor. Su valor está en Composer, contexto de proyecto, ediciones amplias y una interacción muy directa con el código abierto en pantalla.

Tabnine encaja cuando no quieres cambiar el editor del equipo o cuando hay una mezcla de VS Code, JetBrains, Visual Studio y otros entornos. La adopción puede ser menos disruptiva porque se suma al IDE existente.

Privacidad y datos

Cursor ofrece privacy mode y opciones de zero data retention para proveedores de modelos, pero el equipo debe configurar y entender bien esas opciones. Como en cualquier herramienta agéntica, cuanto más contexto le das, más importante es la política de datos.

Tabnine ha construido gran parte de su mensaje alrededor de privacidad, zero data retention, modelos privados y despliegue controlado. Para equipos con compliance fuerte, esa narrativa no es marketing secundario: puede ser el criterio de compra.

Agentes y contexto

Cursor suele sentirse más potente en tareas agénticas interactivas: editar varios archivos, iterar con el modelo y moverse rápido por una base de código desde el editor.

Tabnine Agent acerca Tabnine a esa categoría, pero su ventaja natural sigue siendo dar asistencia gobernable en entornos existentes. Para equipos que temen que un agente toque demasiado, eso puede ser una virtud.

Cuándo elegir Cursor

Quieres un editor centrado en IA y aceptas cambiar el flujo de trabajo.
Haces muchas ediciones multiarchivo y tareas exploratorias.
Tu equipo prioriza velocidad de iteración y experiencia de producto.
Puedes gobernar privacidad y contexto con políticas claras.

Cuándo elegir Tabnine

No quieres cambiar de IDE o tienes varios IDEs en la organización.

Privacidad, despliegue y administración pesan más que la experiencia agéntica más agresiva.

Tu equipo quiere empezar por completions, chat y tareas controladas.

Necesitas una historia clara para seguridad, legal o compliance.

Conclusión

Cursor es más transformador como entorno de trabajo. Tabnine es más conservador y gobernable como plataforma de asistencia. Ninguno gana siempre.

Lo que conviene comprobar

La decisión depende del riesgo que puedas aceptar. Para un equipo pequeño que quiere moverse rápido, Cursor puede ser mejor. Para una empresa que necesita control antes que velocidad máxima, Tabnine merece prioridad.

Criterio final

Si no puedes medir consumo, limitar funciones avanzadas y revisar excepciones, todavía no estás listo para tratarlo como coste controlado.

Fuentes y referencias

También te puede interesar

¿Te ha sido útil? Recibe una lectura semanal de herramientas IA para devs (Claude Code, Cursor, Copilot, MCP, agentes) — en español y sin ruido. Suscríbete gratis a DevAI Semanal

Google ADK: cómo crear agentes Python con tools, MCP y evals sin quedarte en demo

Khavel — Sat, 27 Jun 2026 09:06:12 +0000

Google ADK no es solo otra forma de llamar a Gemini. Su valor está en darte una estructura de ingeniería para agentes: orquestación, tools, MCP, sesiones, evaluación y despliegue sin esconder todo en un prompt gigante.

Google ADK, Agent Development Kit, es un framework code-first para construir, evaluar y desplegar agentes de IA. Está optimizado para Gemini y Google Cloud, pero su idea importante no es el proveedor: es tratar el agente como una aplicación con runner, tools, estado, evals y runtime.

Plan de despliegue

TL;DR

La keyword principal es Google ADK agentes; la intención de búsqueda en español es práctica: entender qué es ADK, cómo crear un agente Python, cómo conectar tools y MCP, cómo evaluar trayectorias y cuándo desplegarlo en Cloud Run o Agent Engine.

Mi postura: ADK merece atención si tu equipo ya vive cerca de Google Cloud o necesita workflows de agente más explícitos que un chat con functions. No lo usaría para un bot trivial; sí para agentes que tocan APIs, documentación interna, BigQuery, tareas asíncronas o pipelines con evaluación.

Checklist

Qué es Google ADK en una frase citable

Google ADK es un framework para crear agentes de IA como software: defines agentes, instrucciones, modelos, tools, workflows, sesiones, evaluación y despliegue con código en vez de confiar en prompts sueltos.

La diferencia frente a una llamada directa al modelo es la arquitectura. En una llamada normal tienes prompt, modelo y respuesta. En ADK tienes un runtime que puede gestionar eventos, estado, tools, subagentes, callbacks, evals y canales de despliegue.

Eso importa porque los agentes reales no fallan solo por el modelo. Fallan por permisos demasiado amplios, tools vagas, estado implícito, rutas de ejecución imposibles de reproducir y cambios de prompt que nadie evalúa antes de publicar.

Recibe una lectura semanal de herramientas IA para devs

Si quieres seguir frameworks de agentes como Google ADK, Pydantic AI, OpenAI Agents SDK, Claude Agent SDK y MCP sin tragarte cada changelog, DevAI Semanal te lo resume en un email de 5 minutos.

Suscribirme gratis

Lectura práctica

La arquitectura mínima de un agente ADK serio

Piensa en ADK como cinco capas. Primero, el agente o workflow que decide el flujo. Segundo, las tools que exponen capacidades concretas. Tercero, session y memory para no depender de contexto pegado a mano. Cuarto, evaluación para comparar comportamiento. Quinto, despliegue en un runtime que puedas observar y limitar.

La parte peligrosa es confundir flexibilidad con barra libre. Un agente con acceso a Google Search, BigQuery, repos internos y herramientas mutantes necesita límites más parecidos a un servicio backend que a un prompt de playground.

La frontera útil: ADK orquesta el flujo, pero el equipo define tools estrechas, estado explícito, evals y permisos antes del despliegue.

Primer ejemplo: un agente Python pequeño

La forma más sana de empezar no es un sistema multiagente. Es un agente con una instrucción concreta y una tool de lectura. Si esto no es reproducible y medible, añadir subagentes solo amplifica el ruido.

from google.adk.agents import Agent
from google.adk.tools import google_search

root_agent = Agent(
    name="research_assistant",
    model="gemini-flash-latest",
    instruction=(
        "Busca informacion tecnica actual, cita fuentes y di cuando "
        "no tengas evidencia suficiente. No ejecutes acciones mutantes."
    ),
    tools=[google_search],
)

Checklist

Tools: el contrato importa más que la lista

ADK permite conectar tools propias, herramientas integradas, OpenAPI y MCP. La tentación es enchufar todo lo que el agente podría necesitar. Mala idea. Una tool debe tener nombre claro, argumentos mínimos, output predecible y permisos acordes al riesgo.

Regla práctica: tools de lectura primero; tools mutantes solo con scopes estrechos, logging y aprobación humana cuando afecten repos, datos de cliente, facturación, infraestructura o producción.

La documentación de ADK incluye McpToolset para conectar servidores MCP por transportes locales o remotos. Eso es potente, pero MCP no sustituye el diseño de permisos. Si un servidor MCP expone demasiadas acciones, ADK solo será el sitio donde ese riesgo se vuelve fácil de invocar.

Briefing

MCP en ADK: cuándo tiene sentido

Usa MCP cuando la capacidad vive fuera de tu aplicación: documentación viva, repositorios, observabilidad, catálogos internos, data warehouses o herramientas SaaS. No uses MCP para esconder una API mal modelada detrás de una tool genérica.

El patrón que sí usaría: un agente ADK con una tool MCP de lectura para recuperar contexto, una tool propia para validar o normalizar resultados y una salida final que el producto pueda auditar. El patrón que evitaría: un agente con diez servidores MCP y ninguna política de allowlist.

Lectura práctica

Segundo ejemplo: conectar un servidor MCP por HTTP

Este ejemplo es deliberadamente estrecho: una sola fuente de documentación por MCP remoto, cabecera explícita y una instrucción que limita el uso a búsqueda técnica. En producción, la clave viviría en Secret Manager o en el entorno del runtime, nunca pegada al repo.

import os

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import McpToolset
from google.adk.tools.mcp_tool.mcp_session_manager import (
    StreamableHTTPConnectionParams,
)

docs_mcp = McpToolset(
    connection_params=StreamableHTTPConnectionParams(
        url="https://developerknowledge.googleapis.com/mcp",
        headers={"X-Goog-Api-Key": os.environ["DEVELOPER_KNOWLEDGE_API_KEY"]},
    )
)

root_agent = Agent(
    name="google_docs_agent",
    model="gemini-flash-latest",
    instruction=(
        "Responde preguntas de implementacion usando documentacion oficial. "
        "Cita la pagina consultada y marca incertidumbre."
    ),
    tools=[docs_mcp],
)

Workflow agents: cuándo salir del agente único

ADK cubre agentes de workflow como SequentialAgent, ParallelAgent y LoopAgent. La señal para usarlos no es que suenen sofisticados; es que tu proceso ya tiene fases claras.

Puntos a revisar

Lo que conviene comprobar

Un SequentialAgent encaja en pipelines como investigar, sintetizar y validar. Un ParallelAgent encaja cuando puedes separar tareas independientes, por ejemplo comprobar documentación, changelog y repositorio. Un LoopAgent solo debería existir con condición de parada clara, presupuesto y salida observable.

La ruta mala es meter routing dinámico desde el día uno. Primero escribe el flujo determinista que un humano seguiría. Luego permite adaptación donde de verdad haya incertidumbre.

Checklist

Sesiones y memoria: no todo contexto merece entrar al prompt

ADK separa conversación, eventos, estado y memoria. Esa separación ayuda a evitar el clásico prompt gigante que mezcla preferencias, datos vivos, resultados intermedios y reglas de seguridad.

Para un agente interno, guardaría en sesión lo necesario para continuar una ejecución; en memoria, preferencias o hechos reutilizables; y fuera del prompt, cualquier dato sensible que solo debería consultarse bajo tool controlada.

Si no puedes explicar qué parte del contexto viene de sesión, memoria o tool call, no estás listo para auditar el agente cuando se equivoque.

Checklist

Evaluación: el punto donde ADK deja de ser demo

ADK incluye evaluación de respuestas y trayectorias. La parte clave es la trayectoria: no basta con que la respuesta final suene bien; importa qué tools llamó, en qué orden, con qué argumentos y si ignoró instrucciones críticas.

Una batería mínima debería tener casos normales, ambiguos y hostiles. Para agentes con MCP, añade casos donde la tool devuelve datos incompletos, una fuente irrelevante, un error de permisos y una respuesta que debería terminar en revisión humana.

Mide al menos: exactitud, uso correcto de tools, coste, latencia, número de llamadas, refusals útiles, errores de permisos y cambios entre modelos. Cambiar de gemini-flash a un modelo más capaz sin evals es una apuesta, no ingeniería.

Briefing

Despliegue: Cloud Run, Agent Engine o nada todavía

ADK puede desplegar agentes en opciones como Cloud Run y Agent Engine. La elección práctica depende del ciclo de vida. Cloud Run encaja si quieres un servicio HTTP controlado por tu equipo. Agent Engine encaja si quieres apoyarte más en el runtime de Vertex AI para agentes.

Antes de desplegar, exigiría cuatro evidencias: un conjunto de evals que pasa, logs de tool calls, límites de coste y permisos revisados. Si falta cualquiera, deja el agente como herramienta interna o CLI hasta que madure.

Lectura práctica

Checklist de producción

Define una instrucción corta y verificable antes de añadir tools.

Registra solo tools necesarias para la tarea principal.

Separa tools de lectura y acciones mutantes.

Usa MCP con allowlist y credenciales de mínimo privilegio.

Guarda secretos en el entorno o Secret Manager, nunca en el prompt.

Crea evals de respuesta final y de trayectoria.

Registra modelo, tokens, tool calls, latencia, errores y coste.

Añade fallback humano para acciones irreversibles.

Versiona prompts, tools y datasets de evaluación junto al código.

Errores que evitaría

El primero es vender ADK como garantía de calidad por estar cerca de Google. Un framework no convierte tools vagas en decisiones buenas.
El segundo es conectar MCP sin política. Si el agente puede descubrir o ejecutar demasiadas cosas, el problema ya no es el modelo: es tu superficie de permisos.
El tercero es usar workflow agents para impresionar. Si el flujo no está claro en una pizarra, tampoco estará claro cuando lo ejecute un LLM.
El cuarto es desplegar antes de evaluar trayectorias. Una respuesta correcta con tool calls incorrectas es una incidencia esperando fecha.

Cuándo elegir ADK frente a OpenAI Agents SDK o Pydantic AI

Elige ADK si tu stack está en Google Cloud, usas Gemini/Vertex AI, quieres una ruta clara a Cloud Run o Agent Engine y necesitas orquestación con tools, sesiones y evals dentro del ecosistema Google.

Puntos a revisar

Lo que conviene comprobar

Elige OpenAI Agents SDK si tu producto depende de la superficie OpenAI, tracing y handoffs propios del SDK. Elige Pydantic AI si tu equipo Python prioriza tipos, output estructurado y portabilidad entre proveedores.

La decisión no debería ser religiosa. Haz una prueba con el mismo caso, las mismas tools y las mismas evals. El framework que haga más fácil auditar el fallo gana.

Plan de adopción en cinco días

Día 1: elige una tarea de lectura con impacto real, como responder dudas de documentación interna o preparar un briefing técnico.
Día 2: crea un agente ADK con una sola tool y logs básicos. Nada de acciones mutantes.
Día 3: añade session state y diez evals: cinco normales, tres ambiguas y dos hostiles.
Día 4: prueba MCP solo para una fuente concreta y mide si mejora la respuesta o solo añade coste.
Día 5: decide runtime. Si las evals no son estables, no despliegues; deja el agente como CLI interna.

Checklist

Conclusión

Google ADK es interesante porque empuja los agentes hacia una forma más operable: runner, tools, workflows, sesiones, evaluación y despliegue. Esa estructura no elimina el riesgo, pero lo hace visible.

Mi recomendación es usar ADK como disciplina, no como excusa para meter más IA en producción. Empieza estrecho, mide trayectorias, limita MCP, audita permisos y despliega solo cuando puedas reproducir una run mala sin leer la mente del modelo.

Preguntas frecuentes

¿Qué es Google ADK?

Google ADK, Agent Development Kit, es un framework code-first para construir, evaluar y desplegar agentes de IA con modelos, tools, workflows, sesiones y runtimes.

¿Google ADK solo sirve con Gemini?

Está optimizado para Gemini y Google Cloud, pero la idea del framework es modular y puede integrarse con tools, MCP y distintos patrones de despliegue.

¿ADK soporta MCP?

Sí. ADK puede conectar servidores MCP mediante McpToolset, incluyendo transportes locales y remotos, para exponer capacidades externas como tools del agente.

¿Cuándo usar workflow agents en ADK?

Úsalos cuando el proceso tenga fases claras: secuencial para pipelines, paralelo para tareas independientes y loop solo con condición de parada y presupuesto.

¿Qué debo evaluar en un agente ADK?

Evalúa respuesta final, trayectoria, llamadas a tools, argumentos, latencia, coste, errores, refusals útiles y comportamiento ante datos ambiguos o hostiles.

¿ADK reemplaza a OpenAI Agents SDK o Pydantic AI?

No. ADK compite como framework de agentes, pero conviene elegir según stack, proveedor, despliegue, tipado, observabilidad y facilidad de evaluación.

Cierre editorial

Regla operativa

Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

Tabnine vs GitHub Copilot: privacidad, autocompletado y control enterprise

Khavel — Thu, 25 Jun 2026 09:10:47 +0000

Tabnine y GitHub Copilot compiten como asistentes de código, pero no empujan exactamente el mismo ángulo: Copilot gana por ecosistema; Tabnine por control y privacidad.

Tabnine vs GitHub Copilot no es solo una comparación de calidad de sugerencias. Es una comparación de filosofía de producto. Copilot está profundamente integrado con GitHub, Microsoft y el ecosistema de modelos premium. Tabnine empuja más fuerte la idea de control: privacidad, despliegue enterprise, modelos gobernados y una plataforma que una organización puede limitar mejor.

La diferencia principal

Para un desarrollador individual, Copilot suele ser la opción más obvia por popularidad, ecosistema y experiencia general. Para equipos regulados, consultoras o empresas que quieren aislar contexto y controlar políticas, Tabnine merece una lectura más seria.

Autocompletado y flujo diario

Copilot se percibe como referencia porque su autocompletado está muy extendido y su experiencia en VS Code/GitHub es fluida. Funciona bien para código común, tests, boilerplate, explicación y chat.

Tabnine también cubre completado, chat y asistencia en IDEs, pero su propuesta se vuelve más interesante cuando la organización valora consistencia, privacidad y administración. No intenta ganar solo por espectacularidad; intenta ser aceptable para equipos que no pueden abrir todo el contexto a cualquier proveedor.

Privacidad y entrenamiento

Aquí está la diferencia que más pesa para empresas. Tabnine comunica con fuerza zero data retention, cifrado y opciones de despliegue privado o air-gapped según plan. También diferencia modelos propios y modelos de terceros, algo importante porque las garantías pueden cambiar según el modelo activado.

Copilot ofrece controles y planes enterprise, pero para usuarios Free/Pro/Pro+ conviene revisar ajustes de uso de datos y entrenamiento. En organizaciones, la pregunta práctica no es quién promete más, sino qué cuenta se usa, qué plan aplica y qué datos puede procesar el asistente.

Agentes y funciones avanzadas

Copilot ha avanzado hacia agent mode, code review, integración con GitHub y flujos de PR. Eso lo vuelve potente para equipos que ya viven dentro de GitHub y quieren que la IA participe en el ciclo completo de desarrollo.

Tabnine también ha añadido Tabnine Agent y CLI, moviéndose más allá del autocompletado clásico. Aun así, su posición diferencial sigue siendo la gobernanza. Si quieres máxima integración con GitHub, Copilot tiene ventaja. Si quieres despliegue controlado y límites enterprise, Tabnine compite mejor.

Cuándo elegir Tabnine

Tu empresa prioriza privacidad, cumplimiento o despliegue controlado.
Necesitas políticas centralizadas para modelos y contexto.
Trabajas en repos propietarios donde no quieres depender de configuraciones individuales.
Prefieres productividad incremental y gobernable a agentes muy autónomos.

Cuándo elegir Copilot

Tu equipo ya vive en GitHub y Microsoft.
Quieres la experiencia más popular y con más integraciones.
Te interesan code review, agent mode y flujos de PR dentro de GitHub.
El riesgo de datos está cubierto por plan Business/Enterprise y políticas claras.

Conclusión

Copilot es la opción más natural para muchos desarrolladores. Tabnine es la opción que conviene mirar cuando seguridad, control y despliegue pesan más que la inercia del ecosistema.

Lo que conviene comprobar: la decisión correcta no es cuál completa mejor una función en una demo. Es qué asistente puedes permitir en tu organización sin que privacidad, coste y gobernanza dependan de preferencias locales de cada desarrollador.

Criterio final: si no puedes medir consumo, limitar funciones avanzadas y revisar excepciones, todavía no estás listo para tratarlo como coste controlado.

Fuentes y referencias

Publicado originalmente en devaisemanal.com.

¿Te sirve este tipo de análisis? Cada martes envío una lectura de herramientas IA para devs — Claude Code, Cursor, Copilot, MCP, agentes — en español y sin ruido. Suscríbete gratis.

GitHub Agent Finder: cómo descubrir agentes, MCP y skills sin convertir Copilot en una caja negra

Khavel — Wed, 24 Jun 2026 09:59:06 +0000

GitHub Agent Finder apunta a un problema real: los agentes no pueden cargar todos los MCP servers, skills y herramientas por si acaso. La mejora no es descubrir más cosas; es descubrir solo lo permitido, con ranking, política y decisión humana.

GitHub Agent Finder es una capa de descubrimiento para Copilot que busca capacidades relevantes para una tarea - MCP servers, tools, skills, agentes o canvases - en un registro permitido y devuelve matches ordenados para usarlos bajo demanda.

Plan de despliegue TL;DR La keyword principal es GitHub Agent Finder; la intención de búsqueda en español es entender qué es, cómo encaja con ARD/MCP registries y qué controles necesita un equipo antes de permitir discovery dinámica de herramientas. Mi postura: Agent Finder es una buena dirección porque reduce contexto basura y configuración manual. Pero si lo tratas como una tienda de plugins, vas a crear el mismo problema de permisos que ya tenías con MCP, solo con mejor UX.

Qué problema resuelve GitHub Agent Finder

Una definición citable: GitHub Agent Finder es un servicio de discovery para Copilot que consulta catálogos compatibles con Agentic Resource Discovery (ARD) y ayuda a encontrar capacidades adecuadas para una tarea sin preconfigurar todas las integraciones en cada agente.

El problema es familiar para cualquier equipo que haya probado MCP o agentes custom. Empiezas con un servidor de GitHub, añades uno de documentación, luego CI, navegador, base de datos, cloud, tickets y un par de skills. En poco tiempo el agente tiene demasiado contexto, demasiadas tools y una frontera de permisos que nadie sabe explicar.

Agent Finder cambia el centro de gravedad: en vez de cargar todo por defecto, Copilot puede buscar en un índice de recursos y proponer capacidades relevantes. Eso es útil solo si el índice está gobernado. La discovery sin política es shadow IT con ranking.

Lectura práctica ARD en una frase: catálogo, registro y ranking ARD no es otro framework de agentes. Es una especificación de discovery: define cómo publicar, describir, buscar y verificar recursos agentic, desde MCP servers hasta skills, agentes y herramientas tradicionales. La distinción importante es entre catálogo y registro. Un catálogo publica recursos y metadatos; un registro o discovery service los indexa y responde búsquedas. Agent Finder se apoya en ese modelo para que Copilot no dependa de una lista estática pegada en un JSON o en un perfil de agente. Para equipos, la pregunta correcta no es qué puede descubrir Copilot. La pregunta correcta es qué catálogos puede consultar Copilot, quién aprueba esos recursos, qué scopes tienen y cómo revocamos acceso.

Modelo recomendado: Agent Finder descubre y rankea capacidades, pero la ejecución real debe quedar separada por scopes, allowlists, logs y aprobación humana cuando haya acciones mutantes.

Qué descubre realmente

La documentación de GitHub describe Agent Finder como una forma de encontrar capacidades como MCP servers, tools, agents y skills en tiempo de ejecución. El anuncio añade canvases dentro del conjunto de recursos que puede considerar.

Eso importa porque capacidad no significa siempre lo mismo. Un MCP server puede exponer una tool mutante sobre GitHub. Una skill puede ser una guía operativa en Markdown. Un custom agent puede traer instrucciones, herramientas y comportamiento especializado. Un canvas puede ser una superficie de trabajo compartida.

Mezclarlos bajo discovery común tiene sentido para UX, pero no para riesgo. Un skill de solo lectura y un MCP server con permisos de escritura en producción no merecen el mismo proceso de aprobación.

La promesa buena: menos contexto muerto

El beneficio más claro es reducir contexto muerto. Hoy muchos setups cargan todos los servidores MCP o todas las instrucciones por si acaso. Eso ensucia el prompt, aumenta coste, introduce ambigüedad y abre más caminos para prompt injection indirecta.

Si Agent Finder funciona bien, el agente no necesita arrastrar cada tool en cada sesión. Describe la tarea, consulta recursos relevantes, obtiene matches rankeados y solo entonces decide qué incorporar.

Ese patrón es mejor que la configuración estática infinita. Pero no elimina la revisión: un ranking no es una autorización. Ranking responde qué parece útil; política responde qué se puede usar.

La promesa peligrosa: discovery como sustituto de gobierno

El fallo fácil sería vender Agent Finder como automatización mágica: el agente encuentra lo que necesita y listo. Eso es exactamente lo que no debes permitir en repos privados, datos de clientes, billing, cloud o CI/CD.

GitHub insiste en tres límites sanos: puedes apuntar a registros públicos o privados, los recursos descubiertos se acotan por settings gestionados y Agent Finder no instala ni conecta silenciosamente nada. Esos tres detalles son la diferencia entre discovery útil y permiso implícito.

En un equipo serio, Agent Finder debería devolver opciones, no conceder autoridad. La persona o política del entorno decide si una capacidad entra en la sesión y con qué alcance.

Briefing Cómo lo usaría en un equipo dev Primero, separaría registros. Un registro público para exploración y aprendizaje. Un registro privado para recursos internos aprobados. Nada de mezclar servidores de demo con herramientas que tocan repos, issues, secrets, observabilidad o bases de datos. Segundo, modelaría recursos por intención. leer documentación, triage de issues, depurar CI, proponer PR, consultar métricas y mutar infraestructura son categorías distintas. La categoría debería determinar scopes, logs y aprobación.

Tercero, publicaría skills y agentes custom como código revisable. Un SKILL.md o un perfil de agente no es documentación inocente: puede guiar decisiones de producción. Debe pasar por PR, ownership y versionado.

Lectura práctica MCP registry no es lo mismo que barra libre de MCP GitHub ya documenta políticas para gestionar uso de MCP en organizaciones y empresas: bloquear MCP, restringirlo a registros definidos y aplicar settings en superficies soportadas como IDEs y Copilot CLI. Agent Finder se apoya en esa misma lógica de registro: descubre dentro de las fuentes que permites. Si el registro está mal curado, el resultado estará mal curado. Si el registro separa lectura, escritura, producción y sandbox, la discovery empieza a ser operable. Mi regla: ningún recurso descubierto dinámicamente debería tener más permisos que una integración configurada a mano. La discovery debe reducir fricción, no subir privilegios por comodidad.

Skills y custom agents: el riesgo no está solo en las APIs

La documentación de GitHub para agent skills usa SKILL.md con frontmatter e instrucciones, y permite ubicaciones de proyecto, personales y compartidas. Los custom agents usan perfiles Markdown con identidad, descripción, tools y configuración de MCP.

Eso es potente porque convierte conocimiento de equipo en componentes reutilizables. También es delicado: una skill puede enseñar al agente a ignorar señales, ejecutar comandos demasiado amplios o confiar en fuentes no revisadas.

Por eso trataría skills, agents y MCP servers como dependencias. Tienen owners, versión, changelog, scope y tests de comportamiento. Si no sabes quién mantiene una capacidad, no debería aparecer en el registro interno.

Checklist de adopción

Define si Agent Finder usará catálogo público, registro privado o ambos.
Separa recursos exploratorios de recursos aprobados para trabajo real.
Clasifica capacidades por lectura, inspección, escritura y mutación crítica.
Haz que skills y custom agents internos vivan en repos revisables.
No permitas auto-instalación ni auto-conexión de capacidades mutantes.
Registra qué recurso descubrió Copilot, por qué tarea y quién lo autorizó.
Empieza con recursos de documentación y CI de solo lectura.
Exige scopes mínimos para MCP servers y revocación sencilla.
Prueba custom agents en privado antes de liberarlos a toda la organización.
Mide si baja el contexto cargado y los errores de herramienta, no solo si parece más cómodo.

Errores que evitaría

El primero es confundir discovery con confianza. Que Agent Finder encuentre una capacidad no significa que sea correcta para tu repo, tus datos o tu compliance.

El segundo es crear un registro privado que acaba siendo un cajón desastre. Si todo entra, el registro no gobierna; solo maquilla el desorden.

El tercero es no revisar las instrucciones. En agentes, el riesgo puede estar en una API, pero también en una frase de SKILL.md que empuja al modelo a actuar fuera del procedimiento esperado.

Implementación mínima razonable

Paso 1: inventaria tus capacidades actuales: MCP servers, skills, custom agents, scripts y herramientas que ya usa el equipo.
Paso 2: elimina duplicados y clasifica cada capacidad por intención, datos accesibles, acciones posibles y owner.
Paso 3: crea un registro privado pequeño con recursos de bajo riesgo y documentación interna.
Paso 4: prueba Agent Finder con tareas reales pero no críticas, observando qué matches devuelve y qué contexto evita cargar.
Paso 5: añade capacidades mutantes solo cuando puedas limitar scopes, auditar uso y exigir aprobación humana.

Briefing Conclusión GitHub Agent Finder es una respuesta sensata a un problema que MCP hizo visible: no puedes escalar agentes si cada sesión arrastra todas las tools, todos los skills y todos los agentes por si acaso. La parte importante no es que Copilot descubra más recursos. Es que descubra menos recursos, mejores, permitidos y relevantes. Si tu adopción termina con un catálogo más ordenado, menos contexto cargado y permisos más estrechos, Agent Finder aporta. Si termina con otro marketplace sin ownership, solo has cambiado el nombre del desorden.

Preguntas frecuentes

¿Qué es GitHub Agent Finder?

GitHub Agent Finder es una capacidad de Copilot para descubrir recursos de IA, como MCP servers, tools, skills y agentes, consultando registros compatibles con ARD y devolviendo matches relevantes para una tarea.

¿Qué es ARD?

Agentic Resource Discovery es una especificación abierta para publicar, descubrir y verificar capacidades agentic en la web o en registros privados.

¿Agent Finder instala herramientas automáticamente?

No. Según GitHub, Agent Finder encuentra opciones y devuelve matches, pero no conecta ni instala silenciosamente recursos.

¿En qué se diferencia de configurar MCP servers a mano?

La configuración manual enumera recursos por adelantado; Agent Finder permite buscar capacidades en tiempo de ejecución dentro de registros permitidos.

¿Es seguro usar Agent Finder en una empresa?

Puede serlo si usas registros privados, settings gestionados, scopes mínimos, logs y aprobación humana para acciones mutantes. No debería usarse como permiso implícito.

¿Qué debería meter primero en un registro privado?

Recursos de bajo riesgo: documentación interna, skills de diagnóstico, herramientas de lectura y agentes custom probados en repos no críticos.

Cierre editorial Regla operativa Activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

Publicado originalmente en devaisemanal.com. Si te sirve este tipo de análisis, suscríbete gratis a DevAI Semanal — herramientas de IA para devs, agentes, MCP y seguridad, resumidas cada semana en español.

DEV Community: Khavel

Evaluación RAG en producción: métricas, datasets y gates antes de cambiar tu pipeline

TL;DR

Qué problema resuelve la evaluación RAG

La arquitectura mental: dataset, pipeline, jueces y gates

Métricas que sí separan el problema

Lo que conviene comprobar

Dataset: empieza pequeño, pero con dientes

Retrieval: mide ranking, no solo similitud

Generación: groundedness no es lo mismo que utilidad

Jueces LLM: útiles, pero no oráculos

Cómo poner gates sin bloquear todo el equipo

Coste, latencia y evaluación continua

Lo que conviene comprobar

Errores comunes que veo en equipos

Plan de adopción en cinco días

Conclusión

Preguntas frecuentes

¿Qué es evaluación RAG?

¿Qué métricas usar para RAG en producción?

¿Necesito ground truth para evaluar RAG?

¿Ragas, LangSmith, LlamaIndex o DeepEval?

¿Cuántas preguntas necesito para empezar?

¿La evaluación automática reemplaza revisión humana?

Cómo montar una evaluación RAG mínima en producción

Regla operativa

Fuentes y referencias

Claude Opus 4.8 vs GPT-5.5 — the actual 2026 price and context numbers

The two flagships, side by side

Where that 20% actually matters

One caveat that trips everyone up: tokens aren't a shared unit

The third option people skip: Google undercuts both

The short version

Vercel AI SDK: cómo montar agentes en Next.js con streaming, tools y MCP

TL;DR

Qué es Vercel AI SDK y qué no es

Arquitectura mínima en Next.js

Streaming: dónde se gana y dónde se rompe

¿Te está sirviendo? Hay una dosis cada semana

Lo que conviene comprobar

Tools: contratos pequeños, permisos explícitos

MCP sin convertirlo en barra libre

Agentes: ToolLoopAgent no arregla un mal proceso

Structured output: cuándo validar JSON

Observabilidad y coste

Checklist de producción

Cuándo elegir AI SDK frente a OpenAI Agents SDK, LangGraph o Cloudflare Agents SDK

Plan de adopción en cinco días

Conclusión

Preguntas frecuentes

Cómo llevar Vercel AI SDK a producción en Next.js

Regla operativa

Recibe una lectura semanal de herramientas IA para devs

Cursor Background Agents: cómo preparar entornos remotos sin regalar tu repo

La idea duradera

Qué hace distinto a un background agent

El archivo environment.json como contrato

Permisos de GitHub: empieza pequeño

Auto-run no es magia, es superficie de ataque

Privacidad y retención

Lo que conviene comprobar

API y automatización

Checklist de adopción

Cuándo no usarlo

Conclusión

Regla operativa

Fuentes y referencias

15 AI models hit end-of-life in the next 90 days — the full table

The table

A few things worth flagging

How to not get surprised by this

Cloudflare Agents SDK: cómo crear agentes con estado en Durable Objects

Qué es Cloudflare Agents SDK y qué no es

Arquitectura mínima que sí desplegaría

Código mínimo: estado, routing y RPC

Lo que conviene comprobar

Configurar Durable Objects sin olvidar migraciones

Estado: cuándo usar setState y cuándo usar SQL

MCP: conectar herramientas sin abrir toda la cuenta

WebSockets y cliente React: progreso sin polling torpe

Estado: cuándo usar `setState` y cuándo usar SQL