DEV Community: Andrea Schiona

I modelli AI del 2026: Fable 5.1, Astra e la sfida cinese

Andrea Schiona — Sun, 06 Sep 2026 12:21:27 +0000

Abstract

Tra agosto e settembre 2026, Anthropic, OpenAI e i principali laboratori AI cinesi hanno rilasciato una serie di modelli che stanno ridefinendo le aspettative su costo, capacità e apertura. Questo articolo riporta i fatti accertati: cosa è uscito, cosa dicono i benchmark, come si confrontano i modelli tra loro, e perché la distanza dall'AGI rimane sostanzialmente invariata nonostante il marketing.

1. Cosa è uscito di recente

Anthropic: Claude Fable 5.1 e Mythos 5.1

Data di rilascio: 1 settembre 2026

Anthropic ha lanciato due varianti dello stesso modello con livelli di safeguard diversi:

Claude Fable 5.1: disponibilità generale tramite Claude API, AWS Bedrock, Google Cloud e Microsoft Foundry.
Claude Mythos 5.1: accesso ristretto a organizzazioni statunitensi certificate nel settore cybersecurity e life sciences.

Specifiche principali:

Finestra di contesto da 1 milione di token, output massimo 128.000 token
Adaptive thinking sempre attivo
Knowledge cutoff: giugno 2026
Disponibilità garantita fino ad almeno il 1° settembre 2027

Prezzi:

Input: $10 per milione di token
Output: $50 per milione di token
Cache reads: $0.25 per milione di token (riduzione del 75% rispetto a Fable 5)

Prestazioni rispetto a Fable 5:

Terminal-Bench-Science 0.1: 52,6% vs. 24,7%
Terminal-Bench 4.0: 55,8% vs. 42,0%
CursorBench 3.2.0: 73,4% vs. 70,5%
AutomationBench: 31,4% vs. 17,1%

Anthropic riporta che Fable 5.1 batte il proprio Opus 5 su ogni benchmark pubblicato, nonostante Opus 5 costi la metà per token. Il modello attiva anche il 60% in meno di interventi delle safeguard cyber e l'85% in meno per le safeguard sulla biologia rispetto a Fable 5. Enterprise Frontier Safeguards, che permettono ai clienti di conservare i dati sulla propria infrastruttura cloud, saranno disponibili a partire dall'autunno 2026.

OpenAI: GPT-6 Astra

Data di rilascio: 3 settembre 2026 (anteprima limitata)

OpenAI ha iniziato il rollout di GPT-6 Astra, definendolo un "salto generazionale". Il presidente Greg Brockman ha parlato di "ingresso nell'era AGI". Il modello è disponibile per utenti Pro, Enterprise e Business Premium.

Cosa lo distingue:

Primo modello OpenAI a raggiungere la soglia "Critical" per le capacità cybersecurity nel Preparedness Framework interno.
Utilizza una tecnica chiamata "recurrent depth", che alcuni esperti di sicurezza AI hanno segnalato come potenzialmente più difficile da controllare.
OpenAI ha pubblicato un avvertimento esplicito sulle capacità cyber avanzate prima del rilascio.
Più veloce e versatile delle versioni precedenti, secondo l'azienda.

OpenAI non ha ancora pubblicato benchmark dettagliati confrontabili con quelli di Anthropic. La copertura iniziale si concentra soprattutto sulle implicazioni di sicurezza più che sulle prestazioni quantitative.

I contendenti cinesi

Alibaba: Qwen3.8-Max e Qwen3.8-Flash

Qwen3.8-Max (3 agosto 2026):

2,4 trilioni di parametri totali, circa 95 miliardi attivi per query
Multimodale: input di testo, immagini e video
Finestra di contesto da 1 milione di token, prezzo flat
Prezzi API: $2 per milione di token in input, $6 per milione in output
Cache input: $0,25 per milione di token

I benchmark self-reported da Alibaba includono Terminal-Bench 2.1 a 86,6 e GPQA Diamond a 92,6. Il modello ha raggiunto il primo posto tra i modelli testuali cinesi su Arena.AI, ma rimane dietro a Claude Fable 5 e a diverse varianti Opus di Anthropic nella classifica globale. I pesi open sono stati promessi a breve.

Qwen3.8-Flash (26 agosto 2026):

125 miliardi di parametri totali, solo 6 miliardi attivi per token
Anteprima open-weight della prossima architettura Qwen4
Prezzi API: $0,15 per milione di token in input, $0,47 per milione in output
SWE-bench Pro: 62,5% contro il 55,4% di DeepSeek V4 Pro
Batte DeepSeek V4 Flash sulla maggior parte dei benchmark di coding e attività d'ufficio pubblicati da Alibaba

DeepSeek: V4-Flash

Data di rilascio: 31 luglio 2026

Modello open-weight mixture-of-experts
Prezzi API: $0,14 per milione di token in input, $0,28 per milione in output
Artificial Analysis Intelligence Index: circa 52-54
SWE benchmark: circa 80,6% al lancio
Prezzi di cache estremamente bassi

A metà agosto 2026 DeepSeek ha aumentato i prezzi di output di V4-Flash fino al 371% nelle ore di punta. Piattaforme terze hanno offerto hosting più economico, ma il modello rimane il leader di prezzo.

Zhipu: GLM-5.3-Flash

Data di rilascio: Fine agosto 2026

320 miliardi di parametri totali, 18 miliardi attivi (320B-A18B)
Open-weight
Finestra di contesto da 1 milione di token
Prezzi dichiarati a un decimo di GLM-5.3 e a un ventesimo di Claude Opus 4.8
Prestazioni di programmazione descritte come comparabili a Claude Opus 4.8 nel benchmark interno Z.ai Code Bench

2. Come stanno evolvendo

Il ritmo di rilascio accelera

I rilasci principali avvengono ogni 3-4 mesi, non annualmente. Fable 5 è uscito a giugno 2026; Fable 5.1 è arrivato il 1° settembre. DeepSeek V4 ad aprile; V4-Flash a fine luglio. Il settore è in una fase di iterazione rapida, non di stasi.

La vera competizione è l'efficienza, non solo la scala

I numeri di punta continuano a enfatizzare i parametri totali, ma la storia operativa è quella dei parametri attivi per token. Qwen3.8-Flash attiva solo 6 miliardi di parametri pur avendone 125 miliardi totali, e batte DeepSeek V4 Pro su SWE-bench Pro a un quarto del costo. DeepSeek V4-Flash fa lo stesso con i workload agentici a prezzi commodity. La tendenza è verso architetture più intelligenti, non semplicemente modelli più grandi.

La compressione dei prezzi è strutturale

Claude Fable 5 costava $10/$50 per milione di token. DeepSeek V4-Flash è entrato a $0,14/$0,28. Qwen3.8-Flash è ancora più economico. I laboratori cinesi usano strategie open-weight e prezzi aggressivi per guadagnare quote tra gli sviluppatori, mentre i laboratori occidentali mantengono i premium puntando su sicurezza, affidabilità ed ecosistema.

Open-weight è il default per gli sfidanti

Ogni rilascio cinese significativo è open-weight: DeepSeek V4, Qwen3.8-Flash-Next, GLM-5.3-Flash. I modelli frontier occidentali rimangono chiusi. Questo crea due mercati paralleli: modelli closed premium per use case regolamentati, e modelli open-weight per deployment con costi sensibili o self-hosted.

3. AGI: cos'è e quanto siamo vicini

AGI significa Artificial General Intelligence: un sistema capace di svolgere qualsiasi compito intellettuale umano—ragionare trasversalmente tra domini, trasferire l'apprendimento, impostare obiettivi propri e operare con vera autonomia. È diverso dai modelli attuali, che sono narrow AI: straordinariamente capaci in distribuzioni specifiche, ma dipendenti da prompt engineering, fine-tuning e supervisione umana per generalizzare.

Nonostante il linguaggio marketing di OpenAI su Astra—"benvenuti nell'era AGI"—non esiste consenso scientifico che l'AGI sia stata raggiunta. I modelli discussi qui sono impressionanti su benchmark, ma i benchmark misurano compiti specifici, non agenzia cognitiva generale. Un modello che punteggia alto su coding, matematica e domande a scelta multipla richiede ancora routing esplicito, layer di sicurezza e gate di approvazione umana per funzionare in workflow complessi.

Una lettura onesta è che siamo in una fase di compressione della frontier capability: il divario tra i migliori modelli chiusi e i migliori modelli open-weight si riduce su compiti specifici, e il costo di un'AI competente si avvicina a zero. Questo è uno spostamento strutturale nell'economia del deployment AI, non l'arrivo dell'intelligenza generale.

4. Confronto diretto

Dimensione	Claude Fable 5.1	GPT-6 Astra	Qwen3.8-Max	DeepSeek V4-Flash
Rilascio	1 set 2026	3 set 2026 (limitato)	3 ago 2026	31 lug 2026
Contesto	1M token	Non dichiarato	1M token flat	Contesto lungo
Output max	128K token	Non dichiarato	131.072 token	Non dichiarato
Input / 1M	$10,00	Non dichiarato	$2,00	$0,14
Output / 1M	$50,00	Probabilmente premium	$6,00	$0,28
Cache read / 1M	$0,25	Sconosciuto	$0,25	Molto basso
Pesi	Chiusi	Chiusi	Open-weight promessi	Open-weight
Multimodale	No	Sconosciuto	Sì (testo/immagini/video)	Principalmente testo
Coding benchmark	Terminal-Bench 4.0: 55,8%	Non pubblicato	Terminal-Bench 2.1: 86,6% (vendor)	SWE ~80,6% (vendor)
Postura sicurezza	Safeguard ridotte; variante Mythos ristretta	Soglia Critical; avvisi safety	Meno documentata nelle fonti esaminate	Meno documentata nelle fonti esaminate
Ideale per	Coding e knowledge work di lunga durata con safeguard forti	Task ad alto rischio che richiedono capability frontier; valutazioni safety-critical	Lavoro professionale multimodale e lungo contesto	Workload agentici e coding cost-sensitive

Nota importante:

I benchmark non sono direttamente confrontabili perché derivano da test diversi.
I punteggi di Qwen3.8-Max e DeepSeek V4-Flash sono vendor-reported o basati su index terzi; quelli di Fable 5.1 lo sono anch'essi, ma con note metodologiche più dettagliate.
Le prestazioni di Astra non sono ancora state pubblicate in dettaglio da fonti indipendenti.
Lo status open-weight dei modelli cinesi permette valutazioni indipendenti, ma il processo è ancora in corso.

5. Cosa cambia per sviluppatori e imprese

Ora hai scelte reali

Cinque anni fa il deployment AI serio significava OpenAI o niente. Oggi lo scenario include:

Modelli closed premium (Fable 5.1, probabilmente Astra) per i casi in cui sicurezza, affidabilità ed ecosistema maturo sono prioritari.
Sfidanti open-weight (DeepSeek V4-Flash, Qwen3.8-Flash, GLM-5.3-Flash) per workload cost-sensitive o self-hosted.
Architetture efficiency-first che attivano una frazione dei parametri per token, rendendo seria l'AI su hardware consumer.

Il costo non è più una scusa valida

A $0,14 per milione di token in input, DeepSeek V4-Flash rende economicamente viable cicli agentici, classificazione su scala e bozze iterative anche per team piccoli. Qwen3.8-Flash a $0,15/M porta prestazioni di coding vicine alla frontier a prezzi simili. Il vero costo non è più l'API: è il design dell'integrazione e la supervisione umana.

Open-weight cambia il modello di deployment

Quando i pesi sono scaricabili, le organizzazioni possono:

Fare fine-tuning per linguaggi specifici del dominio
Eseguire inference on-premise per la residenza dei dati
Quantizzare e servire il modello su GPU consumer
Evitare il lock-in dei contratti API

