I know, I know. I’m the guy who keeps saying the subscription is the better deal.
Open the app, use a good model, get your work done. Somebody else handles the infrastructure. I still think that makes sense for a lot of people.
Then I pulled the trigger on an NVIDIA DGX Spark.
Boom. Now look at me. Running a model locally, moving Field Signal onto it, and making a growing list of things I want agents doing in my lab.
YAY.
The hardware is fun. Of course it is. But I also want to use this build to show what agentic workflows can do for people who have actual work waiting.
Investigating an alert. Reviewing a security policy. Figuring out why an application is unhealthy. Checking that a maintenance task achieved what it was supposed to.
Those are the use cases I want to bring to light through Field Signal.
Field Signal is the first working use case
The Spark is running Qwen3.8-Flash-Next through TensorFold. It’s an existing model I’m hosting on my own hardware.
Apollo handles Field Signal drafting and maintenance. Argus handles research and editing. Their text inference now goes through an authenticated gateway to the Spark.
That gives the model a real workflow to participate in. Read the brief, use the available tools, process the results, and return something the next step can use.
The initial tests completed research and editorial tool loops and produced drafts in the expected format. The gateway also tracks token usage, request duration, status, and client identity, with totals feeding the Compute Ledger.
The first draft of this article came from that setup. Then came the edits. Running locally doesn’t automatically teach a model my tone, apparently. We’re working on it.
I’m keeping Gemini for the generated artwork, including the illustration on this post. Search still uses Exa, and speech is separate. Moving the text workflows to the Spark gives me a useful local starting point without having to rebuild every other part of the site.
VCF Operations gives an agent somewhere useful to start
My lab already has plenty of operational work.
This builds on the read-only VCF Pulse support team I’ve already written about. The next step is to explore where local inference fits and extend the workflows, with the existing work as a starting point.
An alert appears in VCF Operations. Before deciding what to do, I need to understand the affected objects, related symptoms, recent changes, and current state.
I want an agent that can gather that evidence through read-only tools and bring back a useful investigation.
For example, a workload has a performance warning. The agent checks the relevant host, datastore, and resource metrics, identifies what changed around the same time, and shows me the evidence behind its explanation.
It should also tell me when it doesn’t have enough information. A confident guess is still a guess.
The useful output would give me a starting point for the next decision, with sources I can inspect. That is a workflow I can test, document, and eventually help somebody else reproduce.
vDefend brings security into the workflow
I also want to build around vDefend and the work involved in segmentation.
vDefend Distributed Firewall applies security policies at the workload level. The agent work I want to explore is gathering the context needed to review those policies and understand connectivity problems.
Suppose an application stops communicating after a policy change. I want an agent to collect the source and destination context, relevant rules, available traffic evidence, and recent changes. Then I want it to explain which paths deserve investigation.
Another use case is preparing a segmentation review. What application dependencies have we observed? What does the current policy permit? Where do we need more evidence before proposing a tighter rule?
That could save useful preparation work while leaving the policy decision with the person responsible for it.
I’ve already explored the roles of AgentMinder, vDefend, and Avi in my private-AI lab. As these workflows grow, I want to show the information an agent could access, how it reached its recommendation, and what I checked before accepting it.
Avi connects the investigation to the application
Avi is another area I want to spend time on. Its application analytics include health information and client, server, and application timing metrics. Avi’s product overview describes those capabilities.
That gives me a practical agent assignment: investigate an unhealthy application service.
Check the virtual service and pool members. Review health monitor results, relevant events, and timing data. Identify whether the evidence points toward a backend problem, a connectivity issue, or something that needs another team’s attention.
Now connect that with the other systems.
Avi shows a pool member failing health checks. The agent gathers the related workload information, checks relevant NSX and vDefend context, and looks for recent infrastructure changes. It builds an investigation across the systems I would otherwise visit separately.
That is the kind of agentic workflow I want people to see. A specific trigger, a defined set of tools, and an output that helps someone do their job.
The lab is where I can prove the workflow
These expanded lab workflows are plans. Field Signal’s local text workflows are running; extending local inference into operational agents is what I want to build next.
I can create a known problem, give an agent a bounded investigation, and compare its findings with what actually happened. Did it gather the right evidence? Did it miss something? Did its explanation help? How much intervention did it need?
I also want to test follow-up work after maintenance. Did the service recover? Did the warning clear? Did the application remain reachable? What still needs attention?
The first versions will investigate and report through read-only access. Any ability to change the environment should be scoped to a specific job I understand and approve.
Those results are worth publishing, including the awkward ones. People need enough detail to judge whether a workflow would help in their environment.
The Spark gives me somewhere to run these experiments. My lab gives them real systems to work with. Field Signal gives me somewhere to share what I learn.
I bought the box because I wanted to build. Now I want to turn that excitement into workflows people can actually use at work.