Agent team: a Revit model from scans, IFC or plans

Nine specialised agents (Claude Code subagents, .claude/agents/) build one as-built Revit model together, led by a project manager and run by the workflow .claude/workflows/build-model.js (or by hand from the main session). Approved by the user on 17.10.2026: agent definitions plus a workflow, a separate checker, stairs with the load-bearing man.

The team

AgentFileJobDeliversIn Revit
Project managerproject-manager.mdplans the project, keeps the status board, decides at every gate, asks the user, writes the final reportstatus.md, gate decisions, report.mdno
Point cloud manpoint-cloud-man.mdchecks scans (format, coordinates, registration, density, coverage), thins, cuts vertical sections and slices, builds the storey plansinput report, slabs.json, storey plansno
IFC manifc-man.mdchecks the IFC (schema, units, georeferencing, storeys, counts, quantities), converts storey by storeyinput report, storey plansno
Plans manplans-man.mdchecks plans (DXF, PDF, raster; scale, units, layers, storeys), picks the route (own reader or plan-extract)input report, storey plansno
Structure manstructure-man.mdmerges the storeys into one plan, checks the heights, makes the levels and a floor plan per level, states survey point and true northplan.json, levels in Revityes
Family manfamily-man.mdbuilds and keeps the types: generic walls and floors (one layer, no material), door and window sizes; reports template problemsthe types in the model (stage types)yes
Load-bearing manloadbearing-man.mdwalls (straight and curved), floors, slab openings, stairs; later columns and beamsthe structure in Revityes
Fit manfit-man.mddoors and windows with their swing, room separation lines, rooms; later curtain walls, railingsthe fit-out in Revityes
Checkerchecker.mdchecks the model independently: Revit checks, the modelling guideline, the reference (IFC)check.md, defects per agentread only

Phases and gates

1. Intake (project manager): what is to be built, from which data, which reference; names the project folder; writes status.md. 2. Input check (point cloud man, IFC man, plans man; in parallel, only those with data): an input report each and the storey plans. Gate 1 (project manager, the user decides): data quality, coordinates, storey names and heights, and the modelling decisions (rule G-0.2): from the data found, the level of detail per element class, recorded in status.md (e.g. slabs as one element of their full thickness, split into structural slab and floor build-up only where sections or documentation give the build-up). 3. Structure (structure man): plan.json of all storeys, levels and plan views in Revit. Gate 2: levels at the planned heights, against the reference where there is one. 4. Families (family man): every type the plan needs, before anything is placed. 5. Load-bearing (load-bearing man). Gate 3: walls and floors generic, thicknesses, slab openings. 6. Fit-out (fit man). 7. Check (checker), report (project manager). Defects go back to the agent responsible; one round of fixes, then the project manager reports what is still open.

At every gate and in the report the project manager reads the project's scoreboard.md (below): what each agent did, the open findings by owner, the check score and what changed since the previous check.

Only one agent works in Revit at a time (one Revit, one model). The input men work in parallel.

Revit is reached through the pyRevit agent runtime (pyRevit 7, pyrevit mcp; setup in scan2revit/docs/AUTOTEST.md). A phase is one or more stages of the Revit module (scan2revit_build.run(doc, {"stages": [...]})), each one run_modify:

PhaseAgentStages
structurestructure manlevels
typesfamily mantypes (every wall, floor, door and window type the plan needs)
loadbearingload-bearing manwalls, floors, slab openings, stairs
fitoutfit manopenings (doors, windows, swings), room separations, rooms, existing (phase, measured / assumed)
checkcheckerthe model read back (run_query) and checked, a plan per level and a 3D view

Every stage deletes its own elements of an earlier run first, so an agent can rerun its phase after a fix.

Planned: review man (F26, not built yet)

A review man runs the review and correction loop: flagged items from the check, the deviation analysis (run by the checker, F25) and the fact review, the review page, the person's decisions applied to plan.json, the affected phases rerun, every loop on the scoreboard (deviation-and-review.md 5). Until it exists the project manager runs the loop by hand.