Il trade-off è che i modelli open-weight tipicamente offrono meno documentazione formale sulla sicurezza e meno garanzie di supporto enterprise rispetto ai modelli frontier chiusi.

La superficie di sicurezza si espande

La strategia a doppio rilascio di Fable 5.1 (pubblico vs. Mythos ristretto) segnala che i vendor trattano i modelli ad alta capacità come sostanze controllate. La classificazione "Critical" di Astra e gli avvisi pubblici di OpenAI rappresentano un nuovo livello di trasparenza—o almeno di comunicazione—sulla sicurezza. Per le imprese, documentazione di sicurezza, audit trail e impegni sul trattamento dei dati dovrebbero essere requisiti first-class, non dettagli secondari.

6. Conclusione: evoluzione esponenziale o rendimenti decrescenti?

Le evidenze supportano un progresso rapido e non lineare su assi specifici—costo, efficienza e apertura—ma non un progresso esponenziale verso l'AGI.

Costo: crollo esponenziale. Da $10/M input per Fable 5 a $0,14/M per DeepSeek V4-Flash in meno di quattro mesi.
Efficienza: miglioramento non lineare. 6 miliardi di parametri attivi che battono 49 miliardi attivi su benchmark di coding suggerisce che l'innovazione architetturale sta superando lo scaling brute-force.
Capacità: avanza, ma la frontier si consolida. Fable 5.1 rimane leader su più benchmark di coding, e nessun modello open-weight ha punteggi verificati indipendentemente che lo superino chiaramente su tutti i fronti.

La distanza dall'AGI rimane quella di prima: sconosciuta, e probabilmente misurata in anni, non in mesi. Ciò che è cambiato è che l'AI competente e narrow è ora una commodity. Il vantaggio competitivo si è spostato dall'accesso al modello all'orchestrazione, alla qualità dei dati, al design dei workflow e alle infrastrutture di fiducia.

Per gli sviluppatori, il messaggio è pratico: smettete di inseguire il modello "migliore" e iniziate a costruire sistemi multi-modello che instradano i compiti allo strumento giusto per il prezzo giusto. L'era del modello-unico-per-tutto sta finendo; l'era del modello-come-commodity è iniziata.

Fonti

Anthropic Fable 5.1 / Mythos 5.1:
OpenAI GPT-6 Astra:
Alibaba Qwen3.8:
DeepSeek V4-Flash:
- Yellow.com: https://yellow.com/phoenix.html/news/qwen-deepseek-push-chinese-ai-anthropic
- CNBC Chinese AI acceleration: https://www.cnbc.com/2026/01/28/chinese-tech-companies-accelerate-ai-model-rollouts-us-rivals-deepseek-moonshot-kimi.html
Zhipu GLM-5.3-Flash:
- 36Kr: https://eu.36kr.com/en/p/3956555141430402

Where We Are With AI Models in Late 2026: Fable 5.1, Astra, and the Chinese Challenge

Andrea Schiona — Sun, 06 Sep 2026 12:20:57 +0000

Abstract

Between August and September 2026, Anthropic, OpenAI, and major Chinese AI labs released a cluster of new models that reset expectations on cost, capability, and openness. This article surveys the factual landscape: what shipped, what the benchmarks say, how the models compare, and why the distance to AGI remains largely unchanged despite the marketing.

1. What Just Shipped

Anthropic: Claude Fable 5.1 and Mythos 5.1

Release date: September 1, 2026

Anthropic launched two variants of the same underlying model with different safeguard levels:

Claude Fable 5.1: general availability via Claude API, AWS Bedrock, Google Cloud, and Microsoft Foundry.
Claude Mythos 5.1: restricted to vetted U.S. organizations in cybersecurity and life-sciences research.

Key specs:

1-million-token context window, 128,000-token maximum output
Adaptive thinking always on
Knowledge cutoff: June 2026
Availability committed until at least September 1, 2027

Pricing:

Input: $10 per million tokens
Output: $50 per million tokens
Cache reads: $0.25 per million tokens (75% reduction from Fable 5)

Performance vs. Fable 5:

Terminal-Bench-Science 0.1: 52.6% vs. 24.7%
Terminal-Bench 4.0: 55.8% vs. 42.0%
CursorBench 3.2.0: 73.4% vs. 70.5%
AutomationBench: 31.4% vs. 17.1%

Anthropic reports Fable 5.1 beats its own Opus 5 on every published benchmark, despite Opus 5 costing half as much per token. The model also triggers cyber-safeguard interventions about 60% less often than Fable 5, and biology safeguards fire 85% less often on benign queries. Enterprise Frontier Safeguards, allowing customers to store data on their own cloud, roll out in phases from fall 2026.

OpenAI: GPT-6 Astra

Release date: September 3, 2026 (limited preview)

OpenAI began rolling out GPT-6 Astra, calling it a "generational leap." President Greg Brockman wrote that it marks entry into "the AGI era." The model is available to Pro, Enterprise, and Business Premium users.

What makes it different:

First OpenAI model to reach the "Critical" cybersecurity capability threshold under the company's Preparedness Framework.
Uses a technique called "recurrent depth," which AI safety experts have flagged as potentially making models harder to control.
OpenAI warned explicitly about Astra's advanced cyber capabilities before release.
Faster and more versatile than prior iterations, according to the company.

OpenAI has not published detailed benchmark tables comparable to Anthropic's. Much of the early coverage centers on the safety implications rather than quantitative performance comparisons.

The Chinese Contenders

Alibaba: Qwen3.8-Max and Qwen3.8-Flash

Qwen3.8-Max (August 3, 2026):

2.4 trillion total parameters, approximately 95 billion active per query
Multimodal: text, image, and video inputs
1-million-token context window, flat-rate pricing
API pricing: $2 per million input tokens, $6 per million output tokens
Cached input: $0.25 per million tokens

Alibaba's self-reported benchmarks include Terminal-Bench 2.1 at 86.6 and GPQA Diamond at 92.6. The model topped Chinese text-model rankings on Arena.AI but still trails Claude Fable 5 and several Anthropic Opus variants globally. Open weights were promised shortly after release.

Qwen3.8-Flash (August 26, 2026):

125 billion total parameters, only 6 billion active per token
Open-weight preview of the upcoming Qwen4 architecture
API pricing: $0.15 per million input tokens, $0.47 per million output tokens
SWE-bench Pro: 62.5% vs. DeepSeek V4 Pro's 55.4%
Beats DeepSeek V4 Flash on most coding and office-task benchmarks released by Alibaba

DeepSeek: V4-Flash

Release date: July 31, 2026

Open-weight mixture-of-experts model
API pricing: $0.14 per million input tokens, $0.28 per million output tokens (peak hours: 2x regular rate)
Artificial Analysis Intelligence Index: approximately 52-54
SWE benchmark reported around 80.6% at release
Extremely low cache-hit pricing

DeepSeek raised V4-Flash output prices by up to 371% during peak hours in mid-August 2026. Third-party platforms quickly offered cheaper hosting, but the model remains the price leader.

Zhipu: GLM-5.3-Flash

Release date: Late August 2026

320 billion total parameters, 18 billion active (320B-A18B)
Open-weight
1-million-token context window
Pricing claimed at one-tenth of GLM-5.3 and one-twentieth of Claude Opus 4.8
Programming performance described as comparable to Claude Opus 4.8 in Zhipu's internal Z.ai Code Bench

2. How Are They Evolving?

The cadence is accelerating

Major releases now arrive every 3-4 months, not annually. Fable 5 launched in June 2026; Fable 5.1 arrived September 1. DeepSeek V4 shipped in April 2026; V4-Flash followed in late July. The release cadence suggests the industry is in a rapid iteration phase rather than a breakthrough plateau.

The real competition is efficiency, not just scale

The headline numbers still emphasize parameter counts—2.4 trillion for Qwen3.8-Max, 320 billion for GLM-5.3-Flash—but the operational story is about active parameters per token. Qwen3.8-Flash activates only 6 billion parameters despite carrying 125 billion total, yet beats DeepSeek V4 Pro on SWE-bench Pro while costing roughly one-quarter as much. DeepSeek V4-Flash similarly delivers agentic performance at commodity prices. The trend is toward smarter routing and mixture-of-experts architectures, not simply bigger models.

Pricing compression is structural

Claude Fable 5 cost $10/$50 per million tokens. DeepSeek V4-Flash entered at $0.14/$0.28. Qwen3.8-Flash undercuts DeepSeek on list price. Chinese labs are using open-weight strategies and aggressive API pricing to gain developer traction, while Western frontier labs maintain premium pricing by emphasizing safety, reliability, and ecosystem integration.

Open-weight is becoming the default for challengers

Every major Chinese release is open-weight: DeepSeek V4, Qwen3.8-Flash-Next, GLM-5.3-Flash. Western frontier models remain closed. This creates a two-tier market: closed premium frontier models for regulated enterprise use, and open-weight challengers for cost-sensitive, customizable, or self-hosted deployments.

3. AGI: What It Is and How Close We Are

AGI stands for Artificial General Intelligence. It refers to a system that can perform any intellectual task a human can do—reason across domains, transfer learning from one field to another, set its own goals, and operate with genuine autonomy. It is distinct from current models, which are narrow AI: extraordinarily capable within specific distributions, but dependent on prompt engineering, fine-tuning, and human oversight to generalize.

Despite OpenAI's marketing language around Astra—"welcome to the AGI era"—there is no scientific consensus that AGI has been achieved. The models discussed here are impressive on benchmarks, but benchmarks measure specific tasks, not general cognitive agency. A model that scores well on coding, math, and multiple-choice questions still requires explicit routing, safety layers, and human approval gates to operate in complex real-world workflows.

A more honest framing is that we are in a period of frontier capability compression: the gap between the best closed models and the best open-weight models is narrowing on specific tasks, and the cost of competent AI is falling toward zero. That is a structural shift in the economics of AI deployment, not an arrival at general intelligence.

4. Head-to-Head Comparison

The table below compares the models on dimensions where factual data exists. Vendor-reported benchmarks are labeled accordingly.

Dimension	Claude Fable 5.1	GPT-6 Astra	Qwen3.8-Max	DeepSeek V4-Flash
Release	Sep 1, 2026	Sep 3, 2026 (limited)	Aug 3, 2026	Jul 31, 2026
Context	1M tokens	Not disclosed	1M tokens flat	Long context
Max output	128K tokens	Not disclosed	131,072 tokens	Not disclosed
Input price / 1M	$10.00	Not disclosed	$2.00	$0.14
Output price / 1M	$50.00	Likely premium tier	$6.00	$0.28
Cache read / 1M	$0.25	Unknown	$0.25	Very low
Weights	Closed	Closed	Open-weight promised	Open-weight
Multimodal	No	Unknown	Yes (text/image/video)	Primarily text
Coding benchmark	Terminal-Bench 4.0: 55.8%	Not published	Terminal-Bench 2.1: 86.6% (vendor)	SWE ~80.6% (vendor)
Safety posture	Reduced interventions; restricted Mythos variant	Critical cybersecurity threshold; safety warnings	Less documented in reviewed sources	Less documented in reviewed sources
Best for	Long-running coding and knowledge work with strong safeguards	High-stakes tasks requiring frontier capability; safety-critical evaluation	Multimodal and long-context professional work	Cost-sensitive agentic and coding workloads

Important caveats:

Benchmarks are not directly comparable across different tests.
Qwen3.8-Max and DeepSeek V4-Flash scores are vendor-reported or based on third-party indexes; Fable 5.1's are also vendor-reported but accompanied by more detailed methodology notes.
Astra's performance profile is not yet publicly benchmarked in detail.
The Chinese models' open-weight status means independent evaluation is possible but still catching up.

5. What This Means for Developers and Enterprises

You now have real choices

Five years ago, serious AI deployment meant OpenAI or nothing. Today, the landscape includes:

