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.

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.
• Claude (Sonnet) for understanding a user's question and drafting a resolution, once that step exists.
• Escalations would file work through the Build Initiatives service rather than touching code directly.

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

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

• Agent-centric modular architecture. Every interaction has an accountable agent owner — the shared principle on the Carolverse 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.

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

• Owned by an agent. Sam 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.

Current

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 — establishing where user questions and issues about the assistant and services belong.

Future (on demand)

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 with Claude.
• Escalation routing — classify an issue to the owning service and hand it off, or file build work through Build Initiatives.
• A ticket/issue store so requests are tracked from open to resolved.
• Visibility — a monitor of open issues and their resolution state.

This service has no agent-facing tools yet, so there is no command path to document.

Operator / owner path: raise a user question or issue with the service owner, Sam, who triages it — resolving directly where possible or escalating to the owning service. Anything needing a code change is filed as build work through the Build Initiatives service. Tools and an HTTP intake path will be documented here once they are built.