ProtocolPlugins
What are AEE intents?
When a plugin page says "Ten AEE Intents", here is what that actually means.
9 March 20267 min read
You are browsing the plugin store. The Wazuh SIEM plugin says "ten AEE intents" in its description. The NOC Suite Bundle mentions "26 MCP tools and AEE intents across all plugins". What does that number mean, and why should you care?
An AEE intent is a named action that a plugin can perform. It is a specific, structured thing the plugin knows how to do. Not a vague capability claim. A defined operation with a name, expected inputs, and expected outputs, wrapped in a standard message format that every part of the system understands.
When Wazuh says "ten intents", it means the plugin registers ten distinct operations that CommanderQ can call on your behalf.
The Wazuh plugin's ten intents
Here are the ten intents the Wazuh SIEM plugin ships with. Each one is a specific operation you can trigger through CommanderQ or automation.
| Intent | Description |
|---|---|
| wazuh.alerts.list | Fetch security alerts from Wazuh, filtered by severity or time range |
| wazuh.alerts.triage | Ask CommanderQ to analyse alert patterns and prioritise threats |
| wazuh.agents.list | List deployed Wazuh agents across the fleet |
| wazuh.agents.deploy | Install a Wazuh agent on a host via bastion SSH |
| wazuh.agents.remove | Unregister and remove a Wazuh agent |
| wazuh.vulnerability.scan | Run CVE detection on a specific host |
| wazuh.syscheck.list | List file integrity monitoring results |
| wazuh.sca.check | Run compliance checks (CIS, PCI-DSS, HIPAA) |
| wazuh.manager.status | Check Wazuh manager health |
| wazuh.active-response.trigger | Trigger automated threat response with approval flow |
Each intent has a namespace (wazuh), a domain (alerts, agents, vulnerability), and an action (list, deploy, scan). The naming follows dot notation: namespace.domain.action.
So when you ask CommanderQ "scan nw-db-01 for vulnerabilities", the system knows to use wazuh.vulnerability.scan. When you say "deploy a Wazuh agent to the new server", it routes to wazuh.agents.deploy. The intent name is the contract between what you ask and what the plugin does.
Why intents instead of just API calls
A plugin could expose its features as plain API endpoints. Many integrations do exactly that. But intents carry three properties that raw API calls do not.
- Named and discoverable. CommanderQ can list what a plugin can do by querying its intent registry. It knows the difference between "list alerts" and "triage alerts" before calling either.
- Wrapped in a standard envelope. Every intent call is an AEE envelope with sender, recipient, correlation ID, and timestamp. The call and its result are automatically linked and stored.
- Auditable by default. Because every intent is an envelope, every plugin operation appears in the audit trail. You can query "show me all wazuh.agents.deploy calls this week" across your entire fleet.
The envelope, briefly
Every intent call is wrapped in an AEE envelope. The envelope is a fixed JSON structure with 14 fields. Here is what one looks like when CommanderQ calls wazuh.alerts.list:
{
"v": "1",
"id": "01JFX8KMN2...",
"ts": "2026-03-09T10:30:00Z",
"type": "task",
"from": "agent.quox",
"to": "wazuh-plugin",
"intent": "wazuh.alerts.list",
"corr": "CONV_01JFX...",
"reply_to": "01JFX8KMN1...",
"payload": {
"severity": "critical",
"since": "1h",
"limit": 50
}
}The type field says this is a task, meaning it expects a reply. The intent field says what the task is about. The payload carries the intent-specific data. The corr field links this envelope to the conversation it belongs to.
When the Wazuh plugin responds, it sends back an envelope with type: "result", the same corr value, and reply_to pointing at the original task. The system now has a linked pair: request and response, both stored, both queryable.
How it looks in practice
When you ask CommanderQ about Wazuh alerts, the system produces a chain of envelopes with different intents. Here is the sequence for "list critical Wazuh alerts from the last hour":
| Dir | Type | Intent | From → To | Content |
|---|---|---|---|---|
| out | task | quox.chat.query | human.adam → agent.quox | "List critical Wazuh alerts from the last hour" |
| internal | task | wazuh.alerts.list | agent.quox → wazuh-plugin | severity: critical, since: 1h |
| internal | result | wazuh.alerts.list | wazuh-plugin → agent.quox | 3 critical alerts returned |
| internal | task | wazuh.alerts.triage | agent.quox → wazuh-plugin | Analyse these 3 alerts for patterns |
| internal | result | wazuh.alerts.triage | wazuh-plugin → agent.quox | Brute-force pattern detected on nw-db-01 |
| in | result | quox.chat.response | agent.quox → human.adam | "3 critical alerts. Brute-force pattern on nw-db-01..." |
Six envelopes. Two different intent namespaces (quox.chat.* and wazuh.*). All sharing one correlation ID. CommanderQ received your question, called two Wazuh intents to get the data it needed, then assembled a response. Every step is recorded.
Intents beyond plugins
Plugins add their own intents, but the platform ships with a core set that handles chat, fleet management, safety, memory, workflows, and the processing pipeline. Here are some examples:
| Namespace | Intent | Description |
|---|---|---|
| Core | quox.chat.query | A user asking a question |
| Core | quox.chat.response | The agent answering |
| Fleet | quoxagent.job.submit | A command dispatched to a fleet host |
| Fleet | quoxagent.job.result | The result coming back |
| Safety | ops.approval.request | A request for human sign-off |
| Pipeline | aocl.layer.complete | A processing layer finished its work |
| Memory | quox.memory.store | Persist a fact to memory |
| Workflow | quox.flow.node.execute | Run a workflow node |
The platform currently defines over 170 core intents. Plugins extend this further. The intent namespace is open: any plugin can register its own prefix and define as many intents as it needs.
What the intent count tells you
When a plugin advertises its intent count, it is telling you how many distinct, structured operations it supports. A higher number generally means deeper integration.
| Plugin | Intents | Examples |
|---|---|---|
| Wazuh SIEM | 10 | alerts, agents, vulns, FIM, compliance, active response |
| Prometheus | 4 | query, range query, targets, alerts |
| Uptime Kuma | 4 | monitors, status, heartbeats, notifications |
| Proxmox | 5 | VMs, containers, storage, nodes, snapshots |
| Grafana | 3 | dashboards, panels, annotations |
The NOC Suite Bundle combines all five monitoring plugins. Its "26 MCP tools and AEE intents" figure is the sum of all plugin capabilities. Buying the bundle gives CommanderQ the full vocabulary for infrastructure monitoring, from reading Prometheus metrics to deploying Wazuh agents.
How plugins register intents
When a plugin is installed, it registers its intents with the system. The registration includes the intent name, payload schema, and whether it expects a reply.
// wazuh-plugin/intents.js
export const intents = [
{
intent: "wazuh.alerts.list",
type: "task",
requiresReply: true,
payloadSchema: {
severity: { type: "string", enum: ["low","medium","high","critical"] },
since: { type: "string", description: "Time range, e.g. '1h', '24h'" },
limit: { type: "number", default: 50 }
}
},
{
intent: "wazuh.agents.deploy",
type: "task",
requiresReply: true,
payloadSchema: {
host: { type: "string", description: "Target hostname or IP" },
group: { type: "string", description: "Wazuh agent group" }
}
},
// ... 8 more
]This registration is what makes intents discoverable. CommanderQ can query a plugin's intent list, understand what parameters each intent accepts, and call the right one for a given user request. Without this, the AI would be guessing at API shapes.
The AEE envelope structure is fixed and never changes. The intent namespace is open and always growing. New plugins add new intents without touching the protocol specification. This is the same pattern as HTTP: the protocol is stable, but the set of URLs is infinite.
Design principle
Every intent is an audit record
Because every intent call is an AEE envelope, and every envelope is stored, you get an automatic audit trail of everything plugins do. This is not a feature you enable. It is how the protocol works.
// "Show me all Wazuh agent deployments this week"
const deployments = await queryEnvelopes({
intent: "wazuh.agents.deploy",
since: "7d",
type: "task"
})
// Each result includes:
// who requested it (from field)
// when (ts field)
// which host (payload.host)
// what happened (linked result envelope via reply_to)
// which conversation triggered it (corr field)This matters for compliance. If a security auditor asks "who deployed agents to production hosts last month?", you can answer that query directly. The data is structured, typed, and linked. Not buried in log files.
In summary
- An intent is a named action. A specific, structured operation that a plugin or the platform can perform.
- Every intent is an AEE envelope. Standard format with sender, recipient, timestamp, correlation ID. Automatically stored and linked.
- Plugins register their own intents. Wazuh registers 10. Prometheus registers 4. Any plugin can add its own namespace.
- The intent count measures capability. More intents means deeper integration. The NOC Suite Bundle combines 26 across five plugins.
- Every intent call is auditable. You can query what happened, who triggered it, when, and what the result was. By default, not as an add-on.
Next time you see "Ten AEE Intents" on a plugin page, you know what it means: ten things that plugin can do, each one named, structured, discoverable, and automatically recorded in the audit trail.
Read the specification
Open protocol specifications. No vendor lock-in, no proprietary formats. Implement them yourself or use QuoxCORE.