13. The AI Assistant
It can investigate, draft change proposals, and schedule its own follow-ups — and it never mutates state without a human saying yes.
The Assistant is the feature most people remember from a Daalu demo. It’s a chat panel that follows you across the app, but the metaphor of “chatbot” undersells what it does. The Assistant can investigate your infrastructure, draft change proposals, and schedule its own follow-ups. It also doesn’t act on anything that mutates state without a human approving it. This chapter explains both halves of that — what it can do, and what it deliberately won’t.
Where the Assistant lives
The Assistant has two surfaces:
-
The right panel. Anchored to the right side of every page. Open and close it with the chevron at its edge, or hit
Cmd-K(Mac) /Ctrl-K(others). On the home page it’s tenant-wide; on every other page it inherits the page’s context. -
Direct chat at
/copilot. A full-page version for longer conversations. Useful when you want all the screen real estate or you’re working off a phone.
Both surfaces back to the same conversation history. Switching between them doesn’t lose context.
What context the Assistant has
When you ask the Assistant a question, it sees:
- The current page. On Alerts → alert-id, it sees that alert’s details. On Operations → device-id, it sees that device. On the home page, it sees your daily briefing inputs.
- Your last few turns of conversation. A short rolling history so it can follow up “yes, do that” without re-stating the whole context.
- Your tenant’s integrations. It knows which clouds you’ve connected, which observability stacks it can query, which network device source-of-truth you’ve configured.
- The tools it has access to (next section).
It does not see other users’ conversations, other tenants’ data, or anything from your personal computer.
Tools — what the Assistant can do
The Assistant has a fixed catalog of tools — functions it can call. They group into:
Read-only tools
These let it investigate. The Assistant can call any of these without asking; they don’t change state.
query_prometheus(query)— run a PromQL query.query_loki(query)— run a LogQL query.read_pod_logs(namespace, pod, container, lines)— fetch the last N lines of a pod’s logs.list_resources(cloud, resource_kind, region, filters)— list cloud resources.get_deployment(namespace, name, cluster)— read a Kubernetes Deployment.rollout_history(namespace, deploy, cluster)— recent rollouts and their statuses.read_device_config(device_id)— pull the running config from a Nautobot-managed device.search_events(filters)— query the event timeline.recent_alerts(filters)— list recent alerts.- And a few more — see Settings → Assistant → Tools for the live catalog with descriptions.
Write tools
These mutate state. The Assistant does not call them directly. Instead, when its reasoning concludes that one of these should be called, it writes a change proposal and hands it to you.
restart_pod(...),scale_deployment(...),apply_device_config(...), etc.
The list of write tools available depends on which integrations you’ve granted write permissions to. By default, write tools are off.
Notification tools
page_user(user, severity, message),post_to_slack(channel, text)— the Assistant can send these without a proposal, but they’re auditable and only fire on user-explicit ask (“page the on-call”).
The change-proposal mechanic
This is the most important paragraph of this chapter. Read it twice if you have to.
When you ask the Assistant to do something that requires a write — “restart the deploy,” “open a port on this device,” “scale up that ASG” — the Assistant does not call the write tool. Instead, it:
- Reasons through whether the proposed action makes sense.
- Writes a change proposal — a structured artifact describing the proposed call (which tool, with which arguments, expected effects).
- Posts the proposal to the Operations → Proposals page.
- Tells you, in chat, that it’s ready and posts a link.
You then read the proposal, optionally edit it, and either approve or deny it. If you approve, the executor runs the call. Self-approval is blocked — if you asked the Assistant to do something, you can’t approve the resulting proposal yourself.
Why it matters This is the central safety property of Daalu. It is what distinguishes the Assistant from an autonomous agent that “just does stuff.” You’ll see this loop dozens of times in your first month of use, and after a while you’ll trust it enough to be disappointed if you ever lose access to it.
Examples of useful prompts
Things Daalu’s Assistant is genuinely good at, drawn from real customer usage:
-
“Why did alert X fire this morning?” — It pulls the alert, reads the relevant metrics and logs, and writes a 3-paragraph explanation with sources cited.
-
“Show me everything that changed in production yesterday.” — It queries the deploy history, the change-proposal log, the cloud-resource change events, and the device-config diff stream, and synthesizes a list.
-
“This pod keeps OOM-killing. Suggest a fix.” — It reads the pod’s recent OOM events, looks at memory limits, checks recent traffic, and proposes either a limit increase or a scale-out. The proposal is queued; you decide.
-
“Page the platform on-call about this alert.” — It calls the notification tool and confirms.
-
“What’s our total monthly spend on the eu-west-1 region across all accounts?” — It runs cost queries against each connected cloud and aggregates.
-
“List all devices whose config has drifted from source-of- truth in the last 7 days.” — It queries Nautobot-managed inventory and the drift log.
-
“Generate a runbook for alert Y.” — It writes a Markdown runbook based on the alert’s recent firings; you edit and save.
Things the Assistant won’t do
A non-exhaustive list of intentional refusals:
- It won’t execute write tools without approval. Even if you beg.
- It won’t read another tenant’s data. Even if you give it an ID.
- It won’t propose changes to systems it can’t reach. If Daalu doesn’t have a connected integration for a system, the Assistant won’t pretend it can act on it.
- It won’t follow links in alert text. Alert payloads can contain URLs; the Assistant treats them as informational, not as instructions to fetch and execute.
- It won’t make up data. When it doesn’t know, it says so and proposes a tool call. (We’ve spent a lot of effort on this; hallucinations were the main barrier to early adoption.)
Conversations and history
Each user has their own conversation history with the Assistant.
The right-panel chat persists across sessions — logging out and
back in resumes where you left off. The full-page /copilot
view exposes a history sidebar where you can revisit earlier
threads.
Conversations are tenant-scoped: an admin can read another user’s history from the audit logs (Chapter 28 — Settings covers what’s logged and who sees it), but in normal use, your chat is your chat.
To clear: in the Assistant panel, click ⋯ → Clear conversation. This starts a new thread; older threads remain in history.
When the Assistant is wrong
It will be wrong sometimes. The main failure modes:
- Stale tool output. The Assistant queries a system and the system was lagging behind reality. Always double-check with a fresh query when in doubt.
- Wrong synthesis. Three data points pulled correctly, combined into a wrong conclusion. Read the cited sources.
- Overconfidence on ambiguous topics. “Should we use X or Y?” prompts can get strongly-worded answers from the Assistant even when the right answer is “it depends.” Use it as a starting point, not as a final word.
When you spot a failure, click “Send feedback” in the Assistant footer. The feedback goes to the engineering team and genuinely influences how the Assistant is trained over time.