# My AI Experience with the SUEWS-agent 1: From plain English to a climate simulation **URL:** \ **Category:** Show and Tell\ **Tags:** ai-agents\ **Created:** [18 June 2026 08:29 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107 "2026-06-18T08:29:03Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [18 June 2026 08:29 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107/1 "2026-06-18T08:29:03Z")
On 24 June 2026 we are running the [first SUEWS Community Hackathon](https://community.suews.io/t/suews-community-hackathon-re-imagining-cities-of-the-future-24-june-ucl-east/61) 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](https://github.com/UMEP-dev/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: ![05-energy-balance-diurnal.png](https://europe1.discourse-cdn.com/flex014/uploads/suews/original/1X/5211d4485985e6f01643c84790afa7d71d2a5d07.png) 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. ---
**Author:** ![farrahdingal](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/farrahdingal/32/73_2.png) [@farrahdingal](https://community.suews.io/u/farrahdingal)\ **Post date:** [22 June 2026 20:20 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107/2 "2026-06-22T20:20:07Z")
How can I get the tool calls for my own practice run? ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [22 June 2026 21:23 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107/3 "2026-06-22T21:23:16Z")
Good question, @farrahdingal. The tool calls are the structured SUEWS-agent actions that happened underneath the chat. In my run, those were the steps listed at the end of the post, for example: `list_examples` → `init_case` → `inspect_config` → `assess_readiness` → configuration edits → `validate_config` → run → `summarise_run` → `diagnose_run` You normally do not trigger each of these manually. The host agent, such as Codex or Claude Code, decides which SUEWS-agent tool to call as it works through the task. That is why this is worth checking: the final figure alone does not tell us whether the agent actually called `assess_readiness` before running the model. For your own practice run, the easiest thing is to go back to the same Codex thread and ask: > Please list every SUEWS-agent tool call you made in this practice run, in order. For each one, give the tool name, why it was called, and the short result. In particular, tell me whether you called `assess_readiness` before running SUEWS. If Codex still has the session context, it should be able to reconstruct the sequence. If it cannot, I would treat that as useful feedback too: it means the run is not auditable enough from the visible transcript. For the next run, you can make this explicit at the start: > Keep a tool-call log as you work. Each time you call a SUEWS-agent tool, write down the tool name, why you called it, and the result summary. Do not run SUEWS until `assess_readiness` and `validate_config` have both been reported. That log would help us see exactly where your run differed from mine. My suspicion is not that you personally did something wrong, but that the host agent may have gone straight from a valid sample case to running the model without stopping on readiness. That is precisely the kind of behaviour we want to catch and improve before the hackathon. ---
**Author:** ![farrahdingal](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/farrahdingal/32/73_2.png) [@farrahdingal](https://community.suews.io/u/farrahdingal)\ **Post date:** [23 June 2026 10:18 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107/4 "2026-06-23T10:18:14Z")
> [@sunt05](#): > > Please list every SUEWS-agent tool call you made in this practice run, in order. For each one, give the tool name, why it was called, and the short result. In particular, tell me whether you called `assess_readiness` before running SUEWS. Here is what the agent said: > For the **London Dense Residential Hot-Week Trial** , the answer is: > > **I made zero formal SUEWS-agent tool calls.** > That means I did **not** call: > | SUEWS-Agent Tool | Called For This Trial? | Result | > | --- | --- | --- | > | `list_examples` | No | Not used | > | `init_case` | No | Not used | > | `inspect_config` | No | Not used as an agent call | > | `assess_readiness` | **No** | **Not called before running SUEWS** | > | `validate_config` | No | Validation was done through the SUEWS command-line workflow, not logged as an agent tool call | > | `run` | No | The SUEWS model was run locally, not through a recorded agent tool call | > | `summarise_run` | No | I summarized outputs myself from the result files | > | `diagnose_run` | No | Diagnostics were run locally, not through a recorded agent tool call | > What I actually did for that trial was a **local SUEWS workflow** , roughly: > > 1. Used the bundled London/KCL sample case as the starting point. > 2. Edited the configuration to represent your dense residential neighbourhood: 40% buildings, 35% paved, 15% trees, 10% grass/gardens, 12 m buildings. > 3. Selected the hottest 7-day period from the bundled 2012 London forcing data. > 4. Ran SUEWS locally on that edited case. > 5. Ran validation/diagnostics locally. > 6. Analysed the output and made the figure and web page. > > So: **the model run exists, but the formal SUEWS-agent workflow evidence does not.** > > And to answer the key question plainly: > > **No, I did not call `assess_readiness` before running the London heat-risk trial.** > > For the hackathon, your correct workflow should follow Professor Sun’s pattern: > > `list_examples → init_case → inspect_config → assess_readiness → configuration edits → validate_config → run → summarise_run → diagnose_run` > > That is the sequence we should use for your real hackathon run. I then asked how the agent came up with the results and designed the website and everything else, without calling any of the agent tools: > That’s the key distinction: > > **SUEWS-agent tools are not the model itself.** > They are a structured assistant layer that helps choose examples, inspect readiness, validate, run, summarise, and diagnose. > > What I used was the **SUEWS model directly** , through the local command-line workflow, plus Codex’s normal file editing and analysis abilities. > > So the results came from real files, not from guessing: > > - Configuration: [london\_dense\_residential\_config.yml](/Users/farrahdingal/Documents/Codex/2026-06-10/you-re-helping-me-get-set/work/suews-hackathon-practice/analysis/london-dense-residential-hot-week/london\_dense\_residential\_config.yml) > - Model output: [KCL1\_2012\_SUEWS\_60.txt](/Users/farrahdingal/Documents/Codex/2026-06-10/you-re-helping-me-get-set/work/suews-hackathon-practice/analysis/london-dense-residential-hot-week/Output/KCL1\_2012\_SUEWS\_60.txt) > - Diagnostics: [diagnostics.json](/Users/farrahdingal/Documents/Codex/2026-06-10/you-re-helping-me-get-set/work/suews-hackathon-practice/analysis/london-dense-residential-hot-week/diagnostics.json) > - Written report: [HOT\_WEEK\_REPORT.md](/Users/farrahdingal/Documents/Codex/2026-06-10/you-re-helping-me-get-set/work/suews-hackathon-practice/analysis/london-dense-residential-hot-week/HOT\_WEEK\_REPORT.md) > - Web page: [docs/index.html](/Users/farrahdingal/Documents/Codex/2026-06-10/you-re-helping-me-get-set/work/suews-hackathon-practice/docs/index.html) > > In plain terms: I bypassed the **SUEWS-agent “guided workflow”** and drove the **SUEWS engine** myself. > > That is why we still have a figure, numbers, diagnostics, and a website. But we do **not** have the better audit trail Professor Sun is describing, where the assistant can prove: > > `list_examples → init_case → inspect_config → assess_readiness → validate_config → run → summarise_run → diagnose_run` > > The weak point is not “there was no model run.” There was a model run. > The weak point is: **the run was not auditable as a SUEWS-agent-assisted workflow.** > > For the hackathon, we should make this rule explicit at the start: > > > Do not run SUEWS until `assess_readiness` and `validate_config` have both been reported, and keep a tool-call log as you work. > > That will give you both the science output and the AI-collaboration evidence. In the hackathon, it might be helpful to come up with rules… My Guiding Rule: **Can someone judge the science, policy bridge, presentation, and AI collaboration from the public page and repo files?** ---
**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\ **Post date:** [23 June 2026 10:59 UTC](https://community.suews.io/t/my-ai-experience-with-the-suews-agent-1-from-plain-english-to-a-climate-simulation/107/5 "2026-06-23T10:59:28Z")
Farrah, this is a great thread to land on, thank you for digging into it so honestly. I want to add something for everyone reading along, because the workflow and the tool-call sequence have come up a few times now. We are deliberately not turning these into rules for the hackathon. The day is meant to be open exploration: bring your own question, try the tools, get things wrong, and learn as you go. The list\_examples to diagnose\_run sequence is a pattern some of us have found works well, and it is genuinely useful for keeping a run auditable, but please read it as a suggestion, not a checklist to obey. There is no single correct route, and I would much rather people experiment freely than follow a prescribed workflow. What is best here is that the good practice is being discovered by participants and shared, rather than handed down from the front of the room. That is exactly the spirit we are after. So please keep exploring in your own way, and keep sharing what you find, anything that is not private is very welcome on the forum. See you on 24 June.