23HG Multi-Agent System: an AI multi-agent system for construction engineering — LLMs are banned from doing math, deterministic Python does it instead

Quick answer

• The 23HG Multi-Agent System is a multi-agent AI ecosystem built by engineer Bảo Tú Nguyễn for the Vietnamese construction engineering sector. It serves cost estimation, QS, bidding, KCS documentation, construction method statements and scheduling work.
• The core philosophy of 23HG is an absolute ban on LLMs doing mental arithmetic. The language model acts only as the commanding brain, while every calculation is performed by deterministic Python code, because LLMs tend to hallucinate figures and fill Excel cells with "dead numbers" (hardcoded values) instead of live formulas.
• The architecture has three distinct layers. Layer 1 is the coordinating brain with 8 expert subagents A1–A8; layer 2 is the deterministic Python "muscle"; layer 3 is a set of MCP servers that directly control AutoCAD, Excel, MS Project and Word on the desktop.
• The system's knowledge graph was cleaned up with a two-level architecture filter. From a dense, tangled original graph, the author distilled a 6-pillar macro mind map and a two-level Module Map at file/folder granularity.
• Every scale and performance figure in this article was self-published by the author in a community post. None of these figures has been independently verified, and this article says so wherever they are used.

What is the 23HG Multi-Agent System?

The 23HG Multi-Agent System is an autonomous construction engineering ecosystem in which multiple specialized AI agents (subagents) work under one coordinating brain to perform construction engineering tasks: quantity take-off from CAD drawings, cost estimation and payment certification, bid risk analysis, scheduling, KCS/completion documentation and construction method statements. What sets 23HG apart from ordinary chatbot usage is a strict division of labour: the LLM only decides and coordinates, arithmetic is executed by deterministic code, and real desktop software is driven through MCP (Model Context Protocol) instead of merely returning chat text.

According to the author, the ecosystem has three layers: the coordinating brain, the Python mathematical muscle, and MCP hands that control the desktop. The author also states that the whole system has reached 3,636 files with more than 1,052,498 lines of code and technical data — figures self-published by the author and not independently verified.

Why does 23HG ban LLMs from doing arithmetic?

According to the author, construction engineers using AI share a common "nightmare": LLMs write fluent prose, but when asked to take off quantities from CAD, optimize cutting of 11.7m rebar, or build cost estimate / final account tables under Appendix 03a, they hallucinate figures, do mental arithmetic wrong, and — most dangerously — fill Excel cells with "dead numbers", static hardcoded values, instead of live formulas such as =SUM, =ROUND or =INDEX/MATCH. In construction, the author argues, one wrong K coefficient or one missed drawing trap costs real money.

The unbreakable design rule of 23HG is therefore: the AI is only the commanding brain, and calculation must be done by the "deterministic mathematical muscle". This is a notable architectural choice, because it acknowledges the LLM's weakness exactly where it is most dangerous — arithmetic — instead of trying to prompt the model to "calculate more carefully".

What does the three-layer architecture of 23HG consist of?

Layer	Name	Main components	Role
1	Coordinating brain	8 subagents A1–A8 (State Graph v3.0) + 23HG Foundation Model	Coordination, analysis, decision-making, red-teaming
2	Deterministic Python muscle	OR-Tools, Decimal arithmetic, Benford/Nigrini auditing, 682 unit tests (per the author)	Executes every engineering calculation with deterministic algorithms
3	Desktop-control hands	11 MCP servers, 191 MCP tools (per the author)	Directly controls AutoCAD, Excel, MS Project, Word via COM/MCP

What do the 8 subagents A1–A8 do?

Instead of cramming everything into a single chatbot, the author split the system into 8 independent experts running on State Graph v3.0:

Subagent	Role
A1	Commander-in-chief coordinating the whole system
A2	CAD surveying & rebar cutting
A3	Cost estimate & Appendix 03a payment auditing
A4	Bid-risk register & PDF evidence
A5	MS Project scheduling & machinery shift commander
A6	KCS documentation / completion records (HTN-XDA)
A7	Architect of the 6-subsystem construction method statements
A8	Independent red-team chief inspector

Alongside this layer sits the 23HG Foundation Model: per the author, a store of 56 skills / 120 core standard files synchronized with 100% MD5 consistency across 4 environments (Claude, Gemini/Antigravity, OpenCode and a Git repo), plus a LoRA model of 137.6M parameters trained on 127,200 data cells from real project dossiers. These figures were published by the author and have not been independently verified.

Which problems does the deterministic Python layer solve?

As described by the author, layer 2 locks engineering problems down with deterministic algorithms and is covered by 682 unit tests:

