We need to fork the CI workflow that exists for x86 and target the workflow for a non-x86 backend.

Here's a primer on CI:
1. The configurations for jobs live in github.com/openshift/release, specifically in the ci-operator/config directory.

This is used to auto-generate ci-operator/jobs (which is a lot of boilerplate, but what prow actually interfaces with).

The existing jobs we can compare against for assisted installer (at least for the 4.15 fork, are here).
https://github.com/openshift/release/blob/master/ci-operator/config/openshift/assisted-installer/openshift-assisted-installer-release-4.15.yaml

2. OK so now that we've seen the job configuration, we should take special note of this example line from the job.
https://github.com/openshift/release/blob/master/ci-operator/config/openshift/assisted-installer/openshift-assisted-installer-release-4.15.yaml#L62

This tells us that the workflow for the job uses `agent-e2e-compact-ipv4`. A workflow is a collection of step-registry steps. You can learn more about those here: https://docs.ci.openshift.org/docs/

3. So now we know what the workflow is called - so what do we do from here?
The key thing to understand is that `agent-e2e-compact-ipv4` is as much an address as it is a name. To find the corresponding workflow definition, we need to look in ci-operator/step-registry – specifically following along treating the `-`s as though they were `/` signifying subfolders.
So the final URL would be: https://github.com/openshift/release/blob/master/ci-operator/step-registry/agent/e2e/compact/ipv4/agent-e2e-compact-ipv4-workflow.yaml

This file in turn is broken down into references to "steps" and "chains". Chains are connections of steps. Steps are usually a yaml configuration with inputs passed to a shell file.
This workflow has a "pre" chain, a "test" chain, and a "post" chain, which will be invoked in that order.

Let's check out the "pre" chain, since it will cover deployment.
The pre chain is just "agent-pre", so we follow the rules of searching in ci-operator/step-registry as before:
https://github.com/openshift/release/blob/master/ci-operator/step-registry/agent/pre/agent-pre-chain.yaml

It sends us to yet another chain for baremetalds-ipi-pre:
https://github.com/openshift/release/blob/master/ci-operator/step-registry/baremetalds/ipi/pre/baremetalds-ipi-pre-chain.yaml

Finally, this chain actually references steps. I'm going to look specifically at the ref for baremetalds-devscripts-setup:
https://github.com/openshift/release/blob/master/ci-operator/step-registry/baremetalds/devscripts/setup/baremetalds-devscripts-setup-ref.yaml

Notice it finally references a shell file: https://github.com/openshift/release/blob/master/ci-operator/step-registry/baremetalds/devscripts/setup/baremetalds-devscripts-setup-ref.yaml#L5

It also has an architecture input, which will be passed to that shell file. Let's look at the logic used:
https://github.com/openshift/release/blob/master/ci-operator/step-registry/baremetalds/devscripts/setup/baremetalds-devscripts-setup-commands.sh#L211

So if you explore more of the steps and refs, you'd see that this workflow uses the packet baremetal IPI worflow as a base.
In our case we probably want to explore the workflow/steps using this https://github.com/openshift/release/blob/master/ci-operator/step-registry/assisted/agent/assisted-agent-workflow.yaml. From there, we can explore what parts we would need to replace in order to test using P/Z resources.