anchor.diff:  
   To function, an <<agent,_agent_>> is deployed on systems that one might want to
   investigate. Once deployed, each system becomes a GRR <<client,_client_>> and
  -they can start receiving <<message,messages>> from the frontend servers. Each
  -message tells the client to run a specific <<client_action,_client action_>> and
  +they can start receiving <<_message_,messages>> from the frontend servers. Each
  +message tells the client to run a specific <<client-action,_client action_>> and
   return the results. A client action is simply some well known code the agent
   knows how to execute (such as obtaining the list of files in a directory or
   reading a buffer from a file).
  
positive.code: on the server side and the client doesn't have any state at all, they naturally
  survive reboots while processing is taking place.
  
  Now, whether you've been following the <<_getting_started,'Getting started'>>
  chapter or not, as long as you have a client communicating with the server you
  can already check some flows in the GUI. While having selected a client in the
  GUI, click on the 'Manage launched flows' link on the left panel.  This will
  
negative.code: This <<flow,_flow_>> is running on a client because a user initiated it. To do
  so, he probably used the web-based Graphical User Interface (GUI), which allows
  a GRR user to start flows for clients and review the results. Or he could also
  have used the text-based <<the-console,_console_>> to do the same.
  
  Any flow that can be run on a single machine can also be run as a Hunt. A hunt
  allows running a flow on all, or any subset of machines talking to the GRR
  