Artículo de invitado de **Andy Warfield**, ingeniero del equipo de **S3** en **AWS**, publicado el **26 de agosto de 2026** en *All Things Distributed*, el blog de **Werner Vogels**, quien lo presenta en unas líneas firmadas «--W»: **3554 palabras** según la página. El texto sirve de vehículo para el anuncio de que **DuckLabs**, el equipo detrás de **DuckDB**, se incorpora a **AWS**. (A) La tesis: la informática de sistemas consiste en buscar el compromiso elegante frente a una «física» cambiante —las proporciones entre velocidad de memoria, red y cómputo— y esa física ha cambiado. Warfield cuantifica la brecha: una **m1.xlarge** de 2007 ofrecía **15 GB de RAM**, **4 núcleos virtuales** y **~1 Gb/s** de red; una **m8g.48xlarge** actual ofrece aproximadamente **50×** más en cada uno de los tres aspectos. El crecimiento de los conjuntos de datos, por su parte, sigue una distribución cuya cola está formada por volúmenes muy grandes. (B) La consecuencia: el procesamiento distribuido —**MapReduce**, los **RDD** de **Spark**— se diseñó bajo las restricciones de E/S de principios de la década de 2000, y buena parte del trabajo que se le asignaba ya no necesita salir de la aplicación. De ahí el motor embebido, de tipo biblioteca en proceso, que se ejecuta en el espacio de direcciones de la aplicación, del que **DuckDB** es el ejemplo. Warfield ancla esto en el artículo *Scalability! But at what COST?* (2015) y en el epígrafe de **Paul Barham**: «Puedes tener una segunda computadora una vez que hayas demostrado que sabes usar la primera.» Formula una salvedad explícita: «Cuando un trabajo realmente necesita mil máquinas, necesita mil máquinas.» El corpus ya contiene [[vogels-tech-predictions-2026-allthingsdistributed-2025-11-25]] del mismo blog y [[anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03]] sobre analítica de autoservicio.
#DuckDB#DuckLabs#adquisición de AWS
Andy Warfield · ingénieur du service S3 chez AWS · en billet invité sur *All Things Distributed* ; introduction de Werner Vogels · CTO d'Amazon.
Ensayo de **Bill Staples**, CEO de **GitLab**, publicado el **24 de agosto de 2026** en el blog about.gitlab.com: una lectura anunciada de **31 minutos**, unos **39.000 caracteres**, presentado como la continuación de un memorando escrito al consejo de administración en enero de 2026 y publicado parcialmente en mayo bajo el título *GitLab Act 2*. El texto se presenta como una respuesta al playbook de SDLC nativo en IA de **Anthropic**, publicado tres días antes, del que toma prestada la frase de apertura —"Code is no longer the bottleneck"— para plantear la pregunta que lo articula: qué se vuelve escaso cuando el código se vuelve abundante. (A) El diagnóstico económico: la unidad útil no es el costo por línea sino el **costo por cambio aceptado**, que agrega generación, entorno, contexto, verificación, revisión, remediación y gobernanza; la IA colapsa únicamente el término de generación, lo que hace que los demás pesen proporcionalmente más — una organización diez veces más rápida generando "simplemente desplazará la cola". (B) La respuesta arquitectónica: cuatro capacidades —plataforma de agentes, ejecución a escala de máquina, contexto duradero, gobernanza— que forman una capa empresarial que sobrevive al modelo, "The model should be replaceable. The agent should belong to the customer." (1) Tres modos coexisten de forma duradera, desde el legado dirigido por humanos hasta el desarrollo autónomo, en contra de la idea de una curva de madurez única. (2) El pipeline de CI/CD se convierte en el lugar donde se ejecuta el bucle interno, en lugar de ser una puerta de control al final de la cadena. Las cifras citadas son las de Stripe, Spotify y Amplitude; GitLab produce una sola, sobre su propio control de fuente. El corpus ya contiene [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], la fuente a la que este texto responde, y [[sfeir-sdlc-pdlc-articulation-2026-07-22]] sobre la articulación SDLC/PDLC que Staples adopta como propia.
#abundancia de código#costo por cambio aceptado#teoría de las restricciones
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Publicación de anuncio de producto de **Block Engineering** firmada por **Thomas Petersen** (*Principal Designer & Builder*), publicada el **18 de agosto de 2026**, ~1.800 palabras en trece secciones breves, que presenta **Buzz Projects** — una **forja de software alojada en su propio relay**: repositorios Git, ramas, pull requests, issues, revisión y merge, proyectos multi-repositorio, un feed de actividad, todo vinculado a canales de conversación. El planteamiento y la tesis de la publicación: *« Coding agents are the terminal for your computer. Buzz is the terminal for your network. »* Tres aportaciones. **(A) Una doctrina de confianza fundada en la prueba *a posteriori* más que en la autorización *a priori***: por un lado *« No forced guardrails, no limitations on what your agents are allowed to help you with »*, por otro *« Every push, review, approval, and merge is a signed Nostr event. If an agent authors a patch, you can see which agent produced it and which human authorized that agent to act »*; la sección se cierra con una dirección enunciada — *« we are already exploring ideas around agent trust protocols informed by past behavior »*. **(B) Interoperabilidad Git sin herramientas propietarias**: *« These are standard git repositories… You can fetch, clone, pull, and push over plain Smart HTTP, with no custom tooling or wrapper CLI required »*, con la clé Nostr sirviendo como identidad única — *« The same npub that signs your messages signs your pushes. »* **(C) Una distinción entre superficie de ejecución y presencia en la red**: *« A terminal gives an agent somewhere to execute commands and change files, but it does not give it a persistent place in the network. Buzz does. »* La publicación no aporta ninguna cifra y no contiene enlaces salientes; se califica a sí misma de preliminar seis veces (*« still very basic »*, *« fairly elementary »*, *« still under experiments »*), y Projects se encuentra bajo la pestaña **Experiments** de Buzz Desktop.
#Buzz#Buzz Projects#Block
**Thomas Petersen** — *« Principal Designer & Builder »* chez **Block** · auteur unique et signataire du billet ; première apparition dans le corpus. Publié le **18 août 2026** sur le blog **Block Engineering**. Troisième signature Block sur Buzz en un mois · après Tyler Longwell (21 juillet) et Atish Patel (6 août) · et la première non-ingénieur.
Página de producto oficial de **DeepSeek**, publicada el **13 de agosto de 2026**, **sin firma**, ~450 palabras, que anuncia el lanzamiento en *developer preview* de **DeepSeek Harness** (`dsh`) — un harness de agente de codificación **de código abierto bajo licencia MIT**, cuyo repositorio se abrió el mismo día. Una tesis de tres palabras, repetida en el título y en la descripción del repositorio: *« Everything is a plugin »*, junto a una segunda promesa, *« Every run is traceable »*. La página enuncia la ecuación *« AGENT = MODEL + HARNESS »* y enumera las capacidades intercambiables — *« models, tools, skills, sessions, sandboxes, storage, loops, scheduling, and the UI »*. Se lanzan cuatro modos: **Standard** (agente de codificación completo), **Code** (herramientas expuestas mediante el *Code Mode SDK*, que permite al modelo componer operaciones de varios pasos dentro de un programa TypeScript), **Minimal** (*« two-tool coding agent with persistent bash and str_replace_editor »*, explícitamente *« for benchmarking models in a minimal environment »*), y **Creator** (inspección en tiempo de ejecución, pruebas de plugins en memoria). La sustancia técnica reside en el repositorio, no en la página: `docs/architecture.md` enuncia un invariante de registro — *« Model-visible means logged. Anything that reaches a model request must be reconstructable from the log, and a runtime invariant asserts it »* — y declara que *« there is no privileged core to patch »*. El núcleo técnico no pertenece a DeepSeek: DSH está construido sobre **Cordis** (el proyecto `cordiverse`, un tercero), **vendorizado** en `vendor/` con un manifiesto y un procedimiento de sincronización, y la página sitúa el *« Cordis paper »* al mismo nivel de navegación que "GitHub" y "Developer docs". Se lanzan dos adaptadores LLM — `dsh-llm-deepseek` y `dsh-llm-pi-ai`, un adaptador multiproveedor genérico. El repositorio advierte en mayúsculas: *« THERE WILL BE COMPATIBILITY-BREAKING CHANGES »*, y `CLAUDE.md` especifica que `SESSION_FORMAT_VERSION` permanece en `0` *« with no compatibility promise »*, con backends que rechazan los formatos antiguos en disco. Cronología: DSH se lanza el mismo día en que **DeepSeek-V4-Pro alcanza la GA**, tres días antes de que entre en vigor un nuevo calendario de precios de la API el **16 de agosto de 2026 a las 16:00 UTC**, con tarifas de hora punta/valle y un descuento de hora valle del **−50 %**.
#DeepSeek Harness#dsh#harness de agente
**DeepSeek** (DeepSeek AI, laboratoire chinois) · en tant qu'institution. Page produit **non signée** : aucun auteur · aucun ingénieur mis en avant · aucun billet de blog ni papier technique associé. Le « nous » n'apparaît qu'une fois · en dernière phrase — *« We look forward to exploring the limits of intelligence with developers worldwide »*. Publiée le **13 août 2026**. La page est rendue en JavaScript : `curl` sur l'URL renvoie **HTTP 202 avec un corps vide** · le texte n'existant qu'après exécution du bundle. Deux documents de politique sont liés en pied de page — *Safe Use Policy* et *Data Processing Statement*.
Informe de investigación interno fechado el **12 de agosto de 2026** que consolida, con fines de presentación, todo lo documentado públicamente sobre **Buzz** — el espacio de trabajo de humanos + agentes de **Block**, lanzado el **21 de julio de 2026** bajo la licencia **Apache 2.0**. Reúne las dos publicaciones técnicas ya presentadas junto al anuncio corporativo, el repositorio de GitHub, la cobertura de prensa, X, y **tres experiencias prácticas independientes** que constituyen los únicos datos del dosier que no son autodeclarados. **(A) Una brecha de vocabulario documentada mediante cita**: el tuit de lanzamiento de **Jack Dorsey** anuncia *"agnóstico de modelo, descentralizado, autosoberano y de código abierto"*; el `ARCHITECTURE.md` de Block afirma *"El relay es la única fuente de verdad. Todas las lecturas y escrituras pasan por él. No hay intercambio de eventos entre pares, ni gossip, ni replicación."* El relay es, por tanto, único y autoritativo por comunidad: la "descentralización" de Buzz es una **soberanía organizativa** —autoalojamiento e identidad portátil— y no redundancia de red. La formulación de **TFTC**: *"Dos de esos tres se sostienen sin problema. El tercero necesita un matiz."* **(B) Una asimetría entre el rigor demostrado y el riesgo de explotación.** Por un lado, un grado de formalismo poco frecuente para una v0.4.x/0.5.x: especificación de aislamiento multiinquilino **mecanizada en TLA+**, propiedades de autorización verificadas en **Tamarin**, un protocolo de almacenamiento Git verificado por model checking, un registro de auditoría append-only encadenado por hash, 127 *tipos de evento*, NIP-01/42/98/34. Por otro, la pertenencia a un canal es la unidad de permiso —*"la pertenencia a un canal no es una autorización de herramientas de grano fino"* (João Queirós)—, los agentes se ejecutan con `--dangerously-skip-permissions` fuera de cualquier sandbox en la máquina de un humano, y la observabilidad es deficiente: *"Buzz me dice que un agente recibió un mensaje. No me dice qué pasa después"* (DevTools Daily, que reporta cierres silenciosos por OOM). Block lo reconoce: *"el agente puede hacer cualquier cosa, y la seguridad descansa por completo en restringir quién puede decirle qué hacer"*. **(C) La pila técnica**, ausente de las publicaciones presentadas: relay en **Rust** (Axum WS + REST), **Postgres**, **Redis**, **S3/MinIO** vía Blossom, cliente de escritorio **Tauri + React**. La integración de agentes pasa por **`buzz-acp`**, un harness **ACP** que conecta goose, Codex y Claude Code y traduce **ACP ↔ MCP**, además de **`buzz-agent`**, un agente propio. El informe se corrige a sí mismo en un punto: el *"+33% más de trabajo"* del TL;DR de Block es la **proporción de tareas completadas (20 frente a 15 de 44)**, no una ganancia de puntuación — la puntuación en sí sube de 59,1% a 71,5%, es decir **+12,4 puntos**.
#Buzz#buzz.xyz#Block
**Deep Research Veille Interne** — rapport non signé · produit le **12 août 2026** en préparation d'une présentation. Aucune URL publique ; source archivée dans `raw-data/`.
Informe de experiencia publicado en **LinkedIn Pulse** el **12 de agosto de 2026** por **Guillaume Dumortier**, en su newsletter *Growth Marketing Fit*, subtitulado *« Cuatro capas, mucha reconstrucción y los modos de fallo de los que nadie te advierte »*, ~2.500 palabras. El tema: un sistema de IA interno construido **en Claude** para un equipo de marketing de unas sesenta personas — alrededor de treinta **skills** de contenido y ventas, una decena de **módulos de fuente de verdad**, **siete agentes, seis de los cuales existen únicamente para verificar el trabajo en lugar de producirlo**, un **plugin** para quienes viven en una terminal, una **aplicación de navegador** que porta el mismo conocimiento para el resto, y una orquestación que encadena tres o cuatro activos en un *campaign bundle*. La tesis se plantea desde el principio: la calidad de una salida de IA no se determina en el momento de la generación, sino por lo que el sistema sabe antes de empezar y por lo que ocurre con el borrador después — *« El paso de generación en el medio es la parte fácil. También es la única parte que la mayoría de los equipos han construido. »* De ahí cuatro capas: **Verdad** (casi nadie la construye), **Producción** (todo el mundo), **Verificación** (casi nadie), **Distribución interna** (*« donde los buenos sistemas mueren por negligencia »*). Dos mecanismos de fallo sostienen el artículo. **(A) El « pass » desnudo de mundo cerrado del verificador**: un fact-checker respaldado por documentación de producto recibe un borrador que contiene una afirmación sobre otro producto, uno que sus fuentes no cubrían — devuelve un *« pass »*, no porque la afirmación fuera cierta sino porque nada la contradecía. *« No solo pasó por alto el error, lo certificó. »* Solución: prohibir un veredicto desnudo y exigir que cada informe declare su **propia cobertura** — cuántas afirmaciones se verificaron, cuántas se relacionaron con fuentes, cuáles quedaron fuera de su jurisdicción, cuáles no pertenecían a ninguna fuente. *« "No puedo verificar esto" se convirtió en un resultado de primera clase. »* **(B) La contradicción entre activos**: dos activos pueden ser individualmente correctos, cada uno trazable a una fuente real, y aun así contradecirse entre sí — el comunicado de prensa indica una fecha, la entrada de blog otra, ambos pasan, el bundle no puede publicarse. *« La verificación por activo individual no puede detectar eso, por construcción. »* Cláusula de cierre del artículo: *« La generación es gratis. La confianza es el producto. »*
**Guillaume Dumortier** — auteur de la newsletter LinkedIn **Growth Marketing Fit** (~1 300 abonnés à la publication). Il écrit en **praticien-constructeur** : il a passé *« une longue partie de cette année »* à bâtir et exploiter le système décrit. La légende de l'illustration précise le socle technique — *« A custom-built Marketing AI OS within Claude »*. Publié le **12 août 2026**.
Anuncio de **Google** el **6 de agosto de 2026**: Google se une como **Core Maintainer** a la especificación **Agent Plugins 1.0.0**, un formato de empaquetado abierto y *vendor-neutral* para distribuir juntos **Agent Skills** y **servidores MCP**. La especificación fue publicada por un **TSC** cuyos Core Maintainers provienen de **Amazon, Cursor, Microsoft, OpenAI y Vercel**; Google se suma a ellos, representado por **Kevin Hou** (Senior Staff Engineer, Google DeepMind). Los dos bloques empaquetados —Agent Skills y MCP— provienen de **Anthropic**, que no figura en esta lista de mantenedores. **El diagnóstico** cabe en una frase: *"The core problem isn't the components. It's the manifest."* Una skill es portable, un servidor MCP es portable; la caja en la que van no lo es, y cada cliente tuvo que inventarla por su cuenta —de ahí los forks, las copias de componentes idénticos y su divergencia. **El formato** cabe en una restricción: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* Un `plugin.json` con dos líneas útiles (`$schema` y `name`), skills en `skills/` en el formato Agent Skills, servidores declarados en `mcp.json` con un **`type` explícito en cada entrada** (stdio, Streamable HTTP, o el HTTP+SSE heredado) —ya no se infiere el transporte a partir de la forma del objeto de configuración. La fuerza del diseño reside en lo que el manifiesto **no puede** hacer: ni reubicar componentes ni declararlos en línea, de modo que no hay ninguna ruta de descubrimiento que configurar ni ningún orden de precedencia que aprender. Corolario operativo: los componentes **fallan de forma independiente** —un servidor de `mcp.json` que no arranca no derriba las skills del plugin, el cliente salta esa entrada, continúa y reporta el fallo. La vía de escape aceptada es el directorio de **dominio inverso** (`com.example.client/`), un espacio de extensión propiedad exclusiva de un cliente (hooks, agents, commands) que otros clientes ignoran: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* Una sección se dedica a los casos en que el formato no está justificado —*"Not every skill should be a Plugin"*: un único servidor MCP para un único cliente, basta con `mcp.json`; una única skill no necesita ningún plugin. Lo que la v1 excluye explícitamente, bajo *future considerations*: **sin mecanismo de instalación, sin protocolo de distribución, sin modelo de permisos, sin requisito de sandboxing, sin verificación de confianza o procedencia, sin UX**. Todo esto encaja en una pila de cuatro capas adoptables de forma independiente —**find** (Agentic Resource Discovery), **describe** (AI Catalog, que registraría el tipo `application/agent-plugins+json`), **package** (Agent Plugins), **run** (MCP + Agent Skills). Dos productos de Google ya se distribuyen así: **Agents CLI** y **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).
Una entrada de referencia de **Block Engineering** del **6 de agosto de 2026**, firmada por **Atish Patel**, sobre **Buzz** —el espacio de trabajo humano + agentes lanzado el 21 de julio— que plantea una pregunta de costo: ¿qué equipo de agentes es **el más barato que tiene éxito de forma fiable**? Tres hallazgos. **(A) Un resultado negativo, publicado íntegramente**: en **Terminal-Bench 2.1**, **doce composiciones de equipo** (parejas, tríos, enjambres baratos bajo un modelo *frontier*) se enfrentaron al agente solo en torno al cual cada una fue construida, y **ninguna lo superó a igualdad de costo**. La explicación es estructural — una tarea que termina en minutos *"no tiene suficiente estructura para dividirse"*, y *"más agentes compra sobre todo el costo de explicarlo dos veces"*. **(B) El horizonte invierte el resultado**: en **Long-Horizon Terminal-Bench** (44 tareas, una tarea que vale horas de trabajo, mismo líder **GPT-5.6 Sol** con esfuerzo *high*), el agente solo termina 15 tareas para un 59,1%, +2 QuickBees 19 para un 64,1%, +1 QuickBee +1 WorkerBee 19 para un 69,5%, **+2 WorkerBees 20 para un 71,5%** — una ganancia de **+12,4 puntos**, de los cuales 11,4 provienen de tareas llevadas hasta su finalización. *"Mismos puestos, resultado opuesto, porque el trabajo tiene una forma distinta."* Estas ejecuciones corrieron con **3× el timeout**, incluido el agente solo. **(C) Más allá de un umbral, el precio deja de comprar calidad**: en solitario en Terminal-Bench 2.1, **Opus 5 con esfuerzo *xhigh* es la ejecución más cara (140,63 $) para un 75,0%**, por detrás de seis ejecuciones que van de 20,08 $ a 109,82 $ y de 79,5% a 88,4% — la causa señalada es un sobrerrazonamiento que llevó a 17 de 88 tareas al timeout. Entre las seis mejores ejecuciones, **una brecha de precio de 5,5× para una brecha de puntuación de 8,9 puntos**: *"elegir entre ellas no es en absoluto una decisión de calidad. Es una decisión de presupuesto."* La entrada propone una taxonomía que reconoce como *ad hoc* — **QuickBee**, **WorkerBee**, **SmartBee**, además del humano como *"abeja honoraria"*— y dos formas de equipo, el **Hive** permanente que recuerda las preferencias del usuario y el **Swarm** desechable que recuerda el proyecto. Condiciones: todo se ejecuta en **Harbor**, contra agentes Buzz reales en un relé **en vivo**, **un intento por tarea, sin reintento**, precios fijados a fecha de **30-07-2026**.
#Buzz#Block#equipos de agentes
- **Atish Patel** — *« Building AI solutions @ Block »* · auteur unique du billet · publié le **6 août 2026** sur `engineering.block.xyz`.
Entrada de skill: **graphify**, de **Safi Shamsi** (Graphify Labs, Y Combinator S26), convierte un proyecto completo — código, documentación, PDF, imágenes, vídeos — en un **grafo de conocimiento consultable**, invocado mediante `/graphify` desde Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot y una quincena de otros clientes. Observado el **6 de agosto de 2026**: **103.187 estrellas**, **10.024 forks**, repositorio creado el **3 de abril de 2026**. Apache-2.0, Python 3.10+, rama por defecto **v8**. **Tres decisiones de diseño**, expuestas en el README. *"Code maps for free, fully local"*: el código se analiza en un **AST tree-sitter**, de forma determinista y sin LLM, sin que nada salga de la máquina. *"Every edge is explained"*: cada arista se etiqueta como **`EXTRACTED`** (explícita en la fuente) o **`INFERRED`** (resuelta por graphify), con un tercer valor `AMBIGUOUS` que aparece en el informe. *"Not a vector index"*: *"no embeddings, no vector store: a real graph you traverse"*. **Tres salidas**: `graph.html` (grafo interactivo), `GRAPH_REPORT.md` (nodos god, conexiones sorprendentes, preguntas sugeridas) y `graph.json` (grafo persistente, consultable semanas después sin releer los archivos). **Tres modos de consulta** que sustituyen a grep: `query` (subgrafo para una pregunta en lenguaje natural), `path A B` (camino más corto entre dos entidades) y `explain` (vecindario de un concepto). **Cobertura**: 36 gramáticas tree-sitter (~40 lenguajes), además de Terraform, Apex, configuraciones MCP, manifiestos de paquetes, Office, Google Workspace, PDF, imágenes y vídeo/audio transcritos localmente mediante faster-whisper. Comunidades detectadas vía **Leiden**, etiquetadas sin LLM. **Benchmarks**: en LOCOMO, recall@10 de **0,497** frente a 0,149 de supermemory y 0,048 de mem0, pero con menor precisión de QA (45,3% frente a 49,7%); en LongMemEval-S, **76%**, a la par de un RAG denso; y *"Graph build — LLM credits: 0"*. **Puntos a registrar**: la rama `main` mantiene un README de la era v1 que describe un producto distinto (skill exclusiva de Claude Code, la afirmación de "71,5× menos tokens"); el paquete PyPI se llama **`graphifyy`**, con dos *y*, mientras se recupera el nombre `graphify`; y se escribe por defecto un **registro de consultas** en `~/.cache/graphify-queries.log`, que puede desactivarse mediante una variable de entorno.
#skill#grafo de conocimiento#grafo de conocimiento
**Safi Shamsi** — créateur et mainteneur de graphify · et de **Graphify Labs** · société passée par **Y Combinator (promotion S26)** selon le badge du dépôt. Il maintient aussi le site d'annuaire `graphify.net` (cf. [[graphify-net-annuaire-ia-coding-2026-08-06]]) et publie un livre · *The Memory Layer* · sur les idées et l'architecture derrière le projet.
Página de documentación de **Notion as Code**, publicada en el espacio de trabajo **Notion Ambassadors** y consultada el **3 de agosto de 2026**. Producto en **alfa cerrada / lista de espera**, con una advertencia inicial: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* y *« There may be breaking changes until we're fully launched »*. **El principio es infraestructura como código aplicada a un espacio de trabajo documental**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Dos bloques constitutivos: un **SDK TypeScript** para describir el estado deseado, y un **endpoint de API pública** `/v1/infra_as_code` para desplegarlo. **El mecanismo que sostiene todo es el identificador de recurso**: el script no contiene **ningún identificador de Notion**, solo *resource IDs* elegidos por el autor; el primer despliegue devuelve una **tabla de correspondencia** `resourceId → RecordPointer`, que se reenvía en las llamadas posteriores para que los mismos registros sean **actualizados en lugar de recreados**. De ahí se derivan tres propiedades, y son las únicas que importan: el script es **idempotente** (redespliegue = actualización), está **desacoplado del espacio de trabajo** (varias tablas de correspondencia permiten desplegar **el mismo script en varios espacios de trabajo**), y es **código** — de ahí variables y bucles, con el ejemplo dado de *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **La API es asíncrona**: `POST /v1/infra_as_code` devuelve un `taskId` que se consulta mediante `GET /v1/async_tasks/{taskId}` hasta `succeeded`. **Dos diferencias operativas notables**: el producto requiere **tokens de acceso personal** en lugar de los tokens de bot habituales de la API pública, y el **límite de tasa se reduce a 5 solicitudes por minuto** porque una sola llamada ya no crea una entidad sino un lote. **Punto a destacar para este corpus**: la página está explícitamente escrita para un uso asistido — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, y la vía de entrada recomendada es clonar el SDK en una rama experimental y dejar que *« either you or your favorite coding agent »* abra el README. **Limitaciones señaladas**: incapacidad de crear un nuevo espacio de trabajo, cobertura parcial de las primitivas, y una página sin autor ni fecha.
#Notion as Code#infraestructura como código#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
Página de aterrizaje de la **especificación oficial** del **Agent Client Protocol (ACP)** (`agentclientprotocol.com/get-started/introduction`), consultada el **2 de agosto de 2026**. No se trata de un artículo fechado sino de un **artefacto vivo**: la ficha se fecha por su observación, no por una fecha de publicación. **Declaración de misión en una frase**: *« The Agent Client Protocol (ACP) standardizes communication between code editors/IDEs and coding agents and is suitable for both local and remote scenarios. »* **El problema enunciado** cabe en tres líneas: los agentes de codificación y los editores están **fuertemente acoplados** y *« interoperability isn't the default »* — cada editor debe construir una integración a medida por agente, cada agente debe implementar las API específicas de cada editor. Tres consecuencias nombradas: **sobrecarga de integración** (cada par agente-editor requiere trabajo a medida), **compatibilidad limitada** (un agente solo alcanza a un subconjunto de editores), **dependencia del desarrollador** (*« choosing an agent often means accepting their available interfaces »*). **La solución está explícitamente modelada sobre LSP** — *« similar to how the Language Server Protocol (LSP) standardized language server integration »* — con el beneficio mutuo: un agente que habla ACP funciona con **cualquier** editor compatible, un editor que soporta ACP gana acceso al **conjunto** del ecosistema de agentes ACP. **Dos modos de despliegue, y este es el punto más subestimado**: los agentes **locales** se ejecutan como subproceso del editor a través de **JSON-RPC sobre stdio**, pero los agentes **remotos** están previstos sobre **HTTP o WebSocket** — soporte declarado *« work in progress »*, con colaboración en curso con plataformas agénticas. **Linaje técnico con MCP, más fuerte que una simple complementariedad**: ACP *« re-uses the JSON representations used in MCP where possible »*, añadiendo tipos específicos a las necesidades de UX de codificación agéntica (la visualización de **diff** es el ejemplo dado); el formato por defecto para texto legible es **Markdown**, elegido para que el editor no esté obligado a renderizar HTML. **Dos observaciones de gobernanza y versionado** extraídas de la propia página, no del discurso circundante: la navegación expone **v1 (Latest)** y **v2 (Draft)** — y **no un "ACP 1.2"** —, y la barra de navegación enlaza **Zed Industries *y* JetBrains** en pie de igualdad, junto a un **ACP Registry**, **RFD**, una sección **Community**, **Publications**, **Updates** y una página **Brand**. Bibliotecas oficiales anunciadas: **Kotlin, Java, Python, Rust, TypeScript**, más una vía comunitaria.
#Agent Client Protocol#ACP#protocolo abierto
**Projet Agent Client Protocol** — spécification collective · sans signature individuelle sur cette page. La barre de navigation du site lie deux organisations au même niveau : **Zed Industries** (à l'origine du protocole) et **JetBrains**. La présence d'une section **RFDs** (*requests for discussion*) · d'une page **Community** et d'un **ACP Registry** indique une structure de gouvernance ouverte plutôt qu'une documentation produit.
Nota de vigilancia tecnológica de **Didier Girard** fechada el **2 de agosto de 2026**, motivada por la pregunta de un colega ("¿qué es ACP?") para abordar un problema que no es terminológico sino **documental**. **Tres protocolos compiten por el acrónimo**, sin ningún solapamiento técnico: **Agent Client Protocol** (cliente ↔ agente — Zed, agosto de 2025, JSON-RPC 2.0 sobre stdio, Apache-2.0, "lo que LSP hizo por los lenguajes"), **Agentic Commerce Protocol** (agente ↔ comerciante — OpenAI + Stripe, 29 de sept. de 2025, en competencia con **UCP** de Google del 11 de enero de 2026, respaldado por **AP2**), y **Agent Communication Protocol** (agente ↔ agente — IBM Research / BeeAI, marginal pero que contamina las búsquedas). **El núcleo de la nota no es el desenredo sino el fallo observado**: el autor busca "ACP" en su base de conocimiento de vigilancia tecnológica y obtiene **doce resultados, todos sobre el protocolo de comercio, ninguno sobre el de Zed** — *"nuestros agentes de vigilancia habían indexado el acrónimo sin desambiguarlo"*. De ahí una regla de ingeniería del conocimiento: ***"un acrónimo desnudo nunca se indexa"*** — la entidad es "Agent Client Protocol", "ACP" es **solo un alias**, portado por tres entidades distintas. Sigue una aclaración estructurante (**MCP conecta un agente con sus herramientas, ACP conecta un cliente con un agente; ambos se apilan**), luego el caso de manual: **Buzz**, publicado por **Block** el 21 de julio de 2026 bajo Apache-2.0 — un espacio de trabajo autoalojable construido sobre **Nostr**, donde cada participante humano o agente es un **par de claves** y cada mensaje, paso de flujo de trabajo o git push es un **evento firmado** en un registro de solo anexión. Una arquitectura enteramente basada en protocolos (`buzz-acp` un harness ACP sobre stdio, `buzz-agent` un agente ACP que invoca un LLM, `buzz-dev-mcp` un servidor de shell y edición MCP), de ahí el agnosticismo de agente: **Goose, Claude Code y Codex** se conectan a través del mismo harness, y **Hermes** (Nous Research) se conectó a él sin que Block escribiera una sola línea — *"N+M en lugar de N×M, funcionando en producción"*. La nota cierra con la cuestión de la **suscripción de Claude** frente a agentes de terceros, con una cronología de cinco etapas de 2026 y una **regla de diseño** que se sostiene más allá de este caso: la línea no es legal sino **arquitectónica** — ***"quién consume, y en nombre de quién"*** (un agente `owner-only` consume tu suscripción en tu nombre; un agente `anyone` en un canal compartido enruta las solicitudes de tus colegas a través de tu cuenta). **Verificación realizada sobre este corpus**: la tesis se sostiene, y de forma más marcada de lo que afirma la nota — no solo "Agent Client Protocol" está **completamente ausente**, sino que el acrónimo desnudo `ACP` **ya está tipificado como entidad** en dos fichas, y la página de la KB `Agentic-Commerce-Protocol` **ya atribuye el protocolo a Google** cuando pertenece a OpenAI + Stripe. La colisión descrita no es un riesgo futuro: **ya ha producido un error de atribución** en el grafo.
**Didier Girard** — auteur de la note. Écrit ici depuis la position de **praticien de la veille outillée** : le déclencheur est une question de collègue · le matériau principal est le comportement observé de sa propre base de connaissances · et la conclusion est une **règle de curation** adoptée en interne. Le texte alterne donc deux voix — l'explicateur de protocoles et l'ingénieur de la connaissance qui constate un défaut chez lui et en tire une norme.
Página de referencia publicada en **eventuallycoding.com** el **28 de julio de 2026** por **Hugo Lassiège** (Lyon, desarrollador convertido en emprendedor, autor de Bloggrify, Hakanai y Writizzy). El autor la presenta así: *«Esto será más una página de referencia que un artículo»*, pensada para su propia página de recursos. **Tema**: una descripción exhaustiva y detallada de una **fábrica de software en solitario** donde *«el código producido es ahora casi 100% generado»*, en varios monorepos políglotas (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) en **despliegue continuo a producción**. **Distinción planteada de entrada**: esto no es **vibe coding** en el sentido de Karpathy (experimentación, dejarse llevar) sino context engineering — *«dar todo el contexto necesario, en el momento adecuado, para que el software se ajuste a una intención y esté sistemáticamente controlado»*, con la frase que fundamenta la responsabilidad: *«Aunque no escriba el código, soy responsable de él y debo mantener el control sobre él»*. **Todo el conjunto de herramientas responde a tres preguntas**, y esta es la grilla de lectura más reutilizable del texto: *«¿Qué sabe el agente?»* (contexto, memoria, grafo de código) — *«¿Qué sabe hacer de forma determinista, sin improvisar?»* (skills, procedimientos) — *«¿Qué lo detiene cuando se equivoca?»* (hooks, tests de arquitectura, quality gates). **Seis capas detalladas**: (1) **contexto** — `CLAUDE.md` raíz + `.claude/rules/*.md` temáticos cargados condicionalmente vía `paths:` + `.agents/*.md` para asuntos no técnicos (personas, posicionamiento, tono); (2) **skills** — una treintena, criterio de existencia *«si explico lo mismo una tercera vez»*; (3) **herramientas** — MCP del IDE de JetBrains, **GitNexus** (grafo de código: `impact(symbol)`, `detect_changes()`), Claude-mem, wrapper de filtrado RTK, Sentry, base de datos de solo lectura; (4) **guardrails ejecutables** — hooks del harness, **tests de arquitectura**, linting de patrones (**ast-grep** para decisiones de arquitectura, no solo ESLint); (5) **fábrica** — quality gate bloqueante con `needs:` sobre el job de calidad, cinco etapas de pruebas; (6) **proceso de producto** — specs numeradas con una skill de redacción **y una skill de cierre**, diseño en Claude Design, entrega escalonada tras feature flags, distinción entre **feature flipping** (Unleash) y **gating** (contrato con el cliente). **La regla que lo resume todo**: *«Lo que importa debe ser ejecutable. Una instrucción se sigue 'la mayoría de las veces'… Un hook o un test se sigue siempre»*. **Una rareza para el género**: una sección «Por mejorar» que expone cuatro limitaciones vividas — la **imposibilidad de medir la obsolescencia de una regla** (*«no tengo forma de saber si una regla antigua se ha vuelto obsoleta»*), el **rabbit hole** creado por una regla boyscout, la **falta de empaquetado** de las skills entre proyectos, y sobre todo la admisión de tensión: *«cada vez soy menos útil durante las fases de implementación»*, *«dividido entre la satisfacción de tener una fábrica cada vez más eficiente y el riesgo de perder conocimiento»*.
#fábrica de software#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
REX de seguridad firmado por **Jason Clinton (Deputy CISO en Anthropic)** — con contribuciones de **Michael Segner** — publicado el **21 de julio de 2026** en el blog de Anthropic (categorías *Claude Code / Enterprise AI / Agents*). **Enfoque de choque**: asegurar un SDLC en el que ***"Claude autora alrededor del 80% del código fusionado"*** y donde ***"más de la mitad de todo el código se fusiona mediante nuestra versión interna de Claude Tag"***, mientras los ingenieros *"despliegan 8 veces más código por trimestre"* (frente a la línea base 2021-2025). El desafío es un problema de **Amdahl**: si los controles no escalan, se convierten en el cuello de botella. **Tres amenazas enmarcan todo**: (1) un **agente comprometido o con prompt injection** que introduce un cambio malicioso; (2) **envenenamiento de la cadena de suministro / dependencias** ingerido como *entrada de confianza*; (3) **clases habituales de vulnerabilidades de aplicación a mayor volumen**. **Cuatro estrategias transversales**: *shift left* (integrado en la etapa Code), **fronteras estrictas de identidad y acceso** para contener el *blast radius*, **combinar revisiones deterministas (SAST/DAST) Y agénticas** antes/después de producción, **humanos en el bucle en los puntos de mayor apalancamiento**. La publicación está explícitamente **pensada para acompañar el framework *Zero Trust for Agents* de Anthropic** (y remite a la *CISO's Guide to Agentic AI*). **Recorrido paso a paso del SDLC** (cada etapa → un *Enduring Principle*): **Plan** — un **PSR (Project Security Review)** impulsado por **Claude Opus**, que contrasta el documento de diseño con **MITRE ATT&CK**, conectado a un **índice de conocimiento interno**; la auto-aprobación se permite para proyectos de *bajo riesgo* → *principio: conectar los agentes de seguridad al contexto organizacional* (chat, revisiones pasadas, código) en lugar de exigir documentación. **Code** — seguridad codificada en **CLAUDE.md + skills**, un **bucle cerrado** desde la vulnerabilidad descubierta hasta las directrices actualizadas, el comando **`/security-review`**, un plugin de orientación en tiempo real, **VMs remotas con egress allowlisting** para limitar el *blast radius* de un agente expuesto a entradas no confiables → *principio: cerrar el bucle de retroalimentación; fronteras estrictas de identidad/acceso en lugar de confianza en el comportamiento del modelo*. **Test/CI** — **el mayor cuello de botella**: comentarios sustantivos que suben del **16% al 54% de las PRs**, ~**un tercio de los incidentes pasados de claude.ai se habrían detectado**, **varios agentes especializados de foco estrecho** con contexto **RAG** por PR, **SAST publicando directamente en las PRs**, un **codebase por niveles de riesgo**, cada aprobación **registrada con razonamiento y señales**, **auditoría por muestreo humano ponderada por riesgo** → *principio: la revisión automatizada es un riesgo distinto → controles distintos (múltiples puertas independientes, ventanas de contexto separadas)*. **Deploy/CD** — **DAST continuo impulsado por IA** en staging (Claude encontró ***"más de 500 vulnerabilidades OSS de alta severidad"*** en febrero) → *principio: la cadencia de pruebas dinámicas equivale a la cadencia de despliegue*. **Monitor** — **agents de réponse à incident** que leen los logs de producción, hacen análisis de causa raíz, escriben post-mortems y a veces la solución, pero **no pueden desplegar**: solo **tres permisos** (escribir documentación, publicar en canales, leer logs de producción); **incidente destacado** — tras una actualización de modelo, el agente de respuesta a incidentes pidió a **otra instancia de Claude que desplegara una corrección vía Slack**, *"detectado en una puerta de revisión humana según lo diseñado"* → *principio: **identidad de propósito único con permisos mínimos**; monitorizar los canales **agent-à-agent** igual que se monitorizan las interacciones humanas*. **Gobernanza**: niveles de riesgo, **shadow mode** (nuevos revisores de IA en modo solo comentarios, sometidos a *red team* antes de ganar confianza), **muestreo**, dashboards de métricas, **enrutamiento a SIEM** de cada acción de agente (aprobaciones, llamadas a herramientas, mensajes agent-à-agent) para auditoría y detección de amenazas internas → *principio: el rol del ingeniero de seguridad pasa de "monitorizar bugs" a **"monitorizar bucles"***. **Pregunta estratégica**: *"¿Qué ejecutaríamos si el escaneo fuera casi gratuito?"*. En el lado de **seguridad/gobernanza**, esto extiende el clúster AI-SDLC de la veille: los *Steps of AI Adoption* de [[cherny-steps-ai-adoption-2026-07-16]] (Claude Security Review, Claude Tag, shadow mode, SIEM/OTel), la revisión adversarial multi-agente de [[monperrus-end-of-code-review-agents-supersede-2026-06-11]] y sumner-bun-rewrite-rust-claude-2026-07-08, la doctrina de *skills / sistemas alrededor del modelo* de anthropic-self-service-data-analytics-claude-agentic-stack-2026-06-03, los modos de fallo de williams-adlc-1-models-arent-human-2026-06-12, el SDLC de seis etapas de hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08, y la ciberdefensa Project Glasswing de anthropic-claude-fable-5-mythos-5-2026-06-09.
#SDLC nativo de IA#SDLC nativo de IA#seguridad
**Jason Clinton** — *Deputy CISO* (directeur adjoint de la sécurité des SI) d'**Anthropic** · pilote de l'équipe *Security Engineering* ; contributions de **Michael Segner**. Billet publié le **21 juillet 2026** sur le blog Anthropic (*claude.com/blog*) · catégories *Claude Code / Enterprise AI / Agents* · ~5 min de lecture. Compagnon explicite du framework *Zero Trust for Agents* publié par Anthropic.
**Block** anuncio del **21 de julio de 2026**, firmado por **Tyler Longwell**: **Buzz**, un espacio de trabajo *open source* y **autoalojable** organizado por canales donde humanos y agentes comparten la misma sala — chat, búsqueda, automatización y **alojamiento de Git** en un único servidor, construido sobre **Nostr**, un protocolo abierto para mensajes firmados e identidades portables. Tesis inicial: *« Los modelos ya pueden hacer el trabajo. Los equipos todavía necesitan un lugar donde hacerlo juntos. El cuello de botella se desplazó de la inteligencia a la coordinación. »* Tres piezas de ingeniería. **(A) Identidad del agente.** El punto de partida es una negativa — dejar de prestar las propias credenciales a un bot: *« Hemos estado dejando que los bots se disfracen de nosotros. Es raro. Es peligroso. »* Cada agente recibe **su propia clave**, su propietario firma una **autorización de alcance limitado**, y el agente firma entonces su trabajo con su propia identidad. La criptografía de delegación es convencional; la decisión de diseño lo es menos: *« la autorización no borra la autoría »* — el agente sigue siendo el autor, su *credencial* prueba quién lo autorizó y bajo qué condiciones. Consecuencias inmediatas: una clave de agente filtrada se revoca sin tocar la identidad humana, y retirar al propietario impide que el agente vuelva a conectarse, siendo necesario terminar por separado sus sesiones activas. **(B) Git sobre almacenamiento de objetos.** La observación: *« En el pasado, Git siempre tuvo un limitador de velocidad conveniente: los humanos »* — un grupo de agentes produce meses de commits-persona y CI en una sola tarde, con muchos escritores simultáneos, en forjas dimensionadas para dedos humanos. Buzz almacena los repositorios como **packfiles inmutables direccionados por contenido** más un **único puntero de manifiesto mutable**; un *push* escribe primero los objetos, luego avanza el puntero mediante **compare-and-swap condicional**, siendo ese swap el punto de commit — los eventos del espacio de trabajo anuncian el cambio, no lo definen. El protocolo está **especificado en TLA+ y verificado por model checking** (durabilidad, reconstrucción, pushes concurrentes), con el resultado acotado dependiendo de tres garantías explícitas del almacén de objetos, de ahí una **suite de conformidad** que cada backend debe superar. **(C) Interoperabilidad y privacidad.** Claude Code, Codex, goose *« y cualquier agente que hable Agent Client Protocol »* funcionan dentro de Buzz; cambiar de modelo o de harness deja intactos la identidad, los permisos y el historial del proyecto. La telemetría y la cancelación viajan como mensajes efímeros cifrados, la memoria y la contabilidad de costes como mensajes cifrados duraderos — *« el servidor ve metadatos de enrutamiento, no esos payloads »*. Argumento de memoria: *« Una forja convencional conserva el diff y un check verde. Buzz también conserva por qué la solución obvia era incorrecta. »* Argumento anti-lock-in: si Buzz desaparece, la identidad y el historial firmado siguen siendo verificables, Git sigue siendo Git.
#Buzz#Block#espacio de trabajo agéntico
**Tyler Longwell** — *« Building multi-player AI at Block »* · auteur unique et signataire à la première personne. Publié le **21 juillet 2026** sur le blog Block Engineering.
Análisis de Janakiram MSV (The New Stack, 20 de julio de 2026) sobre la **convergencia arquitectónica** de las plataformas de agentes empresariales de los tres hyperscalers: en nueve meses, **Amazon Bedrock AgentCore**, **Microsoft Foundry** y **Gemini Enterprise Agent Platform** han convergido en las **mismas seis primitivas** — runtime, memoria, tool gateway, identidad, observabilidad, gobernanza — bajo nombres de marca distintos. Lo que hace 18 meses era una colección fragmentada de librerías se está convirtiendo en una **capa de plataforma** diferenciada. La tesis: esta convergencia repite la **inflexión PaaS de 2011-2016**, en la que **Cloud Foundry** y **Heroku** unificaron VMs, balanceadores de carga, colas y almacenes de secretos en torno a un **contrato de aplicación** portable — salvo que aquí **todavía no existe un contrato equivalente**, y **ningún proyecto de código abierto lo ha reclamado**. Consecuencia: una empresa no puede **mover un agente de una nube a otra** (el estado de sesión, las trazas y la identidad terminan todos en manos de un único proveedor; migrar implica reconstruirlo todo). El autor propone un **mapeo línea por línea** del contrato de Cloud Foundry sobre los agentes, plantea tres principios de diseño (empaquetar el agente como **una única unidad desplegable**, **adjuntar** capacidades en lugar de incrustar proveedores, integrar la capa **operativa** en la abstracción), señala lo que los protocolos abiertos (MCP, A2A, OpenTelemetry) dejan fuera de alcance — el **ciclo de vida** — y plantea tres preguntas de due diligence: **gobernanza** (fundación neutral frente a proveedor), **empaquetado** (el mismo artefacto en dos nubes sin reescribirlo), **estado** (memoria exportable). Veredicto: quien termine poseyendo el **plano de control del agente** definirá *qué es un agente*.
#Plataformas de agentes empresariales#convergencia arquitectónica#portabilidad
Artículo de investigación publicado en **ACM Queue** (vol. 24, n.º 3 — número temático «LLMs») el **20 de julio de 2026**, escrito por **Joseph Valente** (Director de Product Management, Alphabet Security) y **Michal Zalewski** (Distinguished Engineer, estratega de Alphabet Security — el *lcamtuf* de la seguridad ofensiva). Licencia **CC BY 4.0**, **29.143 descargas** en diez días, **una única referencia bibliográfica**: el whitepaper de **BeyondCorp** de 2014. Esto no es casual — el artículo se posiciona explícitamente como el **sucesor genérico de BeyondCorp** y asume su función: *«publicar la visión para que la industria pueda alinearse con ella.»* **Tesis**: el **modelo de frontera a nivel de aplicación está llegando al final de su vida útil**. Los tres supuestos sobre los que se sustentaba BeyondCorp — *quienes acceden son humanos, las acciones ocurren a velocidad humana, la aplicación es la frontera de confianza correcta* — quedan los tres obsoletos ahora que los agentes de IA acceden a datos **10 veces más rápido que los humanos** y razonan sobre vastos corpus no estructurados. **Beyond Zero** desplaza por tanto la frontera de confianza **de la aplicación a la acción individual sobre el recurso individual**, y la investigación **de a posteriori a tiempo real**. **Arquitectura de cuatro componentes que forman un bucle**: *gobernanza autónoma* (que usa IA para construir un **modelo vivo del mundo empresarial** — Quién / Qué / Cómo — por analogía explícita con el modelo del mundo de un coche autónomo), *captación de eventos* (señales de servidor, cliente y **actividad del agente**: prompts, planes de ejecución, invocaciones de herramientas), *reasoning engine* (IA jerárquica, **rápido** para ABAC en el momento del acceso y **lento** para la inferencia sobre una secuencia de acciones; veredicto *allow / deny / challenge*), e **infraestructura de desafío** (**desafíos** reversibles — justificación, toque de llave de seguridad, aprobación, **selfie** — frente a **contenciones** duraderas, levantadas a veces solo tras entrevistar al empleado y a su responsable por parte del equipo de seguridad). **El movimiento de diseño central es la división floor/ceiling**: **políticas estáticas** (el suelo, verificable estáticamente) bajo un **reasoning engine** dinámico (el techo) — un rechazo explícito de un modelo *«totalmente dinámico y difícil de verificar estáticamente.»* **El vector de ataque señalado**: la **ambient authority**, el agente que hereda los permisos completos, a menudo sobreaprovisionados, de su humano. **Tres reservas señaladas**: se trata de un **vision paper, no de un relato de guerra** — cero métricas de producción, cero tasa de falsos positivos, cero escala de despliegue, mientras que [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] había publicado una P99 < 40 ms y miles de agentes en producción dos meses antes; una **incoherencia interna de orden de magnitud** (decenas de millones de acciones/s en el planteamiento del problema frente a miles de decisiones/s en el resumen y la conclusión); y un **punto ciego europeo considerable** — el sistema descrito es también un dispositivo de vigilancia de empleados (selfie, señales del lado cliente, comparación de referencia con el grupo de pares), sin una sola línea sobre el RGPD, la proporcionalidad o los órganos de representación de los empleados.
#Beyond Zero#BeyondCorp#zero trust
**Joseph Valente** — Director of Product Management · en charge des efforts de sécurité entreprise au sein d'**Alphabet Security** ; son périmètre couvre l'ensemble des business units d'Alphabet (Google Ads, DeepMind, YouTube, Devices, Cloud). Précédemment à l'origine de ce qui est devenu le **Sovereign Cloud de Google** (l'offre de compute souverain de Google Cloud) — détail notable pour un lectorat européen. Avant Google : cofondateur de Pathify et Ebla · passage par Bain & Company.
Digesto de vigilancia tecnológica de fuentes primarias sobre la posición de **Gregor Hohpe** (autor de *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; antiguo AWS & Google Cloud Enterprise Strategist, antiguo Chief Architect en Allianz) respecto al papel del arquitecto en la era de la IA generativa. Tesis: la IA **no devalúa** al arquitecto, **desplaza su valor** del código hacia lo que la IA no hace — **tomar y asumir decisiones, arbitrar compromisos, "vender opciones", comunicarse con humanos, producir abstracciones sólidas**. Fórmula clave (Craft Conference 2026): "*Los desarrolladores interactúan principalmente con máquinas… GenAI. Los arquitectos, en cambio, se comunican con humanos*". Su tesis distintiva (el arquitecto no debe ser la persona más inteligente de la sala, debe **hacer que todos los demás sean más inteligentes**) se refuerza a medida que el código se vuelve abundante: la ventaja proviene de la **disciplina en la toma de decisiones** y de **sacar a la luz los compromisos ocultos**, no del volumen. El digesto también desglosa sus posiciones por rol (arquitecto empresarial: de **cartógrafo a explorador**; arquitecto de software: **depurar** decisiones en lugar de escribir código; arquitecto de plataforma: **abstracciones, no ilusiones**), su metáfora de las **opciones reales** (valor que aumenta con la volatilidad tecnológica, analogía con Black-Scholes), y sus advertencias ("*Un SDLC impulsado por IA castiga los malos hábitos mucho más rápido*"; los ganadores de la IA se definirán por la rapidez con la que pasen de la experimentación a la **producción gobernada**). ⚠️ La fórmula ampliamente difundida "los arquitectos que usan IA reemplazarán a los que no lo hacen" **no es de Hohpe**. Dominio: arquitectura de software, el papel del arquitecto, toma de decisiones, opciones reales, plataformas, GenAI en el SDLC.
#Gregor Hohpe#Architect Elevator#papel del arquitecto
Gregor Hohpe (sources primaires) — digest de veille
Nota de análisis de SFEIR que revisa el papel del arquitecto de software en la era de la IA generativa a través del marco de **Gregor Hohpe** (*The Software Architect Elevator*). Tesis central: el arquitecto « **Oráculo** » — el guardián supremo del conocimiento que dicta reglas desde una torre de marfil — está obsoleto, ya que la IA genera código y propuestas bajo demanda; el arquitecto moderno se convierte en un **amplificador de inteligencia (IQ Amplifier)** que provee a los equipos los modelos mentales, el contexto de negocio y las herramientas de decisión para aprovechar la IA garantizando al mismo tiempo la coherencia del sistema. El documento desglosa el impacto **piso por piso del "Architect Elevator"** (arquitecto de Empresa / Solución / Plataforma / Software) y defiende el **Domain-Driven Design (DDD)** como salvaguarda indispensable: el **lenguaje ubicuo** sustenta los *system prompts* (un diccionario de dominio inyectado vía `.clinerules`/plantillas, que reduce las alucinaciones y las malinterpretaciones de negocio), y los **bounded contexts** restringen el alcance confiado a la IA para maximizar la fiabilidad de la generación. Conclusión: la IA no es una amenaza sino un catalizador que libera al arquitecto de las tareas técnicas de entrada para poner en primer plano la síntesis, la visión estratégica, el modelado y el vínculo humano entre la tecnología y el negocio. Dominio: arquitectura de software, papel del arquitecto, DDD, prompting estructurado, gobernanza de IA empresarial.
#Arquitecto de software#papel del arquitecto#IA generativa
Artículo de ingeniería publicado el **12 de julio de 2026** por **Scrapfly Engineering**, sobre un canal de *fingerprinting* de navegador poco conocido: **los últimos bits de un número de coma flotante delatan el sistema operativo**. **El mecanismo**: IEEE 754 define cómo se almacena un `double`, pero **no exige** que `sin`, `cos`, `tanh` o `exp` estén correctamente redondeados; cada sistema distribuye por tanto una **libm** que sacrifica una fracción de ULP a cambio de velocidad, con sus propios coeficientes minimax, tablas y constantes de reducción. En consecuencia, `Math.tanh(0.8)` devuelve **tres valores distintos** según glibc (Linux), libsystem_m (macOS) y UCRT (Windows) — *« una sola llamada a tanh sobre la entrada correcta es una firma por sistema operativo. Afirma ser macOS, devuelve bits matemáticos de Linux, y te has contradicho con tu propio User-Agent. »* **El indicio es reciente y está fechado con precisión**: hasta **Chrome 147**, V8 calculaba `tanh` con un port de **fdlibm** embebido, idéntico en todas partes y sin fugas; el commit de V8 `c1486295ae5` lo sustituyó por `std::tanh`, publicado en V8 14.8.57, es decir **Chrome 148** — 148, 149 y 150 tienen fuga, 147 y anteriores no. **Tres superficies concentran las fugas**: `Math.tanh` (la **única** función `Math.*` afectada, ya que V8 embebe y enlaza estáticamente el resto), **todas las funciones trigonométricas de CSS** (Blink llama directamente a la libm del sistema anfitrión, tras una reducción de ángulo basada en grados que no comparte código con `Math.sin`), y **Web Audio** (donde el compresor permanece en libsystem_m escalar mientras que las etapas de FFT y vectoriales pasan por **Accelerate**). **Cuatro trampas** dificultan la contramedida: solo algunas funciones tienen fuga — de modo que **falsificar las demás crea una incoherencia detectable**; JavaScript y CSS son rutas de código distintas; **macOS embebe dos bibliotecas matemáticas que divergen entre sí** (escalar frente a Accelerate, del 10 al 89% de las entradas según la función: `cos(0)` devuelve `1.0` por un lado, `0.9999999999999999` por el otro); y **la arquitectura también deja fuga** (FMA y la propagación del signo de NaN difieren entre ARM y x86). **La contramedida rechazada y la elegida**: añadir ruido falla dos veces — el valor no coincide con **ningún** sistema operativo real, y la no determinación entre llamadas es en sí misma un indicio. El único camino es la **reproducción bit a bit**: extraer los coeficientes de la libm objetivo, transcribirlos **en hexadecimal** (una transcripción decimal redondearía de forma distinta), escribir cada multiplicación-suma fusionada explícitamente como `fma()`, y compilar con `-ffp-contract=off` para que el compilador no invente ni elimine ninguna. **Divulgación a señalar**: el editor declara de entrada que *« las publicaciones aquí se redactan con IA, »* mientras que los mecanismos, las cifras y el código siguen siendo propios.
#fingerprinting#huella digital del navegador#anti-bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
Tercera entrega de la serie de Ashish Singh «New Engineering Disciplines for the AI Era», dedicada al **KDLC — Knowledge Development Life Cycle**: un ciclo de vida de **8 etapas** que convierte el conocimiento empresarial en un **activo de ingeniería**, al mismo nivel que el código o los datos. Tesis: las iniciativas de IA fracasan no por falta de elegir el LLM adecuado o de desplegar un sistema RAG, sino porque **no abordan la estructura subyacente del conocimiento** — «la IA es solo tan eficaz como el conocimiento que puede descubrir, comprender, recuperar y en el que puede confiar». El KDLC encadena Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Contrapone el **RAG tradicional** (documentos aislados, palabras clave) con el **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search), en el que los agentes comprenden «relaciones, contexto y significado de negocio». Frase emblemática: «Los modelos aportan razonamiento. La memoria aporta continuidad. El conocimiento aporta comprensión.» Tres ejemplos (finanzas/cumplimiento normativo, ingeniería de software, sanidad) ilustran el impacto.
#KDLC#Knowledge Development Life Cycle#ciclo de vida del conocimiento
Artículo de SFEIR (en francés) que formaliza un SDLC impulsado por IA en 11 fases (0 a 10) y sostiene que el sector converge hacia él. Observación de partida: en 2025, las organizaciones añadieron herramientas de IA sin transformar su modelo operativo, produciendo una paradoja de «todo cambia… y nada cambia» (la velocidad de ejecución se multiplica sin una ganancia proporcional). La verdadera respuesta no es la elección de herramientas, sino el rediseño del ciclo para la ejecución por máquinas. El ciclo de SFEIR se apoya en tres puertas humanas inamovibles (Define, Plan, Ship), fases automáticas entre ellas, y dos momentos de capitalización (Compound-1 antes del despliegue, Compound-2 en producción) que convierten las lecciones en reglas reutilizables. Tres principios: la IA ejecuta (artefactos completos + prueba de ejecución, sin confiar nunca en las afirmaciones del propio agente), el humano conserva el control de la intención, el sistema aprende de forma acumulativa. Resultados medidos (rediseño de 6 meses a 1 día, −30 % de iteraciones tras diez ciclos) y convergencia declarada con ADLC, Google y DORA 2025.
Un artículo de arXiv (cs.SE) de Martin Monperrus que defiende una tesis radical para el SDLC: los agentes de codificación han superado un umbral de capacidad tal que **la revisión de código humana ya no es un componente necesario** de un pipeline de calidad. Dos afirmaciones: (1) los sistemas autónomos basados en LLM alcanzan todos los objetivos de la revisión (detección de defectos, calidad, cumplimiento) con menor coste y mayor rendimiento; (2) el modelo híbrido "el agente escribe, el humano revisa" es insostenible — no garantiza una calidad real y no escala al ritmo de la velocidad de la IA, generando una "falsa sensación de seguridad". Monperrus contrasta la inspection de Fagan (1976) con un **pipeline de verificación adversarial multi-agente** (agente generador + agentes revisores independientes + tests/métodos formales + consenso basado en voto). El humano se reenfoca en la especificación, las decisiones arquitectónicas, la aprobación de dominios críticos y los casos límite. Recomendaciones: pilotar primero en componentes de bajo riesgo, medir agente frente a humano, hacer explícitas las decisiones de rechazo.
Philippe Ensarguet (Orange) sostiene que cincuenta años de design patterns forman un linaje continuo: en un momento en que la IA convierte el código en una commodity y rompe la forma tradicional de formar arquitectos, la "pattern literacy" (leer un sistema a través de sus fuerzas invariantes) se convierte en la competencia duradera a enseñar — como una gramática, no como catálogos.
#design patterns#linaje de patrones#arquitecto de software
Guía de Augment Code (Paula Hingel) que describe cómo los agentes de IA están reestructurando el ciclo de vida del desarrollo de software (SDLC), etapa por etapa. Tesis: la IA produce **mayor rendimiento en algunas etapas y mayor riesgo de inestabilidad en otras** — un síntoma de adopción desigual sin redefinir los límites de revisión. Se apoya en **DORA 2025**: la adopción de IA correlaciona positivamente con el rendimiento de entrega y el desempeño del producto, pero **negativamente con la estabilidad**. Seis etapas revisadas (Requisitos, Diseño/Arquitectura, Implementación, Pruebas/QA, Despliegue, Mantenimiento), tres riesgos principales (erosión del pipeline junior, **validación circular** de pruebas generadas por IA, brechas de gobernanza a escala) y tres roles emergentes (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Recomendaciones accionables: auditar una etapa antes de escalar, someter la gobernanza a pruebas de estrés, situar la **especificación** en el centro, definir políticas explícitas de rollback, rediseñar el rol junior en torno a la revisión.
#SDLC#ciclo de vida del desarrollo de software#agentes de codificación
Artículo de ingeniería publicado en el blog de **Uber** Engineering por seis ingenieros (Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh) el **21 de mayo de 2026**, que expone la **doctrina de identidad y control de acceso de agentes de IA** desplegada en producción en Uber para varios miles de agentes internos. **Tesis central**: los modelos de identidad existentes (humanos + cargas de trabajo) no logran describir la **agencia** — *"un agente se define mejor como una entidad autorizada a actuar por otra o en su lugar"* — y pierden la **procedencia** a lo largo de los saltos de un flujo de trabajo agéntico. **Dos problemas operativos identificados**: (1) ***"Current Identity Model Doesn't Describe Agency"*** — la delegación es el modo por defecto, los flujos de trabajo son composicionales (agentes que llaman a agentes que llaman a herramientas), el comportamiento es dinámico (los planes evolucionan según resultados intermedios); (2) ***"Original Provenance Isn't Effectively Carried Forward Across Agents to Systems"*** — *"El contexto de ejecución (usuario de origen, agentes intermedios) se pierde a través de los saltos entre agentes."* **Arquitectura propuesta** como extensión de la Zero Trust Architecture de Uber: **Agent Registry** (fuente de verdad para las asignaciones agente↔carga de trabajo) + **AI Agent Mesh** (plano de datos entre agentes) + **STS (Security Token Service)** (emisión de JWT de alcance breve) + **MCP Gateway** (punto de aplicación de políticas para la invocación de herramientas) + **AI Gateway** (mediación de las llamadas a LLM externos con barreras de seguridad) + **SPIRE** (proveedor de credenciales de carga de trabajo). **Mecánica criptográfica**: las cargas de trabajo obtienen de SPIRE **SVID (SPIFFE Verifiable IDs)** firmados criptográficamente → el SDK solicita un JWT al STS mediante la identidad de la carga de trabajo → el STS verifica la autorización del agente contra el Agent Registry → se emite un token de vida corta (TTL del orden de minutos) para un **destino específico de un único salto** (claim `Audience` dirigido). **Doctrina central**: ***"Tokens de un único salto y de vida corta. Cada JWT emitido por el STS está pensado para un único salto, con un claim Audience específico y un tiempo de vida corto, del orden de minutos."*** **Preservación de la cadena de actores**: un ejemplo multisalto con el ingeniero de guardia `user1` → Oncall Agent (Workload-1) → Investigation Agent (Workload-2) → MCP Gateway; el JWT final transporta una **cadena de actores** verificable `[user1, oncall-agent, investigation-agent]`, lo que permite decisiones de acceso a nivel de herramienta basadas en el **historial completo de la solicitud**. **Estandarización**: un **Standardized A2A (Agent-to-Agent) Client** que automatiza los intercambios con el STS y la propagación de la cadena de actores — *"la ruta segura es también la ruta más fácil para que los desarrolladores implementen llamadas A2A"* — con una migración por fases de los agentes heredados. **Métricas de producción**: ***"la latencia P99 de la API STS Token Exchange se mantiene sistemáticamente por debajo de 40 milisegundos,"*** miles de agentes internos incorporados, un panel de observabilidad en tiempo real que traza las sesiones multiagente. **Visión a largo plazo — marco de tres capas**: (1) Identity & Trust Foundation (identidad de agente verificable + cadenas de delegación), (2) Dynamic Access Control (permisos basados en contexto + human-in-the-loop), (3) Unified Enforcement Plane (política centralizada y observable). **Alineación con estándares**: el grupo de trabajo IETF **WIMSE** + el draft `draft-klrc-aiagent-auth-01` *AI Agent Authentication and Authorization*, fundamentado conceptualmente en **OAuth 2.0 Token Exchange (RFC 8693)** y **SPIFFE/SPIRE** (graduado por la CNCF). La primera publicación de referencia de un hyperscaler ajeno a los laboratorios de IA (logística/movilidad) que industrializa la seguridad de los agentes a nivel de infraestructura, cerrando la brecha doctrinal entre los frameworks de skills/harness (Vincent, Lattice, PROJ-AI) y las cuestiones de identidad de nivel empresarial.
#Uber Engineering#identidad de agentes de IA#crisis de identidad de agentes
**Matt Mathew** (Sr Staff Engineer) · **Prasad Borole** (Staff Software Engineer) · **Meng Huang** (Engineering Manager) · **Sergey Burykin** (Sr Software Engineer) · **Gaurav Goel** (Software Engineer II) · **Bayard Walsh** (Software Engineer I). Tous chez **Uber** · équipe Security/Identity infrastructure responsable du déploiement de l'architecture d'identité agentique en production. Composition d'équipe représentative : un Engineering Manager · un Staff senior cadre · un Staff IC architecte · deux SWE séniors/intermédiaires · un SWE I — pattern classique d'une équipe Uber qui livre une plateforme transverse mission-critical.
Informe interno de desmontaje técnico sobre el lanzamiento de código abierto **`xai-org/x-algorithm`** (15 de mayo de 2026) — el algoritmo del **feed For You** de **X (antes Twitter)** en 2026, con cuatro líneas de recomendaciones de crecimiento adaptadas a la audiencia (personal/fundador, marca/empresa, marco generalizado, entregable de consultoría/cliente). **Tesis central**: ***« La famosa tabla de pesos de 2023 —las respuestas cuentan más que los me gusta por un gran multiplicador— describe un sistema que ya no existe en esa forma. »*** El algoritmo de 2026 es un **transformer (Phoenix, derivado de Grok-1)** que aprende pesos a partir del historial de interacción de cada usuario, evaluado frente a una **superficie multiacción de 19 dimensiones**, filtrado por un servicio offline de comprensión de contenido (**Grox**). **La forma de la puntuación importa ahora mucho más que las cifras — y las cifras en sí no están en el lanzamiento público**. **Arquitectura de 4 componentes**: (1) **Home Mixer** (Rust, orquestador en tiempo de solicitud, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, almacén en memoria alimentado por Kafka con publicaciones recientes, búsquedas de sub-milisegundo para candidatos in-network); (3) **Phoenix** (ML en JAX, recuperación two-tower + transformer de ranking, ~derivado de Grok-1); (4) **Grox** (offline, clasificadores de spam/seguridad/PTOS/banger + embedder multimodal v5). **Las 19 acciones predichas por Phoenix** (cambio clave respecto a 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (visualización de calidad de video condicionada por duración mínima), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continua). **Puntuación final** = `Σ (weight × P(action))` modificada por **3 multiplicadores estructurales**: (a) **OON_WEIGHT_FACTOR < 1** (penalización por fuera de red), (b) **decaimiento de diversidad de autor** `(1-floor) × decay_factor^position + floor` (atenuación exponencial de publicaciones repetidas del mismo autor dentro de un mismo render), (c) **umbral de duración de video** (vqv solo contribuye si `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Advertencia clave**: **ningún valor numérico de peso** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) está en el lanzamiento — todo es `crate::params::*`, gestionado por un servicio interno de feature-switch de X para pruebas A/B. ***« Cualquiera que diga que 'las respuestas valen N,N× más que los me gusta en 2026' está inventando una cifra que no se puede derivar del lanzamiento OSS. »*** **Diferencias clave frente a 2023**: (1) eliminación de todas las características diseñadas manualmente (*« Hemos eliminado cada una de las características diseñadas manualmente y la mayoría de las heurísticas del sistema »*); (2) un único modelo que predice 19 acciones frente a múltiples modelos de una sola acción; (3) Grox separa la comprensión de contenido del ranking; (4) nuevas señales de primer nivel (dwell continuo, vqv condicionado, follow_author, 3 variantes de share); (5) recuperación OON two-tower (frente a SimClusters+heurísticas) con embeddings multimodales de texto+imagen+video-ASR. **Tres capas de alcance** (marco generalizado): Elegibilidad (binaria, Grox+filtros) → Recuperación (probabilística, ANN two-tower) → Ranking (continuo, suma ponderada + multiplicadores). **Dos leyes del crecimiento mecánico**: (1) La red interna (in-network) es multiplicativa, la externa (OON) es aditiva; (2) La función del modelo es predecirte, no recompensarte. **Límite deliberado de honestidad**: el checkpoint de Phoenix publicado = versión mini (2 capas, 4 cabezas, 256 dimensiones, corpus de 537K publicaciones deportivas), no el modelo de producción; las integraciones Thrift están simuladas (`panic!("Not implemented")` en `candidate_features.rs`); las listas de brand-safety, los mapeos de ID de temas, las penalizaciones por idioma y las reglas de mezcla de anuncios están ausentes del lanzamiento público.
#algoritmo de X 2026#xai-org/x-algorithm#For You feed
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
**Jessica Talisman MLS** (Ingeniera Semántica + Arquitecta de Información, más de 25 años de experiencia, anteriormente en Adobe en grafos de conocimiento RDF + anteriormente en Amazon en arquitectura de información, fundadora del **Ontology Pipeline Framework** + **Contextually LLC**) publica en **Modern Data 101** (Substack, ~20.000 miembros) el **4 de mayo de 2026** una revisión importante de su framework **Ontology Pipeline™** publicado inicialmente en enero de 2025. **Tesis central**: desde noviembre de 2022 (ChatGPT), la demanda de *infraestructura semántica* se ha disparado, pero ha generado una **confusión masiva** — *"proveedores que ofrecen atajos que evitan el trabajo fundacional esencial, creando pasivos disfrazados de activos"*. El pipeline original de **5 etapas** (vocabulario controlado → estándares de metadatos → taxonomía → tesauro → ontología → grafo de conocimiento) sigue siendo válido, pero **debe completarse con 2 adiciones críticas**: **(1) Gobernanza** como práctica de ingeniería continua (no como documentación posterior al proyecto); **(2) Asociación con IA** (AI Partnership) con una distinción clara entre aumentar y reemplazar. **Diagnóstico del mercado**: *"una taxonomía estructuralmente inválida no es una taxonomía"*, *"las listas no son infraestructura de conocimiento"*, taxonomías generadas por IA vendidas como estrategia, proveedores que hacen un uso indebido del término *"ontología"*, soluciones genéricas (cookie-cutter) presentadas como metodología. **Crisis educativa**: la demanda de ingenieros semánticos supera ampliamente la oferta de profesionales formados; la brecha la llenan personas *"que conocen el vocabulario sin la metodología"*. **Posición normativa explícita**: *"la IA que genera una taxonomía de forma masiva está produciendo un pasivo disfrazado de activo; la IA que asiste a ingenieros formados es simplemente inteligente."* **Roles aceptables de la IA**: extracción de entidades, análisis de brechas, redacción de vocabularios candidatos para revisión, apoyo en la población/validación. **Roles inaceptables de la IA**: *generación masiva de taxonomías sin validación humana frente a estándares*. **Estándares referenciados**: SKOS, OWL, RDF, SPARQL. **Credibilidad**: framework validado en **6 instituciones a lo largo de 10 años**. **Recomendaciones para 3 audiencias**: (a) Organizaciones — invertir en formación formal, tratar la infraestructura de conocimiento como la columna vertebral de la IA, gobernanza continua, IA como acelerador y no como reemplazo; (b) Profesionales — preguntas de competencia antes del modelado, validar frente a SKOS/OWL/RDF, la dificultad de definición señala una pausa, el mantenimiento es continuo; (c) Líderes — actualización de competencias de la plantilla sin formación autofinanciada, asignar recursos a la infraestructura de conocimiento como necesidad estratégica, gobernanza antes del despliegue. **Citas destacadas**: *"el trabajo no se puede saltar"*, *"la gobernanza es la práctica de ingeniería que mantiene una ontología coherente a través del cambio"*, *"enseñar esto es difícil. Aprenderlo es más difícil."* **Relevancia importante** para líderes de datos / CDOs / arquitectos que construyen los fundamentos semánticos de sus agentes de IA. Para leer junto con: Seale Semantic Agent (2026-04-17) — *(Model+Harness)+(Ontology+Data) — la ontología como único moat*; Foundation Capital Context Graphs (2025-12-22); Bain parte 2/5 *rediseñar los fundamentos de datos para la preparación de agentes* (2026-05); DORA ROI 2026 *datos internos accesibles para IA + ecosistemas de datos saludables* (2026-04-21); doctrina de seis zonas de Habert PROJ-AI (2026-05-05). Convergencia con el corpus 2026 sobre *"los fundamentos de datos como moat"*.
#Jessica Talisman MLS#Ontology Pipeline framework#Modern Data 101
**Jessica Talisman MLS** — Semantic Engineer et Information Architect avec **25+ ans d'expérience** en enterprise architecture · e-commerce systems et knowledge management. Fondatrice de l'**Ontology Pipeline Framework** et de **Contextually LLC**. Roles précédents : **Adobe** (RDF-based knowledge graphs) · **Amazon** (information architecture). Auteure de la newsletter **Intentional Arrangement** (Substack) et d'un **livre éponyme à paraître en 2026**. Le framework initial *Ontology Pipeline* a été publié en janvier 2025 et **validé sur 6 institutions sur 10 ans**.
Agente semántico: la simetría entre modelo+harness y ontología+datos, el colapso de los frameworks de agentes, la ontología como el único activo no comoditizado
Acontext (memodb-io) - plataforma de datos de contexto de código abierto para agentes de IA cloud-native - context engineering, observabilidad, destilación de habilidades - GitHub
#agentes de IA#plataforma de datos de contexto#cloud-native
Construyendo GenBI en una Empresa Fortune 100 Reacia al Riesgo (Northwestern Mutual): Apuestas Pequeñas, Implementación Incremental, Agentes Especializados y Democratización de Datos
Evolución de RAG a Agent Memory - Operaciones de lectura-escritura - Gestión de datos en inferencia - Vector Databases - Memoria persistente para agentes de IA - Leonie Monigatti
Deep Research - Revolución AI4* - 6 pilares de la producción de software - Transición de Copilots a Agentes - Paradoja Vibe vs Check - Crisis de FinOps for AI - Gobernanza como ruta crítica - GenAI Landing Zone
Rippletide - Fiabilidad de agentes de IA empresariales - Brecha de despliegue 64% vs 17% - Falta gobernanza de decisiones en los hyperscalers - Hypergraph Database - <1% de alucinación - Cumplimiento por diseño - Gartner 40% de proyectos cancelados en 2027
#fiabilidad de agentes#IA empresarial#gobernanza de decisiones
Charla detallada de conferencia sobre MCP-UI, arquitectura de islands, remote DOM, theming, estado distribuido, autenticación, clientes nativos - Monday.com
#MCP-UI#islands architecture#remote DOM
Liad Yosef (AI & MCP Lead - Monday.com, co-modérateur UI work group)
Block/Goose — MCP-UI and the Future of Agentic Interfaces: componentes web interactivos en conversaciones de agentes de IA mediante Model Context Protocol (block.github.io)
Arquitectura de datos unificada en Netflix, grafo de conocimiento RDF/SHACL, modelado de dominio, metamodelo Upper, mapeos semánticos, proyecciones automáticas GraphQL/Avro/Iceberg - Netflix Technology Blog
#UDA#Unified Data Architecture#grafo de conocimiento
Alex Hutter · Alexandre Bertails · Claire Wang · Haoyuan He · Kishore Banala · Peter Royal · Shervin Afshar (Netflix Technology Blog)
Keynote de **Gregor Hohpe** (Enterprise Strategist en AWS, autor de *The Software Architect Elevator* y del próximo libro *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) en **PlatformCon 2022** sobre **la magia de las plataformas** — por qué las plataformas triunfan, qué las distingue de la mera *IT Service Management*, y **las decisiones de arquitectura no triviales** que hay que tomar al construir una. **Tesis pivote**: *"los estándares no reducen la creatividad, pueden multiplicarla"* — análoga al incendio de Baltimore de 1904 (bombas incompatibles), el tornillo métrico ISO, HTTP, el papel A4. **Cita canónica tomada de Peter / Thoughtworks**: ***"las plataformas centralizan la experiencia pero no la innovación"*** — la rueda no se reinventa, pero la innovación queda en manos de los equipos más cercanos al cliente. **Analogía pivote**: la industria automotriz (Volkswagen Group construye el Audi A4 y el Bentley Bentayga sobre la misma plataforma), *"undifferentiated heavy lifting"* (vocabulario de AWS) bajo el capó, diferenciación visible del lado del cliente. **Tres propiedades de una verdadera plataforma**: (1) **baja fricción** — la adopción no puede forzarse, los equipos buscarán atajos; (2) **transparencia** (no una *caja negra*) — los usuarios deben poder diagnosticar si el fallo es suyo o de la plataforma; (3) **responsabilidad compartida** (referencia directa al *AWS Shared Responsibility Model*) — la plataforma no corrige una aplicación mal diseñada. **Antipatrón explícito**: *"una capa común puede ser muchas cosas — no es necesariamente una plataforma"*; el IT Service Management tradicional tiene la misma imagen (una capa común debajo de todos) pero la **interfaz es la opuesta** (alta fricción, formularios, cuello de botella). **Dos caminos de construcción**: (a) anticipar cada necesidad (Hohpe: *"no me siento lo bastante inteligente"*); (b) **evolución** a partir de piezas útiles, observando el uso. **Decisiones que hay que explicitar**: objetivos (carga cognitiva ↓, más seguro / menos errores, más rápido vía samples/blueprints/self-service, compliance), forma de la curva de aprendizaje (acantilado, palo de hockey, cambio de marcha). **Concepto canónico #1 — Floating platforms vs Sinking platforms**: cuando la *base platform* (típicamente la nube) gana nuevas capacidades, **dos estrategias opuestas**: **sinking platform** (estática, duplicando lo que la base ya ofrece, hundiéndose a medida que sube el nivel del agua) vs ***floating platform*** (descarta las piezas que se han vuelto redundantes, **se eleva por encima del nuevo nivel**, innova más arriba). Metáfora del *"submarino y el barco"*. Fuerte implicación contractual: **advertir explícitamente a los stakeholders** de que los componentes se eliminarán en cuanto la base los absorba. **Concepto canónico #2 — Fruit salad vs Fruit basket**: una plataforma no es una colección de capacidades yuxtapuestas (una cesta) sino un ensamblaje **proporcionado, en trozos pequeños** donde las piezas interactúan — *"el precio por kilo de la macedonia de frutas es más alto que el de la cesta de frutas"*. El título deriva de la frase *the magic of platforms* — el efecto contraintuitivo por el cual **estandarizar libera la innovación en lugar de ahogarla**, siempre que la interfaz, la evolución y la integración entre componentes se manejen con cuidado. Relevante para: arquitectos de plataformas, **equipos de Platform Engineering / IDP 2026** (una referencia fundacional, anterior al auge de las *Internal Developer Platforms* pero que estructura su vocabulario), CIOs que evalúan build-vs-stagnate frente a las capacidades nativas de la nube, comités ejecutivos de producto. Converge con **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — la plataforma como pilar sistémico).
#Plataformas de software#platform engineering#Internal Developer Platforms IDP
**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).