Profilo del cliente
Il cliente è un tecnico CAD o un professionista della pianificazione urbana inserito in una società di consulenza per infrastrutture di trasporto — in genere un’azienda da 20 a 100 persone che gestisce la documentazione di planimetrie per strutture di trasporto come terminal bus, stazioni ferroviarie e hub di interscambio. Il suo lavoro quotidiano consiste nel mantenere e verificare disegni CAD che alimentano computi metrici, pratiche autorizzative e pacchetti di consegna agli appaltatori.
Nella maggior parte delle aziende di queste dimensioni non esiste un software dedicato all’analisi semantica dei file DXF. Il tecnico lavora in AutoCAD o in un visualizzatore compatibile, navigando tra la visibilità dei layer e le finestre di dialogo delle proprietà dei blocchi per contare manualmente gli oggetti. Quando un disegno è ben strutturato — con blocchi riutilizzabili e nominati per ogni tipo di arredo o veicolo — il conteggio è noioso ma gestibile. Quando invece la geometria è stata esplosa o le convenzioni di naming dei blocchi sono incoerenti tra discipline, l’audit diventa un lavoro soggetto a errori che può occupare un’intera giornata e lasciare comunque l’analista incerto sulla correttezza dei numeri finali.
Problema
Il disegno oggetto dell’audit era una planimetria DXF multi-zona del layout terrestre di un terminal bus. Conteneva oggetti appartenenti ad almeno sei categorie funzionali: auto gialle in un parcheggio a raso, sedie e tavoli in una zona food court, autobus nella corsia di stazionamento e un layer di vegetazione sul lato destro della planimetria, suddiviso tra alberi grandi e piccoli cespugli.
In apparenza sembrava un normale computo quantitativo. In pratica, il disegno presentava due problemi strutturali che rendevano inaffidabile un approccio diretto basato sul conteggio dei blocchi.
Primo, i veicoli gialli nella zona parcheggio erano stati esplosi invece di essere inseriti come blocchi riutilizzabili. Quello che in un disegno ben organizzato sarebbe stato 33 simboli di veicolo esisteva invece come 7,504 entità linea individuali, 4,778 entità arco e 67 entità cerchio — per un totale di 12,349 primitive distribuite sul layer vehiculos. Non c’era alcun riferimento di blocco da contare; l’analista doveva dedurre il numero di veicoli da proxy geometrici, in particolare i 67 marcatori circolari delle ruote, e applicare un fattore di correzione per i veicoli parziali o tagliati sul bordo del disegno.
Secondo, i simboli di arredo e di attività umana nella zona del terminal non condividevano alcuna convenzione di naming affidabile. Una prima passata di classificazione aveva identificato 60 istanze del blocco A$C206D7EC0 come sedie candidate e 11 istanze del blocco A$C05075C2A come tavoli candidati. Entrambi i conteggi erano errati: l’ispezione visiva ha rivelato che il primo blocco era un simbolo di porta o di apertura dell’anta, posizionato sul layer piso, e il secondo era un simbolo di figura umana — nessuno dei due era arredo. Le vere sedie della zona pranzo erano un blocco diverso (0Q62D sul layer mobiliario), per un totale di 36 istanze. I veri candidati a tavolo erano soltanto 4 oggetti dopo aver rimosso i simboli umani e di porta.
Ogni errore di classificazione richiedeva un ciclo completo di nuova verifica: identificare l’ID del blocco, controllare il layer, esaminare la geometria nel contesto, aggiornare il conteggio e rigenerare l’output dell’audit. Eseguire questi cicli manualmente — caricando filtri, rigenerando set di selezione, esportando sotto-disegni — è il tipo di lavoro CAD iterativo che consuma ore senza alcuna garanzia che la risposta finale sia difendibile.
Perché ora
I progetti di infrastrutture di trasporto sono soggetti a requisiti documentali per fasi. Quando un terminal bus passa dallo sviluppo progettuale alla documentazione esecutiva, il team di progetto deve fornire un elenco quantitativo verificato al cost estimator e, se sono coinvolti fondi pubblici, all’autorità approvante. Un tipo di oggetto classificato in modo errato — porte conteggiate come sedie, vegetazione confusa con parcheggi strutturati — genera errori a valle nelle stime dei materiali, nei calcoli di esodo antincendio e nei budget di progetto.
In questo caso, l’audit era un prerequisito per la consegna della documentazione. Il disegno era evoluto attraverso contributi di più discipline, ed è così che il naming dei layer era diventato incoerente e la geometria dei veicoli era finita esplosa. Il tecnico aveva bisogno di un conteggio finale affidabile prima che il file venisse congelato e rilasciato per la costruzione.
Perché energent.ai
Le alternative del tecnico erano limitate. Il conteggio manuale dei blocchi in AutoCAD richiede di impostare filtri di layer, eseguire comandi di conteggio e verificare manualmente ogni risultato — un processo che scala male quando gli ID dei blocchi sono stringhe hash semanticamente prive di significato come A$C206D7EC0. Scrivere uno script Python personalizzato usando una libreria di parsing DXF era tecnicamente possibile, ma richiedeva tempo di sviluppo che il team non aveva e avrebbe prodotto uno strumento una tantum senza alcun ciclo interattivo di riclassificazione.
Energent.ai offriva un modello diverso: un agente conversazionale in grado di caricare direttamente il file DXF, eseguire comandi Python e bash per analizzare la geometria, produrre file DXF di audit filtrati come output e iterare sulla logica di classificazione tramite correzioni in linguaggio naturale. L’analista non doveva scrivere codice. Quando un conteggio era sbagliato, la correzione era una sola frase — "those are door symbols, not chairs" — e l’agente rieseguiva la classificazione, escludeva il blocco conteggiato erroneamente e produceva un file di audit corretto nella stessa sessione.
In modo cruciale, energent.ai genera file di output intermedi — un DXF per ogni categoria di oggetto — che il tecnico può aprire nel proprio visualizzatore CAD esistente per una verifica visiva prima di accettare il conteggio. Questo ha chiuso il ciclo tra analisi automatizzata e approvazione umana in un modo che uno script standalone o una dashboard BI non possono replicare.
Workflow
Step 1 — Caricamento del file e analisi dei layer. Il tecnico ha caricato il DXF del terminal bus. L’agente ha analizzato i nomi dei layer (vehiculos, mobiliario, piso, BUSES, vegetacion) e gli ID dei blocchi, producendo un inventario preliminare dei tipi di entità distinti e dei conteggi per layer.
Step 2 — Isolamento dei veicoli. L’analista ha chiesto il conteggio delle auto gialle nella zona parcheggio in alto a sinistra. L’agente ha identificato che il layer vehiculos non conteneva inserimenti di blocchi — solo geometria esplosa di linee, archi e cerchi per un totale di 12,349 primitive. Ha isolato le 67 entità cerchio come marcatori delle ruote e ha stimato 33 veicoli assumendo due cerchi-ruota per auto, con un marcatore parziale sul bordo del disegno. Ha prodotto un DXF di audit dedicato per la verifica visiva e ha segnalato la stima come derivata dalla geometria, non dal conteggio dei blocchi.
Step 3 — Classificazione dell’arredo, prima passata. L’agente ha identificato i blocchi di arredo candidati nella zona centrale sinistra del terminal e ha restituito 60 istanze di un blocco come sedie e 11 di un altro come tavoli. L’analista ha esaminato il DXF di audit e ha corretto la classificazione: il blocco da 60 conteggi era un simbolo di porta o di apertura dell’anta sul layer piso; il blocco da 11 conteggi era una figura umana. Nessuno dei due doveva comparire nel conteggio dell’arredo.
Step 4 — Riclassificazione dell’arredo, passata corretta. Applicando le correzioni basate sul contesto della forma, l’agente ha rieseguito la classificazione. Ha mantenuto il blocco 0Q62D sul layer mobiliario come 36 sedie da pranzo e ha identificato 4 candidati a tavolo (blocchi dfy e SofaA2C) dopo aver escluso tutti i simboli di porte e figure umane. Ha prodotto DXF di audit separati per le sedie da pranzo, i candidati tavolo e entrambe le categorie escluse, consentendo all’analista di confermare ogni esclusione in modo indipendente.
Step 5 — Autobus e vegetazione. L’agente ha identificato 41 simboli di autobus sul layer BUSES e, sul lato destro del disegno, ha distinto 5 blocchi di alberi grandi da 46 simboli di piccoli cespugli, producendo un DXF di audit nominato per ciascuna categoria.
Step 6 — Pacchetto finale di audit. L’agente ha assemblato la tabella finale completa dei conteggi, ha prodotto un DXF completo del disegno con attribuzione e ha generato un riepilogo Markdown in linguaggio naturale adatto all’inclusione nel pacchetto di documentazione del progetto.