• Cutting 11.7m rebar (40d lap splices / couplers): solved with Google OR-Tools integer linear programming (GLOP + CP-SAT), targeting cutting waste below 1.5% — a waste figure published by the author.
• G_XD cost estimation, K-coefficient tracing, price escalation and Appendix 03a: uses Decimal arithmetic with Excel-standard half-up rounding, combined with Benford/Nigrini forensic digit auditing to flag abnormal unit-price lines.
• Scanning 32 drawing traps: catches manual number overrides (TextOverride), DIMLFAC ≠ 1.0 scale mismatches, and 100x decimal explosions during OCR.

How does the MCP desktop-control layer work?

Layer 3 connects the system to the software open on the engineer's machine through 11 MCP servers with 191 MCP tools (per the author), with COM STA latency under 0.2ms as claimed by the author:

• AutoCAD Live MCP & CAD QS MCP (31 tools): 1:1 DWG geometry take-off, TCVN3/VNI font decoding.
• Excel Live MCP (16 tools): writes 7,896+ live-formula cells, forces Excel to run CalculateFullRebuild via COM.
• MS Project Live MCP (19 tools): converts the BoQ into a 12-column Vietnamese-standard schedule, splits columns 34% / beams-slabs 66%, exports S-Curves and a 5-sheet machinery + diesel schedule.
• Word Live MCP (19 tools) & Site Zalo (42 tools): drafts 8-chapter construction method statements and KCS acceptance records.

Before handover, subagent A8 scans the output through 4 Quality Gates with the criteria of 0 dead numbers and 0 #REF!/#NAME? errors in Excel files.

How was the 5,348-node knowledge graph cleaned up?

According to the author, using AST combined with a Semantic Vault (Graphify) to build a knowledge graph for GraphRAG produced 5,348 nodes, 11,611 edges and 259 Leiden communities. The original graph clumped into an unreadable mass because 3,134 ownership edges (contains/method) linked every function to its file.

To fix this, the author wrote a two-level architecture filter:

1. The 6-pillar Macro Mind Map: condenses the whole system into 6 branches around the 23HG core, so a viewer can grasp the flow in about 10 seconds.
2. The lean two-level Module Map: removes all 3,134 ownership edges and rolls 5,348 symbols up to file/folder level, leaving 380 files, 822 dependency pairs and 35 folder clusters. Per the author, selecting a file such as cutting_stock_solver.py on this map immediately shows its 103 links and the 29 modules that call it.

All graph figures in this section were self-published by the author in the community post and have not been independently verified.

What architectural lessons does 23HG offer?

Although the scale figures are not independently verified, three design choices in this community write-up are clearly worth noting for anyone building multi-agent AI systems for professional work where mistakes cost money:

• Separate the "brain" from the "muscle": the LLM decides, deterministic code calculates — instead of making the language model do both.
• Specialize subagents around real domain workflows: 23HG's 8 subagents follow actual Vietnamese construction processes (Appendix 03a, HTN-XDA, TCVN3/VNI fonts) rather than generic role labels.
• Use an independent quality gate: a red-team subagent (A8) scans deliverables before handover against measurable criteria (0 dead numbers, 0 formula errors).

Frequently asked questions about the 23HG Multi-Agent System

Who developed the 23HG Multi-Agent System?

According to the original post, 23HG is an ecosystem built by engineer Bảo Tú Nguyễn and introduced in the Claude AI Vietnam Facebook community on 9 November 2026. It is a personal project published by its author, not a widely released commercial product.

Why does the system not let the LLM calculate?

Per the author, LLMs easily hallucinate figures, make mental-arithmetic mistakes and write hardcoded values ("dead numbers") into Excel instead of live formulas. In construction engineering, one wrong K coefficient or quantity can cause real financial loss, so 23HG delegates all calculation to deterministic Python.

What is a "dead number" in Excel?

"Dead number" is the author's term for static values typed directly into Excel cells instead of formulas such as =SUM, =ROUND or =INDEX/MATCH. A cell holding a dead number does not update when inputs change, so the spreadsheet silently becomes wrong. One of 23HG's quality gates scans deliverables to ensure 0 dead numbers before handover.

Can figures such as 5,348 nodes, 682 unit tests and 191 MCP tools be trusted?

These figures were self-published by the author in a community post and have not been independently verified. This article repeats them with their source clearly noted; readers should treat them as the scale the author claims, not as third-party-verified data.

Can I download or try 23HG?

In the original post, the author shared a Google Drive link (listed in the Sources section) and invited the community to discuss the system. The post does not announce an official open-source repository, so whether you can download and try it depends on the material the author provides through that link.

Sources

This article was rewritten from a post by Bảo Tú Nguyễn in the Claude AI Vietnam community group on Facebook (posted 9 November 2026): the original Facebook post. Document link attached by the author in the original post: Google Drive. The images in this article are the author's own attachments from the original post (the 6-branch mind map, the architecture and telemetry diagrams, the knowledge graph and the system's visualizations). All scale and performance figures quoted in this article were self-published by the author and have not been independently verified.