A clinic proposal from a text brief: layout, checks, a simulated morning and the drawings, through your own AI

A use case run on 2026-10-06 with Codex connected to Laydyne over MCP. The clinic, the brief and the numbers given to the simulation are fictional; every result below comes from the run logs (facts.json).

Who, and what they want

A small architecture and interior practice is preparing a first proposal for a doctor who is opening a neighbourhood clinic on the ground floor of an existing building. There is a meeting with the client next week. The practice wants to bring:

• a first layout that fits the brief and can be discussed,
• some evidence that it works: corridor widths, wheelchair routes, and how the waiting room copes with a busy morning,
• one alternative tried under the same conditions, with a reason to keep or drop it,
• a scaled drawing, room areas, and the options and their history kept for the meeting.

They do not drag furniture with a mouse. They write to their own AI (here Codex), and the AI works in the Laydyne Studio tab they have open.

What they had: a text brief

No drawings, no survey. The unit is 21 × 15 m with four columns that cannot move, a glazed street front and a service door at the back. The brief lists the rooms: four consultation rooms, a treatment room, an X-ray room with a control area, a staff room, an accessible and a standard WC, a waiting area for about 20 with two wheelchair spaces and a kids' corner, and a reception counter for two. The doctor also gave rough guesses for a Monday morning: about 24 patients an hour at opening, fewer later, two doctors, a few minutes per visit.

The flow

Six prompts, one Codex session each. The Studio tab holds the work between sessions (the project, its design options, the saved process options and the comparison), so each prompt only says what it wants next.

Step by step

1. From the brief to a first layout

I'm an interior architect preparing a first proposal for a new neighbourhood clinic. I only have the brief below, no drawings yet. Please build a first layout in Laydyne, in the Studio I have open (start a fresh project called "Linden Street Clinic").

The unit: ground floor of an existing building, a rectangle 21 m wide along the street (south side) and 15 m deep, clear height 3.0 m. Glazed shopfront on the street side with the entrance in the middle (1.8 m automatic sliding door). A staff/service door in the back (north) wall near the east corner. Four existing columns, 0.5 × 0.5 m, centred at x = 7 m and x = 14 m on the lines 5 m and 10 m back from the street front. They can't move.

Brief (2 doctors, 2 receptionists, 2 nurses, a part-time radiographer):

