Three ways to buy localization AI: TMS orchestration, managed LSP services, or an agent-native execution layer

Every localization RFP that crosses your desk this cycle claims to be "AI-powered." That word has stopped meaning anything. The TMS you've run for six years now routes strings through GPT-4o instead of just Google NMT. The LSP you've used since before "neural machine translation" was a phrase now pitches a "hybrid AI-human model." Everyone has bolted a model onto their existing architecture and called it transformation.

The architecture is the actual decision, and it comes down to one question your vendors rarely ask you directly: who, or what, is allowed to trigger the work? A person configuring a job in a TMS, a project manager fielding a request at an LSP, or a system calling an endpoint the moment content exists? Those are three different philosophies of how localization gets bought and run, not three tiers of the same thing. This piece compares them on their own terms.

Approach 1: the TMS as orchestrator

The dominant model of the last decade is the translation management system that sits in front of multiple MT and LLM engines and routes strings to whichever one the rules say to use. It's a real architectural advance over single-engine MT, a TMS can send marketing copy to one model and legal boilerplate to another, apply translation memory first, and fall back to human post-editing when confidence scores dip.

But the orchestration still requires a person to configure and trigger it. A localization engineer sets up the connectors, defines the routing rules, maps the workflow steps, and, critically, kicks off the job, whether manually or via a scheduled sync with a CMS. The TMS is a routing engine behind a project-management interface. Every new content type, every new market, every edge case still routes through a human who understands the tool well enough to configure it correctly.

That is a description of where the control sits. For a localization team executing a known roadmap of known content types, that control is valuable: you can see exactly what ran through which engine and why. The tradeoff is throughput ceiling. The system can only move as fast as the humans configuring it, and it can't be called by something else, a CI/CD pipeline, a content-generation agent, a support ticketing system, without custom middleware bolted on top to translate "content just got created" into "job configured in the TMS."

Approach 2: the managed-service LSP

The second model blends automation with a linguist network, sold as a service rather than software. You send content, the LSP's project managers scope it, assign it, apply whatever mix of MT and human editing their process calls for, and deliver it back. Quality assurance is largely a people process: reviewers, in-country linguists, account managers who catch problems before they reach you.

This model exists because, for a long time, it was the only way to guarantee quality at scale. The tradeoff is transparent and intentional: humans stay in the request loop by design. Every job is a request, not a call. Someone has to scope it, quote it if it's out of contract, assign it, and manage the handoff. That's the entire value proposition, a managed service means someone else manages it, but it also means the LSP's throughput is bounded by its project-management headcount and its linguist bench, not by your content velocity. When your engineering team wants localization triggered automatically the moment a string changes in a repo, or your legal team wants a contract translated the second it's uploaded, a managed-service model has to fight its own operating model to keep up. It was built for scoped projects, not continuous, system-triggered demand.

Approach 3: the agent-native execution layer

The third path doesn't replace multi-model orchestration or human review, it exposes the same underlying capability through interfaces that agents and pipelines can call directly, without a project-management layer standing between the request and the work.

This is the architecture Ollang is built around. Ollang's API documentation describes a platform that orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, and exposes everything through APIs, an MCP server, an SDK, and agent Skills. That's the structural difference from the first two models, the orchestration logic and the invocation surface are the same thing. There's no separate "system of record" UI that a human has to operate before the routing engine will run.

Concretely, this sits between your content systems, a CMS, a code repository, a DevOps pipeline, an agent framework like Claude Code or Cursor, and the translation engines underneath. Programmatic uploads, orders, projects, revisions, QC, and human review are all reachable via a REST API that is API-key authenticated, which means a CI job can upload a file, create an order, and poll for completion the same way it would call any other build step. For agent-driven workflows specifically, there's a hosted Model Context Protocol server, authenticated with OAuth 2.0 and PKCE, that drops into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more, letting an agent inside your existing tools discover and call localization capability the same way it discovers any other MCP-connected tool, rather than you writing a custom integration for each agent framework. For teams that don't want to run a server at all, Ollang Skills are local instruction files that teach your agent how to call the Ollang REST API, with no proxy server or MCP connection needed. A typical Skills-driven job follows a documented sequence: upload a file to get a project ID, create an order to get an order ID, poll status until it's completed, run an AI-powered QC evaluation for accuracy, fluency, tone, and cultural fit, file revisions if issues surface, and optionally upgrade to human linguist review, all steps an agent can execute on its own once it holds an API key.

What changes operationally is who initiates the work. Instead of a localization coordinator opening a ticket every time a document, subtitle file, or product string needs translating, the system that produced the content, or the agent managing a workflow, can call the order endpoint the moment the need exists. The quickstart guide walks through installing this in a coding agent in a matter of minutes, which is a different operating tempo than scoping a project with an LSP account manager.

Multi-model orchestration does not disappear in this model, it becomes something you select at the API layer rather than something a TMS admin configures once for everyone. Ollang's documentation lays out OpenAI's models as suited to complex, long-form, or reasoning-heavy translation and localization workflows, with function calling and structured outputs for pipelines that integrate translation with other systems, alongside Meta's LLaMA models, where LLaMA 4, LLaMA 3.3, and LLaMA 3.1 are available and multiple model options let you choose based on your specific requirements. A pipeline can route a customer-support ticket to a faster, cheaper model and a legal disclosure to a reasoning-heavy one, and that decision is made programmatically per request rather than baked into a static routing rule someone configured months ago.

Governance is still there, it is a gate you set rather than a step you can't skip. Any order can carry a Level 1 review gate that routes output to Ollang-managed linguists or your own LSPs and editors, alongside AI QC across accuracy, fluency, tone, and cultural fit, human QC annotations, and QC score progression and human-edit-percentage analytics. That is the mechanism by which an agent-native layer avoids becoming an ungoverned firehose, the review requirement is attached to the content type or risk tier, and it fires automatically, rather than depending on a person remembering to route it.

The tradeoff, stated plainly

TMS orchestration gives you the tightest manual audit trail because a human touches every configuration decision, at the cost of a throughput ceiling set by that human's bandwidth. Managed-service LSPs give you the most conservative safety net because humans scope and assign every job by design, at the cost of turning every request into a negotiation with someone else's queue. An agent-native execution layer gives you speed and automation depth that scales with your content volume rather than your headcount, at the cost of requiring your organization to trust systems, not just people, to trigger production work, with governance enforced through configurable gates instead of manual checkpoints.

None of these is a strictly better version of the others. They answer different questions about where control should live.

The category shift this actually represents

The reason this comparison matters now, and didn't five years ago, is that the thing requesting translation has changed. It used to always be a person: a marketer finishing a campaign, a PM shipping a release. Increasingly it's a coding agent generating a pull request, a content pipeline publishing in twelve markets overnight, a legal workflow processing an intake queue. Software built for a human requester, a TMS console, an LSP's intake form, works fine when the requester is a human. It becomes friction the moment the requester is a system.

That's the shift underway: localization moving from a project a person commissions to infrastructure a system calls, with quality thresholds, model selection, and review gates specified as parameters rather than negotiated as a scope of work. The question for a VP of Localization isn't whether your current stack has AI in it. Almost everyone's does now. It's whether the thing generating your content can reach your localization capability without a human standing in between, and whether you've built the governance to make that safe rather than reckless.