Premium closed models (Fable 5.1, likely Astra) for tasks where safety, reliability, and ecosystem maturity matter most.
Open-weight challengers (DeepSeek V4-Flash, Qwen3.8-Flash, GLM-5.3-Flash) for cost-sensitive, high-volume, or self-hosted workloads.
Efficiency-first architectures that activate a fraction of their parameters per token, making serious AI viable on consumer hardware.

Cost is no longer a valid excuse for not building

At $0.14 per million input tokens, DeepSeek V4-Flash makes agentic loops, classification at scale, and iterative drafting economically viable for small teams. Qwen3.8-Flash at $0.15/M input delivers frontier-adjacent coding performance at similar prices. The barrier to entry is no longer API cost; it is integration design and human oversight.

Open-weight changes the deployment model

When weights are downloadable, organizations can:

Fine-tune for domain-specific language
Run inference on-premise for data residency
Quantize and serve on consumer GPUs
Avoid vendor lock-in on API contracts

The trade-off is that open-weight models typically carry less formal safety documentation and fewer enterprise support guarantees than closed frontier models.

The safety surface is expanding

Fable 5.1's dual-release strategy (public vs. restricted Mythos) signals that vendors are treating high-capability models as controlled substances. Astra's "Critical" cybersecurity classification and OpenAI's public warnings mark a new level of safety transparency—or at least safety marketing. Enterprise buyers should treat safety documentation, audit trails, and data-handling commitments as first-class requirements, not afterthoughts.

6. Conclusion: Exponential Evolution or Diminishing Returns?

The evidence supports rapid, non-linear progress on specific axes—cost, efficiency, and open availability—but not exponential progress toward AGI.

Cost is collapsing exponentially: from $10/M input for Fable 5 to $0.14/M for DeepSeek V4-Flash in under four months.
Efficiency is improving non-linearly: 6 billion active parameters beating 49 billion active parameters on coding benchmarks suggests architectural innovation is outpacing brute scaling.
Capability is advancing, but the frontier is consolidating: Fable 5.1 still leads on multiple coding benchmarks, and no open-weight model has independently verified scores that clearly surpass it across the board.

The distance to AGI remains the same as it was before these releases: unknown, and likely measured in years rather than months. What has changed is that competent, narrow AI is now a commodity. The competitive advantage has shifted from model access to orchestration, data quality, workflow design, and trust infrastructure.

For developers, the message is practical: stop chasing the "best" model and start building multi-model systems that route tasks to the right tool for the right price. The era of one-model-fits-all is ending, and the era of model-as-commodity has begun.

Sources

Anthropic Fable 5.1 / Mythos 5.1 launch coverage:
OpenAI GPT-6 Astra:
Alibaba Qwen3.8:
DeepSeek V4-Flash:
- Yellow.com: https://yellow.com/phoenix.html/news/qwen-deepseek-push-chinese-ai-anthropic
- CNBC Chinese AI acceleration: https://www.cnbc.com/2026/01/28/chinese-tech-companies-accelerate-ai-model-rollouts-us-rivals-deepseek-moonshot-kimi.html
Zhipu GLM-5.3-Flash:
- 36Kr: https://eu.36kr.com/en/p/3956555141430402

Come creare un'organizzazione IT agentica usando IT4IT come architettura di controllo

Andrea Schiona — Mon, 31 Aug 2026 13:16:39 +0000

1. Perché adesso

Negli ultimi 18 mesi l'orchestrazione di agenti AI è uscita dai paper ed è arrivata nei tool: LangGraph, CrewAI, watsonx Orchestrate, Microsoft Agent Framework, ServiceNow e Automation Anywhere hanno tutti introdotto concetti di agentic AI per ITSM e operations.

Ma c'è un buco: nessuno di questi modelli spiega dove l'agente deve agire all'interno del ciclo di vita del servizio IT, chi lo autorizza, e come si misura il risultato in termini di business.

Qui entra IT4IT. Non come processo da seguire, ma come architettura di riferimento che definisce i confini, i dati e i flussi valore entro cui gli agenti possono operare.

2. IT4IT non è un processo, è una spina dorsale architetturale

L'IT4IT Reference Architecture (The Open Group, v3.0.1) definisce quattro flussi valore end-to-end:

Strategy to Portfolio (S2P)
Requirement to Deploy (R2D)
Request to Fulfill (R2F)
Detect to Correct (D2C)

Ogni flusso è definito da:

Functional Components (cosa succede)
Key Data Objects (cosa si muove)
Service Model (come si evolve il servizio)

Questa struttura è indipendente da vendor, metodologia e strumenti. È quindi il dominio di verità su cui mappare qualunque implementazione agentica, invece di lasciare che ogni tool decida da sé cosa significa “sviluppo” o “produzione”.

3. Mappare i 4 flussi valore su agenti specializzati

L'approccio consiste nel sostituire o affiancare esecutori umani con agenti purposed, mantenendo invariata l'architettura IT4IT. Ogni agente è vincolato a:

un flusso valore (valueStream)
una sezione IT4IT (it4itSections)
un set di grant di strumento definiti
un livello di autonomia HITL (Human-In-The-Loop) a tier

Esempio pratico per Requirement to Deploy:

Functional Component IT4IT	Agente specializzato	Autonomia	Controllo umano
Requirement	Analista requisiti agentico	HITL 2 (review)	Architetto approva backlog
Plan & design	Agente pianificazione	HITL 1 (approve)	PM approva milestone
Develop	Agente sviluppatore (coding)	HITL 3 (autonomo)	Code review obbligatoria post
Test	Agente QA automatico	HITL 3	Solo escalation su fallimenti anomali
Deploy	Agente release	HITL 1	Change approval board

Lo stesso schema vale per gli altri flussi:

S2P: agenti di portfolio, demand, prioritizzazione
R2F: agenti di catalog, provisioning, chargeback
D2C: agenti di monitoraggio, root-cause, remediation

4. Gerarchia, identità e controlli umani

Per evitare il caos di “N agenti che fanno quello che vogliono”, il modello operativo richiede tre strati:

4.1 Gerarchia a 3 livelli

Orchestratori — ricevono l'obiettivo, lo scompongono, assegnano ai specialisti
Specialisti — eseguono compiti verticali (es. gap-analysis, security audit, investimento)
Esecutori — interagiscono con tool e dati, sotto grant ristretti

Questa struttura riduce la complessità: l'orchestratore gestisce il flusso, lo specialista gestisce il dominio, l'esecutore gestisce l'azione.

4.2 Identità e tracciabilità

Ogni agente ha un'identità durevole (es. gaid:priv:dpf.internal:coo-orchestrator) e un profondo di esecuzione che registra:

quale grant ha usato
quale prompt/versione
quale outcome
chi ha supervisionato

Questo serve per audit, debug e compliance.

4.3 Governance a tier HITL

Non “umano nel loop” come slogan, ma come parametro configurabile per ruolo e rischio:

Tier 0: solo umano
Tier 1: agente propone, umano approva
Tier 2: agente esegue, umano review post
Tier 3: agente autonomo, con escalation automatica su soglie

I tier non sono uguali per tutti: un agente che modifica regole firewall ha Tier 1, un agente che formatta report ha Tier 3.

5. Pro e contro — realistici

Pro

Allineamento strutturale: IT4IT già definisce i confini dei flussi; gli agenti non “inventano” il proprio ruolo, lo ereditano dall'architettura.
Misurabilità: perché ogni agente opera su Key Data Objects IT4IT, i risultati sono tracciabili come dati, non come chat.
Interoperabilità: se tutti gli agenti parlano la stessa lingua di dati (service release, requirement, incident), i tool non sono più silos.
Gradualità: si può iniziare da un solo flusso valore (es. Detect to Correct) senza rifare tutta l'organizzazione.
Governance by design: identità, grant e HITL tier sono parte del modello, non patch successive.

Contro

Costo di mappatura: ogni Functional Component IT4IT deve essere formalizzato in prompt, grant e metriche. Non è banale.
Rischio di sovraccarico di orchestrazione: a 46 agenti specializzati (come nel modello DPF) serve un controller solido, altrimenti si aggiunge complessità invece di rimuoverla.
Lock-in semantico: se IT4IT guida tutto, cambiare framework futuro è più costoso che con tool generici.
Sicurezza dei grant: un errore nei permessi di un agente in Tier 3 può propagarsi senza controllo. Richiede policy di default-deny strette.
Maturità delle organizzazioni: funziona solo se l'azienda ha già chiari strategia, portfolio e data model. In caos organizzativo, aggiungere agenti amplifica il rumore.

6. Casi concreti e riferimenti verificabili

The Open Group IT4IT Standard v3.0.1 — definisce l'architettura di riferimento e le relazioni tra i 4 flussi valore.
ServiceNow IT4IT v3 Blueprint — mappa funzionalmente IT4IT su strumenti DevOps/ITSM reali; conferma che il framework è implementabile.
Rabobank / Shell / Delta Lloyd — casi studio ufficiali The Open Group che usano IT4IT per semplificare toolchain, ridurre vendor e migliorare time-to-market. Il salto logico è sostituire parte dei processi manuali con agenti governati.
OpenDigitalProductFactory — l'unico progetto open source che mappa esplicitamente agenti su valueStream e it4itSections, dimostrando che l'accoppiamento è fattibile tecnicamente.
Microsoft — Agentic DevOps — mostra come ogni fase del ciclo di sviluppo possa essere assistita o governata da agenti, confermando la fattibilità del modello R2D agentico.
Deloitte — AI Agent Orchestration — evidenzia che la chiave del successo enterprise non è l'agente singolo, ma l'orchestrazione e la governance, esattamente quello che IT4IT fornisce.

7. Come iniziare senza bruciare l'organizzazione

Mappa prima gli strumenti, non gli agenti

Usa IT4IT per catalogare i tool esistenti nei 4 flussi valore. Trova i colli di bottiglia, i silos e le duplicazioni.
Scegli un solo flusso valore come pilota

Detect to Correct è il più comune: monitoraggio, incident, problem. Ha outcome misurabili (MTTR, number of incidents) e rischi contenuti.
Definisci 2-3 agenti specialisti, non 20

Esempio: agente di classificazione incident, agente di runbook automation, agente di root-cause suggester. Tier HITL 1-2.
Ferma l'identità e i grant prima dei prompt

Un agente senza identità verificabile e senza grant espliciti è un rumor nel sistema.
Misura come IT4IT misura

Usa i Key Data Objects del framework: service release lead time, requirement churn, fulfillment automation rate, detection-to-correction time.
Pubblica una “Decision Perspective Gate”

Anche semplice: ogni azione borderline dell'agente deve mostrare perché la prende, su quale criterio IT4IT, e con quale livello di confidenza.

8. Sintesi per il board

L'IT agentica non è un progetto di AI generica. È un progetto di architettura di governance in cui gli agenti sono gli esecutori, e IT4IT è il modello di what-to-build/when-to-act.

I benefici sono reali: trasparenza, velocità, riduzione del toil, tracciabilità. I rischi sono anch'essi reali: complessità di orchestrazione, lock-in semantico, necessità di una governance stretta.

L'approccio più sicuro non è “agenti ovunque”, ma un flusso valore alla volta, con confini IT4IT chiari e HITL non negoziabile.

Fonti

