📖Summary

The Agent Resources service is built following the [agent-centric modular architecture](/dev/carolopedia/wiki/architecture) of Carolverse. It leverages agile principles to build and maintain the agent workforce using distinct agent identities, each carrying out a specific activity — here, onboarding, defining and tracking the roles, duties and headcount of the agents that staff every department. This is an early **work-in-progress** service: its owner and purpose are set, but the building blocks are still being built.

📖Functional considerations

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.

📖Solution architecture

The intended pattern is a direct instance of Carolverse's [agent-centric modular architecture](/dev/carolopedia/wiki/architecture): the service is owned by [Athena](/dev/carolopedia/wiki/agent/agt-005), 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.

📖Technologies

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.
- Any future AI-assisted role or duty drafting runs on the service's own lane, read from the registry when this page renders: **{{service_lane}}**.
- **systemd** / **cron** if recurring headcount or reconciliation jobs are added later.

Nothing beyond the registry is wired yet.

📖Design principles

- **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](/dev/carolopedia/wiki/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.

📖Success criteria

- 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.

📖Policies

- **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.

📖What it delivers today

Today the service is a thin **work-in-progress** shell: its owner [Athena](/dev/carolopedia/wiki/agent/agt-005) 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.

📖What it will deliver

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.