Comment by ridruejo
6 days ago
This matches our experience developing with agents. In particular, as we wanted to use multiple agents in the background to do tasks, we had to really invest in different areas so they would not go in wild directions or have to ask continually for feedback, defeating the purpose of working in the background. First, we needed to provide relevant context on how to do the task (some of it is "generic" like Svelte documentation, some of it is specific to how to write tests for our particular project), be extremely detailed and specific in the prompt about what we want and how to go about it (divide it in different well defined steps) and finally provide with specific tools via MCP (like MySQL access and installing system packages). Once we consistently do all this work upfront, it really pays off because you can launch a large number of agents in parallel that don't interfere with each other (git worktrees, containerized environments) and don't require babysitting for the most part. We just open sourced the tooling we used internally for this: https://github.com/endorhq/rover
Thanks for sharing!
The problem with every single tool in the category that I've come across (e.g. Conductor, Sculptor) is that they assume a single repository. Very rarely in my career working on enterprise software have I been in a situation where all my work was constrained to a single repo. Usually a story or feature spans several repos (whether split between frontend/backend, or a repo-per-service). As an engineer in these situations I never work in isolation considering only one repo -- I work across all of them at once and then prep all the PRs together. I'm not saying this multi-repo approach is good, just that it is the state of the world right now in many cases.
So imo tools like this need to work at a level above a single repo. The agent needs to start by cloning all repos needed for the task, and go from there.
I've solved this in the past using versioned dependencies. Repos get tagged releases, other repos can specify which version they depend on, then the deployment script has to resolve those dependencies and install the right release versions of everything else.
You can also use GitHub submodules to implement a pattern like this, but I don't really trust them for some reason.
Hey! Angel from Endor / Rover :)
Thanks for your feedback! I faced this in the past. As you mentioned, monorepos are more common these days, but multi-repo is an established approach in many teams. The way I "solved" this situation was to move all the related projects into a single folder with a parent AGENTS.md file (CLAUDE.md, etc.). Then, I run Rover / Claude / Gemini on this folder.
However, this is not ideal. Due to the amount of code, it usually misses many things to do. We are currently exploring specific workflows for these use cases, trying to help agents to prepare a complete plan.
Another similar case we are working on is to support spawning the same task across different repositories. This would help teams to apply refactor or changes in different projects at the same time.
Since Sculptor allows you to use custom docker containers (devcontainers), you can check out the other projects in there.
Then your primary project (from Sculptor's perspective) is simply whatever contains the devcontainer / dockerfile that you want it to use (to pull in all of those repos)
It's still a little awkward though -- if you do this, be sure to set a custom system prompt explaining this setup to the underlying coding agent!
(I'm a founder of Imbue, the company behind Sculptor: https://imbue.com/sculptor/ )