The Open Group — IT4IT Standard, Version 3.0.1 — https://publications.opengroup.org/c24a
The Open Group — About IT4IT — https://www.opengroup.org/about-it4it%E2%84%A2
The Open Group Blog — The IT4IT Reference Architecture is a Digital Product Blueprint (2022) — https://blog.opengroup.org/2022/05/24/the-it4it-reference-architecture-is-a-digital-product-blueprint-for-cost-savings-and-automation/
The Open Group Blog — Who’s Using the IT4IT Standard: Banking/Insurance (2019) — https://blog.opengroup.org/2019/09/19/the-interesting-case-of-whos-using-the-it4it-standard-part-one-the-banking-and-insurance-sectors
ServiceNow — IT4IT v3 Blueprint: Utah Version — https://www.servicenow.com/community/architect-articles/servicenow-it4it-v3-blueprint-utah-version/ta-p/2619269
Tambo, T. et al. — Digital services governance: IT4IT for management of technology — Journal of Science and Technology Policy Management, 2019 — https://www.sciencedirect.com/science/article/pii/S1741038X19000518
IAMOT 2017 — IT4IT as a Management of Technology Framework — https://pure.au.dk/ws/files/112882194/IAMOT_2017_IT4IT_AS_A_MANAGEMENT_OF_TECHNOLOGY_FRAMEWORK_proc.pdf
OpenDigitalProductFactory — AI Agent Meta Model — https://github.com/OpenDigitalProductFactory/opendigitalproductfactory/blob/main/docs/architecture/ai-agent-meta-model.md
OpenDigitalProductFactory — Gap Analysis Agent Prompt — https://github.com/OpenDigitalProductFactory/opendigitalproductfactory/blob/main/docs/superpowers/specs/2026-03-30-ai-coworker-skills-marketplace.md
Microsoft — Agentic DevOps in action — https://developer.microsoft.com/blog/reimagining-every-phase-of-the-developer-lifecycle/
D2i Technology — Complete Agentic SDLC Guide — https://d2itechnology.com/blogs/complete-asdlc-guide-requirements-to-deployment/
Deloitte — AI Agent Orchestration (2026 TMT Predictions) — https://www.deloitte.com/us/en/insights/industry/technology/technology-media-and-telecom-predictions/2026/ai-agent-orchestration.html
Deloitte — Agentic AI Orchestration, Governance, and Best Practices — https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/articles/agentic-ai-orchestration-governance.html

How to Build an Agentic IT Organization Using IT4IT as the Control Architecture

Andrea Schiona — Mon, 31 Aug 2026 13:16:38 +0000

1. Why now

In the last 18 months, AI agent orchestration moved from papers into production tooling: LangGraph, CrewAI, watsonx Orchestrate, Microsoft Agent Framework, ServiceNow, and Automation Anywhere all introduced agentic AI concepts for ITSM and operations.

But there is a gap: none of these models explain where an agent must act inside the IT service lifecycle, who authorizes it, and how the outcome is measured in business terms.

This is where IT4IT comes in. Not as a process to follow, but as a reference architecture that defines the boundaries, data, and value flows within which agents can operate.

2. IT4IT is not a process — it is an architectural backbone

The IT4IT Reference Architecture (The Open Group, v3.0.1) defines four end-to-end value streams:

Strategy to Portfolio (S2P)
Requirement to Deploy (R2D)
Request to Fulfill (R2F)
Detect to Correct (D2C)

Each value stream is defined by:

Functional Components (what happens)
Key Data Objects (what moves)
Service Model (how the service evolves)

This structure is vendor-independent, methodology-agnostic, and tool-agnostic. It is therefore the single source of truth for mapping any agentic implementation, instead of letting each tool decide what “development” or “production” means.

3. Map the 4 value streams to specialized agents

The approach is to replace or augment human executors with purposed agents, keeping the IT4IT architecture unchanged. Each agent is constrained to:

a value stream (valueStream)
an IT4IT section (it4itSections)
an explicit tool grant set
a HITL (Human-In-The-Loop) tier level

Practical example for Requirement to Deploy:

IT4IT Functional Component	Specialized Agent	Autonomy	Human Control
Requirement	Agentic requirements analyst	HITL 2 (review)	Architect approves backlog
Plan & design	Planning agent	HITL 1 (approve)	PM approves milestones
Develop	Coding agent	HITL 3 (autonomous)	Mandatory post code review
Test	QA automation agent	HITL 3	Escalation only on anomalous failures
Deploy	Release agent	HITL 1	Change approval board

The same pattern applies to the other streams:

S2P: portfolio, demand, prioritization agents
R2F: catalog, provisioning, chargeback agents
D2C: monitoring, root-cause, remediation agents

4. Hierarchy, identity, and human controls

To avoid the chaos of “N agents doing whatever they want,” the operating model requires three layers:

4.1 Three-level hierarchy

Orchestrators — receive objectives, decompose, assign to specialists
Specialists — execute vertical tasks (gap analysis, security audit, investment scoring)
Executors — interact with tools and data, under restricted grants

This structure reduces complexity: the orchestrator manages the flow, the specialist manages the domain, the executor manages the action.

4.2 Identity and traceability

Every agent has a durable identity (e.g. gaid:priv:dpf.internal:coo-orchestrator) and an execution ledger that records:

which grant was used
which prompt/version
which outcome
who supervised

This enables audit, debugging, and compliance.

4.3 Tiered HITL governance

Not “human-in-the-loop” as a slogan, but as a configurable parameter by role and risk:

Tier 0: human only
Tier 1: agent proposes, human approves
Tier 2: agent executes, human reviews post
Tier 3: agent autonomous, with automatic escalation on thresholds

Tiers are not uniform: an agent modifying firewall rules has Tier 1; an agent formatting reports has Tier 3.

5. Pros and cons — realistic

Pros

Structural alignment: IT4IT already defines flow boundaries; agents do not “invent” their role, they inherit it from the architecture.
Measurability: because every agent operates on IT4IT Key Data Objects, results are trackable as data, not chat.
Interoperability: if all agents speak the same data language (service release, requirement, incident), tools are no longer silos.
Gradual adoption: start with one value stream (e.g. Detect to Correct) without rebuilding the whole organization.
Governance by design: identity, grants, and HITL tiers are part of the model, not afterthought patches.

Cons

Mapping cost: every IT4IT Functional Component must be formalized into prompts, grants, and metrics. Not trivial.
Orchestration overhead: with 46 specialized agents (per models like DPF), you need a solid controller, or you add complexity instead of removing it.
Semantic lock-in: if IT4IT governs everything, switching to a future framework is more expensive than with generic tools.
Grant security: a misconfigured Tier 3 agent can propagate unchecked. Requires strict default-deny policies.
Organizational maturity: works only if the company already has clear strategy, portfolio, and data models. In organizational chaos, adding agents amplifies noise.

6. Concrete references

The Open Group IT4IT Standard v3.0.1 — defines the reference architecture and relationships between the 4 value streams.
ServiceNow IT4IT v3 Blueprint — functionally maps IT4IT onto real DevOps/ITSM tools, confirming implementability.
Rabobank / Shell / Delta Lloyd — official The Open Group case studies using IT4IT to streamline toolchains, reduce vendors, and improve time-to-market. The logical leap is replacing manual processes with governed agents.
OpenDigitalProductFactory — the only open-source project explicitly mapping agents onto valueStream and it4itSections, proving the coupling is technically feasible.
Microsoft — Agentic DevOps — shows how every phase of the development lifecycle can be assisted or governed by agents, confirming the feasibility of the R2D agentic model.
Deloitte — AI Agent Orchestration — highlights that enterprise success depends on orchestration and governance, exactly what IT4IT provides.

7. How to start without burning the organization

Map tools first, not agents

Use IT4IT to catalog existing tools into the 4 value streams. Find bottlenecks, silos, and duplications.
Pick one value stream as a pilot

Detect to Correct is the most common: monitoring, incident, problem. It has measurable outcomes (MTTR, incident count) and contained risk.
Define 2–3 specialist agents, not 20

Example: incident classification agent, runbook automation agent, root-cause suggester. HITL Tier 1–2.
Lock identity and grants before prompts

An agent without verifiable identity and explicit grants is noise in the system.
Measure like IT4IT measures

Use the framework’s Key Data Objects: service release lead time, requirement churn, fulfillment automation rate, detection-to-correction time.
Publish a Decision Perspective Gate

Even simple: every borderline agent action must show why it was taken, on which IT4IT criterion, and with what confidence level.

8. Bottom line for the board

Agentic IT is not a generic AI project. It is a governance architecture project in which agents are executors, and IT4IT is the model of what-to-build and when-to-act.

The benefits are real: transparency, speed, reduced toil, traceability. The risks are equally real: orchestration complexity, semantic lock-in, need for strict governance.

The safest approach is not “agents everywhere,” but one value stream at a time, with clear IT4IT boundaries and non-negotiable HITL.

Sources

The Open Group — IT4IT Standard, Version 3.0.1 — https://publications.opengroup.org/c24a
The Open Group — About IT4IT — https://www.opengroup.org/about-it4it%E2%84%A2
The Open Group Blog — The IT4IT Reference Architecture is a Digital Product Blueprint (2022) — https://blog.opengroup.org/2022/05/24/the-it4it-reference-architecture-is-a-digital-product-blueprint-for-cost-savings-and-automation/
The Open Group Blog — Who’s Using the IT4IT Standard: Banking/Insurance (2019) — https://blog.opengroup.org/2019/09/19/the-interesting-case-of-whos-using-the-it4it-standard-part-one-the-banking-and-insurance-sectors
ServiceNow — IT4IT v3 Blueprint: Utah Version — https://www.servicenow.com/community/architect-articles/servicenow-it4it-v3-blueprint-utah-version/ta-p/2619269
Tambo, T. et al. — Digital services governance: IT4IT for management of technology — Journal of Science and Technology Policy Management, 2019 — https://www.sciencedirect.com/science/article/pii/S1741038X19000518
IAMOT 2017 — IT4IT as a Management of Technology Framework — https://pure.au.dk/ws/files/112882194/IAMOT_2017_IT4IT_AS_A_MANAGEMENT_OF_TECHNOLOGY_FRAMEWORK_proc.pdf
OpenDigitalProductFactory — AI Agent Meta Model — https://github.com/OpenDigitalProductFactory/opendigitalproductfactory/blob/main/docs/architecture/ai-agent-meta-model.md
OpenDigitalProductFactory — Gap Analysis Agent Prompt — https://github.com/OpenDigitalProductFactory/opendigitalproductfactory/blob/main/docs/superpowers/specs/2026-03-30-ai-coworker-skills-marketplace.md
Microsoft — Agentic DevOps in action — https://developer.microsoft.com/blog/reimagining-every-phase-of-the-developer-lifecycle/
D2i Technology — Complete Agentic SDLC Guide — https://d2itechnology.com/blogs/complete-asdlc-guide-requirements-to-deployment/
Deloitte — AI Agent Orchestration (2026 TMT Predictions) — https://www.deloitte.com/us/en/insights/industry/technology/technology-media-and-telecom-predictions/2026/ai-agent-orchestration.html
Deloitte — Agentic AI Orchestration, Governance, and Best Practices — https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/articles/agentic-ai-orchestration-governance.html

Agenti di coding in parallelo senza conflitti: Git Worktrees

Andrea Schiona — Mon, 31 Aug 2026 08:01:12 +0000

TL;DR: se usi Claude Code, Codex o agenti di coding simili, un singolo checkout condiviso è un disastro quando lanci più agenti in parallelo. git worktree crea cartelle di lavoro separate, ognuna sul proprio branch, condividendo lo stesso repository: zero conflitti, zero push/pull inutili, merge diretto in integrazione.

Il problema: agenti che si pestano i piedi

Due agenti sullo stesso repo, stessa cartella, stesso branch:

scrivono gli stessi file
sovrascrivono modifiche
nessun isolamento di contesto

Risultato: caos, anche se ogni agente “funziona” bene da solo.

La soluzione: una worktree per agente

git worktree add ../feature-login -b feature/login main
git worktree add ../feature-payments -b feature/payments main
git worktree add ../integration -b integration main

Struttura risultante:

project/
├── main/               → branch main
├── integration/        → branch integration
├── feature-login/      → branch feature/login
└── feature-payments/   → branch feature/payments

Ogni agente ha:

la propria cartella
il proprio branch
lo stesso repository condiviso

Nessun conflitto di file, nessun conflitto di working directory.

Il dettaglio che sorprende: niente push, niente pull

Le worktree sono sullo stesso repo locale. Quindi l’integrazione può fare direttamente:

