As an agent is standing on a plot of ground (cell), and wishes to move to a neighboring cell, it will need to know things about the area it's traversing. Some things, like difficulty of traversing, can be deduced by knowledge of the slope and vegetation type; a grassy field is easier to cross than a fir stand or a lake, and traveling along or down a slope is easer than going up a slope. Additionally, traveling through a burning or recently burned area may be impossible. All of these attributes of the cell can be retrieved through a simple query from the firefighter agent. The translating of landscape attributes into costs of traversal is a well-established technique in sptial models.
In the GIS-CA libraries, since the agent is directly associated with the cell on which s/he is ``standing'', querying the state of the cell or the neighboring cells is a trivial matter. Through the hierarchy described above, every object knows its relationship to other objects through embedded functions. While it's technically possible to code an agent that carries around a list of the cells upon which it's standing and the immediate surroundings, there is no need. If the agent wishes to know the state of a fuel component in the cell to its north, it simply passes the request to ``it's'' cell, the cell passes the request to the cellsurface to find it's northern neighbor, the cellsurface passes the request to the neighboring cell, the cell passes the request to ts fuel component, and the fuel component responds. The chain of communication is hidden from the agent making the request (and to the modeler writing the code for the request); all the agent knows is that it's getting information from ``it's'' north. A rudimentary action that would be a nightmare of subroutines in FORTRAN or C becomes a simple request in an object-oriented structure.
For the agent to modify the state of a cell (it's ``own'' cell or a neighboring cell), the actions are similar. The agent passes a request to the object for it to modify itself, and the cell compli (or doesn't, as per its internal state). Thus, to simulate an agent with a firehose, one would have the agent send a message to a neighboring cell requesting that it increase its moisture corresponding to the amount of water that is being sprayed on it.
The firefighters in this simulation are managed by a linked list. At each time step, a message is sent to every member of the list to ``step''. To have firefighters and their landscape coupled into a single virtual world, one only needs to associate the firefighters with locations on the world. As the simulation runs, one needs to ensure that the firefighters and the cell-objects are all recieving instructions to update themselves (do things) at the appropriate time intervals. As this typically involves tens of firefighters and tens of thousands of cells acting in (virtual) parellel, the need for proper list management and scheduling is crucial. These aspects are handled directly from Swarm's list managers and schedulers. Lists are created, and the scheduler is simply told to send a ``step'' request to the landscape (who forwards the requests to its cells), and to every member of the firefighter list.