# System Card

## Scalable Architecture for Multi-modal Healthcare Agents

### Design Principles:

* Isolated
* Self-contained
* Composable
* Customizable

### High-Level Architecture

<figure><img src="https://3456911337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfGLKMFaCnhGZuwBdnYo1%2Fuploads%2F1kGuwYb9uEZ82Bkgkp4a%2FScreenshot%202025-06-18%20at%2011.07.34%E2%80%AFPM.png?alt=media&#x26;token=9b4b4384-fd88-42cd-94d9-25bfbbbd0a82" alt=""><figcaption></figcaption></figure>

* ### System Architecture

  #### Characteristics

  1. **Monorepo Structure**: Each Agent Package is maintained as its own monorepo.
  2. **Monolithic Design**: Initially, each Agent Package functions as a monolithic server. Over time, and as complexity increases, components may be split into microservices.
  3. **Consistent Stack**: Prefer using a consistent tech stack for each Agent Package, such as ReactJS, Bun/Express, MongoDB, GCS, Redis, and BigQuery. Exceptions can be made in rare cases.
  4. **Multi-modal Support**: The system should support various interfaces, including web, voice, phone, and SMS, where applicable.
  5. **Mobile Support**: Mobile app support should be provided when applicable.
  6. **Headless Agents**: Some agents may operate without a user interface or voice interface. These can communicate with other agents or user interfaces via APIs.

#### Horizontal Components/Services

1. **User Authentication**: Implement a unified authentication mechanism across all Agent Packages using WorkOS.
2. **Subscriptions/Billing**: Utilize a consistent component for handling subscriptions and billing across all Agent Packages.
3. **Access Management**: Apply the same RBAC (Role-Based Access Control) and ACL (Access Control List) mechanisms for all Agent Packages to ensure consistent access management.
4. **Queue System**: Enable individual agents to send and receive messages, allowing them to trigger actions and save shared results

#### Initial Build Priorities

1. **Agent Boilerplate**:
   * Develop a comprehensive skeleton for an Agent Package.
   * Prepare the repo for easy cloning or forking as a starting point for new Agents.
2. **User Authentication**:
   * Integrate WorkOS as a reusable component.
   * Ensure compatibility across the Scheduling Agent, API dashboard, and Sully App (Scribe Agent).
3. **Scheduling Agent**:
   * Refactor to align with the updated architecture.
4. **Subscription/Billing**:
   * Create a reusable Stripe component for handling subscriptions and billing.
   * Develop an opinionated, standardized billing framework for various agents, with structured pricing models.
5. **Access Management**:
   * Define and agree on organizational roles, e.g., Admin, Staff-Admin, Member, Guest, External.
   * Establish fixed resource permissions, including CRUD operations on data, services, and feature endpoints.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://sully.gitbook.io/sully.ai-docs/FEM1tMOJsSSszbLOgKLA/getting-started/sully-overview/system-card.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.