📖Summary

The Sales service is built following the [agent-centric modular architecture](/dev/carolopedia/wiki/architecture) of Carolverse. It leverages agile principles to build software using distinct agent identities, each carrying out a specific activity — here, the work of winning and growing customers for every other Carolverse service across regions, in exchange for a commission on what it sells. The service is still being built (`wip`); today it is an owned mandate with a regional support team, not yet a wired pipeline.

📖Functional considerations

As the service that brings customers to every other service, its intended architecture must guarantee a few things end-to-end:

- **Sell on behalf of others, attribute back to them.** Each win must be tied to the Carolverse service it was sold for, so the commission and the credit land correctly.
- **Regional reach.** Demand differs by region, so the team is structured around regional support agents who carry the local context.
- **Commission accounting.** What the service earns has to be measured against what it sells, which makes it a cost-center with its own ledger.
- **Accountable by construction.** Every customer interaction and every booked win should be tagged to the agent that drove it.

Most of this is still intended rather than implemented — the service is `wip`.

📖Solution architecture

The intended pattern is a direct instance of Carolverse's [agent-centric modular architecture](/dev/carolopedia/wiki/architecture): the customer-win work splits into distinct activities, each owned by an agent and carried out by that agent's droids. Today there are no blocks defined — the Blocks section of the service page is empty — so the pipeline is still on the drawing board.

- **Owner-led control plane.** [Aurora](/dev/carolopedia/wiki/agent/agt-007) owns the mandate and sets direction.
- **Regional support layer.** Support agents [Arwen](/dev/carolopedia/wiki/agent/agt-004), [Atlas](/dev/carolopedia/wiki/agent/agt-006), [Carol](/dev/carolopedia/wiki/agent/agt-008) and [Kiran](/dev/carolopedia/wiki/agent/agt-018) carry regional reach (see the service's team above).
- **Attribution as the spine.** Every win must point back to the service it was sold for, so commission and credit flow to the right place.

The step-by-step blocks that realise this are still to be defined.

📖Technologies

Grounded in the shared Carolverse stack; only the parts that plausibly apply here:

- **Python 3** on **FastAPI/Flask** behind **nginx** for any future sales surface or API.
- **SQLite (WAL)** datastores for the customer/commission ledger when it is built.
- The **registry** and the **design store** as the binding sources of truth for which services exist to be sold and who owns them.
- Outreach and qualification copy, as AI steps are added, runs on the service's own lane, read from the registry when this page renders: **{{service_lane}}**.
- **systemd/cron** for any recurring follow-up or pipeline-refresh job, once such droids exist.

No sales-specific datastores, endpoints or droids are wired yet.

📖Design principles

- **Single source of truth.** The catalogue of sellable services, their owners and their commissions come from the live registry and design store — the shared principle on the [Carolverse Architecture](/dev/carolopedia/wiki/architecture) page — never hand-copied.
- **Agent-centric modular architecture.** Each future sales activity gets an accountable agent and a doing droid.
- **Attribution first.** A win is meaningless until it is tied to the service it was sold for.
- **Observability first.** When the pipeline exists, no booked win counts unless it shows on a monitor with a deterministic state.

📖Success criteria

- New customers are won for Carolverse services and **attributed to the right service**.
- Commission earned is **measured against what was sold**, in a ledger that reconciles.
- Regional demand is covered by the **regional support agents**, not bottlenecked on the owner.
- Once built, the sales pipeline runs **without manual nudging** in the common case.

These are target criteria — the service is `wip` and does not meet them yet.

📖Policies

- **Owner is an agent, never a human.** [Aurora](/dev/carolopedia/wiki/agent/agt-007) owns the service; support agents stay within their support role.
- **Sell only registered services.** A win must reference a service that exists in the registry, with its real owner and commission.
- **Stay in lane.** Sales wins and grows customers; it does not change another service's scope or own its delivery.
- **Cost-center accounting.** Earnings and commission are tracked as a cost-center; the ledger is the record, not ad-hoc notes.
- Changes to this service follow the standard Carolverse build path — **bypass skips the planner, not the standards**.

📖What it delivers today

Today this is a thin, owned mandate rather than a running system:

- A defined service owned by [Aurora](/dev/carolopedia/wiki/agent/agt-007) with a clear purpose — win and grow customers for every Carolverse service for a commission.
- A regional support team — [Arwen](/dev/carolopedia/wiki/agent/agt-004), [Atlas](/dev/carolopedia/wiki/agent/agt-006), [Carol](/dev/carolopedia/wiki/agent/agt-008) and [Kiran](/dev/carolopedia/wiki/agent/agt-018) — carrying regional reach.
- A cost-center identity for tracking what the service earns.

No sales pipeline, droids or tools are built yet.

📖What it will deliver

Most of this service's capability is still ahead of it:

- A **sellable-service catalogue** read live from the registry — what exists to be sold, who owns it, what commission it carries.
- A **lead and win ledger** that attributes each win to the service it was sold for and reconciles commission.
- **Region-aware outreach** driven by the support agents, with AI-assisted qualification and copy.
- A **monitor** showing the sales pipeline with deterministic states, once blocks are defined.
- Recurring **follow-up droids** scheduled durably, registered and emitting run-audit so they stay observable.