> 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/overview/where-mediafier-fits.md). # Where Mediafier Fits How Mediafier sits as the vertical media layer alongside the models, agent runtimes, workflow, and data platforms a team already uses. > **A map of Mediafier against the stack a modern media organization is already buying.** This page is for evaluators positioning Mediafier alongside the rest of their AI investment — frontier models, agent runtimes, workflow platforms, data systems — not a competitive matrix and not a ranking of named vendors. *** ## The five layers of a modern AI stack A media organization adopting AI typically buys (or builds) capability across five horizontal layers. Each layer has its own category of vendors. The layers are independent: a customer can swap a frontier model without re-platforming their agent runtime, or change agent frameworks without touching the data platform underneath. | Layer | What this layer supplies | Where customers usually source it | | -------------------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | | **Vertical domain layer** | Industry-specific tools, governance, evidence, and outcomes. **This is where Mediafier sits** for the media vertical. | Build, partner, or buy. Mediafier is the buy option for media. | | **Agent runtimes** | Plan/act loops, tool-call orchestration, agent supervision. | Agent frameworks and orchestrators the engineering team picks. | | **Workflow & integration** | Trigger-based automations, data-pipeline plumbing, low-code glue. | Workflow automation platforms and data-pipeline orchestration tools. | | **Data & knowledge** | Lakehouses, vector indices, retrieval-augmented stores. | Data platforms a customer already operates for analytics and ML. | | **Foundation models** | Frontier model APIs and self-hosted weights. | Model providers a customer's procurement has already approved. | The four layers below the vertical domain layer are horizontal: they serve every vertical, not just media. The vertical layer is what turns that horizontal substrate into work a media organization can actually ship. Without it, every media team rebuilds the same media-domain primitives — bundles, versions, provenance, governance, evidence — on top of whatever horizontal stack they already bought. *** ## How Mediafier integrates with each layer Mediafier is engineered to plug into whichever stack the customer already runs. The integration shape at each layer: * **Agent runtimes.** Mediafier exposes its governed tools as MCP servers callable from any MCP-aware harness. The same gateway is the single endpoint for every agent platform, IDE, or CLI. No framework lock-in; the customer keeps their existing agent runtime. * **Workflow & integration.** The same MCP surface appears in workflow-automation tools as a high-value node — a trigger from the customer's existing automation can fire a governed MediaClaw run directly, with per-call metering and audit. * **Data & knowledge.** Every governed call produces a labeled, traced, cost-attributed event consumable by the customer's existing data platform. Analytics, observability, and downstream ML investments compound on Mediafier's telemetry rather than needing a parallel pipeline. * **Foundation models.** MediaClaws are model-agnostic. The customer's approved models drive the cognitive rig; Mediafier governs how those models call into media work. Swapping a model is a config change, not a re-platforming. In each case Mediafier sits *above* the layer and *uses* it — never replaces it. *** ## What customers keep when they adopt Mediafier A media organization building on Mediafier does not have to migrate off any of the horizontal vendors they already trust: * The **brain** — foundation models — stays where it is. * The **data** — lakehouses, vector indices, knowledge stores — stays where it is. * The **workflow plumbing** — automation, pipelines, integration glue — stays where it is. * The **agent runtime** — whichever framework the engineering team picked — stays where it is. What changes is that media work — bundles, versions, provenance, governance, evidence — becomes agent-addressable through one governed gateway, instead of being rebuilt per project on top of whatever stack is already in place. The practical effect for procurement: Mediafier is designed to sit alongside existing vendors. It adds a vertical layer; it does not displace a horizontal one. *** ## What customers gain over building the layer in-house The alternative to buying the vertical layer is building it: an internal team writes the media-domain governance, the evidence model, the multi-tenant boundaries, the per-call billing, the learning loop, and the governed discovery surface from scratch on top of horizontal vendors. That is a multi-quarter, IP-intensive investment. Mediafier delivers the same capability set as a shared platform: * A library of governed media tools any agent can call. * A governed discovery surface that decouples agents from internal systems of record. * A control plane that enforces identity, organization context, authorization, rate limiting, billing, and audit on every call. Built once, governed once, reused across every customer engagement. Fixes and guards added for one customer apply to the shared platform; customer content never does (see [Learning & Data Boundaries](/trust/learning-and-data-boundaries.md)). Mediafier complements the models, agent harnesses, workflow systems, data platforms, and media systems a team already uses; it provides the governed media layer between them. *** ## What this page does not cover * **It does not rank or compare named vendors.** Specific vendor positioning, partner economics, or go-to-market alignment with a named platform is handled in the partner agreement and partner- facing collateral, not in customer documentation. * **It does not promise integrations with every named runtime.** The platform's contract is MCP over HTTPS and standard agent-runtime patterns; concrete integration recipes live with each harness or framework's own documentation. * **It does not commit to a specific data-platform integration.** Per- call telemetry is exportable as structured events; specific pipelines are customer-side configuration. *** ## Where to go next | If you're… | Read next | | -------------------------------------------- | ----------------------------------------------------------- | | Looking at the broader platform architecture | [Platform Architecture](/platform/platform-architecture.md) | | Looking at how to integrate | [MCP Access](/connect/mcp-access.md) | | Looking at the marketplace ecosystem | [The Marketplace](/partners/marketplace.md) | | Looking for procurement readiness | [Enterprise Readiness](/trust/enterprise-readiness.md) |