There are two things here:
Yes, it’s an imp. This means it uses the imp device architecture (which gives you maintained device-side OS & security stack, without needing re-integration to ship updates) plus the imp cloud architecture (which gives you easy and secure code deployment, plus a cloud VM which absolutely helps you deliver quicker, higher performance integrations with cloud services).
It doesn’t need to talk to the agent to operate; it runs code locally and will do all the same sort of MCU things that any MCU can do down there. However, you’re correct in that all communications are via the TLS1.2 ECDHE channel to an imp server.
The name “fieldbus accelerator” really says it all - it’s for connecting devices sitting on fieldbuses (eg MODBUS-RTU, MODBUS-TCP, BACnet, etc) to cloud services, securely and easily. It’s not designed for sensors - the battery powered sensor node accelerator is loaded with those.
The physical manifestation of the off the shelf implementation suits who it was designed for - people who are using it to securely connect fieldbus devices to cloud services. If you have a different use case in mind, you can download the cad - it’s open source - and remove/replace/reformat the design to your requirements.
The “traditional” IoT model of edge device (incapable of talking to the internet), gateway (which can manage the internet bit) and cloud service is not necessarily a good thing. For one, it gives you more attack surface, as is regularly demonstrated with almost every linux-based gateway being hacked. Here, the fieldbus gateway is a provably secure endpoint - our platform has been through many customer pentests, plus has UL2900-2-2 certification - which bridges a variety of legacy devices securely to data services.
In the imp model, the “gateway” is essentially virtualized (that’d be the agent) - and so is free from most of the resource constraints of embedded devices. One example is that agents have no problems verifying TLS certificate chains, which is in contrast to the shortcuts that many embedded devices take (no root certs = no way to validate third party services). We have customers who do all sorts of things in the agent (up to and including XML parsing and generation for legacy backend interfacing).
Also bear in mind that if you want data to go through your own servers, that’s our private cloud offering. You get to own your DNS, your TLS CA, signing keys, and so on.
Does that help?