Not a flying drone (though count to think of it, that might work), I mean a drone system tray app, that secure tunnels to the drone server, which allows your AI to operate via MCP cross-system (think SSH, but for LLMs).
I'll leave details at that, if anyone has any questions, or possible scenarios they'd want to use it for, lemme know in the comments and I'll tell you whether it's capable or not, or if it's a feature I might add to it. Still ironing out some bugs, but would love to hear if anyone else would use it, besides me. Kinda sad open sourcing things that dont get used, so if there's demand, I'll release it. Else I'll just start my AI support services empire myself ;)
Top comments (6)
id use it. i run a fleet of background agents across a couple of machines and the thing i actually want is exactly what you described, one place to reach them from instead of a pile of per host wiring.
scenario for you, since you asked. agent needs to read state on machine a, then act on machine b based on what it read. thats the boring version and its also the one that scares me, because each step is individually fine and the sequence is the part nobody authorized. i spent a lot of time on that shape and the finding that stuck was that a single observer goes blind when the view is partitioned. each endpoint sees its own half, both halves look legitimate, and nothing in the system ever holds the whole sequence in one place.
so my question is about the drone server, not the tunnel. does it emit one ordered record of what the model did across every connected system, or does each endpoint log locally and you reassemble later. if its the first, that is the actual product in my opinion and the ssh comparison undersells it, because ssh gives you access and this would give you a custody trail. if its the second, the cross system part is exactly where the gap opens.
either way put me down as demand. open sourcing it beats the empire.
Bit of both. Each drone keeps a local log, it tracks system state, if you run or end a process, it's PID, etc. is in the log. But it also reports the full state to the server. The intention being that it's meant as a end-device debug tool. I got annoyed packaging a .exe, copying it over, running it, it fails, so I have to take it's partial log file, dump it back over to the other system and rinse repeat till bugs are cleared. So I opened a secured tunnel, they do an auth handshake securely through the handshake server, switch to P2P secured tunnel, then it's a live-wire between the 2, so PC A can do anything on PC B, whether that's opening a notepad and writing, running commands (that's why auth handshake and encrypted, validated traffic), take screenshots, copy over files, etc. Essentially a MCP (my rust NMCP, so it doesnt slow the system down), so it can interact cross-system natively through the secured channel. Still some kinks to work out, like the polling rate for logs, maybe a lazy-sync, but because it uses my VCTP protocol for any transfers, it's quite efficient (no JSON). Once I get the basic bugs sorted out and document the deployment system properly, then I'll open source it. Incase you're worried, yes, NMCP does support standard JSON structured MCP tools, though you lose speed, with the intent being you can configure the drone for whatever task you need it to do. It has all it needs to be fully functional on the end device, but if you want to do certain tasks, you can just modify to append tools to each client. My current setup uses an Azure VM as the handshake server, the P2P tunnels through my local network (even through separate subnets), I can see that I'll be expanding on Drone alot in the future, if drone is served from a LLM server and has a little chatbox, it could essentially be converted into a 'remote support' agent, where if someone has a problem, the LLM can be first line of support to fix it for them. But that's just 1 of the many use-cases I imagine people would enjoy. My intention for instance is to have it run on any cloud VM I run, so it can give me eyes and ears in my VMs, centrally managed. Given that it's designed zero-alloc, it just sits at 10.2 mb of ram, which is well worth it for giving a LLM full access to another system for debugging.
the debug loop you described is exactly why it exists and that tracks. package the exe, copy it over, watch it fail, drag the partial log back, repeat. thats the whole reason anybody builds a tunnel. and zero-alloc sitting at 10.2mb for full cross-system access is a real number, most things that do a fraction of that are heavier.
on the both answer though, i want to push on one seam because i think it is the difference between a debug tool and a custody trail, and you are close enough to it that it is worth naming.
local log plus full state reported to the server gives you aggregation. it does not automatically give you ordering. those are different properties and the second one is the expensive one. if drone A reports its state and drone B reports its state, the server ends up holding two accounts that are each internally true, and nothing in that structure establishes that A happened before B, or that B happened because of A. across one machine you get ordering for free from the local clock. across two you do not, and it is not a small gap, its the gap.
and you already named where it bites. you said the open kinks are polling rate and maybe a lazy-sync. if state arrives by poll and the interval differs per drone, then two events on two machines can land at the server in the wrong order relative to when they actually happened, and there is no way to tell from the record afterward. a sequence that got reassembled wrong looks identical to one that was always fine.
the reason i care about that specific seam is the shape i spend most of my time on. an agent reads state on machine A, then acts on machine B based on what it read. every individual action is authorized. the sequence is the thing nobody authorized, and it only exists as a sequence, so if your record cannot establish order across the boundary it cannot see it at all. each endpoint sees its own half, both halves look legitimate, and nothing anywhere holds the whole thing.
that matters more the second you do the thing you said you want to do next. right now a human is on one end deciding what happens on the other, and a human has a memory of what they just did. once its an LLM served from your LLM box with a chatbox in front of it, the thing composing actions across machines has no memory outside what you give it, and the server log stops being a debug convenience and becomes the only witness there is.
not saying build a distributed clock, that is a lot for a debug tool. but a monotonic sequence number issued by the handshake server and stamped on every action before it executes would give you total order across drones for basically free, and it survives a drone dying mid-action because the gap in the numbers is visible.
either way put me down as demand. eyes and ears in every VM centrally managed is the thing i actually want, and open sourcing it beats the empire.
@xulingfeng You want drone? I've been using it to test out V.E.L.O.C.I.T.Y. Share, Messenger and Remote. Still some kinks with the sandboxing, but I'll sort that out soon enough, but it's really helped with E2E development, cuz I can live-deploy and execute commands without needing to back and forth. Something you'd probably have some experience with, with QA 😂
No rush. Let me finish this piece of fried chicken first🍗, then we'll talk.
github.com/UnitBuilds-CC/V.E.L.O.C...
Drone's live