Planned: drawings first (F17 to F21, not built yet)

Decided on 24.10.2026 (decisions.md D-8 to D-10, plan in drawings-and-scans.md): when drawings and a scan of the same building exist, the plans man reads every sheet first into facts.json (phase 2a), the drawings are aligned to the scan frame (2c), a person decides the facts on a review page at gate 1, the builders use the accepted facts as priors (levels, one-sided wall thickness, slab thickness, opening heights, room names) and the checker compares drawn with measured. Until these tools exist the phases above stay as they are.

The project folder

Inputs lie by route in scan2revit/data/pointcloud|ifc|plans/<name>/ (git-ignored); the team works in scan2revit/data/projects/<project>/project/:

FileWho writes it
status.mdproject manager: plan, phase, gate decisions, open questions; the line synthetic: yes for a project from synthetic data only (its scoreboard may be published)
inputs/<agent>.mdinput men: the input report
storeys/<name>/plan.jsoninput men: one build plan per storey
plan.jsonstructure man: the merged plan of all storeys
model.rvt, revit.json, log.json, workspace/tools/revit_project.py (a copy of the template revit_test\blank.rvt; the runtime's workspace; every stage logged)
check.md, check.json, check/checker (through revit_project.py phase check; check.md says what changed since the previous check)
scoreboard.json, scoreboard.mdevery agent through tools/scoreboard.py; every phase of revit_project.py adds its own entry
handovers/<agent>.mdevery agent: done, open, files, rule proposals
rule-proposals.mdproject manager: the rule proposals of all handovers and the user's answer to each
report.mdproject manager: the final report

Scoreboard

scan2revit/tools/scoreboard.py keeps what every agent did and found, per project (scoreboard.json, schema scan2revit.scoreboard/1, and scoreboard.md):

Owners of failed checks, by the rule's section: 1 and 11 family man; 4 and 10 structure man; 5, 6 and 8 load-bearing man; 2, 3, 7 and 9 fit man (the stage existing is the fit man's); wrong input data the input man; G-13.2 (stage errors) the agent of the stage. check.md names the owner of every failed check.

Findings: who finds what, to whom it goes, how it is fixed

The agents do not contact each other: they run one after the other, and what they find travels on the scoreboard, in their handovers and in check.md. Every finding takes the same way:

1. Found: the agent who sees it files it (add, with severity, rule id and the owner it proposes). It goes to the project manager. 2. Forwarded: at the next gate, or in the fix round after the check, the project manager decides who has to act (the proposed owner, another agent, or the user) and forwards it (route). Decisions for the user go into the gate's questions. 3. Fixed: the agent it was forwarded to fixes it within its job (a Revit fix only by rerunning its phase) and says how (fix --how). Nobody changes tool code or another agent's work during a build: that is a finding for the project manager, and code changes go through development with review. 4. Confirmed: the checker reruns the check that found it and confirms the fix (verify), or reopens it, and it goes back to the project manager.

scoreboard.md shows the whole way of every finding ("Findings flow": found by, forwarded to, status, fixed by, how, confirmed by); documentation/agent-scoreboard.md (site page agents.html) sums it up per finder and owner and lists every finding of the synthetic projects. Findings filed before 25.10.2026 have no recorded way: they went from the checker to the owner it named, in the workflow's fix round.

Rule proposals

The modelling guideline changes only with the user's approval. An agent that finds a rule wrong, missing or unclear writes a proposal into its handover under the heading Rule proposals: the rule id (or "new, section n"), the proposed text, the reason with the project evidence. The project manager collects them into rule-proposals.md (one entry each: agent, rule, proposal, reason, the user's answer), asks the user at the next gate or in the report, and only an approved proposal goes into scan2revit/skills/modeling/SKILL.md (with its row in section 14, and the copy on the status site in step).

Tools

Rules for every agent