Who this is for, and what they want
You lead an office fit-out on three floors of an existing building. The client comments on every issue, so the drawings go out as Rev A, come back with mark-ups, go out again as Rev B, and so on. Each time you need the same things: a dimensioned plan of every floor, the quantities (areas by room type, desks, chairs, doors), a clear account of what changed since the last issue, and the confidence that you can put the previous revision back on the table exactly as it was sent.
This article follows one such cycle on a fictional building, Marlow House, for a fictional client, Fenwick Partners. The project lead never drew anything by hand: every step is one prompt to their own AI agent (Codex), which works in Laydyne over MCP while the Studio is open in the browser.
What they had
- Laydyne Studio open in a browser tab, and Codex connected to it over MCP. Nothing here needs Pro: modelling, checks, drawings, design options, browser saves and the change log are on the Free plan (Pro adds simulation runs, the built-in AI and cloud saving).
- A brief in words: three floor plates of 30 × 20 m, 3.6 m floor to floor, a core with two lifts, a stair and toilets against the north wall, and the rooms wanted on each level.
- No drawings to start from. The agent assumed furniture and partition sizes and recorded them as assumptions.
The flow
You write the prompts and pass on the client's comments; the agent calls Laydyne's tools, writes the files and checks its own work; Laydyne keeps the layouts, the saved versions and the change log, and draws the sheets. One revision cycle is eleven steps, from the brief to the marked PDF that goes with Rev B.
Step by step
The prompts below are the ones that were sent, word for word. Times and token counts are from Codex's own log of each run (codex exec --json).
1. Build the three levels
I'm the project lead on an office fit-out and I want to manage the drawings in Laydyne. Please set up the project in the Laydyne Studio I have open, as a new project called "Marlow House — office fit-out, levels 1–3". The building is existing: three identical floor plates, 30 m east–west by 20 m north–south, 3.6 m floor to floor. The core is the same on every level, against the north wall in the middle, about 9 × 6 m: two lifts, a stair and toilets. Connect the three levels with the stair and the lifts. […] Level 1: a reception desk facing the entrance, a waiting area with 6 chairs, two 6-person meeting rooms in the south-west corner, an open work area with 24 desks and chairs, and a print/copy point. Level 2: […] 48 desks and chairs in clusters of 6, four meeting rooms […] Level 3: […] 36 desks and chairs, a 14-person boardroom, two 6-person meeting rooms and a quiet room. Enclose the rooms with glazed partitions and give each room a door. Make every room a named zone tagged with its room type […] Run check_space on all levels and fix what it finds, then show me each level in 2D and tell me what you assumed.
The agent wrote all three floors as one change set (apply_changes, checked with a dry run first), connected them with the stair and both lifts, ran check_space on every level until it reported nothing, and looked at each plan before answering. 220 seconds, 24 Laydyne calls.
2. Issue Rev A
Please issue the drawings as Revision A: first issue to the client for comment, dated today. The client is Fenwick Partners (attn. their facilities manager).
- Save the current layout in Laydyne as a design option called "Rev A".
- Save the project in the browser, so that we can always go back to exactly what was issued.
- Produce the drawing set as one PDF with a dimensioned sheet per level (get_view_image with delivery: true, format "pdf", planLayout "sheets"), save it in this folder as MH-FO-RevA.pdf and check its SHA-256.
- Take off the quantities with get_space_quantities and write MH-FO-RevA-quantities.csv: area per room type for each level and in total, and the number of desks, chairs and doors per level and in total.
- Start an issue register, ISSUE-REGISTER.md: revision, date, purpose, recipient, each file with its SHA-256, and the Laydyne space hash of what was issued.
Tell me whether the sheets themselves show that they are Revision A.
The agent froze the layout as a design option, saved the project in the browser, wrote the PDF, the quantities (Rev A quantities CSV) and the register, with the space hash fnv1a-d542089b of what was issued. Its answer to the last question was honest: no. The title block carried the date and the space hash, but nothing said "Rev A".
3. Put the revision on the sheets
We added this to Laydyne between the runs: get_view_image now takes revision {label, date, description, previous} and prints "Rev A" beside the date and a small revision table, without touching the model. Then the same request went to the agent:
I'd like the sheets themselves to show that they are Revision A. If Laydyne can print the revision in the title block, please re-issue MH-FO-RevA.pdf that way (Rev A, today's date, "First issue for comment"). The model must stay exactly what we issued, so check the space hash against the register, then update ISSUE-REGISTER.md with the new PDF and its SHA-256.
The agent found the new field on its own, checked that the space hash was still fnv1a-d542089b and re-issued the set. The first attempt printed "Rev Rev A", because the agent passed "Rev A" as the mark; Laydyne now prints the mark once whichever way it is written, and the same level sheets now also list the room areas.
4. Apply the client's comments
Fenwick Partners have commented on Rev A. Please make these changes in the Laydyne Studio:
- Level 1: move the partition between the two meeting rooms 1.2 m so that one of them becomes a 10-person room; add chairs to suit.
- Level 1 reception: turn the reception desk to face the lifts instead of the entrance, and enlarge the waiting area to 10 chairs.
- Level 2: replace the two desk clusters nearest the east wall (12 desks and chairs) with two 6-person meeting rooms, glazed, each with a door.
- Level 3: add a row of 4 phone booths along the south wall of the core.
Don't change anything else. Run check_space on all levels, fix any new findings, and show me the changed levels in 2D. Don't issue anything yet. […]
Four clusters were equally close to the east wall, so the agent chose the northern two and wrote that down as an assumption. It previewed each edit before applying it, turned the furniture of the narrowed meeting room to clear the new partition, and finished with no findings on any level. 220 seconds, 27 calls.
5. Issue Rev B
Please issue Revision B: Fenwick Partners' Rev A comments incorporated, dated today, for approval. Do it the same way as Rev A (see ISSUE-REGISTER.md in this folder): save the layout as design option "Rev B", save the browser project again so that it replaces the saved one and the Rev A save stays as an earlier version, make MH-FO-RevB.pdf and MH-FO-RevB-quantities.csv, and add Rev B to the issue register.
Replacing the browser save kept Rev A as version 1 and Rev B as version 2 of the same project. Every sheet of the new set lists both revisions (Rev B quantities CSV).
6. Show exactly what changed
For the Rev B transmittal I need to show the client exactly what changed between Rev A and Rev B:
- compare the two revisions with compare_design_options and give me the change table;
- the quantities before and after: area per room type, desks, chairs, doors and phone booths per level, with the difference;
- for each changed level, the plan with the differences marked (get_view_image with diff from Rev A to Rev B), saved in this folder as PNG.
Also draw the same difference from the browser save of Rev A to the browser save of Rev B and tell me whether it agrees with the design-option comparison. Write it all up in MH-FO-RevB-changes.md.
compare_design_options returned 26 added · 12 removed · 25 moved · 32 changed parts (Level 1: 8 · 0 · 13 · 19; Level 2: 14 · 12 · 12 · 13; Level 3: 4 · 0 · 0 · 0). The browser saves gave the same counts on every level. The agent also flagged a subtlety itself: on Level 2 the comparison pairs the removed task chairs with the new meeting chairs by position and reports them as moved, although they were removed and added.
| Totals | Rev A | Rev B | Difference |
|---|---|---|---|
| Desks | 108 | 96 | −12 |
| Chairs | 184 | 192 | +8 |
| Doors | 25 | 27 | +2 |
| Phone booths | 0 | 4 | +4 |
| Open work area (m²) | 630.85 | 595.25 | −35.60 |
| Meeting rooms (m²) | 276.80 | 310.34 | +33.54 |
| Waiting (m²) | 49.00 | 53.90 | +4.90 |
| Floor area (m²) | 1,800.00 | 1,800.00 | 0.00 |
The same comparison is also in the Studio: History → a saved point → Show on plan.
7. Who changed what, and when
Before this step the project lead renamed the zone "Print / copy" to "Print / copy / post" by hand in the Studio.
Someone on the team asked who changed what on this project and when. From Laydyne's change log, give me the history of the project: when each change was made, whether it came from the Studio screen, an AI agent over MCP or Laydyne's built-in AI, and what it touched, grouped into before Rev A was issued and between Rev A and Rev B (the issue register is ISSUE-REGISTER.md in this folder). Also list the saved versions of the browser project and the design options. Write it to HISTORY.md.
The change log held 9 entries: 8 from the agent over MCP and 1 from the Studio screen, each with its time, the floors it touched and counts of what was added, removed or changed. The agent grouped them around the two issues and listed the hand edit separately, because it came after Rev B. It also said what the log cannot tell: who the person was.
8. Reopen Rev A exactly as issued
In tomorrow's meeting the client wants to look at Rev A again exactly as it was issued. Open Rev A from the browser save we made when we issued it, check that it is the issued Rev A (compare its space hash and quantities with ISSUE-REGISTER.md in this folder), and show me levels 1 and 2 in 2D. Then go back to Rev B as the current work, and make sure the browser project still has Rev B as its latest version.
The agent opened version 1 of the browser save: space hash fnv1a-d542089b, 108 desks, 184 chairs and 25 doors, as in the register. It drew the plans with the Rev A title block and then opened Rev B again. The hand edit made in step 7 was not lost: opening a save first keeps the current work as a separate copy, and the agent said so. 80 seconds, 10 calls.
9. One marked PDF for the transmittal
The client would rather have one PDF than loose PNGs. Please make MH-FO-RevB-changes.pdf: the Rev B sheets, one per level, with the changes from Rev A marked on each sheet and Revision B in the title block (with Rev A listed below it). Check that each sheet's legend matches that level's changes in MH-FO-RevB-changes.md, then add the PDF and its SHA-256 to the Rev B entry in ISSUE-REGISTER.md.
The first time, the agent did not call Laydyne at all: it stitched the PNGs from step 6 into a PDF with its own tools and drew its own title block over Laydyne's ("title block added locally"). Laydyne could already mark the differences on a PDF set, but the tool description did not say so, and each sheet's legend counted the whole building. We fixed both and asked again: this time one Laydyne call produced the marked Rev B set (3 pages), each legend counting its own level.
Results and numbers
Codex (codex-cli 0.160.1, model gpt-6-astra at low reasoning effort, as configured) ran each step as a fresh session in an empty folder outside any repository, against a local Studio. The table lists the runs the article shows.
| Step | Time | Input tokens (of which cached) | Output tokens | Laydyne calls (refused) |
|---|---|---|---|---|
| 1. Build the three levels | 220 s | 747,303 (684,288) | 6,458 | 24 (2) |
| 2. Issue Rev A | 134 s | 694,298 (607,744) | 3,453 | 8 (0) |
| 3. Revision on the sheets | 140 s | 567,274 (480,000) | 1,734 | 3 (0) |
| 4. Client comments | 220 s | 1,270,522 (1,192,576) | 4,787 | 27 (1) |
| 5. Issue Rev B | 131 s | 732,329 (661,760) | 3,686 | 13 (0) |
| 6. What changed | 171 s | 755,640 (683,264) | 5,037 | 11 (2) |
| 7. History | 144 s | 432,328 (390,912) | 3,445 | 7 (0) |
| 8. Reopen Rev A | 80 s | 480,800 (416,256) | 1,135 | 10 (0) |
| 9. Marked PDF | 120 s | 744,573 (669,824) | 2,346 | 3 (1) |
| Total | 1,360 s (22 min 40 s) | 6,425,067 (5,786,624) | 32,081 | 106 (6) |
- 90.1% of the input tokens were cached: the agent re-reads its own conversation and the tool list at every turn.
- The 6 refused calls changed nothing: 3 times the tab was busy because the agent sent calls in parallel, once a reachability check listed more than 20 targets, once an edit used a field that edit does not take, and once the agent asked for the second piece of a PDF without repeating the settings of the first (that message now says so).
- Steps 3 and 9 were each run twice; the table shows the second run. The first runs (87 s, and 242 s with no Laydyne call) are described in their sections.
What came out: two PDF sets, two quantity CSVs, a change report, a marked PDF for the transmittal, an issue register and a project history, with Rev A and Rev B kept as design options and as two versions of one browser save.
What it cannot do yet
- An issue register. Laydyne does not record what was sent to whom and when. The agent kept ISSUE-REGISTER.md itself, with the files' SHA-256 and the space hash.
- A full audit trail. The change log says Studio, MCP agent or built-in AI, not which person. Its entries give floors and counts, not which parts or fields; to say what the hand edit changed, the agent compared it with the saved Rev B. When an earlier version is opened, the log becomes that version's log, and the later entries stay only in the copy kept before opening.
- Revisions across computers. Browser saves keep the last 5 versions in that browser, and a project holds up to 10 design options. Cloud saves are not reachable over MCP, so a colleague reopens Rev A only from a project file you send.
- Revision clouds. Changes are marked with dashed, filled and arrowed outlines and counted by part. There are no clouds with a revision triangle, and a part replaced by a similar one nearby can appear as "moved".
- Names chosen once stay. In step 1 the agent named the floors "Level 1 — first issue"; every later sheet repeats it. The agent guidance now says to keep revision words out of names.
- History after a reload. After the browser tab is reloaded, the History dialog lists the browser versions again only once the project is saved or opened.
- Areas are from the drawn outlines; nothing here checks building regulations, and every size the agent assumed is an assumption until measured.
Try it yourself
Open Laydyne Studio, connect your AI over MCP, and start with:
Use the Laydyne tools on the Studio I have open. Build [your floors and rooms], with every room a named zone tagged with its type, run check_space on all levels and fix what it finds. Then issue it as Revision A: save the layout as design option "Rev A", save the project in the browser, make one PDF with a dimensioned sheet per level (get_view_image with delivery: true, format "pdf", planLayout "sheets" and revision {label: "A", date, description}), write the quantities from get_space_quantities to a CSV, and start ISSUE-REGISTER.md with each file's SHA-256 and the space hash. When I send comments, apply only those, issue Rev B the same way (replace the browser save so Rev A stays as its earlier version), and show me what changed with compare_design_options and a PDF of the plans with the differences marked (diff from Rev A to Rev B, with revision B and A in the title block).