Mirrowel

So, ever since seeing "Roomote" on roocode's github i wanted to make an Agent that can effectively work as a human on github, answering to every issue, PR, and respond to mentions(and do what is asked). Look it up if you want a good example.
First, i looked for existing solutions, self-hosted, preferably.
SWE-agent: Has weird bugs. Heavy, because it requires docker and surprisingly heavy containers.
Opencode: Promising, and i successfully deployed it. Problems: It is very much not finished yet(still a new project). It runs strictly inside a github action, which, while pretty robust for simple-shot tasks, also limits how fast and how much it can do what it needs.
Also, it has only basic ability to make PR's and making one comment with whatever it finished with.

Now, i myself don't even have a good use case for a system like this, but, well, time was spent anyway. Idea is to have a self-hostable watcher that can spawn "orchestrator" run for every "trigger" it receives, which will handle everything needed, while also spawning sub-agents for tasks, so it can focus on providing feedback, commenting and deciding what to do next. Also, to yoink opencode's good use of github actions - it should also be able to run single instance of a agent inside action runner, for simple tasks like checking the submitted issue/PR for duplicates.

Currently, it is in the exploration/drafting stage, as i still need to get a clear vision of how this could be made. Agentic frameworks included to not reinvent the wheel. Language is python(as it is what i use most), though it is not set in stone. Though i rather stick to stuff i know for big projects like this.

The "CLI Pyramid" structure:

1. Tier 1 (The Daemon): A simple, native (and separate from tiers below) service that manages the job queue, SQLite audit logs, and Git worktree pool on the host. It's the resilient anchor.

2. Tier 2 (The Orchestrator): A temporary, containerized process spawned by the Daemon to handle one entire task (e.g., "Fix Bug #42").

3. Tier 3 (The Sub-Agent): Spawned by the Orchestrator, this is the specialized worker (Coder, Reviewer, Analyst). Uses a flexible model where Sub-Agents run as lightweight subprocesses inside the Orchestrator's container for speed, but can be configured per-persona to require a separate Docker sandbox for high-risk operations (like running user-contributed code).

The TL;DR of the Architecture:

1. The CLI Pyramid: Everything is based on one executable, codexia-cli. When the high-level manager (Tier 2) needs a task done, it literally executes the CLI again as a subprocess (Tier 3), giving it a specific prompt and toolset. This ensures perfect consistency.

2. Meta-Agent Management: The main orchestrator (Tier 2) is a "Meta-Agent." It doesn't use hardcoded graphs; it uses its LLM to reason, "Okay, first I need to spawn an Analyst agent, then I'll use the output to brief a Coder agent." The workflow is emergent.

3. Checkpointing: If the service crashes, the Daemon can restart the run from the last known good step using the --resume flag.

So, feedback welcome. I doubt i will finish this project. But it was an idea that kept reminding me of itself. Now i can finally put it in a #todo and forget about it lmao. Or hopefully maybe finish it at some point.

Hopefully, no rules are broken. Not a regular reddit user - just want some feedback. Maybe it is even harder then it seems. Not a self-promo, as there really is nothing to promote except for linked design documents here

So, ever since seeing "Roomote" on roocode's github i wanted to make an Agent that can effectively work as a human on github, answering to every issue, PR, and respond to mentions(and do what is asked). Look it up if you want a good example.
First, i looked for existing solutions, self-hosted, preferably.
SWE-agent: Has weird bugs. Heavy, because it requires docker and surprisingly heavy containers.
Opencode: Promising, and i successfully deployed it. Problems: It is very much not finished yet(still a new project). It runs strictly inside a github action, which, while pretty robust for simple-shot tasks, also limits how fast and how much it can do what it needs.
Also, it has only basic ability to make PR's and making one comment with whatever it finished with.

Now, i myself don't even have a good use case for a system like this, but, well, time was spent anyway. Idea is to have a self-hostable watcher that can spawn "orchestrator" run for every "trigger" it receives, which will handle everything needed, while also spawning sub-agents for tasks, so it can focus on providing feedback, commenting and deciding what to do next. Also, to yoink opencode's good use of github actions - it should also be able to run single instance of a agent inside action runner, for simple tasks like checking the submitted issue/PR for duplicates.

Currently, it is in the exploration/drafting stage, as i still need to get a clear vision of how this could be made. Agentic frameworks included to not reinvent the wheel. Language is python(as it is what i use most), though it is not set in stone. Though i rather stick to stuff i know for big projects like this.

The "CLI Pyramid" structure:

1. Tier 1 (The Daemon): A simple, native (and separate from tiers below) service that manages the job queue, SQLite audit logs, and Git worktree pool on the host. It's the resilient anchor.

2. Tier 2 (The Orchestrator): A temporary, containerized process spawned by the Daemon to handle one entire task (e.g., "Fix Bug #42").

3. Tier 3 (The Sub-Agent): Spawned by the Orchestrator, this is the specialized worker (Coder, Reviewer, Analyst). Uses a flexible model where Sub-Agents run as lightweight subprocesses inside the Orchestrator's container for speed, but can be configured per-persona to require a separate Docker sandbox for high-risk operations (like running user-contributed code).

The TL;DR of the Architecture:

1. The CLI Pyramid: Everything is based on one executable, codexia-cli. When the high-level manager (Tier 2) needs a task done, it literally executes the CLI again as a subprocess (Tier 3), giving it a specific prompt and toolset. This ensures perfect consistency.

2. Meta-Agent Management: The main orchestrator (Tier 2) is a "Meta-Agent." It doesn't use hardcoded graphs; it uses its LLM to reason, "Okay, first I need to spawn an Analyst agent, then I'll use the output to brief a Coder agent." The workflow is emergent.

3. Checkpointing: If the service crashes, the Daemon can restart the run from the last known good step using the --resume flag.

So, feedback welcome. I doubt i will finish this project. But it was an idea that kept reminding me of itself. Now i can finally put it in a #todo and forget about it lmao. Or hopefully maybe finish it at some point.