cd ../integration
git merge feature/login
git merge feature/payments
npm test

Git conosce già tutti i branch locali. Push e pull servono solo quando entra l’uomo:

PR, review, CI, audit trail
Piano locale agenti → piano remoto esseri umani

Cleanup corretto

git worktree remove ../feature-login
git branch -d feature/login

git worktree remove pulisce anche il registro interno. Se hai già cancellato la cartella a mano: git worktree prune.

Ciclo completo per un task:

git worktree add ../feature-login -b feature/login main
cd ../feature-login && git add . && git commit -m "feat: login"
cd ../integration && git merge feature/login && npm test
git worktree remove ../feature-login
git branch -d feature/login

Runtime condiviso: il problema dei port

Le worktree isolano file e branch, non i processi. Due agenti che fanno npm run dev o eseguono test si contendono :3000, database di test locali e RAM per i browser headless.

Workaround semplice: ogni worktree ha il suo .env.local con porta dedicata:

echo "PORT=3101" > ../feature-login/.env.local
echo "PORT=3102" > ../feature-payments/.env.local

Per database di test condivisi, suite E2E concorrenti e isolamento reale serve un passo ulteriore — forse contenitori o worktree su macchine separate.

Nota critica: lo stash è condiviso

⚠️ refs/stash è unico nel repo condiviso. Se un agente fa stash in una worktree, l’altra worktree lo vede e può applicarlo nel posto sbagliato.

Regola: mai usare stash con agenti paralleli. Usare solo commit sul proprio branch.

Cosa dice l'ecosistema nel 2026

Questo pattern non è più un trucco per power-user. Team e strumenti di produzione lo hanno adottato come default.

Worktree-per-task vs worktree-per-agent
La scelta consigliata è worktree-per-task: ogni task ha il proprio branch e la propria worktree, e gli agenti vengono assegnati alle worktree invece di possederle permanentemente. Così si evita stato stale e si mantiene la riutilizzabilità.

Supporto nativo

Claude Code supporta --worktree / -w per avviare una sessione isolata, oltre all’isolamento dei subagent in worktree separate.
Codex CLI non ha una flag nativa --worktree; il pattern comune è git worktree add manuale seguito da codex --cd ../path.
Cursor ha aggiunto supporto first-class alle worktree nella release 2026.1.

Strumenti di orchestrazione
Tool come Intent, AQ, Atlas, Nimbalyst e l’orchestrazione cloud di Warp automatizzano creazione, assegnazione, review e cleanup delle worktree. Trattano la worktree come unità di isolamento e costruiscono sopra scheduling, review dei diff e gate di merge.

Previsione di conflitti
Tool come Clash prevedono merge conflict prima che avvengano, monitorando quali file vengono toccati da worktree parallele.

Cinque failure mode da progettare

Port e servizi in conflitto — gli agenti competono per lo stesso dev server, database o cache. Fix: .env.local esplicita per worktree.
Stato esterno condiviso — database, Docker volumes e code sono ancora condivisi. Fix: database o container separati per worktree.
Confini di task laschi — due agenti toccano lo stesso modulo e generano un conflitto imprevisto. Fix: ownership esplicita dei file prima di avviare.
Stato non committato invisibile — le modifiche in corso di un agente non sono visibili all’altro finché non vengono committate. Fix: WIP commit per handoff.
La review diventa il collo di bottiglia — creare molti agenti è economico, leggere molte diff no. Fix: task scope stretto, merge sequenziale e un combined test pass finale.

Workflow pratico

Mappa i confini. Decidi quali file può toccare ogni agente.
Crea una worktree per task. Branch da base pulita; evita di forzare lo stesso branch due volte.
Bootstrap. Installa dipendenze, copia env, assegna port.
Esegui con prompt scoping. Indica ownership boundary e criteri di successo.
Merge sequenziale. Un branch alla volta, con test tra i merge.
Cleanup. git worktree remove e cancella il branch dopo il merge.

Dove si inserisce in contesto enterprise

Non è solo un trucco per sviluppatori singoli. In ambito enterprise, l’isolamento per worktree mappa direttamente su:

Value stream Requirement-to-Deploy: ogni worktree è un cambiamento controllato in corso, pronto per approval workflow.
Change control: i commit sono tracciabili, reversibili e legati a task branch specifici.
Integration gating: la worktree di integrazione è il singolo punto di merge con testing obbligatorio.
Governance dei costi: l’esecuzione parallela riduce il wall-clock time, ma solo se i confini di task sono abbastanza stretti da evitare rework.

Il pattern è diventato talmente standard che nel 2026 guide di Augment Code, MindStudio, Warp e numerosi practitioner indipendenti lo descrivono come baseline per il multi-agent coding, non come tecnica avanzata.

Link

📄 Articolo originale: https://dev.to/servatj/running-coding-agents-in-parallel-with-git-worktrees-507i

Running Coding Agents in Parallel with Git Worktrees

Andrea Schiona — Mon, 31 Aug 2026 08:01:11 +0000

TL;DR: if you run Claude Code, Codex, or similar agents, a single shared checkout is a disaster when you spin up multiple agents in parallel. git worktree gives you separate working directories, each on its own branch, sharing the same repository: zero conflicts, zero unnecessary push/pull, direct merge into integration.

The problem: agents stepping on each other

Two agents on the same repo, same folder, same branch:

editing the same files
overwriting each other's changes
no context isolation

Result: chaos, even if each agent works perfectly in isolation.

The fix: one worktree per agent

git worktree add ../feature-login -b feature/login main
git worktree add ../feature-payments -b feature/payments main
git worktree add ../integration -b integration main

Resulting structure:

project/
├── main/               → branch main
├── integration/        → branch integration
├── feature-login/      → branch feature/login
└── feature-payments/   → branch feature/payments

Each agent gets:

its own folder
its own branch
the same shared repository

No file conflicts, no working directory conflicts.

The surprising detail: no push, no pull

All worktrees belong to the same local repository. So integration can directly:

cd ../integration
git merge feature/login
git merge feature/payments
npm test

Git already knows all local branches. Push and pull only matter when humans enter the loop:

PRs, review, CI, audit trail
Local agent plane → remote human plane

Proper cleanup

git worktree remove ../feature-login
git branch -d feature/login

git worktree remove deletes the folder and cleans Git's internal registry. If you already nuked the folder by hand, git worktree prune fixes the bookkeeping.

Full cycle for one task:

git worktree add ../feature-login -b feature/login main
cd ../feature-login && git add . && git commit -m "feat: login"
cd ../integration && git merge feature/login && npm test
git worktree remove ../feature-login
git branch -d feature/login

Shared runtime: the port problem

Worktrees isolate files and branches, not processes. Two agents running npm run dev or test suites will fight over :3000, local test databases, and RAM for headless browsers.

Simple workaround: each worktree gets its own .env.local with a dedicated port:

echo "PORT=3101" > ../feature-login/.env.local
echo "PORT=3102" > ../feature-payments/.env.local

For shared test databases, concurrent E2E suites, and real isolation, you need a further step — perhaps containers or worktrees on separate machines.

Critical note: stash is shared

⚠️ refs/stash is unique in the shared repo. If one agent stashes in a worktree, the other worktree sees it and can apply it in the wrong place.

Rule: never use stash with parallel agents. Use only commits on your own branch.

What the ecosystem says in 2026

This pattern is no longer a niche trick. Multiple production teams and tools have validated it.

Worktree-per-task vs worktree-per-agent
Practitioners recommend worktree-per-task as the default: each task gets its own branch and worktree, and agents are assigned to worktrees rather than owning them permanently. This keeps reuse simple and avoids stale state.

Native tool support

Claude Code supports --worktree / -w to spawn an isolated session, plus subagent isolation inside separate worktrees.
Codex CLI does not have a native --worktree flag; the common pattern is manual git worktree add plus codex --cd ../path.
Cursor added first-class worktree support in the 2026.1 release.

Orchestration layers
Tools like Intent, AQ, Atlas, Nimbalyst, and Warp’s cloud orchestration automate worktree creation, assignment, review, and cleanup. They treat a worktree as the unit of isolation and build scheduling, diff review, and merge gating on top of it.

Conflict prediction
Tools like Clash predict merge conflicts before they happen by monitoring which files parallel worktrees are touching.

Five failure modes to design around

Port and service collisions — agents fight over the same dev server, database, or cache. Fix: explicit .env.local per worktree.
Shared external state — databases, Docker volumes, and queues are still shared. Fix: separate databases or containers per worktree.
Loose task boundaries — two agents touch the same module and produce a conflict neither anticipated. Fix: explicit file ownership before launching.
Uncommitted state is invisible — one agent’s in-progress edits are not seen by another until committed. Fix: WIP commits for handoffs.
Review becomes the bottleneck — worktrees make it cheap to start many agents, but reading many diffs is still expensive. Fix: narrow task scope, sequential merge, and one combined test pass.

A practical workflow

Map boundaries first. Decide which files each agent can touch.
Create one worktree per task. Branch from a clean base; avoid forcing the same branch twice.
Bootstrap each worktree. Install dependencies, copy env files, assign ports.
Run agents with scoped prompts. Tell each agent its ownership boundary and success criteria.
Merge sequentially. One branch at a time, with tests between merges.
Clean up. git worktree remove and delete the branch when the feature is merged.

Where this fits in enterprise delivery

This is not just a solo-developer productivity trick. In enterprise settings, worktree isolation maps cleanly onto:

Requirement-to-Deploy value streams: each worktree is a controlled change in progress, ready for approval workflow.
Change control: commits are auditable, revertible, and tied to specific task branches.
Integration gating: the integration worktree becomes the single merge point with mandatory testing.
Cost governance: parallel execution reduces wall-clock time, but only when task boundaries are tight enough to avoid rework.

The pattern has become so standard that 2026 guides from Augment Code, MindStudio, Warp, and multiple independent practitioners describe it as the default baseline for multi-agent coding — not an advanced technique.

Link

📄 Original article: https://dev.to/servatj/running-coding-agents-in-parallel-with-git-worktrees-507i

L'AI enterprise sta fallendo nello sviluppo software. Ecco perché — e cosa viene dopo

Andrea Schiona — Sat, 29 Aug 2026 12:04:10 +0000

L'AI enterprise sta fallendo nello sviluppo software. Ecco perché — e cosa viene dopo

Learning brief — Settembre 2026

La maggior parte delle iniziative AI enterprise nel software development si blocca prima del primo anno. Il problema non è la qualità dei modelli, il costo o la resistenza dei developer. È la scelta tra point solution e piattaforme, tra tool isolati e sistemi agentic AI-native che condividono un contesto unificato.

1. Il problema non è l'AI. È come viene deployata

Dopo due anni di adozione AI, gli executive stimano un aumento di ricavi del 44% legato all'uso di AI. Allo stesso tempo, la soddisfazione dei developer per gli strumenti AI è scesa da oltre il 70% nel 2023-24 al 60% nel 2025. Il divario tra promessa e realtà non è causato dall'AI stessa. È causato da come viene implementata.

La maggior parte delle aziende deploya AI come set di point solution disconnesse: un tool per il completamento codice, un altro per security scanning, un altro per test generation. Questi tool vengono appoggiati su workflow già frammentati, tool sprawl e dati siloizzati. Invece di risolvere i problemi sottostanti, l'AI li amplifica. I developer passano più tempo a cambiare contesto, riconciliare output e manutenere integrazioni che a costruire features.

La media enterprise ha circa 254 tool, con 61 gestiti direttamente da IT. Il 60% dei dipendenti fatica a ottenere le informazioni che servono, perdendo in media 5,3 ore a settimana. I developer sono interrotti in media 13 volte all'ora. In questo ambiente, aggiungere un altro tool AI non crea leverage. Crea rumore.

2. Le point solution funzionano nelle demo. Non funzionano nella pratica

