# Team Operating Model

## Purpose
This document describes the default operating model for the A IMF agency team: how profiles are cloned, how roles are assigned, and how communication should flow.

## Core Idea
Start with a small, basic base profile that contains the shared defaults needed by most agents. Then clone it for each specialized role so the majority of settings are already in place.

This reduces setup work and keeps behavior consistent across the team.

## Suggested Base-and-Clone Pattern
1. Create a baseline profile from `default`.
2. Configure shared settings once in that baseline profile.
3. Clone that profile for each role-specific agent.
4. Customize only the settings that differ for that role.

Example:
```bash
hermes profile create team-base --clone-from default
hermes profile use team-base
hermes config edit
```

Then clone from `team-base` into role profiles such as:
- `ethan-pm`
- `luther-architect`
- `benji-dev`
- `ilsa-qa`
- `william-db`
- `grace-frontend`
- `angela-research`
- `paris-research`

## Role Assignment Model
- **Ethan-pm** — orchestrator, task intake, prioritization, and final coordination
- **Luther-architect** — senior architecture and technical tradeoffs
- **Benji-dev** — junior implementation, scoped feature work, refactors
- **Ilsa-qa** — quality assurance, verification, acceptance checks
- **William-db** — schema, migrations, query tuning, data design
- **Grace-frontend** — UI implementation, client-side behavior, presentation
- **Angela-research** — research and analysis track A
- **Paris-research** — research and analysis track B

## Communication Model
### Ethan as the Orchestrator
Yes: the PM/orchestrator role can be treated as the single coordination point for the whole team.

In that model:
- The human communicates with **Ethan** as the front door.
- Ethan decomposes work and delegates to the specialist roles.
- Specialists return their outputs to Ethan.
- Ethan consolidates the results into a final response or decision.

This keeps the workflow simple for the human while preserving role specialization behind the scenes.

## Preferred Testing Model
The preferred path is:
1. **Luther-architect** defines the implementation with a clear test script or test plan.
2. **Angela-research** and **Paris-research** execute the scripted verification duties together when the plan is explicit enough.
3. **Ilsa-qa** reviews both outputs, compares them, and judges quality.
4. **Ethan-pm** resolves differences and merges findings into the final decision.

This keeps testing efficient and avoids requiring a dedicated tester unless the test design itself is complex.

### When a dedicated tester is needed
If the architect cannot produce a sufficiently clear test script, or if the workflow needs exploratory test design, then add a dedicated tester profile later.

## Research Workflow
For research-heavy tasks:
1. Send the same question to both **Angela-research** and **Paris-research**.
2. Let them use different models or different reasoning styles.
3. Have **Ethan-pm** and **Ilsa-qa** compare the outputs.
4. Choose the best result or synthesize them into one final report.

This is a good pattern when you want diversity of thought and a higher-confidence final answer.

## Future Expansion
If a project needs more roles later, add them as new cloned profiles instead of changing the base team structure.

That keeps the system easy to understand and extend.