Results
L’audit ha prodotto conteggi verificati per sei categorie di oggetti all’interno di un disegno che non presentava alcuna convenzione affidabile per la denominazione dei blocchi e un tipo di oggetto completamente esploso:
| Object | Final count |
|---|---|
| Yellow cars (geometry-estimated) | 33 |
| Dining chairs | 36 |
| Table-like furniture candidates | 4 |
| Buses | 41 |
| Large trees | 5 |
| Small bushes | 46 |
Tre errori iniziali di classificazione sono stati individuati e corretti: 60 simboli porta/oscillazione pavimento inizialmente etichettati come sedie della fila terminale, 11 simboli di figura umana inizialmente etichettati come tavoli e simboli di vegetazione che nella prima passata erano stati confusi con il layer dei veicoli. Ogni ciclo di correzione ha richiesto un singolo scambio conversazionale anziché una passata completa di riesame manuale.
L’agente ha prodotto 11 file DXF di audit denominati — uno per ciascuna categoria di oggetti più due file di verifica delle esclusioni — insieme a un riepilogo completo in Markdown, sostituendo quello che sarebbe stato un foglio di calcolo per il conteggio manuale con una traccia di audit verificabile, file per file, che qualsiasi membro del team può aprire e controllare.
Proof
"Il disegno era passato attraverso tre discipline e i nomi dei blocchi erano completamente opachi. Non avevo modo di sapere che A$C206D7EC0 fosse un simbolo di porta senza aprire ogni istanza singolarmente. Quello che mi ha dato energent.ai è stata la possibilità di dire 'questo non torna' e ottenere un file corretto in pochi secondi, invece di passare un’altra ora nel layer manager."
— Tecnico CAD, consulenza per infrastrutture di trasporto
Il deliverable prodotto dall’agente — il riepilogo Markdown bus_terminal_dxf_tldr.md e l’intero set di DXF di audit per categoria — può essere aperto in qualsiasi visualizzatore compatibile con DXF e confrontato con il disegno originale. Il DXF dell’intero disegno con attribuzione incorpora direttamente nel file la provenienza dell’audit, rendendo l’output tracciabile per i registri di progetto.
Trust note
Il conteggio delle auto gialle pari a 33 è una stima geometrica, non una certezza basata sul conteggio dei blocchi. Poiché i veicoli sono stati disegnati come primitive esplose anziché come inserti riutilizzabili, il conteggio si basa sull’assunzione che ogni auto contribuisca esattamente a due marker circolari delle ruote al totale di 67 cerchi. Prima di usare questo numero in un computo metrico ufficiale o di presentarlo a un’autorità di regolamentazione, è necessaria un’ispezione visiva del DXF di audit dei veicoli isolati rispetto al disegno originale. Allo stesso modo, le candidate per l’arredo simile a tavoli rappresentano la geometria sopravvissuta dopo il filtraggio di esclusione; un esperto di dominio dovrebbe confermare ogni istanza rispetto all’intento architettonico prima che il conteggio sia considerato definitivo. L’output di Energent.ai accelera il ciclo di audit e mette in evidenza le classificazioni errate che i metodi di conteggio manuale mancano regolarmente, ma non sostituisce l’approvazione finale del tecnico sulle classificazioni ambigue.