Le point solution AI sono vendute come plug-and-play, ma richiedono preparazione dati, lavoro di integrazione e manutenzione continua. Ogni tool possiede il proprio schema dati, le proprie metriche di utilizzo e la propria definizione di successo. Questo rende quasi impossibile misurare il ROI attraverso un portfolio. Peggio ancora, ogni tool aggiunge attack surface, requisiti di compliance e overhead di governance.

Dal punto di vista della sicurezza, i numeri sono impietosi. Un membro del team security supporta tipicamente 80 developer. Quando dozzine di tool AI si integrano ciascuno con codebase e servizi esterni, la review manuale diventa impossibile. Il risultato è una diminuzione della scrutiny sul codice, shadow AI, governance frammentata e esposizione aumentata.

Le point solution migliorano task isolati. Non migliorano il sistema. Questa è la distinzione che conta.

3. L'agentic AI cambia l'architettura, non solo l'assistente

Il passo successivo non è un copilot migliore. È una piattaforma AI-native agentic: un sistema in cui multiple AI agent condividono un knowledge graph unificato, protocolli standardizzati e un layer di orchestrazione che scompone obiettivi complessi in subtask.

AI tradizionale: reagisce solo quando viene promptata
Context-aware assistant: suggerisce proattivamente, ma richiede approvazione umana per ogni azione
Agentic AI: pianifica, esegue, adatta e coordina workflow attraverso tool e fonti dati

Nella pratica, questo significa che quando viene scoperta una vulnerabilità critica, un sistema agentic può automaticamente scansire i codebase affetti, valutare l'impatto di business, creare patch, aggiornare documentazione e notificare stakeholder—senza che un umano debba manualmente passare il lavoro tra tool. Gli umani intervengono per eccezioni, conflitti di policy e decisioni non routinarie. Il lavoro operativo routinario gira senza attrito.

Questo viene a volte chiamato "lights-out development": ottimizzazione, testing e remediation continuano automaticamente, mentre i developer si concentrano su architettura, business logic e innovazione.

4. L'orchestrazione è dove la scala diventa realtà

L'orchestrazione di agenti è il layer di coordinamento che trasforma multiple entità specializzate in un sistema coerente. Ogni agente ha un ruolo: architettura, security, performance, testing. Collaborano attraverso interfacce condivise piuttosto che integrazioni rigide.

Una buona orchestrazione non solo schedulare task. Gestisce dipendenze, risolve conflitti, applica governance e scala a umano quando necessario. Permette anche esecuzione parallela: la validazione security può avvenire mentre testing e aggiornamento documentazione girano simultaneamente.

La governance è embedded nel flusso. Approval gates, quality gates, compliance checkpoints e audit trail non sono afterthought. Sono first-class citizen del workflow. È così che le aziende ottengono i benefici dell'esecuzione autonoma senza perdere il controllo.

5. Sicurezza e trust devono essere progettati fin dal giorno uno

I sistemi agentic AI operano con privilegi elevati, accedono a codebase sensibili e prendono decisioni autonome. Gli executive classificano cybersecurity threats, data privacy e governance tra le loro prime preoccupazioni. Queste preoccupazioni sono valide—ma non sono un motivo per evitare l'agentic AI. Sono un requisito di design.

Le giuste guardrail includono:

audit trail e monitoraggio real-time delle decisioni agente e accesso dati
classificazione dati così che gli agenti applichino procedure di handling appropriate
role-based access control con privilegio minimo necessario
human-in-the-loop checkpoint per azioni ad alta conseguenza

Se implementato bene, l'agentic AI migliora anche la sicurezza. Gli agenti possono analizzare anomalie across ambienti più velocemente degli umani, correlare vulnerabilità con impatto di business e sintetizzare alert per remediation più rapida.

6. Misura l'impatto di business, non le metriche di vanity

Misurare l'AI per tasso di adozione è uno degli errori più comuni nei programmi enterprise. L'adozione non equivale a valore. Le organizzazioni leader misurano outcome di business.

Categorie utili:

Business growth: feature velocity to revenue, time-to-market reduction, innovation pipeline
Developer productivity: story points per sprint, code review cycle time, deployment frequency, focus time recuperato
Security posture: vulnerability remediated, mean time to resolution, compliance automation
Cost efficiency: risparmio da consolidamento tool, ottimizzazione infra, errori evitati
Customer experience: bug escape rate, performance applicativa, volume di ticket supporto

I developer riportano risparmi di tempo significativi, ma la sfida di misurazione è che molto di quel tempo viene assorbito da nuovo lavoro di coordinamento. L'obiettivo non è massimizzare l'uso di tool. È convertire risparmi di tempo in outcome di business misurabili.

7. Cosa significa per il tuo prossimo investimento AI

Prima di comprare un altro tool AI, fai tre domande:

Questa soluzione condivide contesto con il resto del mio ambiente di sviluppo?
Riduce il carico di integrazione, o aggiunge un altro silo?
Posso misurare il suo impatto su outcome di business, non solo su usage metric?

Se la risposta alle prime due domande è no, il tool probabilmente underperformerà in contesti enterprise indipendentemente dalla sua qualità tecnica. Se la risposta alla terza domanda è no, non sarai in grado di giustificarne l'espansione o ottimizzarne il deployment nel tempo.

Le organizzazioni che vincono con l'AI nel software development non sono quelle con più tool. Sono quelle con meno sistemi, meglio integrati—e con la disciplina di misurare ciò che conta.

Fonti

Enterprise guide to agentic AI in software development, GitLab, 2026
DORA — Balancing AI tensions: Moving from AI adoption to effective SDLC use, March 2026
Developer Productivity Benchmarks 2026 — AI-Native Engineering Data
Spiceworks — What is AI sprawl? How to fix It in 2026
Waymaker — SaaS Sprawl 2026: Why 47+ Apps Are Killing Your Team’s Productivity
Exceeds AI — Top 10 Enterprise AI Platforms 2026: ROI-Proven Rankings
AISquared — Unified AI Platform vs Point Solutions: A Decision Framework [2026]
Lines n Circles — Enterprise AI ROI 2026: Metrics, Benchmarks & P&L
Towards AI — AI-Driven & Agentic Software Development Life Cycle in 2026
LTM — SDLC AI Radar 2026

Enterprise AI is failing in software development. Here's why — and what comes next

Andrea Schiona — Sat, 29 Aug 2026 12:04:09 +0000

Enterprise AI is failing in software development. Here’s why — and what comes next

Learning brief — September 2026

Most enterprise AI initiatives in software development stall before year one. The problem is not model quality, cost, or developer resistance. It is the choice between point solutions and platforms, between siloed tools and agentic AI-native systems that share a unified context.

1. The real problem is not AI. It is how AI is deployed.

After two years of AI adoption, executives estimate a 44% revenue increase tied to AI use. At the same time, developer satisfaction with AI tools has dropped from over 70% in 2023–24 to 60% in 2025. The gap between promise and reality is not caused by AI itself. It is caused by implementation.

Most companies deploy AI as a set of disconnected point solutions: one tool for code completion, another for security scanning, another for test generation. These tools are layered onto already fragmented workflows, tool sprawl, and siloed data. Instead of solving underlying problems, AI amplifies them. Developers spend more time switching contexts, reconciling outputs, and maintaining integrations than actually building.

The enterprise average is roughly 254 tools, with IT directly managing 61. Sixty percent of employees find it difficult to obtain the information they need, losing on average 5.3 hours per week waiting for it. Developers are interrupted 13 times per hour. In that environment, adding another AI tool does not create leverage. It creates noise.

2. Point solutions look productive in demos. They are not productive in practice.

AI point solutions are marketed as plug-and-play, but they require data preparation, integration work, and ongoing maintenance. Each tool owns its own data schema, usage metrics, and success definition. That makes ROI almost impossible to measure across a portfolio. Worse, each tool adds attack surface, compliance requirements, and governance overhead.

From a security standpoint, the math is unforgiving. One security team member typically supports 80 developers. When dozens of AI tools each integrate with codebases and external services, manual review becomes impossible. The result is declining code scrutiny, shadow AI, fragmented governance, and expanded exposure.

Point solutions do improve isolated tasks. They do not improve the system. That is the distinction that matters.

3. Agentic AI changes the architecture, not just the assistant

The next step is not a better copilot. It is an agentic AI-native platform: a system in which multiple AI agents share a unified knowledge graph, standardized protocols, and an orchestration layer that breaks complex goals into subtasks.

Traditional AI assistants react only when prompted.
Context-aware assistants suggest proactively but still require human approval for each action.
Agentic AI systems plan, execute, adapt, and coordinate workflows across tools and data sources.

In practice, this means that when a critical vulnerability is discovered, an agentic system can automatically scan affected codebases, assess business impact, create patches, update documentation, and notify stakeholders—without requiring a human to manually hand off work between tools. Humans step in for exceptions, policy conflicts, and novel decisions. Routine operational work runs without friction.

This is sometimes called “lights-out development”: routine optimization, testing, and remediation happen continuously, while developers focus on architecture, business logic, and innovation.

4. Orchestration is where scale actually happens

Agent orchestration is the coordination layer that turns multiple specialized agents into a coherent system. Each agent has a role: architecture, security, performance, testing. They collaborate through shared interfaces rather than rigid integrations.

Good orchestration does more than schedule tasks. It manages dependencies, resolves conflicts, enforces governance, and escalates to humans when necessary. It also allows parallel execution: security validation can happen while testing and documentation updates run simultaneously.

Governance is embedded in the flow. Approval gates, quality gates, compliance checkpoints, and audit trails are not afterthoughts. They are first-class citizens of the workflow. That is how enterprises gain the benefits of autonomous execution without losing control.

5. Security and trust must be designed in from day one

Agentic AI systems operate with elevated privileges, access sensitive codebases, and make autonomous decisions. Executives consistently rank cybersecurity threats, data privacy, and governance among their top adoption concerns. Those concerns are valid—but they are not a reason to avoid agentic AI. They are a design requirement.

The right guardrails include:

audit trails and real-time monitoring of agent decisions and data access
data classification so agents apply appropriate handling procedures automatically
role-based access control with minimum necessary privileges
human-in-the-loop checkpoints for high-consequence actions

Done well, agentic AI also improves security posture. Agents can analyze anomalies across environments faster than humans, correlate vulnerabilities with business impact, and summarize alerts for quicker remediation.

6. Measure business impact, not adoption vanity metrics

Measuring AI by adoption rate is one of the most common mistakes in enterprise programs. Adoption does not equal value. Leading organizations measure business outcomes.

Useful categories include:

Business growth: feature velocity to revenue, time-to-market reduction, innovation pipeline
Developer productivity: story points per sprint, code review cycle time, deployment frequency, reclaimed focus time
Security posture: vulnerabilities remediated, mean time to resolution, compliance automation
Cost efficiency: tool consolidation savings, infrastructure optimization, avoided error costs
Customer experience: bug escape rate, application performance, support ticket volume

Developers in organizations using AI report saving meaningful time, but the measurement challenge is that much of that time gets absorbed by new coordination work. The goal is not to maximize tool usage. It is to convert time savings into measurable business outcomes.

7. What this means for your next AI investment

Before buying another AI tool, ask three questions:

Does this solution share context with the rest of my development environment?
Does it reduce integration burden, or add another silo?
Can I measure its impact on business outcomes, not just usage?

If the answer to the first two questions is no, the tool will likely underperform in enterprise settings regardless of its technical quality. If the answer to the third question is no, you will not be able to justify expansion or optimize the deployment over time.

The organizations that win with AI in software development are not the ones with the most tools. They are the ones with the fewest, best-integrated systems—and with the discipline to measure what matters.

Sources

