Saltar al contenido

root / tags / agentic-ai-foundation

#Agentic AI Foundation

5 fiches

Herramientas y Plataformas Traducción verificada automáticamente

Designing AI with character: what we learned building Berd

Entrada de blog corporativo de **Block** (`block.xyz/inside`), sin firma —el autor mostrado es **«Block»**—, publicada el **18 de agosto de 2026**, ~930 palabras, que anuncia **la apertura del código de Berd**, la aplicación de escritorio interna de Block para trabajar con agentes, y expone la tesis de diseño que la guió: dar carácter a los agentes *«no solo mediante roles, instrucciones, skills y herramientas, sino mediante identidades visuales distintivas»* —de ahí los personajes animados desarrollados internamente, los *«Gloopies»*—. La entrada parte de una constatación de fragmentación (*«The technology was powerful, but the experience around it was fragmented»*) y de un problema de interfaz precisamente nombrado: *«the product gives people little sense of how the agent is configured, which context and tools are available to it, and how it differs from another agent»*. Dos aportaciones estructurantes. **(A) Una articulación en tres niveles**: **goose** sigue siendo el framework y el *runtime* que sostiene el bucle del agente; **Berd** es el cliente de escritorio (proyectos, contexto, sesiones, agentes, configuración); ambos se comunican mediante el **Agent Client Protocol**. **Buzz** se designa como la continuación, para cuando el trabajo en solitario se vuelve colaborativo (*«Start alone, then go multiplayer»*). **(B) Seis requisitos transmitidos a Buzz**, enunciados como conclusión: *«private space, durable context, recognizable agent identities, reusable skills, visible configuration, and clearer visibility into an agent's configured context, tools, and capabilities»* —una parrilla directamente reutilizable para evaluar un cliente de agentes—. El propio texto distingue identidad de capacidad: *«The avatars make the agent recognizable. Its role, skills, and tools make it useful.»* No se aportan cifras de uso ni se nombra ninguna licencia para la apertura del código.

#Berd#Block#código abierto

**Aucun auteur nommé** : le billet est signé **« Block »** — le champ *Author* de la page porte le nom de l'entreprise. Publié le **18 août 2026** sur `block.xyz/inside` · le blog **corporate** · et non sur `engineering.block.xyz`.

Arquitectura y Construcción Traducción verificada automáticamente

Buzz (buzz.xyz) — Rapport de recherche pour présentation

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/`.

Arquitectura y Construcción Traducción verificada automáticamente

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

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

Janakiram MSV

Economía y Mercado Traducción verificada automáticamente

The state of open source AI (v1.0.1, juillet 2026)

**Informe periódico de Mozilla**, *The state of open source AI*, **v1.0.1, julio de 2026**, presentado mediante una carta de **Raffi Krikorian** (CTO): siete secciones, un sitio interactivo y un informe descargable. Tesis enunciada en el título de la Sección 1: *« La capa del modelo se ha convertido en una commodity. El valor se acumula en el harness que se sitúa por encima. »* **Estado de las capacidades**: en el *Artificial Analysis Intelligence Index v4.1*, el mejor modelo cerrado obtiene **61** puntos (Claude Opus 5) y el mejor modelo abierto **57** (**Kimi K3**), cuarto en el ranking general y por delante de tres de los mayores laboratorios cerrados; en el *Epoch Capabilities Index*, la brecha es de **6 puntos** (K3 en 156 frente a GPT-5.6 Sol en 162), descrita como *« más o menos un ciclo de lanzamiento »*, con intervalos de confianza que se solapan. **Frontera en diente de sierra**: el open lidera en código frontend (K3 con 1.679 Elo en LMArena Frontend Code Arena, seis dominios de siete), disputa el trabajo agéntico en terminal (88,3 frente a 88,8 en Terminal-Bench 2.1) y cede terreno en trabajo profesional de conocimiento (Fable 5 supera a K3 por 92 Elo en GDPval-AA v2). **Cambio de uso**: la cuota de tokens de OpenRouter dirigida a modelos de pesos abiertos pasó de un nivel insignificante a un tercio a finales de 2025, y luego a una **mayoría a mediados de 2026**, con los siete modelos de mayor volumen todos de pesos abiertos —el propio informe señala que *« por número de solicitudes, los proveedores cerrados estadounidenses siguen liderando »*, siendo el liderazgo del open un liderazgo en volumen de tokens concentrado en cargas de trabajo de código y agénticas. **El contraste central**: *« El open es fácil de lanzar. El open es difícil de desplegar. »* —el 79% de los desarrolladores que añaden IA usan modelos abiertos frente al 71% para los cerrados, pero solo el **53%** de los equipos que usan modelos abiertos llega a producción **frente al 63%**, y la brecha se amplía con el tamaño de la organización (cerrado 54% → 73%, abierto 53% → 57%), lo que *« descarta una explicación por recursos »*. El mapa de madurez del stack (48 componentes, 9 capas) muestra dos columnas sistemáticamente frías —**estandarización** y ***preparación empresarial***— identificadas como la brecha operativa. **Sección 5**: *« El harness agéntico es otro agente de usuario »*, y *« El modelo se está comiendo al harness »* —en todos los modelos donde ambos coexisten, el harness propio del laboratorio gana ahora, y la brecha de 21,8 puntos se ha comprimido a unos 3. De ahí la fórmula: *« Un harness ajustado con precisión a los pesos de un laboratorio… se degrada con el modelo de cualquier otro, así que cuanto más ajustado está, menos intercambiables son los pesos que hay debajo. El lock-in llega como efecto secundario de la optimización. »*

#Mozilla#state of open source AI#pesos abiertos

**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).