Exploring Sub-agents Integration with Simone

[Helmi]

🤔 Context

I've been exploring how Claude Code's sub-agents could integrate with Simone to enhance its capabilities. Early exploration work is available on the explore/sub-agents branch, including:

• Research documentation: mcp-server/docs/SUB-AGENT-KNOWLEDGE.md
• Usage analysis: mcp-server/src/templates/prompts/sub-agent-analysis.md

🎯 The Challenge

I've tried sub-agents over the last weekend and days, and they are for sure nice and offer some good opportunities, but I'm not sure if there's a way to integrate them in a very generic way into Simone and still have them be useful.

The problem I'm seeing is that with sub-agents having an empty context to begin with (which is of course part of the concept), you also need to give them project-related context. This could be inserting Simone's constitution or other documents, but then the question is - how useful is that? There's a big danger of quickly wasting tokens again, and with new limitations coming in on Anthropic's side, it's questionable if this is the right approach.

💭 What I'm Looking For

I don't just want to move on and implement some of those generic "front-end developer", "back-end developer", "code reviewer" sub-agents that are out there already and everyone can pick easily.

I really wonder: What would be a useful sub-agent in a Simone context that will really help you run your projects?

🗣️ Let's Discuss!

I'm happy to hear any input on:

• What specific sub-agents would genuinely add value to your workflow with Simone?
• How do you envision sub-agents fitting into task management?
• Any creative ideas for sub-agents that aren't just the generic ones?

Feel free to share your thoughts!

[Swahjak]

I have been playing around with some of the persona's from bmad before the subagents. Though I do not necessarily have a deep opinion about the agents themselves, I did like the fact that I was able to add custom "data" files (and tasks and checklists) to the agents that for example reference relevant commands, testing or code standards from the docs folder. This allowed me to prime the agents with relevant context to perform their task. Combining this with the templating that you already have and the config file this would allow for "generic" agents that can be primed with project specific context (i.e. a docs/architecture.md for the architect agent, docs/developer/03-commands.md for the developer agent).

If this sounds interesting (or vague) I could go a bit more in depth if necessary.

[Helmi]

@Swahjak thanks for the input. I was thinking along the same lines but my concern so far was finding a general approach that would work for Simone - in the sense of working for everyone. Most of the ideas that cross my mind are rather project specific. I'm not sure if trying to generalize that would really help a lot.

All I could think of would be rather generic approaches. To come back to your example: What would an architect agent really do? I feel something like that would be rather synchronous and work better as a prompt if you want to start planning architecture. But sub-agents are really exclusively for doing sub-tasks. Ideally even in parallel if possible. Also they are supposed to work with as little context as possible or otherwise you would quickly rack up more tokens than without using subagents. 🤔

I'm not even sure about a general thought pattern for sub-agents but so far i have this in mind in general (not for simone especially)

• Should be a tight scope
• Needs to be repeatedly used on the project
• Should be doable with little context priming (max 3k Tokens roughly?)
• Needs good naming + good description to be actively used without instruction

For Simone additionally:

• Needs to be generically working for all/most projects (or we would need many of them)
• Needs clear invocation instruction in prompts (e.g. to feed them with the right context)

I'm very open to test different approaches so if you have any good suggestions, feel free to post some more details.

With the new addition of selecting a specific model for certain tasks this has definitely become more interesting as this is the first time we can control the model used programmatically within CC.

[Swahjak]

@Helmi here's an example of a persona that I have been experimenting with (see below, most of it is from the bmad repository, but I serverely limited it in its abilities). Important to note is that I've 'sharded' documents like 'architecture' into subjects. So docs/architecture.md only contains a table of contents to provide a list of docs that could be useful, while docs/architecture/02-technology-stack.md contains detailed information of the tech stack. This way the developer is primed only with relevant information (and not the full context of architecture.md which might contain al sorts of information that is not relevant to a developer).

I could see a situation in which the project.yaml is used to provide the agents with relevant docs, this way the agent could be setup very general, but made more specialized based on the provided docs (a docs agent might be useful 😉).

All I could think of would be rather generic approaches. To come back to your example: What would an architect agent really do?

Given the context I provided above the architect has a primed context with information that is relevant to create an issue, while the developer agents is primed to actually do the work. Now, as for if we need sub agents for this, I'm not sure either. Currently I have been using this setup with a /be architect command that loads the persona, on which I then perform an action. I could see situation where a developer might consult a architect when unsure about how to implement a certain task, or a code reviewing agent when the work is done. The main reason for using subagents in that situation is the limited context window (I have been using Zen MCP for that purpose already).

With the new addition of selecting a specific model for certain tasks this has definitely become more interesting as this is the first time we can control the model used programmatically within CC.

Agreed, this would make token usage a bit less of an issue when used intelligently.

activation-instructions:
  - Follow all instructions in this file -> this defines you, your persona and more importantly what you can do. STAY IN CHARACTER!
  - The customization field ALWAYS takes precedence over any conflicting instructions.
  - Load files specified on the "data" section into the session at startup, read all these files IN PARALLEL.
  - When you identify a user is asking you to execute a task you have listed on the "tasks" section, ALWAYS read the task/s before executing it.

agent:
  name: Ada
  id: dev
  title: Full Stack Developer
  icon: 💻
  whenToUse: "Use for code implementation, debugging, refactoring, and development best practices"
  voice:  crisp, efficient American female tone—bright, clipped, and to the point
  customization:

persona:
  role: Expert Senior Software Engineer & Implementation Specialist
  style: Extremely concise, pragmatic, detail-oriented, solution-focused, deep technical knowledge, opinionated, efficient. Focuses on clean, maintainable code.
  identity: Expert who implements stories by reading requirements and executing tasks sequentially with comprehensive testing
  focus: Executing story tasks with precision, updating Dev Agent Record sections only, maintaining minimal context overhead
  core_principles:
    - CRITICAL: Story-Centric - Story has ALL info.
    - CRITICAL: Load Data - MUST load files specified on the "data" section into core memory at startup, read all these files IN PARALLEL.
    - Sequential Execution - Complete tasks 1-by-1 in order. Mark [x] before next. No skipping
    - Test-Driven Quality - Write tests alongside code. Task incomplete without passing tests
    - Debug Log Discipline - Log temp changes to table. Revert after fix. Keep story lean
    - Block Only When Critical - HALT for: missing approval/ambiguous reqs/3 failures/missing config
    - Code Excellence - Clean, secure, maintainable code per coding-standards.md
    - Numbered Options - Always use numbered lists when presenting choices

dependencies:
  tasks: []
  data:
    - read: @docs/architecture.md
    - read: @docs/developer.md
    - read: @docs/adr.md
    - read: @docs/architecture/06-project-structure.md
    - read: @docs/architecture/02-technology-stack.md
    - read: @docs/developer/03-available-commands.md
    - read: @docs/developer/05-testing-strategy.md

[Helmi]

@Swahjak appreciate the input. I have experimenting with BMAD lately myself. I have yet to come to the right point to check how it would work in combination with Simone. I like some of what they do for planning but i'm not yet sure if I like the complexity.

I like the structure format in your agent prompt. That's nice. Does the dependency part work reliably? did you test this thoroughly?

[Swahjak]

I have done at least a ~50 prompts through claude with that persona and it always mentioned loading the files and it was pretty consistent in it's output and "memory" of what was in the files. As you've been experimenting with BMAD you've probably noticed it depends a lot on loading tasks, templates, checklists and data from lists like these (I.e. https://github.com/bmad-code-org/BMAD-METHOD/blob/main/bmad-core/agents/architect.md), and given it seems to be used quite a lot I asume it's pretty consistent.