The agent

The agent decides what to do. The sandbox, the data lake and the expertise packs are the environment it works in.

The loop

You describe an outcome. The agent plans the analysis, writes the SQL and Python to run it, executes 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.

The attached working is the design constraint. An answer that cannot be checked is not usable in a disclosure, so the working is a primary output rather than a debug view.

Rows never enter the token stream

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

This reduces cost and improves correctness. A model asked to read 40,000 rows will produce an inaccurate total. A model given a handle and asked 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 held in the environment, so code the agent writes cannot read them.

Each conversation gets its own persistent sandbox. Intermediate tables survive across turns, as they would in a notebook.

Expertise packs

Domain knowledge is loaded as expertise packs rather than written into a single prompt. Examples: what AASB S2 asks for, how NSW flood studies are structured, and which ACCU methods exist. With the flood pack loaded, the agent treats a flood planning area and a probable maximum flood extent as different layers.