> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clinia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Agents as a Service

> Deploying and managing agents through Clinia's service model

# Agent Collaborative Workflows

Because agents are services, they can **collaborate** by sharing memory and delegating tasks.

### Example Collaboration Workflow

<Steps>
  <Step title="Primary Agent Interaction">
    A primary agent handles the clinician conversation and gathers clinical information.
  </Step>

  <Step title="Task Delegation">
    The primary agent hands off billing code suggestions to a specialized background agent.
  </Step>

  <Step title="Shared Memory Access">
    Both agents access a shared core memory, ensuring that the billing agent knows what procedures were discussed earlier.
  </Step>

  <Step title="Result Integration">
    The background agent's recommendations are integrated back into the primary conversation flow.
  </Step>
</Steps>

<Info>
  Collaboration is managed via tool calls and memory updates rather than direct message passing, reducing complexity and improving reliability.
</Info>

***

<Tip>
  Clinia's **Agents as a Service** model empowers organizations to build modular, reusable agents that can scale across applications. Combined with stateful memory and flexible tool integration, it lays the foundation for a robust agentic platform tailored for healthcare.
</Tip>

Traditionally, building an agent meant embedding it directly into an application. Clinia takes a different approach: **agents are services**. You define an agent once and then interact with it through a REST API. This service model simplifies deployment, promotes reusability and centralizes state management.

## Defining Agents as Services

An agent service is identified by an `agent_id` and exposes a simple endpoint:

```http theme={null}
POST /agents/{agent_id}/messages
```

<Info>
  Your application sends user messages to this endpoint, and the agent returns responses. The underlying agent may call tools, update its memory or collaborate with other agents—all of this happens behind the service boundary.
</Info>

## Benefits of the Service Model as a Service

<CardGroup cols={2}>
  <Card title="Single Point of Deployment" icon="rocket">
    You define the agent once on Clinia's platform and then use it across multiple applications (e.g., an EHR interface, a clinician chat app or a scheduling bot). Consistent behaviour is guaranteed because all calls go through the same service.
  </Card>

  <Card title="Persistent State" icon="database" href="/explanation/agents/memory">
    Since agents run on the server, their memory, tools and configuration are persisted by default. You can stop and resume an agent without losing context. See [Agent Memory](/explanation/agents/memory) for details on how memory is structured.
  </Card>

  <Card title="Shared Core Memory" icon="share-nodes" href="/explanation/agents/memory">
    Multiple agents can share the same core memory, enabling collaboration. A background agent that updates billing codes can access the same clinical context as the primary agent that communicates with clinicians.
  </Card>

  <Card title="Template-driven Setup" icon="template">
    Clinia supports templates for common agent types (e.g., general practice assistant, scheduling assistant). Templates provide predefined persona memories and tool configurations, speeding up development while allowing customization.
  </Card>

  <Card title="Centralized Monitoring" icon="chart-line" href="/explanation/agents/monitoring">
    Because agents live on the platform, you can monitor all interactions in one place and apply coaching feedback consistently. See [Monitoring and Benchmarking](/explanation/agents/monitoring) for more.
  </Card>
</CardGroup>

<Note>
  Shared memory also allows agents to coordinate through long‑term knowledge rather than ad‑hoc message passing.
</Note>

## Agent Types

Clinia recognizes several classes of agents, each optimized for different workloads:

<Tabs>
  <Tab title="Background Agents">
    ### Background Agents

    * 🔄 **Run in the background** and perform tasks asynchronously
    * 📋 **Handle tasks** such as filling out forms or generating summaries
    * 🤝 **Share memory** with primary agents but operate independently

    <Info>
      Perfect for automated workflows that don't require direct user interaction.
    </Info>
  </Tab>

  <Tab title="Low-latency Agents">
    ### Low-latency Agents

    * ⚡ **Optimize for rapid responses** using constrained context windows
    * 💾 **Use aggressive memory management** to minimize processing time
    * 🚨 **Suitable for time-sensitive interactions** like triaging urgent patient queries

    <Warning>
      Trade-off between speed and context retention - use for urgent scenarios only.
    </Warning>
  </Tab>

  <Tab title="Workflow Agents">
    ### Workflow Agents

    * 📋 **Execute predefined sequences** of tool calls
    * 🧠 **Use decision points** guided by the language model
    * 👥 **Support human-in-the-loop workflows** where agents can pause for human approval or input
    * 🔄 **Perfect for deterministic tasks** like standardized intake or referral processes

    <Tip>
      Best for structured workflows with clear steps and decision points.
    </Tip>
  </Tab>
</Tabs>

<Info>
  These categories are not mutually exclusive; you can combine their characteristics to suit your use case. The common thread is that all agents are service endpoints with persistent state, tool orchestration and configurable personas.
</Info>