I didn't even know about CONTEXT_INFO! Depending on what you are doing, you might look into CLR triggers, as the string manipulation would be much easier (er...any kind of parsing would be much easier). The major limitation I see with it is that it is only 128 bytes of info. If that works, great. My users want comments though.
In my auditing design, I have two tables, one is the master audit history table, containing the table, ID, User name, date, type and comment of any change. The other table stores the old and new values of any changed fields. I use three sprocs to manage this. One is the master sproc that saves an audit record about any change, i.e. table being changed, ID of changed row, user name, date and a comment about the change. Then I have a sproc that saves away the old values and one that saves the new values. I use CodeSmith to manage the last two (it builds the sprocs for me, so when I change a table, I don't have to manually go update the old/new value sprocs). Then I have a base BO that manages the extra data needed for auditing and manages calling the sprocs appropriately during save/update/delete.
Let us know how using the CONTEXT_INFO goes. I'm going to look into this more myself.