📖Summary

The Customer Support 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, fielding user questions and issues about the assistant and the other services, resolving what it can and escalating the rest. This is an early, work-in-progress service: the intended shape is below, and most of its capability is still to be built.

📖Functional considerations

Support sits in front of every other service, so its architecture is shaped by what it must guarantee end-to-end — even though most of it is not built yet:

- **One front door for help.** A user question or issue about the assistant or any service should land in one place rather than being lost across surfaces.
- **Resolve, then escalate.** Straightforward questions should be answered directly; anything that needs a code change or another team should be handed off with context, not dropped.
- **Accountable by construction.** Every interaction is owned by an agent, so a request is never anonymous and an escalation always has a destination.
- **Honest about state.** Until the resolution and escalation paths exist, the service must say plainly what it can and cannot do today.

📖Solution architecture

The intended pattern is a thin intake-and-route layer in front of the rest of Carolverse, built as a direct instance of the [agent-centric modular architecture](/dev/carolopedia/wiki/architecture): the owning agent fields a request, and routing is a deliberate handoff to whichever service owns the problem.

- **Single intake.** One path receives a user question or issue about the assistant or a service.
- **Triage then act.** The request is either answered in place or classified to the owning service and escalated.
- **Escalation as a handoff, not a fix.** Support never changes another service's code; it raises the issue to that service's owner or files build work.

The service currently has no blocks or droids — this control plane is described, not yet implemented.

📖Technologies

Grounded in the shared Carolverse stack; only the parts that plausibly apply to a thin support service:

- **Python 3** on **FastAPI** / **Flask** behind **nginx**, when the service surface is built.
- **SQLite (WAL)** for the eventual ticket/issue store.
- The **registry** and **design store** as the binding sources of truth for which services and agents an issue can be routed to.
- Understanding a user's question and drafting a resolution, once that step exists, runs on the service's own lane, read from the registry when this page renders: **{{service_lane}}**.
- Escalations would file work through the [Build Initiatives](/dev/carolopedia/wiki/service/build-initiatives) service rather than touching code directly.

None of this is wired yet — it is the intended stack, not the current one.

📖Design principles

- **Agent-centric modular architecture.** Every interaction has an accountable agent owner — the shared principle on the [Carolverse Architecture](/dev/carolopedia/wiki/architecture) page.
- **Single source of truth.** Routing reads which service owns a problem from the live registry, never a hand-kept list.
- **Resolve over escalate, but escalate cleanly.** Answer what can be answered; hand off the rest with full context.
- **Honesty about readiness.** A work-in-progress service states plainly what it does not yet do.

📖Success criteria

- A user question or issue about the assistant or any service has **one clear place to go**.
- Answerable questions are **resolved directly**; everything else is **escalated to the owning service** with context.
- No request is **dropped or anonymous** — each has an owner and an outcome.
- The service is **honest about its readiness**, surfacing only what it can actually do.

📖Policies

- **Owned by an agent.** [Sam](/dev/carolopedia/wiki/agent/agt-026) owns the service; every interaction is tagged to an agent, never a human.
- **Support resolves and routes — it does not change other services.** Fixes are escalated to the owning service or filed as build work, never made by editing another team's code.
- **Honesty over coverage.** While the service is work-in-progress, it states clearly which capabilities exist and which are still being built.

📖What it delivers today

Honestly: very little is built today. The service is defined with an owner and a purpose, but no resolution or escalation machinery is live yet.

- A named, owned support service — owned by [Sam](/dev/carolopedia/wiki/agent/agt-026) — establishing where user questions and issues about the assistant and services belong.

📖What it will deliver

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

- An **intake surface** where users raise questions and issues about the assistant or any service.
- **Triage and resolution** — answer straightforward questions directly, drafted on the service's own lane: **{{service_lane}}**.
- **Escalation routing** — classify an issue to the owning service and hand it off, or file build work through [Build Initiatives](/dev/carolopedia/wiki/service/build-initiatives).
- A **ticket/issue store** so requests are tracked from open to resolved.
- **Visibility** — a monitor of open issues and their resolution state.