Context
Infrastructure knowledge is usually split across inventory, metrics, alerts, prior incidents, and operator memory. The project explores how an agent can bring that evidence together without becoming another privileged management surface.
In progress · Infrastructure observability · AI agents
Building a read-only Network Assistant
I’m building an agent that can assemble infrastructure evidence, explain likely failure paths, and help verify recovery—without holding production remediation credentials.
Conceptual evidence path
How the assistant should reach an answer
- Observe
- Normalize
- Correlate
- Explain
- Human review
- Verify
Conceptual workflow only. No live topology, identifiers, operational data, or management path is shown.
The problem
Monitoring shows symptoms; operations needs evidence
A health check or alert can show that something is wrong without explaining how identity, storage, virtualization, DNS, network paths, application dependencies, or earlier incidents contributed. An assistant is only useful if its conclusions remain source-backed and its access remains bounded.
What could go wrong
- Collector credentials quietly gaining write capability
- Weak correlations being presented as confident remediation
- Private topology, identifiers, or activity patterns leaking into output
- The AI layer being unavailable during the incident it is meant to explain
- Stale intended-state or incident context producing the wrong recommendation
Current implementation
What exists today
- Created a dedicated Network Assistant agent profile
- Built an initial containerized monitoring core with passing health probes
- Defined a read-only observation boundary and structured MCP interface
- Separated observation and recommendation from human-controlled remediation
- Kept this public portfolio completely disconnected from the assistant and its data
Next gates
What is deliberately unfinished
- Enforce least-privilege tools and local inference on the dedicated profile
- Finish message routing and the first-contact workflow
- Connect and validate read-only collectors with source-side write denial
- Complete source-of-truth inventory and independent alert delivery
- Exercise failure, stale-data, and recovery-verification scenarios
How I validated it
Current evidence and release gates
- The initial monitoring core passes its defined health probes
- The public site remains static and exposes no assistant endpoint or telemetry feed
- Incomplete hardening, routing, and source integrations are published as incomplete
- Production readiness will require collector-side write denial, source attribution, failure-mode tests, and alert delivery that does not depend on the AI layer
Publication boundary
Only the abstract design and milestone state are public. Endpoints, hostnames, addresses, credentials, asset counts, alert history, actual topology, and operational telemetry stay private.
What this demonstrates
Agentic operations is a security architecture problem
This project shows how I approach an operational agent as more than a chat interface. Identity, permission scope, evidence provenance, intended state, degraded operation, human authority, and recovery verification all have to work together.
The project is preliminary. The page distinguishes working components from design goals and intentionally excludes private infrastructure detail.
Technologies in the design
Hermes AgentMCPLocal inferenceMetricsSource-of-truth inventoryIndependent alertingContainersTelegram routing