The problem is execution context and mach bootstrap in OS X (more info on Apple documentation worth reading). You need to simulate execution from proper context. In OS X it's done using launchctl bsexec command. From TheDarkKnight's answer to Starting/stopping a launchd agent for all users with GUI sessions you have:

Unload Agents

#!/bin/bash
for id in `ps aux | grep -v grep | grep MyAgent | awk {'print $2'}`
do
    launchctl bsexec $id launchctl unload /Library/LaunchAgents/myAgent.plist
done

Replace MyAgent with the name of your Launch Agent.

Load Agents

#!/bin/bash
for pid_uid in $(ps -axo pid,uid,args | grep -i "[l]oginwindow.app" | awk '{print $1 "," $2}'); do

    pid=$(echo $pid_uid | cut -d, -f1)
    uid=$(echo $pid_uid | cut -d, -f2)

    launchctl bsexec "$pid" chroot -u "$uid" / launchctl load /Library/LaunchAgents/myAgent.plist
done

On OS X 10.11 and Later

From the comment by vrrathod about OS X 10.11, El Capitain, use:

launchctl bootstrap gui/$uid /Library/LaunchAgents/myAgent.plist

Assuming your launchd job is correctly set-up, you may be reaching a limitation of AppleScript.

AppleScript Requires a GUI (Aqua Session)

If your AppleScript is launched using launchd as a user root process, it will not have a graphical user interface associated. The majority of AppleScript requires a graphic user interface to work consistently. Depending on the version of OS X, it may work, but it is not designed to.

Processes on OS X can not trivially cross between user sessions.

Do Shell Script

A more robust approach is to separate out the functionality needing higher privileges into a shell script such as bash, perl, ruby, or python.

Your AppleScript can then call that script using AppleScript's do shell script:

do shell script "command" user name "me" password "mypassword" with administrator privileges

If you need to avoid embedding a username and password, this is possible but beyond the scope of this question.