For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

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 — endpoint, auth and client setup

Connect a harness, IDE or pipeline of your own

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

Looking for the individual control-room surface

Pippa Chat (above)

Reviewing identity and tenancy for chat users

Reviewing audit posture

Last updated