> For the complete documentation index, see [llms.txt](https://docs.mediafier.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediafier.ai/platform/slack-and-teams.md).

# Where Agents Run

Where agents run: the agent-first MCP surface, team chat, and the Pippa control room on one gateway and one audit trail.

> **Same gateway, same governance, same audit trail — wherever the work happens.** Agent-first integration (your harness, IDE, or pipeline over MCP) is how an AI tool reaches Mediafier. Team chat and the Pippa control room are how people do. They are different jobs on one platform, not a ranking.

## Surfaces at a glance

| Surface               | Who uses it                 | What it is for                                                                  |
| --------------------- | --------------------------- | ------------------------------------------------------------------------------- |
| **Agent-first (MCP)** | Agents, harnesses, IDEs, CI | Using Mediafier from an AI tool — see [MCP Access](/connect/mcp-access.md)      |
| **Slack & Teams**     | Teams working in a channel  | Team-native conversational operations (this page)                               |
| **Pippa Chat**        | Individual operators        | A web/mobile control room to run, watch, and direct media work conversationally |

## Pippa Chat

Pippa is the control-room interface, not the front door: a consolidated web/mobile UI where a single operator can ask the platform to perform a media task in natural language, watch the run unfold (plan, tools called, results, costs), approve, override, or correct the agent mid-run, and drill from a task into the underlying Evidence Cards and trace-correlated audit rows. It uses the same gateway, governance, and audit chain as every other surface.

## Slack & Teams

When the work happens in a team channel, Mediafier shows up there.

***

## Why a chat surface

Most media operations are not solo. They are coordinated in shared team channels... content review threads, ingest queues, brand-safety escalations, distribution sign-offs. The work people already do in Slack and Teams is the work that benefits most from a governed AI agent reaching it directly.

The Slack & Teams surface is purpose-built for that flow. An agent joins the channel; the team converses with it the way they converse with each other; every action the agent takes is identity-bound, metered, and audited.

***

## Two different things share the word "Slack"

Slack and Microsoft appear in Mediafier twice, and the two are not ranked against each other — they answer different questions.

|               | The app                           | As an MCP client                          |
| ------------- | --------------------------------- | ----------------------------------------- |
| **Slack**     | Mediafier in your Slack workspace | Slackbot connects to the gateway          |
| **Microsoft** | Mediafier in Teams                | Microsoft Copilot connects to the gateway |

The right-hand column is **agent-first inside those hosts**. When Slackbot or Microsoft Copilot connects to the Mediafier MCP endpoint, the host is the agent and Mediafier is the governed capability plane — the same path Claude Code and Cursor take, reached from a different place. Mediafier does not own the host's conversation loop in that mode.

The left-hand column is this page: Mediafier's own application inside the workspace, where the value is proactive notification, approvals landing next to the people who grant them, and multi-operator threads.

## Where each surface fits

| If you want to…                                       | Go to                                                                  |
| ----------------------------------------------------- | ---------------------------------------------------------------------- |
| Use Mediafier from an AI tool you already have        | [MCP Access](/connect/mcp-access.md) — endpoint, auth and client setup |
| Connect a harness, IDE or pipeline of your own        | [Agent-First Access](/connect/agent-first-access.md)                   |
| Get Mediafier updates and collaborate in a native app | **Slack & Teams** — this page                                          |

***

## What chat is good at

| Use case                                 | Why chat                                                                       |
| ---------------------------------------- | ------------------------------------------------------------------------------ |
| Approvals routed to the right humans     | The approval lands in the channel where the relevant operators already are.    |
| Notification + drill-down                | The agent posts a status, with a thread for follow-up.                         |
| Multi-operator collaboration             | Two operators can react to the same run inside the same thread.                |
| Triage from existing escalation channels | The agent enters the channel where escalations already happen, not a new tool. |

***

## What chat shares with every other surface

The same gateway runs every chat-originated tool call. That means:

* **Identity** — the chat user's identity is mapped server-side to a Mediafier principal via Auth0. The agent never trusts a client- supplied identity claim.
* **Org isolation** — the tenant context is derived from the resolved principal. A user in the wrong org cannot reach another org's tools via chat.
* **Authorization** — only tools the chat user is permitted to invoke are reachable.
* **Rate limiting** — chat-originated calls share the org's rate budget.
* **Billing** — every tool call is metered against the org's credit ledger.
* **Audit** — every action produces an immutable audit row and a trace ID. A run kicked off from a Slack thread is indistinguishable from a run kicked off from a CLI as far as the audit chain is concerned.

Chat is presentation; the chain underneath is the same chain.

***

## What chat is not

* It is not a separate identity domain. The chat user is mapped to a real Mediafier principal; chat does not get a fast-path bypass.
* It is not a privileged client. Same gateway, same audit, same credits.
* It is not the only place to operate the platform. Agents can be driven from any harness; individual operators can use Pippa.

***

## Where to go next

| If you're…                                      | Read next                                                                                                                                        |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Engineering an integration                      | [Agent-First Access (CLI + MCP)](/connect/agent-first-access.md)                                                                                 |
| Looking for the individual control-room surface | Pippa Chat (above)                                                                                                                               |
| Reviewing identity and tenancy for chat users   | [Identity & Authentication](/trust/identity-and-authentication.md), [Multi-Tenant Organization Model](/trust/multi-tenant-organization-model.md) |
| Reviewing audit posture                         | [Audit, Observability & Compliance](/trust/audit-observability-and-compliance.md)                                                                |