• Entrance with a wind lobby and room to park a wheelchair and a buggy
• Reception and payment counter for 2 staff, visible from the entrance and the waiting area
• Waiting area: about 20 seats, 2 wheelchair spaces, a small kids' corner
• 4 consultation rooms, about 3.0 × 3.6 m each: desk, doctor's chair, patient chair, exam couch, hand basin
• Treatment room about 4 × 4 m with 2 couches (injections, drips)
• X-ray room about 4 × 4.5 m with a small control area (shielding is the specialist's job, just note it)
• Staff room with lockers and a small kitchenette
• Toilets: one accessible WC (at least 2.0 × 2.0 m inside) and one standard WC
• Corridors at least 1.5 m wide for wheelchairs, doors at least 0.9 m clear

Lay out the walls, doors and rooms (label each room with a floor zone), place the main furniture, and show me the 2D plan and a 3D view. Tell me which sizes you assumed.

Codex created the project, wrote the walls, sliding doors, labelled zones and furniture as one change set of about 30 KB, tried it twice with apply_changes in dry-run mode, applied it, looked at the plan, fixed what check_space found (a chair in front of the X-ray control door, a narrow strip by the staff room) and drew the plan again. It listed what it assumed: consultation rooms 3.0 × 3.6 m, treatment 4.0 × 4.0 m, accessible WC 2.4 × 2.4 m, standard WC 1.8 × 2.4 m, a 4.2 × 2.8 m wind lobby, 1.0–1.2 m internal doors, 200 mm outer walls and 150 mm partitions.

169 parts on 315 m², in 469 seconds and 32 tool calls. One call failed (the same wall was in both update and remove of one batch) and was corrected in the next call.

2. Check it before anyone sees it

Before I show the clinic layout to anyone, please check it in Laydyne (the Linden Street Clinic is open in my Studio).

Run check_space and fix overlaps, passages narrower than 0.9 m and blocked doors. I also need the accessibility basics: corridors 1.5 m clear, a 1.5 m turning circle inside the accessible WC, and a wheelchair user able to get from the entrance to every consultation room, the treatment room, the X-ray room and the accessible WC (use a wheelchair-sized route check if Laydyne has one). Tell me plainly what Laydyne checked and what it cannot check (I will still do the code review myself).

When it is clean, save the brief with the project, save this layout as design option "A: shared reception counter", and save the project in the browser.

check_space started with 27 findings, all of them narrow gaps of 5–75 cm, mostly furniture standing a little off a wall. Codex moved them, then ran the route check with an agent 0.9 m wide (radius 0.45 m) from the entrance to the four consultation rooms, the treatment and X-ray rooms, the accessible WC and every door on the way: all 16 places were reachable. A second check with a 1.5 m circle confirmed the turning space in the accessible WC. It stored the brief and saved design option A (170 parts, 0 findings).

Codex was clear about the limits: these are geometry checks on the model, not a wheelchair's swept path, door operation, transfers, equipment access or code compliance.

What happened first. In the first run of this prompt Codex stopped before saving: three gaps beside the WC pans (0.25 m between the accessible pan and its side wall, which is where the grab rail must be) were reported as major narrow passages, with the hint to move the pan 0.65 m away from the wall. Codex asked whether to keep them as exceptions. Laydyne now treats a gap narrower than a person beside a toilet, urinal or basin as the fixture's side space, and its tools say that an option can be saved with findings that were reviewed. The run shown here is the same prompt after that fix.

3. Simulate the busy morning

Next I want to see how layout A copes with a busy morning, using Laydyne's process simulation. These numbers are the doctor's rough guesses, not measurements:

• Doors open 9:00, last check-in 11:30. Patients arrive at random: about 24 per hour from 9:00 to 10:00, 16 per hour from 10:00 to 11:00 and 10 per hour from 11:00 to 11:30.
• Everyone checks in at the reception counter (1 to 3 minutes), then waits in the waiting area.
• They see one of the 2 doctors in a consultation room: 4 to 12 minutes, usually about 7.
• About 20% then go to the treatment room with one of the 2 nurses (5 to 15 minutes).
• About 10% are sent by the doctor for an X-ray with the radiographer (5 to 10 minutes) and come back for a short second look by a doctor (2 to 4 minutes).
• Finally everyone pays at the same reception counter (1 to 2 minutes) and leaves. The 2 receptionists do both check-in and payment.

Run the whole morning several times and show me: the waits for check-in, for the doctor and for payment, the time from arriving to leaving, how busy each kind of staff is, and how many people are in the waiting area at the peak compared with the 20 seats. Save the setup and result as a process option for layout A so I can compare later. Say which inputs I should measure in a real clinic before trusting the numbers.

Codex read the process catalog, wrote the scenario (arrival profile 24/16/10 per hour, staff as resources, the consultation in one of two rooms with a doctor, weighted branches for treatment and X-ray, the walk between places in the plan), ran 20 mornings with the same seeds and saved it as a process option.

The doctors were busy 92 % of the time until the last patient left (Codex's measure; Laydyne's own comparison gives 52 % over the whole six-hour window, which includes the quiet end). Receptionists were at 39 %, nurses 22 %, the radiographer 17 %. The waiting area held 15.1 people at its peak on average, between 6 and 32; on 4 of the 20 mornings the peak passed the 20 seats, by 12 on the worst. The last patient left at 12:22 on average.

So the doctors are the bottleneck, and the waiting room is sized for an average morning, not a bad one. Codex listed what to measure before trusting this: real arrivals (including the queue at opening), consultation times and turnover, the treatment and X-ray shares, staff breaks and other duties, companions and seat use.

Codex sent five catalog reads at once; two were answered "busy" (the tab takes three at a time) and retried. 160 seconds, 22 calls.

4. Try option B under the same conditions

Let's try an alternative under exactly the same conditions as the morning run for layout A.

Option B: give payment its own window near the exit, so check-in and payment don't share one queue: one receptionist on check-in at the reception counter, one on payment at the new window. Change the layout for that (start from design option A), keep the corridors and accessibility as they are, run check_space, and save it as design option "B: separate payment window". Compare A and B with compare_design_options and tell me what changed.

Then run the same morning on B with the same arrivals, seed and number of runs, save it as a process option, and compare A and B with compare_process_options. The doctor also asked whether a fifth consultation room would help with only 2 doctors; answer that from the model too if you can. Tell me which differences are real and which are inside the noise.

Codex restored option A, added a payment window with a lowered counter by the exit lobby, shortened the check-in counter and moved one chair. compare_design_options: 2 parts added, 3 moved, 5 changed, 165 unchanged; 0 findings; all routes still reachable.

Then the same morning on B, same seeds (20261006–20261025), compared seed by seed:

Two receptionists who both check in and take payment form one pooled queue; split into two single-server queues, check-in waits grow and the time in the clinic does not change, because the doctors set it. B saves walking, not time. On the fifth room Codex answered from the model: the wait for a consultation room was zero in every run (the scenario pairs each of the two doctors with one of two rooms), so more rooms cannot shorten the doctor wait; it did not simulate a fifth room separately.

190 seconds, 20 calls, no failures.

5. The decision, and the detail

The doctor kept A. The next prompt:

The doctor read the A/B comparison and is keeping option A: one shared counter where both receptionists can check in and take payment. Please refine option A for the client meeting with the furniture, equipment and fixtures in every room. Start from design option A in Laydyne.

• Consultation rooms: desk, doctor's chair, patient chair, a chair for a companion, exam couch, hand basin, a cabinet
• Treatment room: 2 couches with curtains or screens, a trolley, a sink, cabinets
• X-ray room: the X-ray unit and table, a control desk behind a screen, note "shielding by specialist"
• Staff room: lockers, a table with chairs, kitchenette, fridge
• Reception: the counter with 2 workstations, a payment terminal, a cabinet for files
• Waiting area: the seats, 2 wheelchair spaces kept clear, kids' corner with a rug and a low shelf, plants, a water dispenser
• Toilets: WC, basin, and a note on grab rails in the accessible WC

Use the closest part Laydyne has where there is no exact one, and give each item a source ("assumed") and a short note where the client must confirm. Run check_space again and keep the corridors and wheelchair routes as they are. Show me a 3D view of the waiting area and of one consultation room, and save it as design option "A2: A with furniture".

Codex previewed the whole change first, added 19 parts and updated 82 (positions, sources, notes) in one edit, checked again (0 findings, routes kept) and saved option A2 with 189 parts. Laydyne has no medical parts yet, so it used the nearest: a bed for the exam couch, a machine for the X-ray unit and the water dispenser, a screen for the curtain, payment terminals for the workstations; each carries a note for the client.

144 seconds, 17 calls; one batch named a WC twice and was merged on the next call.

6. Hand over

Please prepare the pack for the client meeting from the Linden Street Clinic project and put the files in the current folder:

1. The scaled drawing set of option A2 as a PDF (get_view_image with delivery: true and format "pdf"; join the pieces and check the SHA-256).
2. Room areas and part counts from get_space_quantities, as a CSV.
3. A comparison handout of the design options A, B and A2 (get_design_packet, HTML), so the doctor can see why we kept A.
4. A backup of the whole project with export_project (it keeps the options and the process comparison).
5. Save the project in the browser too.

Then give me a short history of what changed since the first layout (from the project's change log), and list each file with what it is.

Files: the drawing (PDF, A3 at 1:100), room areas and part counts (CSV), an HTML handout comparing A, B and A2 (2.1 MB, kept in the run folder), and the project file with every option, the process options and the saved comparison. Codex checked each file against its SHA-256. 166 seconds, 13 calls.

The history was the weak point of this run: the change log at hand-over had only the last three entries, because restoring a design option started the log again. That is fixed now (a restore is the next line of the project's history); the saved points (browser saves and design options) were kept throughout.

Results and numbers

Codex used gpt-6-astra at low reasoning effort. 91.6 % of the input tokens were cached: each new session re-reads Laydyne's tool list (about 309,000 characters) and the earlier turns. All four failed calls were the agent's own (a part named twice in one batch, calls sent in parallel) and were recovered on the next call. The first, blocked run of step 2 took another 261 seconds and 23 calls. These are the agent's times; the time an architect spends reading and deciding is not measured.

What the practice takes to the meeting: a layout from a text brief with its assumptions listed, geometry and wheelchair-route checks, a simulated morning showing the doctors as the bottleneck and the waiting room's bad days, one alternative rejected for a stated reason, a furnished option, the drawing, areas and the project with every option.

What it cannot do

• No crowd physics. Waiting patients stand at one point; a 10:00 picture of the waiting area shows "×3" on one figure, not three people on three seats. Queues are counts and capacities, not physical lines; collisions and avoidance are not computed.
• No compliance or safety. Evacuation, fire and accessibility codes, radiation shielding, door operation and transfer space are not checked. The route check uses a circle 0.9 m wide, not a wheelchair's swept path.
• The inputs are guesses. Arrival rates and service times came from the doctor's rough estimates. The numbers compare A and B under the same guesses; they are not a forecast of a real clinic.
• Utilisation depends on its definition. Codex's 92 % (until the last patient left) and Laydyne's 52 % (over six hours) describe the same runs.
• No medical part library yet. Exam couches, the X-ray unit and the dispenser are generic parts with notes.
• Sizes are not measured. Every dimension is from the brief or assumed and marked so in the parts' notes.

Try it yourself

Open Laydyne Studio, connect your AI over MCP (see the manual), and start with your own brief:

I only have a written brief, no drawings. In Laydyne, in the Studio I have open, start a fresh project called "<name>" and build a first layout: the unit is <width> × <depth> m with <fixed elements: columns, entrance, service door>. Rooms: <list with approximate sizes and what goes in them>. Corridors at least <width> m, doors at least <width> m clear. Label each room with a floor zone, place the main furniture, run check_space and fix overlaps and narrow passages, then show me the 2D plan and a 3D view and tell me which sizes you assumed. Save it as design option "A".

Then continue with the checks, a process simulation (Pro) and a second option, as in steps 2–6 above.