Copping the Answer from Yuval Gross from Stack Overflow:
At this point we do not have a general guideline on how to integrate your existing app/client/module with the update agent, which is something we're working to add very soon. For now I can refer you to some of the relevant pointer in our documentation, which will help you to get started:
Update agent PnP interface: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-plug-and-play
Update agent workflow: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/understand-device-update#device-update-agent
Workflow code reference: https://github.com/Azure/iot-hub-device-update/blob/main/src/agent/adu_core_interface/src/agent_workflow.c
Note that for installation specific implementations we have the concept of a "handler" which is maps to a specific "updateType". Here is the relevant pointer:
https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-agent-overview#update-handlersAn example of such handler is APT or SWUpdate, which resides here:
https://github.com/Azure/iot-hub-device-update/tree/main/src/content_handlers/swupdate_handler
That does not really answer my Question but shows me that I am not missing something obvious.
How I see this is that, I can either extend the Agent functionality by modifying the source code, so that the sdk functions are executed as well. Or and that's the part I'm not sure about, I could have the SDK running at one module and the Agent as another. That way all date is sent and received, but I have two programs running.
I think I could start the Agent from the SDK when an Update is viable. In that case 99% of the time there would be only one running program.
If @António Sérgio Azevedo could verify this, then this Question can be closed.