The architecture exists to keep the agent roster authoritative and consistent end-to-end:

• One canonical workforce record. Every agent's identity, role, duties and department membership must resolve to a single source of truth, not be re-described per service.
• Onboarding as a defined flow. Adding an agent should follow a repeatable path (define role and duties, place it in a department, register it) rather than ad-hoc edits.
• Headcount that is queryable. Roles and headcount across departments must be reportable on demand.
• Agents, not humans. The workforce being staffed is agents; the model and language reflect that (the service was renamed from Human Resources for exactly this reason).

Most of this is still intended rather than built — see future deliverables.

The intended stack is the shared Carolverse one, used only where it applies to a thin service:

• Python 3 on FastAPI / Flask behind nginx for any app surface.
• SQLite (WAL) for the workforce records, with the registry as the binding source of truth for agent identity.
• Claude (Sonnet/Opus) for any future AI-assisted role/duty drafting.
• systemd / cron if recurring headcount or reconciliation jobs are added later.

Nothing beyond the registry is wired yet.

The intended pattern is a direct instance of Carolverse's agent-centric modular architecture: the service is owned by Athena, who defines and maintains the agent workforce, with the work carried out through her droids once they exist.

• The registry holds agent identity, roles and department membership; this service is the front door for onboarding into and maintaining that record.
• No blocks are defined yet. As the service is built out, each step (onboard, define role, track headcount) becomes a block owned by an agent and carried out by a droid (see the service's team above).

This is the architecture as planned; today the service is a thin owner-plus-purpose shell.

• Single source of truth. The agent roster, roles and headcount come from the live registry, never hand-copied — the shared principle on the Carolverse Architecture page.
• Agent-centric modular architecture. Every future block has an accountable agent and a doing droid.
• Agents are the workforce. The model treats the staff as agents, not humans (the reason for the rename from Human Resources).
• Honest about readiness. While wip, the service states plainly what is intended versus built.

• A new agent can be onboarded through a defined flow — role, duties and department set — rather than by ad-hoc registry edits.
• The agent roster, roles and headcount across departments are queryable and accurate.
• The workforce record stays consistent with the registry as the single source of truth.

• Registry is the source of truth for agent identity, roles and headcount — this service maintains it, it does not duplicate it.
• Owner is an agent. The service is owned by Athena (agt_005); workforce records describe agents, not humans.
• Changes route through the service and its (future) droids — the registry is not hand-edited.

Current

Today the service is a thin work-in-progress shell: its owner Athena and its purpose — onboard, define and maintain the agent workforce — are set, but it has no blocks, droids or tools yet. There is no built capability to list here.

Future (on demand)

The bulk of this service's capability is still ahead:

• An onboarding flow to add a new agent with its role, duties and department.
• A role and duty catalogue describing what each agent does.
• A headcount view of roles across departments, derived from the registry.
• The blocks and droids (owned by Athena) that carry out the above.

This service has no agent-facing tools yet. To operate it, work through its owner Athena and the registry, which holds the agent workforce record. As the onboarding, role-catalogue and headcount blocks are built, their tools and an operator/HTTP path will be added here.