You need something with a screen somewhere in the system to be able to monitor it and input data, which means a phone app or a web app. In the case of OpenAPS,

You need something with a screen somewhere in the system to be able to monitor it and input data, which means a phone app or a web app. In the case of OpenAPS, it works mostly as you described: an Intel Atom SoC talks to the CGM and to the pump, and syncs with a webapp (called Nightscout) for monitoring and user input if internet access is available, but continues to operate autonomously if it isn't. The webapp sends an alert if the microcontroller hasn't connected for awhile (30 minutes), which is how you find out if it's lost communications or powered off. Users have to be able to input when they're eating carbs. It's possible to do that through the pump (that's how I do it), but there are some ways in which that's not ideal. Most people enter carbs through the webapp. This is capable of creating a dangerous situation for the user (not of killing them). It's a security risk, but also a practical necessity. Some peoples' setups are more internet dependent than that, though. For certain models of CGM, the way you get data from them is by giving them an internet connection and using a web API provided by the CGM maker. (This is built on abusing APIs that were intended for eg family members monitoring glucose values of children who might not be close by.) And, in the case of Loop, the decision algorithm executes on a phone. These setups aren't ideal, but they're all made by hackers with limited time and resources desperate to get something that works, because the market isn't providing anything acceptable.