Template:FAQ:Agent 10
That's a difficult question.
Comparing the three protocols, SNMP was not originally designed as an internal subagent-communication protocol, and there are certain architectural limitations to SMUX, which were addressed as part of the design of AgentX. These include such aspects as reliable handling of SET requests (particularly in the face of failures), a common value for sysUpTime, and a mechanism for sharing tables across multiple subagents. So from a purely functional point of view, AgentX is the most appropriate choice for subagent communication.
In terms of implementation, SMUX is the most mature of the three, but is no longer being actively maintained. The original author has moved on, and the current developers don't use this facility. It also only includes master agent support - the package does not provide a SMUX sub-agent API. The AgentX support in the 4.x line has a number of known problems, and is not suitable for use in front-line situations (though it's probably sufficiently stable and functional for simple day-to-day use). The 5.0 agent has seen a significant amount of development, and is a much more reliable beast. Bear in mind that the AgentX and proxy SNMP implementations are relatively new code, so have not received the same level of active service that the core agent has. But with that caveat, either of these options should be suitable for most use.
This decision will probably be dictated by external considerations (i.e. the other agents you need to combine with). Ideally, you should be looking towards AgentX, but this is not always possible.
Dynamically loaded modules serve a somewhat different purpose, and are purely concerned with how the individual MIB implementation modules are located. These can be combined with either a "pure SNMP" model, an AgentX subagent or a proxied SNMP agent. They will involve a slightly greater load on agent start-up (plus an extra level of complexity if things go wrong) - balanced against the ability to avoid re-compiling and re-linking a working binary.
Note that as far as individual MIB modules are concerned, the protocol used to transport the request is more or less irrelevant. The same information is being requested (or set) each time, so a MIB module ought to be protocol-independent. This was one of the design aims of the AgentX support, and the exact same module code can be included as part of a pure-SNMP master agent, or an AgentX subagent, either compiled in or dynamically loaded with no modifications needed to the MIB module code itself.