Currently, the only way to influence how an active agent is autoregistered is through host metadata (HostMetadata or HostMetadataItem in the agent configuration). Autoregistration actions can then only use three conditions: host name, host metadata and proxy.

This works, but in practice metadata is mostly used to carry very basic information, typically the operating system of the machine. This has several drawbacks:

• The agent already knows this information (OS family, version, architecture, agent version and variant), yet every agent configuration file must be explicitly edited to send it.
• Metadata is a single free-text string. When several pieces of information are needed (OS, role, environment, site), they must be concatenated into one string and parsed with “contains” or regular expression conditions, which is fragile and error-prone.
• HostMetadataItem accepts only one item, so combining several agent-collected values requires a custom UserParameter or system.run.
• Using metadata for basic facts leaves less room for what it is really useful for: business information the agent cannot guess (role, environment, customer, a shared secret).

Proposal

1. The agent sends a set of standard attributes with every autoregistration request, with no configuration required. For example:
   • OS family (Linux, Windows, macOS, etc.)
   • OS name and version
   • Architecture
   • Agent version and variant (agent / agent 2)
2. These attributes are available as separate conditions in autoregistration actions (for example “OS family equals Windows”), alongside the existing host name, host metadata and proxy conditions.
3. Optionally, the attributes are available as macros in autoregistration operations, so they can be used to populate tags or inventory fields.

Benefits

• Zero-touch deployment: a default agent configuration is enough to link the right OS template and host group.
• Simpler and more robust autoregistration rules, with no string parsing.
• Host metadata remains fully available for site-specific or security-related information.
• Easier mass deployments, in particular for MSPs and large environments where agent configuration is standardised.

Backward compatibility
Existing HostMetadata and HostMetadataItem behaviour is unchanged. Older agents that do not send the new attributes simply do not match the new conditions.