Ticket-based TMS vs. callable execution layer: two architectures for enterprise localization

Every VP of Localization has sat through the same demo cycle. A vendor shows a new "AI Hub" or "multi-model workbench," MT quality looks better than last year's, and the roadmap slide promises faster turnaround. Six months later, the operational experience hasn't changed: someone still opens a ticket, a project manager still triages it, and a status page still refreshes to tell you what you already suspected, it's in progress. The AI improved. The way work enters and leaves the system did not change.

This article compares architectures rather than translation engines. Two models exist in the market now. One is ticket-based: a human files a request, a project manager routes it, and a portal shows status while humans wait. The other is a callable execution-layer model: a system or an AI agent calls an endpoint, and a structured order object with status, documents, and QC data comes back, with no ticket queue required. The difference matters more than any single AI feature, because it determines who or what can request localization, and how quickly that request becomes reviewable output.

The ticket-based paradigm, honestly described

Most enterprise TMS platforms, and most translation agencies wrapped in software, run on a project-creation model. Someone opens a UI, fills in a form, attaches files, and submits. A project manager, a human sitting in a queue, picks it up, assigns vendors or language pairs, and kicks off work. If the content spans modalities, a product page, a support video, a contract, that usually means separate intake flows, separate handoffs, and separate humans coordinating between tools that do not talk to each other natively.

Status in this model is something you check, not something the system pushes to you in a form you can act on programmatically. You log into a portal, look at a progress bar, and if you want to know why something is stuck, you message the PM. The unit of work is the ticket, and the unit of coordination is the person managing the ticket. None of this is incompetence, it is the architecture the industry built when the requester was always a human localization manager with time to file a request and wait for a human response.

The problem comes when that assumption stops holding.

Why "AI Hub" doesn't change the architecture

Many vendors have added multi-model routing inside their portals, letting users pick GPT, a proprietary MT engine, or compare outputs. That improves translation quality options. It does not change the operating paradigm.

The AI Hub still lives inside the same project-creation and ticket shell. A human still opens the project, selects the model, waits for the queue to process it, and checks a dashboard for status. Swapping which model does the translating doesn't change who or what can initiate the request, or how the result is handed back. It's a better engine on the same chassis. For a VP of Localization deciding what infrastructure to standardize on for the next five years, that distinction matters, because the chassis, not the engine, determines whether your systems and agents can call localization directly or whether every request still needs a human to file it.

The callable paradigm, concretely

The alternative is to treat localization as a set of discrete, callable actions that any authenticated system, human-operated software, a CI/CD pipeline, or an AI agent, can invoke directly, without a ticket queue mediating the request.

This is how Ollang is built. Ollang is an AI-native localization platform for video, audio, and document content 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. The functionality is addressable.

Concretely, the workflow decomposes into a small number of callable steps, documented in Ollang's API documentation:

Upload: a source asset, video, audio, document, image, subtitle file, or strings file, is submitted programmatically and returns a project identifier rather than sitting in an inbox waiting for someone to open it.

Order-create: a call creates one or more translation orders against that project, and supports order types including closed captions, subtitles, document translation, AI dubbing, and studio dubbing, returning order IDs immediately instead of a ticket number.

Order-get: status is retrieved on demand, returning full details of a specific order by ID, including status, languages, documents, and QC results. There is no portal page to refresh; the calling system polls or receives a callback.

QC-eval: quality review is itself a callable action. It runs an AI QC evaluation on an order to assess translation quality across criteria including accuracy, fluency, tone, and cultural fit, and returns scores for those criteria plus segment-level analysis. That's a structured, machine-readable governance signal returning alongside the translation itself, not a separate audit a human requests later.

The same actions are reachable in two ways, and the choice matters operationally. A backend engineering team wires the REST endpoints directly into a pipeline. A localization or content team lets an AI agent call the same functionality conversationally. Instead of switching between an editor and a dashboard, an agent can upload files, create orders, run QC, and manage projects from a single conversation. Under the hood these are the same callable primitives; what changes is who or what issues the call. The access layer is a hosted Model Context Protocol server, using OAuth 2.0 with PKCE, that integrates with Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and others. An agent operating inside a coding or content workflow can request a document translation or a subtitle order the same way it would call any other tool, and get back an object it can parse, not a ticket it must wait for a human to close.

This matters most where ticket handoffs compound. Video localization and AI dubbing traditionally involve separate vendors for transcription, translation, and mixing, stitched together by a PM. Document and legal-document localization traditionally route through a different tool than subtitles or website strings. When upload, order-create, order-get, and qc-eval are the same callable primitives across all of it, a single pipeline call can move a source asset through dubbing or document translation and return a QC-scored result in one round trip, regardless of which modality the content started as.

Why the gap widens as agents become the requester

The ticket paradigm assumed the requester is a person with a queue tolerance measured in hours or days. That assumption is eroding. As AI agents take on more of the work of building, shipping, and maintaining enterprise content, pulling a new product page, generating a support article, updating a contract template, the requester increasingly is a system that expects a programmatic response in the same call-and-return format as every other tool it uses.

A ticket queue cannot take a call from an agent. It can only take a human clicking "submit," followed by a wait. That means every agent-driven workflow that touches localization under a ticket-based vendor must stop, hand off to a human, wait for a PM to route it, and pick back up later, even if the underlying MT model is excellent. The bottleneck is not translation quality; the architecture only has one door, and it is sized for humans.

Multi-model routing inside a portal does not close the gap. Good MT behind a human-mediated queue is still a queue. A callable execution layer behind an average model is still callable. Over time, the second architecture compounds in the enterprise's favor, because every new agent, pipeline, or internal tool that needs localization can call the same order-create and qc-eval actions the first integration used, without a new vendor relationship or a new ticket type being invented for it.

The argument, restated

The comparison is architecture versus architecture, and architecture is hard to change once a hundred internal systems have been built against it. A VP of Localization choosing infrastructure today is not just picking a translation quality bar for this quarter. They are choosing whether localization can be called the way every other piece of enterprise infrastructure is called, programmatically, on demand, with status and QC data returned as data rather than as a dashboard color, or whether it stays a service that has to be asked for. Vendors that improved their models but kept the ticket queue addressed yesterday's problem. Vendors that replaced the queue with a callable order object addressed infrastructure issues likely to shape future enterprise content operations: not how good the translation is, but whether the system that needs it can get it without a human in the loop.