if agents continue to get better with RL, what is future proof about this environment or UI?
I think we all know that managing 5-10 agents ... is not pretty. Are we really landing good PRs with 100% cognitive focus from 5-10 agents? Chances are, I'm making mistakes (and I assume other humans are too)? Why not 1 agent managing 5-10 agents for you? And so on?
Most of the development loop is in bash ... so as long as agents get better at using bash (amongst other things), what happens to this in 6 months?
I don't think this is operating at a higher-level of abstraction if agents themselves can coordinate agents across worktrees, etc.
Interesting thoughts - thank you! And directionally agree - given that agents are becoming ever better, they'll take more and more of the orchestration on themselves. Still, we believe that developers need an interface to interact with these agents; see their status and review / test their work. Emdash is our approach for building this interface of the future - the ADE :)
People use UIs for git despite it working so well in the terminal... Many people I knew at uni doing computer science wouldn’t even know what tmux is. I would bet that the demand for these types of UIs is going to be a lot bigger than the demand for CLI tools like Claude Code. People already rave about cowork and the new codex UI. This falls into the same category.
We're figuring our business model out. There're two avenues that we principally think about (1) bundled coding agent subscription and (2)enterprise version with auth, team management, sharing of agent interactions. Admittedly, it's early and this can change. What won't change is that this UI layer for running multiple coding agents is and will be open-source. Emdash itself is funded by YC. Initially developed as a tool while working on another product, but we weren't funded then.
(2) sounds like a great idea if you can ensure private company data never reaches your servers, with features like remote controlling agents from a central place
Been driving my agents (CC, currently testing Pi) for a couple of weeks via Emdash. Finally, got a productive worktree setup working. There were still rough edges when I started, but the team has shipping fast [0] and is vaporizing concerns on the fly. Building on top of the native CLI seems to be the right strategy as well.
We connect to remote servers via SSH, are provider-agnostic, and open-source. e.g. in Codex you can only run OpenAI models and not Gemini, Amp, you name it. Give it a spin :)
this looks great, but can't test, the .deb package is broken with an issue about NODE_MODULE_VERSION mismatches. There seems to be a PR waiting for approval. Will keep an eye on it.
Have you considered adding any kind of agent coordination layer, e.g. letting one “orchestrator” agent spawn and direct sub-agents on specific subtasks, rather than having the developer manually assign each task? Or is the explicit human-in-the-loop assignment a deliberate design choice to keep control and avoid runaway costs?
We've considered it! The way we're seeing it, this is something that the CLIs themselves are getting good at natively, such as Claude Code. We generally consider ourselves to be at a higher abstraction / task level, where the individual CLIs are responsible themselves for breaking down and distributing a larger task across subagents.
How does Emdash handle state management when running multiple agents on the same codebase? Particularly interested in how you prevent conflicts when agents are making concurrent modifications to dependencies or config files. Also, does it support custom agent wrappers, or do you require the native CLI?
Thanks for your questions! You can separate the agents in Emdash by running them on separate git worktrees so they can do concurrent modifications without interfering. We don't support custom agent wrappers currently, interesting. Have you written your own? What is your use case for them over native CLIs?
This is essentially just setting up an MCP connection to your kanban provider and instructing the agent to plan out an epic. I did this this morning for some data modeling our team needed to do. For the most part it generated a good set of tickets, but there were some hallucinations due to ambiguity. Reviewing the already written out tickets was much better than writing them out myself.
But the standard that will hopefully take over in most mature shops is spec driven development where instead of a team reviewing code, they review a spec which is used to generate tasks and subsequently code to satisfy the spec. Then 2 kanban boards exist. One for writing and submitting specs and another for the agents themselves to implement the approved specs.
Thanks. Btw, doesn't work at all for me. I installed, tried to connect to my WSL2 instance on localhost via SSH, which worked. Selected a folder and got Claude Code is not installed (it is very much installed :)).
Grabbed the version before and got "PTY unavailable: ... was compiled against a different Node.js version using NODE_MODULE_VERSION 127, this version requires NODE_MODULE_VERSION 123".
Hope you can fix the bugs. I love Conductor on my Mac, but I need something for my WSL2 machine. Ideally Windows which can SSH into WSL2 (for UI speed) or runs on Linux itself. This is very close to what I need if you fix the bugs :).
Thank you for flagging! We had a CI bug in v0.4.16 that caused the compilation error that we patched in the latest release (v0.4.17). I created a ticket for the provider detection on remote servers. On it!
Conductor is definitely in the same space. Main points of differentiation that I am aware of are that we allow you to connect to remote servers via SSH, natively embed many more coding agents (21) with their full functionality, and are open-source.
Not in its purest sense! We're using the monaco editor for file editor and diffs, but other than that no VScode included. The file editor is really a secondary view inside of Emdash. The focus is on the chat with the coding agent. We'll make this more clear in the readme. Thanks for the feedback!
interesting! hadn't looked into sparse checkout before, but will do now. Initial thoughts are that sparse might be risky if we lose some arbitrary files that might be relevant context for the coding agents. Will look into this!
if agents continue to get better with RL, what is future proof about this environment or UI?
I think we all know that managing 5-10 agents ... is not pretty. Are we really landing good PRs with 100% cognitive focus from 5-10 agents? Chances are, I'm making mistakes (and I assume other humans are too)? Why not 1 agent managing 5-10 agents for you? And so on?
Most of the development loop is in bash ... so as long as agents get better at using bash (amongst other things), what happens to this in 6 months?
I don't think this is operating at a higher-level of abstraction if agents themselves can coordinate agents across worktrees, etc.
CLIs like claude code equally improve over time. tmux helps running remote sessions like there were local.
Why should we invest long time into your „ADE“, really?
> see their status and review / test their work
Won’t that be addressed eventually by the CLIs themselves?
Maybe you’re betting on being purchased by one of the agentic coding providers given your tool has long term value on its own?
[0] https://github.com/generalaction/emdash/releases/
If you're talking about shared services, that's another matter.
But the standard that will hopefully take over in most mature shops is spec driven development where instead of a team reviewing code, they review a spec which is used to generate tasks and subsequently code to satisfy the spec. Then 2 kanban boards exist. One for writing and submitting specs and another for the agents themselves to implement the approved specs.
Then tried running the Linux version on WSL2 (not ideal because the wayland server on WSL2 is slow) - doesn't work. This 404s: https://github.com/generalaction/emdash/releases/download/v0...
Grabbed the version before and got "PTY unavailable: ... was compiled against a different Node.js version using NODE_MODULE_VERSION 127, this version requires NODE_MODULE_VERSION 123".
Hope you can fix the bugs. I love Conductor on my Mac, but I need something for my WSL2 machine. Ideally Windows which can SSH into WSL2 (for UI speed) or runs on Linux itself. This is very close to what I need if you fix the bugs :).