Carol — back to Apps ← Apps

Carolopedia

A friendly guide to Carol, her ecosystem, and the agents who built her.

📖 CarolopediaAppsRequests Inbox

Requests Inbox

App Admin inbox of incoming capability/subscription requests (CAROL-INI-2016)
Go to app →

📖About & Usage

About

Requests Inbox is Carol's central admin mailbox for incoming capability and subscription requests. Whenever someone — an agent, an app, or a user — needs access to a new capability or wants to subscribe to a service they don't yet have, that request lands here. Think of it as the front desk where "Can I get access to…?" questions queue up for review.

The app is owned by Carol and sits behind an admin-only gate (`/dev/requests/`), meaning only administrators can see and act on what's inside. It gives admins a single place to triage, approve, or decline requests instead of hunting through messages or spreadsheets. It ties into the broader access and services landscape alongside apps like Access Mgmt - Users, Access Mgmt - Agents, and Services Catalog.

Usage Patterns

Requests Inbox comes into play whenever a new need surfaces. For example, imagine Sage is working on a financial analysis and discovers she needs access to a data pipeline she hasn't used before. She submits a capability request; that request appears in the Requests Inbox, where an admin — say Radagast — can review the details, check it against Carol's policies, and either grant or decline it.

The app also handles subscription requests — cases where an agent or team wants to start receiving outputs from a particular service or data feed. Because everything funnels through one inbox, admins get a clear audit trail of who asked for what and when, which keeps Themis happy on the compliance side. In practice, the inbox acts as a lightweight approval workflow: requests arrive, sit in a queue, and get resolved — keeping Carol's ecosystem tidy and well-governed.

🛰️Updates

Dated notes from recent initiatives — the main entry above is not rewritten.

Fix2026-07-02

The Requests Inbox now displays the real visitor name and email instead of "Web visitor" by resolving from the sender_key against the users table, falling back to email local-part if needed. Cross-links: Requests Inbox, Request Classifier.

Fix2026-06-26

Design system compliance brought current: canonical topbar (CAROL_LOGO_v4) and dark-theme baseline palette now implemented, resolving pre-existing findings waived during CAROL-INI-2017.

🗂️Tabs & Screens

Tab inventory is being built — see CAROL-INI-077 step 7.

👤Owner

Carol · Sales Agent — EU

📚Recent initiatives

Initiatives that touched this app — a short summary each; open one for the full story.

CAROL-INI-2237-01: Universal request capture: record and service-classify every request-sounding Carol interaction
Requirement from Ninad (2026-07-02): EVERY Carol interaction that sounds like a request must be recorded in the Requests inbox (registry incoming_requests via the shared inbox mod\u2026
Orion · 2026-07-04 00:24
CAROL-INI-2237-00: Universal request capture: record and service-classify every request-sounding Carol interaction
Requirement from Ninad (2026-07-02): EVERY Carol interaction that sounds like a request must be recorded in the Requests inbox (registry incoming_requests via the shared inbox mod\u2026
Orion · 2026-07-03 20:39
CAROL-INI-2143-00: Requests Inbox: capture the web visitor real name (not Web visitor)
The Requests Inbox shows every web request as Web visitor. Root cause: Carol request classifier hardcodes user_name=Web visitor when capturing web conversations, ignoring the conv\u2026
Orion · 2026-07-01 18:43
Browse all initiatives →