---
title: "What apps can do"
description: "A SotaAgents app is a versioned capability package that extends the platform inside an organization and its workspaces. One app can contribute callable tools, reusable skills, n…"
url: "https://sotaagents.ai/manual/developer-guide/what-apps-can-do"
generated_by: "sotaagents-ldp"
docs_index: "https://sotaagents.ai/manual/llms.txt"
locale: "en"
---

# What apps can do

A SotaAgents app is a versioned capability package that extends the platform inside an organization and its workspaces. One app can contribute callable **tools**, reusable **skills**, native UI surfaces, tool-result renderers, hooks, events, prompts, and scoped data access. The platform owns identity, installation, authorization, environment selection, asset delivery, and audit. Your app owns its business logic and app-specific data.

### Why apps exist

SotaAgents ships one assistant, but no assistant can know your CAD drawing standards, your legal-review procedure, or the API of the ERP your company runs on. Rather than growing the core product for every domain, the platform is deliberately incomplete: an app is how a team adds the missing capability, and the platform bends around it. The same shell serves a legal document-review app, a knowledge base, a CAD generator, an office-document builder, and a web-search app precisely because none of that domain logic lives in the core.

Concretely, an app is a directory containing a `manifest.yaml` and — when the capability needs computation, private credentials, external APIs, or durable domain data — an HTTP service you host yourself. Nothing is discovered by inspecting your code. The platform exposes exactly what the manifest declares, for exactly the organization, workspace, and environment it resolved, and refuses anything undeclared.

Two things follow. The assistant gains abilities it could not otherwise have: a **tool** it can call to query or change your systems, a **skill** that teaches it your procedure, a **screen** that renders your data inside the workspace. And your team ships those abilities on its own release cadence, in its own language and runtime, without any change to SotaAgents itself.

> [!NOTE]
> An app is the unit of extension, not a plugin script.
>
> It is versioned, installed per organization, enabled by default in every workspace unless an administrator adds a workspace override, and resolved to one exact environment on every request. That is what makes third-party domain logic safe to run beside first-party features.

Tools

Typed backend actions the assistant can call.

Skills

Instructions and workflows that guide the assistant.

Native UI

Workspace pages, admin screens, inline views, and artifact renderers.

App data

Authorized, environment-scoped storage and backend access.

![Organization App Store containing installed and catalog apps](/manual/assets/developer/app-store-catalog.webp)
_Apps are discovered and installed at organization level, inherit enabled access in workspaces, and support explicit workspace overrides._

![Knowledge Base app running as a native workspace page](/manual/assets/developer/app-workspace-native-ui.webp)
_A production app can provide a complete workspace experience while keeping platform navigation, identity, and access control._

![An expanded Web Search tool result rendered inside a SotaAgents conversation](/manual/assets/developer/web-search-tool-result.webp)
_The expanded app action shows its query, visual previews, and source cards directly inside the conversation._

![An Office App presentation artifact open beside its SotaAgents conversation](/manual/assets/developer/slide-artifact.webp)
_The durable slide artifact opens in the workspace panel while its originating conversation and artifact card remain visible._

### Where app experiences appear

| Manifest surface | Use it for | Typical host |
| --- | --- | --- |
| `page` | Persistent workflows with navigation and state. | Workspace or admin pages. |
| `tool-view` | Render one bound tool call, including optional input-streaming state. | Inside a conversation tool result. |
| `message-part` | Render a bound message contribution inline. | Inside an assistant or user message. |
| `artifact` | A durable output users can reopen, inspect, or export. | Artifact panel. |
| `card` | Compact app-owned status or entry content. | Workspace assistant card slot. |
| `composer-action` | A compact action beside the chat input controls. | `chat.composer.actions`. |
| `composer-panel` | Contextual, app-owned UI that can read and atomically edit the active draft. | `chat.composer.panel`. |

`useComposer` is intentionally available only inside a `composer-panel`. A `composer-action` is a separate surface and does not receive direct draft-edit authority.

> [!NOTE]
> The platform always resolves an exact environment.
>
> Every tool, screen, asset, and data request belongs to Development, Staging, or Production. There is no automatic fallback from one environment to another.