The agent

The agent is the part that decides what to do. Everything else is the environment it does it in.

The loop

You describe an outcome. The agent plans the analysis, writes the SQL and Python to get it, runs that in a sandbox with the data lake mounted, inspects the results, and either continues or corrects itself. It reports the answer with the code and the datasets attached.

That last part is the design constraint everything else follows from. An answer you cannot check is worthless in a disclosure context, so the working is a first-class output rather than a debug view.

Rows never enter the token stream

Query results do not get pasted back into the model's context. They are registered in a data reference store and the agent receives a summary plus a handle — row count, column types, a few aggregate statistics. Follow-up steps operate on the handle.

This is partly cost and partly correctness. A model asked to eyeball 40,000 rows will hallucinate a total; a model handed a handle and told to write SELECT SUM(...) will not.

The sandbox

Analysis runs in a container with Python, DuckDB, Polars and PyArrow, and no credentials. Secrets are injected at an egress proxy rather than being present in the environment, so code the agent writes cannot exfiltrate them even if it tries.

Each conversation gets its own persistent sandbox, so intermediate tables survive across turns the way they would in a notebook.

Expertise packs

Domain knowledge — what AASB S2 asks for, how NSW flood studies are structured, which ACCU methods exist — is loaded as expertise rather than baked into a single prompt. It means the agent knows that a flood planning area is not the same thing as a probable maximum flood extent, and behaves accordingly.