Enterprise guide to agentic AI in software development, GitLab, 2026
DORA — Balancing AI tensions: Moving from AI adoption to effective SDLC use, March 2026
Developer Productivity Benchmarks 2026 — AI-Native Engineering Data
Spiceworks — What is AI sprawl? How to fix It in 2026
Waymaker — SaaS Sprawl 2026: Why 47+ Apps Are Killing Your Team’s Productivity
Exceeds AI — Top 10 Enterprise AI Platforms 2026: ROI-Proven Rankings
AISquared — Unified AI Platform vs Point Solutions: A Decision Framework [2026]
Lines n Circles — Enterprise AI ROI 2026: Metrics, Benchmarks & P&L
Towards AI — AI-Driven & Agentic Software Development Life Cycle in 2026
LTM — SDLC AI Radar 2026

Gestire gli agenti AI come dipendenti: perché il performance management è il prossimo confine

Andrea Schiona — Fri, 28 Aug 2026 20:06:22 +0000

Il rischio reale dell'AI enterprise non sono gli agenti autonomi. È la complessità tra di loro.

Executive Briefing — Settembre 2026

Quando le aziende deployano fleet di agenti AI invece di sistemi singoli, il pericolo vero non è un agente che si mette a fare il matto da solo. È la complessità emergente delle loro interazioni: una ragnatela di chiamate a cascata, permessi dimenticati e gap di accountability che nessuna checklist può chiudere.

1. Il problema che nessuno vede arrivare

Le aziende non deployano un agente e lo guardano girare. Deployano fleet: bot di supporto, agenti di retrieval, layer di orchestrazione, ognuno che chiama API, delega ad altri agenti, si infila in sistemi che non erano stati progettati per decisioni automatiche. Lo scenario che dovrebbe farvi perdere il sonno non è un singolo agente che combina un guaio. È cento agenti che fanno esattamente quello per cui sono stati costruiti, tutti insieme, in combinazioni che nessuno ha disegnato.

La complessità non cresce linearmente col numero di agenti. Aggiungi un secondo agente e aggiungi una connessione. Aggiungi il decimo e potenzialmente aggiungi decine di connessioni, perché ora qualsiasi agente può chiamarne un altro, e ogni chiamata può scatenarne una terza altrove. Un ticket di supporto che prima toccava un solo sistema oggi può passare attraverso quattro agenti prima che un essere umano lo veda. E ogni passaggio è un punto decisionale non approvato.

La maggior parte dei programmi AI enterprise si blocca quando gli umani responsabili perdono il filo. Chiedete a un team security quali agenti possono raggiungere quali sistemi, e otterrete silenzio. Chiedete quale agente ha triggered quale downstream action tre salti fa. Ancora silenzio.

2. Perché le checklist non funzionano

L'istinto è trattarlo come compliance: approva l'agente, registralo, passa oltre. Ma una checklist valuta un singolo punto nel tempo. La complessità corre lungo una catena, e non puoi governare una catena con una pila di approvazioni one-time più di quanto puoi dire che una dieta è riuscita perché hai mangiato una verdura una volta.

Due modalità di guasto dominano.

Permessi che si allargano. Qualcuno builda un agente per riassumere ticket di supporto e gli dà accesso API ampio perché fare il refactor dei permessi avrebbe richiesto un altro sprint. Sei mesi dopo, quello stesso agente ha un percorso nel sistema dei pagamenti. Nessuno ricorda di averlo approvato. Perché nessuno l'ha fatto.

Proprietà che si assottiglia. Cinque agenti toccano un workflow, qualcosa si rompe al quarto passo, e ti ritrovi a chiedere chi è responsabile di un link che a nessuno è stato assegnato, perché l'organigramma si è fermato a "deploya l'agente" e non è mai arrivato a "indica l'umano che risponde."

Questa è una storia di governance infrastructure che non ha tenuto il passo con il comportamento reale degli agenti: interconnessi, a cascata, che moltiplicano più velocemente dei processi creati per tracciarli.

3. Cosa dice la ricerca

Il problema non è teorico. Un sondaggio 2026 su oltre 1.600 leader aziendali globali mostra che l'85% delle aziende punta ad adottare AI agentica entro tre anni, ma il 76% riconosce che la propria infrastruttura operativa non la può supportare. Solo il 21% ha una governance matura per agenti autonomi. Gartner proietta che il 40% dei progetti agentic AI fallirà entro il 2027 per costi crescenti, valore di business poco chiaro e controlli di rischio inadeguati.

Il lavoro accademico formalizza i failure mode:

Agent sprawl. Le piattaforme low-code rendono la creazione di agenti accessibile a tutti, producendo proliferazione non controllata di agenti ridondanti, frammentati e non governati tra team e funzioni.
Governance gap. Solo il 21% dei leader ha governance matura. Il divario tra velocità di adozione e prontezza di governance è netto.
Accountability diffusion. Nelle architetture multi-agente, la responsabilità si assottiglia lungo lo stack fino a concentrarsi di default sull'operatore enterprise, anche se quest'ultimo non aveva visibilità reale sulla catena decisionale.

Uno studio sulla governance delle identità macchina ha scoperto che agenti AI, service account e token API superano di oltre 80 a 1 le identità umane negli ambienti enterprise, eppure non esiste un framework integrato per governarli. Le conseguenze sono misurabili: un singolo agente non governato ha prodotto perdite tra 5.4 e 10 miliardi di dollari nel outage CrowdStrike del 2024.

I sistemi multi-agente LLM mostrano tassi di fallimento in produzione tra il 41% e l'86.7%, con quasi il 79% dei fallimenti originati da problemi di specifica e coordinamento, non da limiti dei modelli.

4. La superficie d'attacco tra agenti

La security research aggiunge un altro strato. Uno studio ha rivelato che l'82% dei modelli AI state-of-the-art è suscettibile a inter-agent trust exploitation, con un ulteriore 41% vulnerabile a prompt injection diretti. Quando gli agenti operano in architetture multi-agente, creano subagenti, delegano subtask e passano istruzioni e credenziali attraverso catene le cui relazioni di trust sono raramente verificate cryptographicamente.

La delega agente-to-agente è un potenziale accountability gap e una potenziale superficie di privilege escalation. Ogni boundary di delega è un punto dove un attaccante può pivotare, dove un permesso malconfigurato può cascadare, dove un disaccordo semantico tra agenti può produrre risultati che nessun agente singolo ha previsto.

5. Cosa funziona davvero

La soluzione parte dall'identity. Ogni agente deve esistere come entità propria, non come permesso ombra preso in prestito da chi lo ha deployato. Un nome nel registro. Un'autorità scopedata. Un umano sponsor che risponde di quello che fa.

Ma l'identity è necessaria, non sufficiente.

Il pezzo più difficile è l'oversight che vale per tutta la catena, non solo per ogni singolo link. Devi vedere cosa ha fatto un agente, cosa ha scatenato downstream, e dove finisce quella traccia in tempo reale, non in un report che qualcuno tira fuori una volta al trimestre. Se ti fermi all'identity, ti ritrovi con un archivio di agenti perfettamente documentati che operano dentro un sistema che nessuno può spiegare.

L'oversight da solo ti dice cosa è già successo. Guardare una catena non è la stessa cosa che controllarla. L'enforcement è il pezzo che quasi tutti i programmi saltano: la capacità di bloccare una chiamata fuori policy prima che esegua, non solo registrarla per qualcuno che la trova in una revisione tre settimane dopo. Una dashboard che ti mostra che un agente ha violato lo scope cinque minuti fa è un tool di monitoring. Un sistema che blocca la violazione prima che accada è governance.

Le aziende serie su agent accountability hanno bisogno di entrambi. La maggior parte ha costruito solo il primo.

6. Il cammino

La complessità non è un motivo per frenare. Le aziende che ci riescono non stanno rallentando. Stanno costruendo verso Human-Agent Harmony, dove scala e accountability crescono insieme invece di scambiarsi.

Il rischio reale non era un singolo agente che fa esattamente quello per cui è stato costruito. Sono cento agenti che lo fanno tutti insieme, in combinazioni non progettate. Quella moltiplicazione è quello che tiene l'AI enterprise bloccata in pilot forever invece di arrivare in produzione.

Risolvi la complessità e l'autonomia smette di essere il villain. Diventa il punto.

Fonti

VentureBeat — Enterprise AI's real risk isn't autonomous agents. It's the complexity between them. (Rory Blundell, Gravitee, 2026)
arXiv — Governing the Agentic Enterprise: A Governance Maturity Model for Managing AI Agent Sprawl in Business Operations (2604.16338)
arXiv — Who Governs the Machine? A Machine Identity Governance Taxonomy (MIGT) for AI Systems (2604.06148)
Arion Research — Orchestrating the Hybrid Workforce, Part 7: Orchestration Governance, Trust, and Accountability
arXiv — Semantic Consensus: Process-Aware Conflict Detection and Resolution for Enterprise Multi-Agent LLM Systems (2604.16339v1)
Lumenova AI — Taming Complexity: A Guide to Governing Multi-Agent Systems
Token Security — Collaborative AI Agents: Securing Multi-Agent Networks

Managing AI agents like employees: why performance management is the next frontier

Andrea Schiona — Fri, 28 Aug 2026 20:06:21 +0000

Managing AI agents like employees: why performance management is the next frontier

Executive Briefing — September 2026

Companies are deploying thousands of AI agents, but almost none treat them like a workforce. The result is a growing stack of “digital abandonware”: agents that outlive their purpose, drift in quality, and create hidden risk. The organizations that will win are the ones that apply HR discipline to nonhuman workers.

1. The new workforce is half human, half digital

Enterprises are no longer experimenting with one or two AI agents. IBM reports managing roughly 4,000 digital workers side by side with humans. Industry forecasts suggest many enterprises will deploy more than 1,600 agents by the end of 2026. The shift is no longer theoretical: agents handle reconciliation, scheduling, research, coding, and customer interactions.

Yet while the technology stacks have matured, the management stacks have not. Ask a security team which agents can reach which systems, and the answer is often incomplete. Ask who owns the performance of a specific agent after six months, and the answer is usually nobody. The result is a workforce without a manager.

2. Why agents need more than a deployment checklist

McKinsey’s recent podcast on talent and AI makes the point bluntly: deploying an agent is not the same as governing it. Agents need:

Identity: a verified entity distinct from the employee or team that deployed it
Ownership: a named human sponsor accountable for outcomes
Performance rhythm: review cadences, not just launch events
Lifecycle management: fine-tuning, deprecation, and retirement
Access governance: task-scoped permissions that change as the role changes

Without these, organizations accumulate what practitioners are starting to call “abandonware”: agents that were fit for purpose six months ago, but have since drifted into risk because nobody was assigned to care for them.

3. What “performance management” means for an agent

Performance management for humans is familiar: goals, reviews, feedback loops, calibration. For agents, the analogous disciplines are just emerging.

PwC’s 2026 Trust and Safety Outlook finds that 85% of U.S. respondents trust AI agents with at least one daily task, but organizations still lack mature governance. The gap is not trust; it is structure. Agents need evaluation cadences, access reviews, and documented change management just like employees.

Research from arXiv formalizes this idea as Evaluation-Driven Development and Operations, or EDDOps. In this model, an agent registry is not a passive catalog, but an active control plane. Every transition — from draft, to approved, to published, to deprecated, to retired — is gated by evaluation evidence. Stale agents are automatically flagged for re-evaluation; failing agents are deprecated rather than left running indefinitely.

A complementary open-source reference architecture, AgentHR, extends the metaphor further: agent profiles, trust tiers, budgets, heartbeat scheduling, and even retirement workflows. The stack is not science fiction; it is HR logic mapped onto software.

4. The manager who should own agents

One of the most consistent findings across sources is that the wrong person usually owns agents today. Too often, agents default to the CTO’s organization because they are “technology.” But McKinsey argues the owner should be the business owner who uses the agent in a workflow — the head of finance for reconciliation agents, the head of customer service for support agents.

The PwC framework reinforces this: agent access should mirror workforce tiers, with role-based permissions, shorter permission windows, and continuous monitoring. A research agent should not inherit the same access as a workflow-orchestration agent, even if they serve the same employee.

