A service reports that it's unhealthy. What do you do next?
You might check the logs, look at its dependencies, find the owner, inspect the relevant policy, or search for an incident that looks familiar. You might discover that the last restart didn't actually fix the problem.
The hard part isn't necessarily finding one piece of information. It's connecting the pieces and deciding what they mean together.
That problem reminded me of something from human anatomy and physiology: the body doesn't work as a collection of completely isolated parts. Nervous signals, feedback mechanisms, and organ systems interact. A symptom alone often doesn't explain the entire picture.
I started building NeuroGraph around a similar engineering intuition: an agent should understand relationships between operational facts, remember previous outcomes, and verify whether an attempted fix worked.
Repository: https://github.com/MaskedMan-code/NeuroGraph
Why I wanted a graph-based approach
During an incident, the relevant context can be scattered across service inventories, alert descriptions, runbooks, team ownership, policies, and incident history.
A conventional assistant might receive an error and produce a plausible answer. But plausibility isn't enough for an operational workflow. I wanted the system to establish what it knows, explain where the evidence comes from, and acknowledge what it cannot establish.
NeuroGraph represents the operational environment as a connected graph in FalkorDB.
The graph includes services, employees, teams, projects, dependencies, incidents, policies, documents, actions, outcomes, and memories.
For example, Graph Explorer can find a path like this:
emp-bob → svc-payment-api-stg → pol-staging-restart
That path tells us more than three independent records. It connects a person to a service they own and to the policy governing a possible remediation.
The graph is doing actual work here. It's not just a visualisation placed on top of an otherwise disconnected application.
The stack behind NeuroGraph
The project uses:
Next.js for the user interface.
FastAPI for backend APIs.
LangGraph for workflow orchestration and session continuity.
FalkorDB for graph relationships, operational data, and explicit application memory.
The interface includes an operations dashboard, Graph Explorer, Incident Copilot, Memory Timeline, Audit Log, and demo settings.
The workflow follows graph-backed evidence to identify an affected service, retrieve its owner and dependencies, inspect the applicable policy, look at prior incidents, and decide what the current request permits.
I think of the graph as a bit like a network of connected pathways. The analogy isn't meant to suggest that a database is a biological nervous system. The engineering point is simpler: context becomes more useful when relationships can be traversed and inspected.
Three request modes
I separated three things that are often blurred together in agent demos.
- Investigate only
The agent gathers evidence about the service, its dependencies, policy, ownership, incident history, and relevant memories.
This mode must not produce operational proposals or execute actions. It should still suggest sensible investigative steps if the incident remains unresolved.
- Recommend action
The agent can prepare a proposed remediation and explain the relevant evidence and policy constraints, but it doesn't execute the operation.
That separation matters. A recommendation should remain inspectable rather than quietly becoming an action.
- Request action
An explicit action request enters the policy-controlled workflow. Permissions, environment restrictions, policy decisions, approval requirements, and tool-level checks constrain what can happen.
In this prototype, operations are simulated. The production restart scenario requires human approval and remains pending rather than bypassing that requirement.
I also tested alert content that included malicious instructions. The workflow treats those instructions as untrusted data; they don't get to override the system's policy simply because they appear in an incident report.
A restart isn't the same as recovery
This became one of my favourite tests.
The staging transaction processor was degraded. NeuroGraph accepted a simulated restart, but the verification step still observed the service as degraded.
A less careful demo could mark the whole workflow successful because the restart command returned successfully.
NeuroGraph records the distinction between the accepted command and the failed verification. The Audit Log records the observed status, and the failed outcome is stored in application memory.
Then I ran another investigation.
The agent retrieved the previous failed outcome rather than treating the earlier attempt as a successful recovery.
That's where another analogy from physiology becomes useful: feedback matters. A response has to be evaluated against the state it was supposed to improve. Sending a signal is not proof that the desired result occurred.
For an operational agent, the equivalent is straightforward:
Action accepted does not mean service recovered.
Memory should preserve the outcome, not just the attempt
NeuroGraph stores application memories as graph records with types and verification statuses. These include episodic memories, procedural knowledge, decisions, outcomes, and session-related records.
That is deliberately separate from LangGraph's workflow checkpoints.
The distinction is useful because different memories answer different questions:
An episodic memory can describe a previous incident.
A decision memory can record which policy applied.
An outcome memory can say whether the remediation was verified.
Procedural memory can capture steps worth considering during a future investigation.
A previous fix should not automatically become today's answer. The present incident may have a different root cause, and a past remediation might only have mitigated the symptoms.
In one investigation, the agent correctly retrieved an earlier database connection-pool issue while noting that the current root cause had not been established.
I also found and corrected a response-quality problem: when no operational proposal existed, the workflow could say that no action was needed even though a service remained degraded. The updated response recommends reviewing evidence, escalating to the owner, and continuing the investigation before closing the incident.
That correction was small, but the distinction matters. An agent can refrain from an unsafe operation and still give useful guidance.
Testing the prototype
I ran the backend suite and got 45 passing tests. The frontend passed TypeScript type checking and its Next.js production build.
I also manually tested graph traversal, incident investigation, recommendations, production approval, prompt-injection handling, simulated action execution, failed verification, the Audit Log, cross-run memory retrieval, and the dashboard.
Those tests establish that the demonstrated workflows run in this prototype. They are not a comprehensive security audit or a claim of production readiness.
What isn't finished yet
NeuroGraph currently runs in deterministic demo mode. No live LLM provider is configured, so the demo doesn't claim to show live LLM reasoning. Its operational actions are simulated and don't modify real infrastructure.
Authentication is demo-grade, too. The current version isn't suitable for handling private production operational data without further work on identity, authorization, durable storage, deployment, and security.
I want that boundary to be explicit because an attractive demo isn't the same thing as a production-ready incident platform.
What I'd like to explore next
The next stage is to finish the deployment validation, improve investigation guidance, review dependency advisories, and explore adding a live LLM without letting it bypass deterministic policy and tool controls.
I'm also interested in the broader question of agent memory: how do we make sure an agent remembers a failed attempt as a failure, instead of repeatedly recommending the same action?
For now, NeuroGraph has been a useful way to explore connected operational data, persistent memory, and verification-driven workflows.
Try the code: https://github.com/MaskedMan-code/NeuroGraph
I'd be interested in hearing how others approach agent memory and failed-action recovery. When an automated fix doesn't work, what should the system preserve so the next investigation actually benefits from the experience?
Top comments (0)