You could convert either mechanism into an event driven system by using a named system semaphore,

Your super agent would create the named semaphore and then wait on it.

Your other code puts the information required by the super agent into a "known place"; whether that is a db table or the file system; and then signals (posts) the semaphore to tell the super agent it has work.

A perhaps simpler mechanism would be to have the super agent listen on a port. The other code delegates work to it by writing the details of the task to that port; and the tcp stack does the queuing.

The downside is that work items aren't persistent across system failures. The upside is work items aren't persistent across system failures.

Low utilization:
Requests are sufficiently infrequent that tasks complete before the next comes in. Agent is initiated for each new task and goes away when it is done, thus it only performs a query at the frequency of requests.

High utilization:
Requests come in faster than they can be completed. Agent is initiated by the first request of the cluster, and only once. For a file-based agent, main loop can look like:

while(my @list = `ls -t`) {
    chomp @list;
    for my $file (@list) {
        open my $fh, '<', $file or log_it_somehow;
        execute_json(<$fh>);
        close $fh;
        unlink $file;
    }
}
[download]

Between the two cases, the agent is only running when there is need and there is no busy-wait. If you wanted to use a database rather than the file system, there's nothing fundamental to change to the algorithm. It's the idea of initiating on request that moves this into event driven space. You can certainly use a framework, but this is simple enough that a framework is probably overkill.