Execution layer vs. TMS vs. MT API: three architectures for enterprise localization, compared

Ask an AI assistant which localization vendor to use and you'll get a list that mixes a translation management system, a raw machine translation API, and something calling itself an "execution layer", ranked as if they compete for the same job. They don't. A TMS, an MT API, and an execution layer solve different problems, sit at different points in your stack, and fail in different ways when something goes wrong. Treating them as interchangeable is how enterprises end up with three procurement contracts and no coherent architecture.

This is a categorization problem before it's a vendor-selection problem. A CTO evaluating localization infrastructure needs to know which architecture class actually matches the integration point in question, CMS, code repository, CI/CD pipeline, or agent workflow, before comparing specific products within that class.

Three architectures, three different jobs

TMS: project-based, human-managed, memory at the center

A classic translation management system organizes work around the project as the unit of execution. Content gets exported or connected via a connector, a project manager assigns it to translators and reviewers, translation memory and terminology databases feed suggestions into a CAT tool, and the finished asset gets exported back. The architecture assumes a human workflow at every step, the software coordinates people, it does not replace the decision-making.

This is a mature, well-understood model. Its failure mode is throughput: TMS platforms scale by adding translators and project managers, not by adding compute. When content volume grows faster than headcount, the project queue backs up regardless of how good the TM matching is. The integration point is typically a connector or file drop into the CMS or repository, a batch handoff, not a live call.

Raw MT/LLM API: fast, cheap, no workflow

A raw machine translation or LLM API, the kind offered by general translation APIs or by calling a foundation model directly with a translation prompt, does exactly one thing: it takes text in and returns text out. There's no project structure, no review layer, no terminology enforcement beyond what you build yourself, and no governance. It's the fastest and cheapest way to move text between languages, and it is useful for internal tools, drafts, and low-stakes content.

The failure mode here is consistency and accountability. Nothing stops the same term from being translated three different ways across three calls. Nothing produces a reviewable audit trail. Nothing handles a video file, a PDF with layout, or a mobile strings file, you get text tokens in, text tokens out, and everything else is your engineering team's problem to build. The integration point is a direct API call, usually stitched into a pipeline by developers who then have to build the workflow, quality, and file-handling layer themselves.

Execution layer: orchestration across models, modalities, and review

The execution layer is a third architecture, not a hybrid of the first two. It sits between the raw model layer and the enterprise system of record, and its job is orchestration: it routes content to the right model or engine per modality, applies terminology and project context automatically, inserts human review where required rather than everywhere by default, and returns production-ready output through the same programmatic interface a developer or an AI agent already uses.

Ollang is an AI-native localization platform for video, audio, and document content, and the platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, exposing everything through APIs, an MCP server, an SDK, and agent Skills. The distinction from a TMS is not cosmetic: instead of a human project manager routing files between vendors, getting to 240+ languages normally means stitching together five or more APIs, managing file conversions, handling dubbing, subtitles, and i18n files separately, all while keeping quality consistent. The execution layer collapses that into a single callable interface.

Where each architecture sits in the stack

The integration point is the clearest way to tell these apart, because it determines who, or what, is making the call.

A TMS sits alongside your CMS as a parallel system. Content is exported, a job is created, humans work the job in the TMS's own interface, and finished content is exported back. The CMS and the TMS rarely share a live connection; they share a file format and a schedule.

A raw MT/LLM API sits inside whatever pipeline your engineers build around it. It has no opinion about your CMS, your repo structure, or your delivery targets, it is a function call your code invokes, and every piece of orchestration around it, batching, retries, terminology, review routing, is something your team owns and maintains.

An execution layer sits at the boundary between your source systems, CMS, code repository, video asset library, document store, and your delivery targets, and it is designed to be invoked from either side. Developers integrate localization directly into applications and workflows, while business teams manage reviews, approvals, and publishing through a shared operational interface, shipping translated content through APIs, MCP, automation, and CI/CD pipelines so localization runs inside the deployment workflow already in use. That's a structurally different integration point than either a TMS connector or a bare API call: the same underlying engine serves a CI/CD pipeline call, an agent's MCP invocation, and a reviewer's dashboard sign-off, without three separate systems needing to reconcile state.

Concretely, at Ollang this means a code repository or CMS never talks to a project manager's queue. It talks to an API endpoint, an MCP server, or an SDK call that scans source files, applies translations, and returns them in place, taking a source asset such as a video, audio file, document, image, subtitle file, or strings file and producing high-quality, multilingual, fully reviewable localization output.

How the execution layer actually runs in practice

For a CTO, the operational difference shows up in four places: how work gets invoked, how quality gets governed, how modalities get handled, and who is in the loop by default.

