Describe a scene in English; get physics back.

Authoring a sonar scene means knowing what a plausible seafloor looks like, which objects belong on it, and which imaging geometry will actually see them. That is a narrow expertise, and it is the reason most people who want synthetic sonar data never generate any. Studio removes the requirement: you describe the scene, an agent builds it, and the real simulator runs on a real GPU.

Preview the terrain before you spend the GPU.

A full simulation is minutes of GPU time; a heightmap preview is tens of seconds. Studio renders the terrain first, marks the band that the sonar will actually image, and says plainly when the thing you asked for falls outside it. You correct the scene in conversation, and only then does anything expensive run.

The agent is not guessing at a schema. It reads the same scene definition the simulator does, runs the same validator that blocks a bad run in the desktop app, and reports failures as failures rather than quietly producing something else.

The Studio interface: a conversation on the left where the agent describes boulders and trawl grooves it has placed, and a heightmap preview on the right with a dashed line marking the along-track band the sonar will image

The preview step. The dashed line marks the imaged along-track band; here the agent has noticed that only part of the boulder outcrop falls inside it, and offers to move it before anything is simulated.

The same products a local run produces.

When the scene is right, the job goes to the GPU and comes back as the full product set: the dynamic-range-compressed image for looking at, the complex SLC for processing, and the raw HDF5. Nothing about the output is a demo path; it is the same pipeline, the same formats, and the same imagery a local run of that scene file would produce.

Studio showing a finished synthetic aperture sonar image of a rippled seafloor with objects, alongside a product list offering full-resolution PNG, display JPEG, port image and HDF5 downloads

A finished run. The scene was specified in conversation; the image is point-scatterer physics on a HISAS 1030 geometry, 40 m along track by 200 m in range.

50 s

wall clock end to end for a 20 m scene at 200 scatterers per square metre, from sentence to image

docs/studio.md

20 tools

create, patch and validate a scene; paint zones; preview the heightmap; queue and watch a run; list, render and build 3D models; answer questions from the reference docs

Sandboxed by the harness, not by the prompt.

An agent that can run a simulator is an agent running code on a workstation, so the interesting engineering is in what it cannot do. It has no shell, and no ability to read, write, or edit files. It talks to exactly one in-process tool server. It loads none of the operator's own settings, hooks, or extensions.

Its documentation tool is the clearest case. Studio can answer questions about sonar theory and the scene schema because it can read the project's reference documentation, and only that: the lookup resolves the path first and then checks that the result is still inside the public reference directory, so no phrasing of a question reaches anything else in the repository.

None of this is enforced by asking the model nicely. It is the tool surface the model was given.

The constraint that matters is not what the agent is told to avoid; it is what it was never handed.