Headcounts are inventory style - to compare over time you are better off storing snapshots of the counts at regular intervals.  Doing the calculations logically won't give it to you and trying to nest some of the aggr rules (last, first, etc) in timeseries functions will be problematic.

Once you have a snap shot the AGO() works like a charm:  Date, HEADCOUNT, AGO(HEADCOUNT)

Use of information drives physical design ... so in your case you want to know a count at a particular point in time AND what it was at a referential point in time past.

To do this you need to take snapshots of the counts as they are - so then you can look back.  It is far to involved to be trying to look back in time to figure out what the count was at any point by starting with history and adding all the hires and removing the fires/transfers on every request.

Here's a good write up from Kimball on the types of fact tables:

http://www.kimballgroup.com/2008/11/fact-tables/

What you would need is a Periodic Snapshot Grain table.

To make this 'thinkable' -- I assume you look at your bank balance occasionally ... but to know what it was a few months ago you look at an old statement.  That statement is a periodic snapshot of your account at that time and you probably get one monthly.   You could take your own weekly snapshot of your account by printing the web page (or getting the ATM receipt) weekly - nonetheless those are snapshots. 

Your issue is solved with a physical structure not a logical one.