Use a launch agent. All other methods will kill your mind with many useless details and hidden tricks. In general, this is a very difficult task with many angular enclosures, and it is very difficult to implement properly. The launch agent allows you to focus on your task and save a lot of time.
The best solution for you is to rewrite the agent so as not to use the command line, but connect to the launchd daemon and request the correct parameters / settings.
If this is impossible or difficult, you can write a shell-to-shell agent, which at startup will connect to the daemon, ask for parameters, and then run the original agent with the appropriate command line.
If you think that it is too difficult to implement the "connect to daemon" mechanism ... maybe this is so, but it is much easier than starting the agent in another session from the daemon (if implemented correctly with support for various angular cases).
But if you really, really-not what you want in a dirty way, you can play with "launchctlbsexec". Some examples that work: Starting / stopping the launch agent for all users with GUI sessions (instead of loading “launchctl load”, it can run any executable in the context of the session).
Some updates about this.
From "play with launchctl bsexec", I mean something like this:
ps aux | grep loginwindow | grep user | awk '{ system("sudo launchctl bsexec "$2" sudo -u user /Applications/TextEdit.app/Contents/MacOS/TextEdit") }'
Find some application in the session that you want, take its PID and call "launchctlbsexec" to launch what you want in the same session. The example above will launch TextEdit in the user input session, even if this line is executed under a different user account or from a service.
But I tested it on Lion - it does not work. It only works for Leopards (10.5 / 10.6) for me. What I tried to say - not using launch agents will cause constant pain in your ass and nothing more. After a dozen such things, we switched entirly to launch agents and are now happy :)