What may it read?
Read-only by default, scoped per tool, least privilege. Credential handling and network paths are documented before connection.
Brutlabs Copilot
Brutlabs AI driven root cause analysis
An AI agent that understands your network topology and operational context, finds root cause in minutes and proposes a fix behind human approval gates.
Source of truth
Config CI/CD
Telemetry
Logs
telemetrytor-rack14-a unreachable — last sample 03:40:58, every interface dark
logsfinal syslog before loss: PSU-2 output failed, chassis on one feed
logstor-rack14-b — LACP member down, 24 hosts now single-homed
configno change deployed to this device in 21 days — not change-induced
sotintended role redundant ToR pair — rack 14 is running without redundancy
recallmatches INC-1884 — PSU-1 failed on this chassis 63 days ago, never replaced
Root cause
Both power supplies on tor-rack14-a have now failed. PSU-1 failed 63 days ago and was never replaced, which left PSU-2 as a single point of failure. The chassis lost power at 03:40:58.
Proposed fix
Raise a hardware dispatch for both PSU bays, and hold rack 14 on tor-rack14-b until they are replaced.
Blast radius: 24 hosts, one rack, no redundancy until the swap.
Awaiting approval
Nothing is applied until an engineer approves it.
6 signals correlated · 44 s to root cause · 1 page raised, with the cause attached
How it works
The agent and everything around it
A model on its own cannot debug a network. What makes it useful is what surrounds it: your context on one side, a safety harness on the other, and an output an engineer can check rather than take on trust.
Inputs
Human promptsAn engineer points it at something: ‘why is site 12 slow since this morning?’
AlertsMonitoring routes an incident in on its own, without anyone typing a thing.
Operator questionsFollow-ups mid-incident, asked against the evidence it has already gathered.
Brutlabs Copilot
Reasoning layerAn LLM that decides which query to run next, rather than summarising the one you already ran.
Network skillsDiagnostic procedures tuned to your platforms, your topology and the conventions your team actually uses.
Knowledge baseYour runbooks, your past incidents, and the resolutions that turned out to work.
Semantic context
Source of truthIntended state, inventory, topology and device roles — what the network is supposed to look like.
TelemetryInterface state and metrics at raw resolution, with enough history to know what normal looks like.
Logs and eventsSyslog, flow records and event history, labelled consistently enough to join against the rest.
Safety harness
RBACA scoped identity of its own. It reads what the role permits and nothing beyond it.
Tool permissionsEvery command and automation tool is allowed explicitly, or it is not available at all.
Human approvalNothing reaches the network until an engineer approves it. Autonomy widens per action, when you decide it has earned it.
Output
Root-cause hypothesisWhat the agent believes is wrong, stated plainly enough to disagree with.
The reasoningWhich signals it followed, in what order, and what it ruled out along the way.
The evidenceThe underlying queries and returns behind every step, timestamped — so you can check the work, not just the answer.
Connections
Full semantic and topological context, not just alerts
The agent is only as good as what it can query. Our agent taps into mutiple sources of data about your network, and each one contributes to a diagnosis.
Tap 01
Source of truth
Intended state, inventory, topology and roles. Supplies the comparison that catches most change-induced faults: what the network is supposed to look like.
The layer we build →Tap 02Config deployment
Change events, rendered diffs, timestamps and device scope from the change management pipeline. Answers ‘what changed on this path recently’ in milliseconds.
The layer we build →Tap 03Telemetry
Interface state and metrics at raw resolution — streamed over gNMI where the platform supports it, polled otherwise — with enough retained history to know what normal looks like on this link.
The layer we build →Tap 04Logs and events
Syslog, flow records and event history with labels consistent enough to join against metrics and change data.
The layer we build →Reasoning
How it gets from signal to cause
01
Detect
A deviation appears in telemetry, or an alert routes in. The agent begins from raw signal, not from an alert's own summary of itself.
02
Gather
It pulls the underlying series, the log window for the same device and period, and the change history for that path.
03
Correlate
Signals are joined on consistent device, interface and site labels. Three unrelated-looking events become one sequence with an onset time.
04
Compare
Running state is checked against intended state in the source of truth. This is where any mismatch surfaces.
05
Recall
Retrieval over your incident history and runbooks: has this signature, template or device caused this before, and what resolved it?
06
Conclude
A stated root cause with the evidence chain attached, or an explicit ‘novel fault, escalating’ when the evidence does not support a conclusion.
07
Propose
A fix expressed as a change to your pipeline, with a rollback plan and a stated blast radius.
08
Wait
Approval gate. Nothing is applied until an engineer says so, unless you have explicitly promoted that action to act-and-report.
Control
Deployed with all the proper guardrails
We answer all the questions that decide whether an agent is deployable in a production environment.
01
02
What may it change?
Nothing, until you say otherwise. Actions climb an explicit autonomy ladder — observe, propose, approve-then-act, act-and-report — one action at a time, on evidence.
03
How far can it reach?
Blast-radius policy caps device count, roles, sites and time windows, enforced before execution rather than reviewed afterwards.
04
What does it record?
Every observation, inference, proposal, action and verification, exportable for compliance and readable in a post-incident review.
05
What if it is wrong?
Post-action verification against the original signal. If the signal does not recover, it rolls back and escalates rather than retrying.
06
Where does the data live?
Deployable inside your own cloud or data centre, with self-hosted models where policy requires. The exact data flow is documented up front.
Difference
How to tell these tools apart
The category is crowded and the demos look alike. These are the questions that separate them, and our answers — which you should hold us to.
01
Can it compare intent against reality?
A tool that reads your environment as-is inherits whatever is already wrong with it. Comparing running state against intended state is the highest-yield question in network diagnosis, and it can only be asked if intent is written somewhere a machine can query. Documents in a knowledge base are not that — you cannot diff a wiki page against a running config.
02
Does it retrieve, or does it investigate?
A natural-language front end retrieves the context you point it at and writes prose about it. An agent chooses its next query based on what the last one returned, because during an incident the sequence of questions is the diagnosis.
03
Where does its change history come from?
Answering ‘what changed on this path six minutes ago’ needs rendered diffs, timestamps and device scope emitted by the deployment pipeline — not what somebody typed into a change ticket afterwards.
04
What happens when the data is not there?
A product can only read what you already have. Where the layer does not exist, we build it — which is usually the larger half of the work, and the reason we say so before selling you an agent.
Limits
What the agent does not do
Worth saying plainly, because a vendor who claims none of this is not worth believing on the rest.
Genuinely novel faults. With no precedent and no recorded intent to compare against, the agent has little to reason from. It will say so and escalate, with the context assembled — useful, but not a diagnosis.
Business judgement. Whether to fail over during a trading window is not a technical question. The agent supplies the technical picture; the call stays with your engineers.
Poorly instrumented networks. The agent is bounded by its data. A confident answer drawn from thin telemetry deserves more suspicion, not less, which is exactly why we build the foundation before connecting anything.
The honest framing: the agent handles the large, repetitive middle of the incident distribution — faults with a knowable cause and a known fix — and hands your engineers the tail with the evidence already gathered.
Questions
Agent questions
What data does the agent need access to?
Four sources: your source of truth for intended state and topology, your config pipeline for change history and diffs, your metrics and telemetry store, and your log store. Access is read-only by default, scoped per tool, with least-privilege credentials rather than a shared administrative account.
Does our network data leave our environment?
That is your decision and we design for either answer. The agent can run entirely within your cloud or data centre, and it can be configured against self-hosted models where policy requires it. Where a hosted model is used, we use enterprise terms under which your data is not used for training. We will document the exact data flow before anything is connected.
How do we know the agent is right?
You check its working. Every conclusion carries the evidence that produced it — the queries it ran, the signals it read, the diffs it compared — so an engineer can audit the reasoning in seconds rather than taking the answer on faith. We recommend running it in observe-only mode against real incidents first and comparing its diagnosis to your team's.
How is this different from the network copilots we have been demoed?
Two things, mostly. The first is what it reasons over: a tool that connects to your environment as-is is bounded by what is already there, and most estates do not have intended state written down anywhere a machine can query, so the highest-yield comparison in diagnosis cannot be made. We build that layer when it is missing. The second is the loop — retrieving context and summarising it is a different product from deciding which question to ask next. To be fair to the category: if you already run a real source of truth and a config pipeline, connecting an agent genuinely is quick, and it is quick for us too.
What happens with a fault the agent has never seen?
It says so. Novel faults are labelled as novel and escalated to a human with the context already assembled — which is still a material saving, because the gathering is usually the slow part. It does not fabricate a runbook match to appear useful.
Can it work alongside our existing monitoring and ITSM tools?
Yes. The agent is designed to read from what you run and to deliver its output where your team already works — your chat platform, your ticketing system, your change pipeline. It is not a replacement console.
How long does agent enablement take?
Once the foundation layers are in place, connecting and tuning the agent typically takes weeks rather than months. When the foundation is not in place, that work dominates the timeline — which is why the readiness assessment comes first.
See the agent run against your own incidents
The readiness consult covers what the agent would need in your environment, what it could diagnose today, and what would have to be built first.
No scripts. No invasive discovery. Just clarity.