The architecture of eValid is very simple: you control it and your read its outputs via simple text files. The input test script file and all of the output event logs as well as any special output your test script generates are all delivered to simple files, located in a working folder of your choice.
If you have two (or more) eValid copies working, then they can communicate between each other via writing and reading from script files.
There is a simple "mutual exclusion" (mutex) operator pair of commands, Lock/Unlock, which can coordinate two (or more) eValid copies so that one can be writing/reading and the, later, the other can be reading/writing. And back and forth.
This applies in both functional testing as well as load testing scenarios.
It is also possible, inside an eValid script, to invoke some OTHER communications method, using the SystemCall/SystemCallWait commands. Here we decided (on purpose!) not to invent anything, but to allowe eValid to use whatever method YOU want to use. Some of these include (but are not limited to) ftp access to/from files, remote procedure calls, use of shared filesystems (disks), and even HTTP/S if you wish.
The main point is, yes, they can communicate and yes, eValid provides the primitives needed to support coordination, and yes, eValid gives you access to the Windows enviornment so you can get the needed cooperation done with the minimum of effort.