The AI Concierge

Overview

The AI Concierge is the catalog-driven generalist of the TrackMe AI family. Where the five specialised AI Advisors handle curated remediation flows for specific surfaces (ML models, DSM/DHM thresholds, FLX thresholds, FQM dictionaries, WLK/MHM health), the Concierge handles the long tail of operational requests by grounding itself in the live TrackMe REST API catalog (~423 endpoints) and proposing structured action contracts that you approve from a consent card in the chat.

The Concierge is reached through the AI Assistant: when you ask the chat to do something operational — disable an entity, change a priority, set a maintenance window, trigger a backup, delete a tenant — and that intent does not map to a specialist advisor, the assistant routes the request to the Concierge.

Important

The Concierge has zero static write tools by design. It never mutates anything directly: it proposes actions, and your confirmation click is what fires the REST call — through your own Splunk credentials, RBAC-checked at the REST boundary. The consent-card click is the structural safety property.

Note

Unlike the specialised AI Advisors, the AI Concierge does not require Python 3.13.x / Splunk 10.2.x — it runs on Python 3.9.x and later, so it is available on the same Splunk releases as the rest of TrackMe. See Artificial Intelligence in TrackMe (Requirements & compatibility).

How it works

The Concierge follows a propose-then-confirm contract:

1. Discover — it searches the live API catalog for endpoints matching your intent, filtered by surface (entity / tenant_home / vtenants / global) and verb (read / write).

2. Validate — every candidate endpoint is checked against the live catalog: the path must exist, the danger level must match, and the body template must carry placeholders for protected fields.

3. Propose — it emits a typed concierge_invocation action contract carrying one or more proposed actions.

4. Consent — the chat renders each action as a card showing the target endpoint, the request body (editable), a danger-level badge, and per-action Run / Edit request body / Cancel controls. Destructive actions require you to type the action name to confirm.

5. Execute — your click fires the REST call. Each write is stamped with the [AI Agent] prefix in the entity audit trail, exactly like the specialist advisors.

Single-action example

In the example below, the operator is investigating a DSM entity and types a plain-language request into the AI Assistant: “Disable monitor for this entity, it’s a noisy feed and we don’t need it anymore”. The intent does not map to a specialist advisor, so the assistant proposes a Concierge action — a consent card that targets the exact REST endpoint with the resolved request body, ready to run or edit.

Once you confirm, the Concierge fires the REST call and reports completion inline, with the structured result of the action it performed.

Multi-action proposals

A single request can produce several proposed actions when the intent naturally spans more than one operation. In the example below the Concierge proposes a coordinated set of actions (ds_monitoring, ds_update_priority, set_maintenance), each rendered as its own card with the required capability, the target endpoint, the request body, and an Edit request body control. You approve, edit, or cancel each action independently.

Where the Concierge is available

The Concierge is wired into every chat surface as the universal fallback. On entity, Tenant Home and Virtual Tenants surfaces it layers under the specialists — when your intent matches a specialist (e.g. “why is this entity red?” on a DSM entity), the assistant proposes the specialist; only when no specialist matches does it fall through to a Concierge proposal.

On the six feature-level surfaces the specialists do not apply, so the Concierge is the sole bridge target:

• REST API Reference

• Backup & Restore

• Global Maintenance Mode

• Maintenance Knowledge Database

• Bank Holidays Management

• License Management

Safety and validation

The Concierge operates on the full REST catalog, so it has the broadest surface of any AI capability. Several layers of defence-in-depth keep it safe:

Guardrail	What it does
Catalog grounding	Every proposed path is validated against the live API catalog — both before the contract is emitted and again at consent-card render time. Hallucinated or removed paths disable the Confirm button with a clear banner.
Consent is structural	The Concierge cannot mutate anything without an explicit user click. There is no autonomous write path.
Danger badge + typed confirmation	Every action carries a danger level (low / medium / high / critical). destructive actions require you to type the action name (e.g. del_tenant) before Confirm enables.
RBAC at the REST boundary	The action fires through your Splunk session; an operation you are not authorised for fails at the REST boundary with a clean 403 surfaced on the card — the agent does not bypass RBAC.
Audited end-to-end	Every Concierge proposal is indexed to the tenant summary index (sourcetype trackme:ai_agent:concierge_advisor:propose) and every confirmed write carries the [AI Agent] prefix in the per-entity audit trail. See Auditing AI activity.

Note

Two operational caps apply per tenant: ai_concierge_max_actions_per_proposal (default 10) and ai_concierge_rate_limit_per_minute (default 5). The Concierge has no per-tenant enablement gate and no separate destructive-action gate — RBAC, the consent card, and typed confirmation are already the safety layers.

Related

• AI Assistant — the conversational front door the Concierge is reached from.

• The AI Advisors — the specialised advisors the Concierge complements.

• Auditing AI activity — the audit dashboards that record Concierge activity.