SQL Agent jobs are not contained within the Availability Group. When using SQL Agent jobs to manipulate a database within an Availability Group, there are all sorts of special considerations that need to be taken, particularly related to failover.
What happens if the job is running during failover? The job will likely fail, as the replica it is running on is now a non-writable secondary, and probably needs to be re-run on the now-primary replica. What if a job has been created, but not started when there is a failover?
What happens if a row is inserted, then immediately updated? The two SQL Agent jobs would have a dependency in the order in which they run. This is an issue with using SQL Agent jobs in general, regardless of whether an AG is part of the equation, but would be exacerbated if the initial
INSERT were "lost" in a failover.
Additionally in your specific scenario, you will be generating one SQL Agent Job per insert/update/delete. SQL Agent will only start one job per second. This means you will have a self-imposed limitation of one insert/update/delete operation per second. This will be a serious scalability issue, in addition to the headaches of job management.
Instead, have your CRUD procedures insert directly into the Service Broker Queue. The process to enqueue a message for Service Broker will likely perform much better than creating a SQL Agent job (but I've not tested it to give specific numbers). The Service Broker queue is contained within the database, so you do not have to worry about messages being "lost" in a failover.
If you need to do data manipulation, that can be done from within your Service Broker queue before additional processing/sending is done. Because that manipulation is being done within the Service Broker, it would all be asynchronous to your CRUD operations.
Using SQL Agent jobs for your scenario should not be necessary at all.