Governance, in other words, should be federated to where the work happens, not centralized in a technology team that does not understand the business context.

5. Metrics that actually measure agent performance

“Adoption rate” is a poor proxy for value. What matters is whether the agent is creating the intended outcome over time. Neuralwired’s 2026 enterprise playbook proposes the Agent Performance Score, evaluating accuracy, autonomy, and adaptability on a quarterly cycle using API logs rather than surveys.

Adept.ai’s case study found that quarterly log reviews reduced performance drift and created audit trails for error liability. The IEEE showed that hybrid loops — agent completes task, automated risk scoring, human review above threshold — cut errors by 32% compared to fully autonomous deployments.

These are not theoretical gains. They are the result of treating agents as measurable assets rather than black-box tools.

6. The human side: cognitive load and anxiety

Deploying agents creates a people problem, not just a technology problem. McKinsey’s Kate Smaje notes that the highest users of AI are often the most exhausted: automation removes routine work, but leaves cognitively demanding judgment, decision-making, and difficult conversations. The workforce needs new skills, not just new tools.

There is also a cultural dimension. Forrester found that only 60% of organizations plan to implement agent performance evaluations by 2027. The rest are flying blind. Meanwhile, employees fear replacement, customers worry about data exposure, and regulators are beginning to classify enterprise agents as high-risk systems under frameworks such as the EU AI Act.

The organizations that navigate this best are the ones having open conversations about why AI is being deployed, what it will change, and how humans and agents will share accountability. The worst ones are the ones that skip the conversation and hope the technology will carry the transformation on its own.

7. What to do now

Inventory your agents. How many are running? Who owns each one? When were they last reviewed?
Assign accountability. Every agent needs a named human sponsor, usually the business owner who depends on it.
Build review cadences. Quarterly evaluation cycles, tied to evaluation evidence rather than vibes.
Govern access like identity. Agents need credentials, scoped permissions, and automatic expiration tied to role changes.
Plan for retirement. Agents should have a sunset condition. If an agent cannot justify its cost and value after review, deprecate it.
Train the humans. Managers need to understand what agents are doing well, where they drift, and how to interpret their outputs.

Sources

McKinsey — Your AI agents need performance management, too (McKinsey Talks Talent, Aug 2026)
PwC — AI agent governance for workforce use (Trust and Safety Outlook 2026)
arXiv — Registry-Governed Agent Lifecycle: EDDOps on AWS AgentCore (2607.00345)
arXiv/Implementation — A Governance-Layer Architecture for Human-Governed AI Workforces (Delwar, 2026)
AgentHR.tech — Open-source Agent System of Record (2026)
Neuralwired — Managing AI Agents: The 2026 Enterprise Playbook
IBM — IBM Manages 4,000 AI Agents Like Employees (Think 2026 / Beri)
Forrester — AI performance reviews and agent evaluation (Nov 2025 / 2026 HR playbooks)
Adept.ai — Enterprise agent deployment case study (Feb 2026)

Il rischio reale dell'AI enterprise non sono gli agenti autonomi. È la complessità tra di loro

Andrea Schiona — Fri, 28 Aug 2026 06:58:47 +0000

Il rischio reale dell'AI enterprise non sono gli agenti autonomi. È la complessità tra di loro.

Executive Briefing — Settembre 2026

Quando le aziende deployano fleet di agenti AI invece di sistemi singoli, il pericolo vero non è un agente che si mette a fare il matto da solo. È la complessità emergente delle loro interazioni: una ragnatela di chiamate a cascata, permessi dimenticati e gap di accountability che nessuna checklist può chiudere.

1. Il problema che nessuno vede arrivare

2. Perché le checklist non funzionano

Due modalità di guasto dominano.

3. Cosa dice la ricerca

Il lavoro accademico formalizza i failure mode:

Agent sprawl. Le piattaforme low-code rendono la creazione di agenti accessibile a tutti, producendo proliferazione non controllata di agenti ridondanti, frammentati e non governati tra team e funzioni.
Governance gap. Solo il 21% dei leader ha governance matura. Il divario tra velocità di adozione e prontezza di governance è netto.
Accountability diffusion. Nelle architetture multi-agente, la responsabilità si assottiglia lungo lo stack fino a concentrarsi di default sull'operatore enterprise, anche se quest'ultimo non aveva visibilità reale sulla catena decisionale.

4. La superficie d'attacco tra agenti

5. Cosa funziona davvero

Ma l'identity è necessaria, non sufficiente.

Le aziende serie su agent accountability hanno bisogno di entrambi. La maggior parte ha costruito solo il primo.

6. Il cammino

Risolvi la complessità e l'autonomia smette di essere il villain. Diventa il punto.

Fonti

VentureBeat — Enterprise AI's real risk isn't autonomous agents. It's the complexity between them. (Rory Blundell, Gravitee, 2026)
arXiv — Governing the Agentic Enterprise: A Governance Maturity Model for Managing AI Agent Sprawl in Business Operations (2604.16338)
arXiv — Who Governs the Machine? A Machine Identity Governance Taxonomy (MIGT) for AI Systems (2604.06148)
Arion Research — Orchestrating the Hybrid Workforce, Part 7: Orchestration Governance, Trust, and Accountability
arXiv — Semantic Consensus: Process-Aware Conflict Detection and Resolution for Enterprise Multi-Agent LLM Systems (2604.16339v1)
Lumenova AI — Taming Complexity: A Guide to Governing Multi-Agent Systems
Token Security — Collaborative AI Agents: Securing Multi-Agent Networks

Enterprise AI's real risk isn't autonomous agents. It's the complexity between them

Andrea Schiona — Fri, 28 Aug 2026 06:58:46 +0000

Enterprise AI's real risk isn't autonomous agents. It's the complexity between them.

Executive Briefing — September 2026

When enterprises deploy fleets of AI agents instead of single systems, the real danger is not a rogue agent. It is the emergent complexity of their interactions — a web of cascading calls, forgotten permissions, and accountability gaps that no checklist can fix.

1. The problem nobody sees coming

Enterprises do not deploy one agent and watch it run. They deploy fleets: support bots, retrieval agents, orchestration layers, each calling APIs, delegating to other agents, reaching into systems that were never designed for machine decision-makers. The failure mode that should keep you up at night is not a single agent doing something bad. It is a hundred agents doing exactly what they were built to do, all at once, in combinations nobody designed for.

Complexity does not grow linearly with agent count. Add a second agent and you add one connection. Add a tenth and you potentially add dozens, because any agent might call any other, and each call can trigger another somewhere else. A support ticket that used to touch one system might now pass through four agents before a human ever sees it. Every handoff is an undocumented decision point.

Most enterprise AI programs stall when the humans responsible lose the thread. Ask a security team which agents can reach which systems, and you get silence. Ask which agent triggered which downstream action three hops ago. More silence.

2. Why checklists fail

The instinct is to treat this like a compliance checklist. Approve the agent. Log the agent. Move on. But a checklist checks a single point in time. Complexity runs across a chain, and you cannot govern a chain with a stack of one-time approvals any more than you can call a diet successful because you had a vegetable once.

Two failure modes dominate.

Permissions creep. Somebody builds an agent to summarize support tickets and grants it broad API access because scoping it properly would have taken another sprint. Six months later, that same agent has a path into the payments system. Nobody remembers signing off on that. Nobody did.

Ownership thinning. Five agents touch one workflow, something breaks at step four, and now you are asking who is responsible for a link nobody was ever assigned to own. The org chart stopped at "deploy the agent" and never got to "name the human who answers for it."

This is a story about governance infrastructure that has not caught up with how agents actually behave: interconnected, cascading, multiplying faster than the processes built to track them.

3. What the research says

The problem is not theoretical. A 2026 survey of over 1,600 global business leaders found that 85% of enterprises aim to adopt agentic AI within three years, yet 76% acknowledge their operational infrastructure cannot support it. Only 21% have a mature governance model for autonomous agents. Gartner projects that 40% of agentic AI projects will fail by 2027 due to escalating costs, unclear business value, and inadequate risk controls.

Academic work formalizes the failure modes:

Agent sprawl. Low-code platforms make agent creation accessible to anyone, producing uncontrolled proliferation of redundant, fragmented, ungoverned agents across teams.
Governance gap. Only 21% of leaders have mature agent governance. The disconnect between adoption velocity and governance readiness is striking.
Accountability diffusion. In multi-agent architectures, responsibility thins across the agent stack until it concentrates by default on the enterprise operator, regardless of whether that operator had meaningful visibility into the decision chain.

A study on machine identity governance found that AI agents, service accounts, and API tokens now outnumber human identities in enterprise environments by ratios exceeding 80 to 1, yet no integrated framework exists to govern them. The consequences are measurable: a single ungoverned automated agent produced $5.4 to $10 billion in losses in the 2024 CrowdStrike outage.

Multi-agent LLM systems exhibit production failure rates between 41% and 86.7%, with nearly 79% of failures originating from specification and coordination issues rather than model capability limitations.

4. The inter-agent attack surface

Security research adds another layer. One study revealed that 82% of state-of-the-art AI models are susceptible to inter-agent trust exploitation, with an additional 41% vulnerable to direct prompt injection attacks. When agents operate in multi-agent architectures, they spawn subagents, delegate subtasks, and pass instructions and credentials through chains whose trust relationships are rarely cryptographically verified.

Agent-to-agent delegation is a potential accountability gap and a potential privilege escalation surface. Each delegation boundary is a place where an attacker can pivot, where a misconfigured permission can cascade, and where a semantic disagreement between agents can produce outcomes no single agent intended.

5. What actually works

Fixing the cluster starts with identity. Every agent needs to exist as its own entity, not a shadow permission borrowed from whoever deployed it. Its own name in the register. Its own scoped authority. A named human sponsor who answers for what it does.

But identity is necessary, not sufficient.

The harder piece is oversight that holds across the entire chain, not just at each individual link. You need to see what an agent did, what it set off downstream, and where that trail ends in real time, not in a report someone pulls together once a quarter. Get agent-level identity right and stop there, and you end up with a filing cabinet full of perfectly documented agents operating inside a system nobody can actually explain.

Oversight by itself only tells you what already happened. Watching a chain is not the same as controlling it. Enforcement is the piece most programs skip: the ability to stop an out-of-policy call before it executes, not just log it for someone to find in a review three weeks later. A dashboard that shows you an agent breached its scope five minutes ago is a monitoring tool. A system that stops the breach from happening in the first place is governance.

Enterprises serious about agent accountability need both, and most have only built the first.

6. The path forward

Complexity is not a reason to pump the brakes. The enterprises getting this right are not slowing down. They are building toward Human-Agent Harmony, where scale and accountability grow together instead of trading off against each other.

The real risk was never a single agent doing exactly what it was built to do. It is a hundred of them doing exactly that, all at once, interacting in combinations nobody designed for. That kind of multiplication is what keeps enterprise AI stuck running pilots forever instead of running production.

Solve for complexity and autonomy stops being the villain. It starts being the whole point.

Sources

VentureBeat — Enterprise AI's real risk isn't autonomous agents. It's the complexity between them. (Rory Blundell, Gravitee, 2026)
arXiv — Governing the Agentic Enterprise: A Governance Maturity Model for Managing AI Agent Sprawl in Business Operations (2604.16338)
arXiv — Who Governs the Machine? A Machine Identity Governance Taxonomy (MIGT) for AI Systems (2604.06148)
Arion Research — Orchestrating the Hybrid Workforce, Part 7: Orchestration Governance, Trust, and Accountability
arXiv — Semantic Consensus: Process-Aware Conflict Detection and Resolution for Enterprise Multi-Agent LLM Systems (2604.16339v1)
Lumenova AI — Taming Complexity: A Guide to Governing Multi-Agent Systems
Token Security — Collaborative AI Agents: Securing Multi-Agent Networks