anchor.diff:  
   - when a job runs on an agent, the first step when putting together the environment happens in the job itself:
   
  -~~~
  -Job environment
  -~~~
  +### Job environment
   
   - a base environment is created for every job
   - this is environment that Buildkite returns if you look at a job using the REST API
  
positive.code: For a list of variables/flags you can set on your agent, see the [`buildkite-agent start` page](/docs/agent/cli-start).
  For a deeper look at what's involved in starting the agent, you can see the the [`buildkite-agent start` code on github](https://github.com/buildkite/agent/blob/master/clicommand/agent_start.go).
  
  ~~~
  Job is accepted by an agent
  ~~~
  
  copy in the job's environment from bk.com
  merge in some of the agent's env vars (i.e. not the registration token, it's given it's own access token)
  adds some new agent vars (describes the agent that the job is running in)
  vars to tell the bootstrap and other commands what to do
  bootstrap is started with the env supplied by the agent
  bootstrap adds its own env vars
  bootstrap runs all the hooks (plugin, environment etc.) 
  vars from hooks are merged in to the bootstrap env, these can override anything that exists in the env (be careful with these, they're powerful)
  
  Tada! This is the env your command runs in.
  
  If you change the env in the job script, it will only survive as long as the script is running. 
  
  
negative.code:   - env vars set in a trigger step end up as build-level env on the newly created build
    - NOTE: the 'all steps env' from the top of a pipeline.yaml isn't applied to trigger steps, the only env that applies to trigger steps is what you choose to set in that trigger step's `env` attribute (which ends up as build env in the new build)
  
  ### Agent environment
  
  Separate to the job's base environment, your `buildkite-agent` process has an environment of its own. This is made up of:
  - operating system environment variables 
  