Thanks! Stack is simpler than it looks. It's a local Rust server that opens in your browser, with embedded frontend (`agentbeacon` → localhost). Desktop shell is planned but not shipped yet.
On the VSCode / Cursor extension angle, I thought about it a lot. Once you're running hierarchies of agents across multiple features in parallel, the work shifts away from any single file or repo. The editor is still a surface, but it's one surface for one thread. The decision queue is a surface for the fleet. An IDE extension would make it hard to manage multiple projects at the same time. There is probably some room for a lightweight glue extension eg jump from queue entry to file or something like that.
That said, you're dead right that there's huge "for free" wins in the IDE space, which is exactly why everyone converges there, though it comes with its own constraints.
Good luck with the pre-alpha. Would be curious to see it when you ship. Thanks for taking a look.
How reliably do agents stick to the 'coast exec' boundary in practice? Especially when they spawn subagents that may or may not inherit the instructions.
Curious if you've seen a difference between agents finding things through the graph structure vs just vector search over a docs directory. The section constraints and check validation seem like the real quality wins here, wondering how much the wiki link topology adds on top of that.
So the graph is human-maintained, and agents consume it and `lat check` is supposed to catch broken links and code-spec drift. How do you manage this in a multi-agent setup? Is it still a manual merge+fix conflicts situation? That's where I keep seeing the biggest issues with multi-agent setups