Customer profile
The customer is a CAD technician or urban planning professional embedded in a transportation infrastructure consultancy — typically a firm of 20 to 100 people that manages site-plan documentation for transit facilities such as bus terminals, rail stations, and interchange hubs. Their day-to-day work involves maintaining and auditing CAD drawings that feed quantity surveys, permit applications, and contractor handoff packages.
In most firms of this size, there is no dedicated software for semantic parsing of DXF files. The technician works in AutoCAD or a compatible viewer, navigating layer visibility and block property dialogs to manually tally objects. When a drawing is well-structured — with named, reusable block inserts for every furniture or vehicle type — counts are tedious but tractable. When geometry has been exploded or block naming conventions are inconsistent across disciplines, the audit becomes error-prone work that can consume a full day and still leave the analyst uncertain whether the final numbers are correct.
Problem
The drawing under audit was a multi-zone DXF site plan of a bus terminal terrestrial layout. It contained objects across at least six functional categories: yellow cars in a surface parking area, dining chairs and tables in a food-court zone, buses in the vehicle bay, and a vegetation layer on the right side of the plan split between large trees and small bushes.
On the surface this sounds like a standard quantity takeoff. In practice, the drawing had two structural problems that made a straightforward block-count approach unreliable.
First, the yellow vehicles in the parking zone had been exploded rather than placed as reusable block inserts. What would have been 33 vehicle symbols in a well-organized drawing instead existed as 7,504 individual line entities, 4,778 arc entities, and 67 circle entities — a total of 12,349 primitives spread across the vehiculos layer. There was no block reference to count; the analyst had to infer vehicle count from geometric proxies, specifically the 67 wheel-circle markers, and apply a correction factor for partial or clipped vehicles at the drawing boundary.
Second, the furniture and human-activity symbols in the terminal zone shared no reliable naming convention. An initial classification pass identified 60 instances of block A$C206D7EC0 as candidate chairs and 11 instances of block A$C05075C2A as candidate tables. Both counts were wrong: visual inspection revealed that the first block was a door or floor-swing symbol placed on layer piso, and the second was a human-figure symbol — neither were furniture. The true dining chairs were a different block entirely (0Q62D on layer mobiliario), totalling 36 instances. The true table-like furniture candidates numbered only 4 objects after the human and door symbols were removed.
Each misclassification required a full re-inspection cycle: identify the block ID, check the layer, examine the geometry in context, update the count, and regenerate the audit output. Running those cycles manually — loading filter dialogs, regenerating selection sets, exporting sub-drawings — is the kind of iterative CAD work that consumes hours with no guarantee the final answer is defensible.
Why now
Transportation infrastructure projects are subject to phased documentation requirements. As a bus terminal moves from design development into construction documents, the design team must supply a verified quantity list to the cost estimator and, where public funding is involved, to the approving authority. A misclassified object type — doors counted as chairs, vegetation conflated with structured parking — creates downstream errors in material estimates, fire-egress calculations, and project budgets.
In this case, the audit was a prerequisite for a documentation handoff. The drawing had evolved through multiple discipline contributions, which is how layer naming became inconsistent and vehicle geometry ended up exploded. The technician needed a reliable final count before the file was frozen and issued for construction.
Why energent.ai
The technician's alternatives were limited. Manual block counting in AutoCAD requires setting layer filters, running count commands, and manually verifying each result — a process that scales poorly when block IDs are semantically meaningless hash strings like A$C206D7EC0. Writing a custom Python script using a DXF parsing library was technically viable but required developer time the team did not have and produced a one-off tool with no interactive reclassification loop.
Energent.ai offered a different model: a conversational agent that could load the DXF file directly, execute Python and bash commands to parse the geometry, produce filtered audit DXF files as outputs, and iterate on classification logic through plain-language correction. The analyst did not need to write code. When a count was wrong, the correction was a single sentence — "those are door symbols, not chairs" — and the agent re-ran the classification, excluded the miscounted block, and produced a corrected audit file within the same session.
Critically, energent.ai generates intermediate output files — one DXF per object category — that the technician can open in their existing CAD viewer to visually verify before accepting the count. This closed the loop between automated analysis and human sign-off in a way that a standalone script or a BI dashboard cannot replicate.
Workflow
Step 1 — File upload and layer survey. The technician uploaded the bus terminal DXF. The agent scanned layer names (vehiculos, mobiliario, piso, BUSES, vegetacion) and block IDs, and produced a preliminary inventory of distinct entity types and counts per layer.
Step 2 — Vehicle isolation. The analyst asked for a count of yellow cars in the top-left parking zone. The agent identified that the vehiculos layer contained no block inserts — only exploded line, arc, and circle geometry totalling 12,349 primitives. It isolated the 67 circle entities as wheel markers and estimated 33 vehicles on the assumption of two wheel-circles per car, with one partial marker at the drawing edge. It produced a dedicated audit DXF for visual verification and flagged the estimate as geometry-derived, not block-count-derived.
Step 3 — Furniture classification, first pass. The agent identified candidate furniture blocks in the middle-left terminal zone and returned 60 instances of one block as chairs and 11 of another as tables. The analyst reviewed the audit DXF and corrected the classification: the 60-count block was a door or floor-swing symbol on layer piso; the 11-count block was a human figure. Neither should appear in the furniture count.
Step 4 — Furniture reclassification, corrected pass. Applying the shape-context corrections, the agent re-ran the classification. It retained block 0Q62D on layer mobiliario as 36 dining chairs, and identified 4 table-like furniture candidates (blocks dfy and SofaA2C) after excluding all door and human-figure symbols. It produced separate audit DXFs for the dining chairs, the table candidates, and both excluded categories, allowing the analyst to confirm each exclusion independently.
Step 5 — Buses and vegetation. The agent identified 41 bus symbols on layer BUSES and, on the right side of the drawing, distinguished 5 large tree blocks from 46 small bush symbols, producing a named audit DXF for each category.
Step 6 — Final audit pack. The agent assembled the complete final count table, produced an attributed full-drawing DXF, and generated a plain-language Markdown summary suitable for inclusion in the project documentation package.
Results
The audit produced verified counts for six object categories across a drawing that contained no reliable block-naming convention and one fully exploded object type:
| Object | Final count |
|---|---|
| Yellow cars (geometry-estimated) | 33 |
| Dining chairs | 36 |
| Table-like furniture candidates | 4 |
| Buses | 41 |
| Large trees | 5 |
| Small bushes | 46 |
Three initial misclassifications were caught and corrected: 60 door/floor-swing symbols initially tagged as terminal row chairs, 11 human-figure symbols initially tagged as tables, and vegetation symbols that had been conflated with the vehicle layer during the first pass. Each correction cycle took a single conversational exchange rather than a full manual re-inspection pass.
The agent produced 11 named audit DXF files — one per object category plus two exclusion-verification files — alongside a full Markdown summary, replacing what would have been a manual tally spreadsheet with a traceable, file-by-file audit trail that any team member can open and verify.
Proof
"The drawing had been through three discipline hands and the block names were completely opaque. I had no way to know A$C206D7EC0 was a door symbol without opening every instance individually. What energent.ai gave me was the ability to say 'that looks wrong' and get a corrected file back in seconds rather than spending another hour in the layer manager."
— CAD technician, transportation infrastructure consultancy
The deliverable the agent produced — the bus_terminal_dxf_tldr.md Markdown summary and the full set of per-category audit DXFs — can be opened in any DXF-compatible viewer and cross-referenced against the original drawing. The attributed full-drawing DXF embeds the audit provenance directly in the file, making the output traceable for project records.
Trust note
The yellow car count of 33 is a geometric estimate, not a block-count certainty. Because the vehicles were drawn as exploded primitives rather than reusable inserts, the count rests on the assumption that each car contributes exactly two wheel-circle markers to the 67-circle total. A visual inspection of the isolated vehicle audit DXF against the original drawing is required before this number is used in an official quantity survey or submitted to a regulatory authority. Similarly, the table-like furniture candidates represent surviving geometry after exclusion filtering; a domain expert should confirm each instance against the architectural intent before the count is treated as final. Energent.ai's output accelerates the audit cycle and surfaces misclassifications that manual tally methods routinely miss, but it does not replace the technician's sign-off on ambiguous classifications.