On 24 June 2026 we are running the first SUEWS Community Hackathon at UCL East, where a room of people will drive an urban climate model entirely in plain language, working with an AI agent, no coding required.
As a warm-up, between 18 and 23 June 2026 I’ll share how I, an ordinary academic rather than someone in an AI lab, actually use AI agents in my work, and how our SUEWS-agent works through real cases. It is open on GitHub, so this is not only for hackathon participants; if you want to install it, try it, or follow the project, start from that repository. No hype, no jargon for its own sake. To start, let me walk you through one full session, exactly as it happened: what I typed, and what the agent did and said at each step.
Here is everything I gave it, in plain English:
I’m new to urban climate modelling. I’d like to look at a typical dense residential neighbourhood in London: roughly 40% buildings around 12 m tall, 35% paved streets and car parks, and the rest split between street trees and small gardens. Using SUEWS, could you set up this neighbourhood and run a short simulation for a hot summer week, then tell me what the surface energy balance looks like in plain terms?
No configuration files, no code. Within seconds, the agent had created a starter configuration from a bundled central-London example that ships with the model, and opened it up to inspect.
Then came the moment that made me trust it. Before doing anything with that starter, the agent ran its own readiness check, and the check stopped it:
“3 site-defining value group(s) are still the bundled sample’s defaults — replace them before trusting results for your site.” (ready: false)
In other words, the tooling itself refused to treat the sample as my neighbourhood, and would not pretend otherwise. That guardrail is built into the SUEWS-agent; I did not have to remember to ask for it.
So it rewrote the configuration to match my description: buildings up to 40% at a mean height of 12 m (down from the sample’s 22 m), paved down to 35%, street trees up to 15%, gardens to 10%, and the open water removed, with the surface roughness adjusted to suit the lower buildings. The seven surface fractions summed to exactly one. It then validated the configuration against the model’s own rules, not its own opinion, and that came back clean.
Here it did something I had not asked for, and got right. I had asked for a single week. Instead it announced:
Now let me run the full-year simulation (needed for spin-up) and then extract the hot summer week.
A climate model needs a run-in period before its soil moisture and heat stores settle, so a cold-started single week would be meaningless. It ran a full year, pulled out the hottest seven days (14 to 20 August 2012), and analysed those. The right call, made and explained on its own.
Here is the figure it produced:
And here is how it read that picture back to me, in plain terms:
The city is overwhelmingly hot and dry … 75% of the surface is sealed, so virtually none of the incoming energy is used to evaporate water.
The numbers behind that: the neighbourhood takes in about 94 W/m² of net radiation and adds 74 of its own from traffic, buildings and people. Of that, some 136 W/m² goes straight into heating the air and only about 13 into evaporation. The ratio of the two, the Bowen ratio, came out near 9; a green rural field in summer sits closer to 1 or 2.
One point of precision, since it is easy to overclaim. This is the surface energy balance: the accounting of where the incoming energy goes. That lopsided split is the engine behind urban warming, but the urban heat island itself is a temperature contrast you would only see by comparing this neighbourhood against a greener, rural site, which this single run does not do.
And it got something wrong. In its tidy closing summary, the location line read:
central London, 51.51°N, −0.12°E (same as the bundled King’s Cross dataset)
The bundled site is in fact KCL, King’s College London, not King’s Cross, a different part of the city a couple of kilometres north. It also brushed past one of its own diagnostic warnings a little too easily. I caught both because I read the output, which is the job. The agent removed the typing, not the responsibility.
That is the line worth drawing on day one. The agent does the plumbing: the configuration, the bookkeeping, the runs. The model does the physics: the same equations, the same code, the same science as ever. The human does the judging. What changed is not the science but the distance to it, from weeks of learning a configuration format down to a few minutes of plain language, with my attention freed for whether the setup and the answer actually make sense.
This is the first post in a short series building up to the hackathon, our first live community trial of the idea. Next I’ll step back and explain what an AI agent actually is, before returning to why we taught one to drive a climate model and what happened when people tried it for themselves.
The exact tool calls, in order
The agent’s own steps, start to finish: list_examples → init_case → inspect_config → assess_readiness → (configuration edits) → validate_config → run → summarise_run → diagnose_run. Session: Claude (Sonnet 4.6) + suews-mcp 2026.6.5, installed exactly as any public user gets it. 29 turns, 6 min 21 s end to end.