Vai al contenuto

root / tags / a2a

#A2A

5 fiches

Architettura e Costruzione Traduzione verificata automaticamente

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

Analisi di Janakiram MSV (The New Stack, 20 luglio 2026) sulla **convergenza architetturale** delle piattaforme agent enterprise dei tre hyperscaler: in nove mesi, **Amazon Bedrock AgentCore**, **Microsoft Foundry** e **Gemini Enterprise Agent Platform** sono convergenti sugli **stessi sei primitivi** — runtime, memoria, tool gateway, identità, osservabilità, governance — sotto nomi commerciali diversi. Ciò che 18 mesi fa era una collezione frammentata di librerie sta diventando un **livello di piattaforma** a sé stante. La tesi: questa convergenza ripercorre l'**inflessione PaaS 2011-2016**, in cui **Cloud Foundry** ed **Heroku** hanno unificato VM, load balancer, code e secret store attorno a un **contratto applicativo** portabile — salvo che qui **non esiste ancora un contratto equivalente**, e **nessun progetto open source lo ha rivendicato**. Conseguenza: un'impresa non può **spostare un agente da un cloud all'altro** (stato di sessione, tracce e identità finiscono tutti presso un unico fornitore; migrare significa ricostruire tutto). L'autore propone una **mappatura riga per riga** del contratto Cloud Foundry sugli agenti, definisce tre principi di design (impacchettare l'agente come **una singola unità distribuibile**, **collegare** le capacità invece di incorporare i fornitori, integrare il livello **operativo** nell'astrazione), indica ciò che i protocolli aperti (MCP, A2A, OpenTelemetry) lasciano fuori campo — il **ciclo di vita** — e formula tre domande di due diligence: **governance** (fondazione neutrale vs. fornitore), **packaging** (lo stesso artefatto su due cloud senza riscriverlo), **stato** (memoria esportabile). Verdetto: chi finirà per possedere il **control plane degli agenti** definirà *cos'è un agente*.

#Piattaforme agent enterprise#convergenza architetturale#portabilità

Janakiram MSV

Economia e Mercato Traduzione verificata automaticamente

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

**Rapporto ricorrente di Mozilla**, *The state of open source AI*, **v1.0.1, luglio 2026**, introdotto da una lettera di **Raffi Krikorian** (CTO): sette sezioni, un sito interattivo e un rapporto scaricabile. Tesi enunciata nel titolo della Sezione 1: *« Il livello del modello si è commoditizzato. Il valore si sposta sull'harness sovrastante. »* **Stato delle capacità**: sull'*Artificial Analysis Intelligence Index v4.1*, il miglior modello chiuso ottiene **61** punti (Claude Opus 5) e il miglior modello open **57** (**Kimi K3**), quarto in classifica generale e davanti a tre dei più grandi laboratori chiusi; sull'*Epoch Capabilities Index*, lo scarto è di **6 punti** (K3 a 156 contro GPT-5.6 Sol a 162), descritto come *« all'incirca un ciclo di release »*, con intervalli di confidenza sovrapposti. **Frontiera a dente di sega**: l'open è in testa nel codice frontend (K3 a 1.679 Elo sulla LMArena Frontend Code Arena, sei domini su sette), contende il lavoro agentico da terminale (88,3 contro 88,8 su Terminal-Bench 2.1), e cede terreno sul lavoro professionale di conoscenza (Fable 5 supera K3 di 92 Elo su GDPval-AA v2). **Spostamento d'uso**: la quota di token OpenRouter instradati verso modelli open-weight è salita da un livello trascurabile a un terzo entro fine 2025, poi a una **maggioranza entro metà 2026**, con i sette modelli a maggior volume tutti open-weight — il rapporto stesso osserva che *« in numero di richieste, i fornitori chiusi statunitensi restano in testa »*, il vantaggio open essendo un vantaggio in volume di token concentrato nei carichi di lavoro di coding e agentici. **Il contrasto centrale**: *« L'open si spedisce facilmente. L'open si distribuisce con difficoltà. »* — il 79% degli sviluppatori che adottano l'IA usa modelli open contro il 71% per il chiuso, ma solo il **53%** dei team su modello open raggiunge la produzione **contro il 63%**, e lo scarto si allarga con la dimensione dell'organizzazione (chiuso 54% → 73%, open 53% → 57%), il che *« esclude una spiegazione basata sulle risorse »*. La mappa di maturità dello stack (48 componenti, 9 livelli) mostra due colonne costantemente fredde — la **standardizzazione** e la ***prontezza enterprise*** — identificate come il divario operativo. **Sezione 5**: *« L'harness agentico è un altro user agent »*, e *« Il modello sta divorando l'harness »* — su ogni modello in cui entrambi esistono, l'harness proprietario del laboratorio ora vince, con lo scarto di 21,8 punti compresso a circa 3. Da cui la formula: *« Un harness calibrato strettamente sui pesi di un laboratorio… degrada su qualsiasi altro modello, quindi più stretta è la calibrazione, meno intercambiabili sono i pesi sottostanti. Il lock-in arriva come effetto collaterale dell'ottimizzazione. »*

#Mozilla#state of open source AI#pesi open

**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).

Agenti di codifica IA e Skills Traduzione verificata automaticamente

The New SDLC With Vibe Coding — From ad-hoc prompting to Agentic Engineering

Whitepaper Google (primo capitolo, il "Day 1", di una serie firmata da Addy Osmani, Shubham Saboo e Sokratis Kartakis) che mappa la trasformazione del ciclo di vita dello sviluppo software (SDLC) nell'era degli agenti di coding. Tesi: il cambiamento fondamentale non è un nuovo linguaggio, bensì il passaggio dalla scrittura di codice all'**espressione dell'intento**. Il documento delinea uno spettro che va dal *vibe coding* (prompting e accettazione) all'*agentic engineering* (l'IA implementa sotto vincoli, test e cicli di feedback progettati da esseri umani), con il **context engineering** come competenza centrale, il modello della **software factory** (il deliverable dello sviluppatore = il sistema che produce il codice), l'**harness engineering** (Agent = Model + Harness) e un'analisi economica CapEx/OpEx del costo totale di possesso.

#new SDLC#vibe coding#agentic engineering

Addy Osmani · Shubham Saboo · Sokratis Kartakis (Google)