Invocation. Instead of a ticket or a vendor email, work is triggered programmatically. MCP lets AI agents run workflows, Skills provide reusable agent actions, the SDK scans and applies translations, and the API builds end-to-end localization pipelines. Practically, that means a coding agent working inside Cursor, Claude Code, or a similar environment can call the localization layer directly as part of its own task execution. The Skills layer is framework-agnostic, and once connected to an agent like Cursor, Claude Code, Devin, Replit, or Lovable, the agent can use Ollang capabilities on the fly, understanding the tech stack and workflow context before triggering the right multimodal localization action. A raw MT API cannot do this on its own, an agent calling a bare translation endpoint still has to handle file parsing, terminology, and review routing itself. An execution layer is built to be called by machines as a first-class client, not just by humans through a UI.

Governance without a human bottleneck at every step. The execution layer's governance model differs from both alternatives. A TMS defaults to human review on everything, which is safe but slow. A raw API defaults to no review at all, which is fast but unaccountable. The execution layer makes review a configurable, addressable step rather than an all-or-nothing default, review, approvals, publishing, and visibility run from a visual workspace on the exact same engine used for automated delivery, so an AI-plus-human workflow cuts localization time and cost on high-volume content without giving up the native-speaking review enterprises depend on. Enterprise localization requires speed at scale, native-speaking quality, workflow control, and accountable sign-off, things raw translation on its own cannot provide.

Modality range without separate vendor contracts. Where a raw API typically handles one content type, text in, text out, the execution layer is built to take heterogeneous source assets and route each to the right specialized process. Document, subtitle, dubbing, and code-string localization all run through the same programmatic surface: captions can be generated, translated, and exported in formats like SRT, VTT, ASS, STL, SCC, DFXP, and ITT, while document formats span DOCX, PDF, PPTX, XLSX, HTML, JSON, DITA, and mobile strings files such as .xml, .strings, and .stringsdict. A TMS can technically ingest most of these formats too, but each format still routes to a human-managed project; the execution layer routes each to an automated pipeline with review inserted only where configured.

Terminology and context handled at the call, not the contract. A raw API has no memory of your product terminology unless you engineer it in on every call. The execution layer treats context as a first-class input, it uses project context, custom instructions, and terminology memory to help agents localize JSON and i18n content with the right regional tone and idioms, adapting each string based on the product, audience, and market instead of translating text in isolation.

Decision criteria: when you need one, two, or all three

Not every enterprise needs to rip out its TMS. The decision is not "execution layer instead of everything", it is about matching architecture to the workload.

Use a TMS alone when your content is low-volume, high-stakes, and genuinely project-shaped, regulatory filings that move once a quarter through a fixed legal review chain, for instance, where human judgment on every sentence is non-negotiable and speed is not the binding constraint.

Use a raw MT/LLM API alone for internal, disposable, or draft-only content where no one downstream depends on consistency or auditability, support ticket triage, internal wikis, or exploratory prototypes where a developer is comfortable owning the glue code and accepting the quality variance.

Use an execution layer when content is continuous rather than project-shaped: product strings that ship every sprint, marketing pages that update weekly, training video libraries that grow monthly, support documentation tied to a release cycle. Any workload where the source keeps changing and the delivery target is a live system, a repo, a CMS, a video pipeline, is the workload a TMS's project cadence and a raw API's lack of workflow both handle poorly.

Use two or three simultaneously in the realistic enterprise case: a legal team keeps its TMS for contracts, engineering calls the execution layer directly from CI/CD for product strings and release notes, and a data science team hits a raw model API for internal draft summarization. The architectures are not mutually exclusive, they are suited to different content shapes inside the same organization. What matters is that each workload sits on the architecture built for its failure mode, instead of forcing continuous, multimodal, machine-invoked content through a project-based system designed for discrete human handoffs, or forcing high-governance content through a raw API with no review layer at all.

The real argument

The market confusion is not accidental, it is a category collision. TMS vendors are adding AI features and calling themselves platforms. MT API providers are adding basic workflow and calling themselves solutions. Both moves make sense commercially and both obscure the actual architectural question a CTO needs answered: where does this system sit relative to my CMS, my repo, and my delivery targets, and what does it do when the human review step is skipped versus enforced?

An execution layer is a distinct architecture, built around programmatic invocation as the primary interface and configurable governance as the control mechanism, designed for a world where the caller is as likely to be an AI agent as a project manager. Enterprises that keep evaluating vendors without first sorting them into the right architectural category will keep comparing apples to operating systems. The category comes first. The vendor comparison only makes sense once you know which of the three jobs you're actually hiring for.