Not with a strategy document, and not with a model comparison. With one job.
The job to pick is the one where most of the elapsed time is spent on something a model can do well and a person can check quickly. On an agency delivery team that turned out to be diagnosis: reproducing and locating a reported problem, which is where the hours went, rather than writing the fix, which is where the consequences live. The output is evidence a developer reads, so the existing review step does not have to move, and there is no new process to sell to anyone.
Before the job runs, decide who may approve what, and make that decision structural rather than a line in a prompt. On my own systems that is a database trigger; on a team it can be as small as "the agent opens the pull request and never merges it". Then name the receipt: the file, the row or the comment that proves the job happened, so that a finished model turn is never mistaken for finished work.
Run it once with someone watching. The first run is the specification, and it is where you find out what the job actually needs. Only after it has produced its receipt does it get a schedule.
Then the second job, chosen the same way. The teams that get stuck are the ones that tried to start everywhere at once, or that started with the most interesting problem rather than the most expensive one.
My own answers, from my own work. They change when the work does.