Ticket-based vs. callable: two different models for enterprise localization in 2026

Your localization backlog doesn't grow because translators are slow. It grows because every new piece of content, whether a product update, a support macro, a contract clause, or an AI agent's output, has to stop and wait for a project to be created around it before anything happens. That pause, repeated thousands of times a week across a large enterprise, is the real bottleneck. It's also invisible in most vendor demos, because demos show the moment translation happens, not the moment before it, when someone has to decide a project exists.

The thesis of this piece is narrow and structural: the dominant enterprise vendors, Smartling, Phrase, Lokalise, LILT, have layered AI routing, adaptive MT, and quality scoring on top of a model that is still, at its core, ticket-and-project based. Content enters a project. It gets assigned. It moves through translation memory and glossary matching. It comes back for review and gets delivered, manually or semi-automatically. An agent-native execution layer inverts that: any system or AI agent issues a request against an API or MCP endpoint and gets production-ready output back, with governance rules already applied and no project setup step required. This is a different answer to the question "where does localization live in your stack."

The ticket model, and why it was the right design for twenty years

Every major TMS platform is, underneath the AI branding, an orchestration layer for a workflow that assumes a human-initiated project. A general description of the category holds true across vendors: a translation management system automates and centralizes content ingestion, workflow routing, translation, quality review, and multilingual delivery. That's an accurate description of what these platforms do well, and it's why they became the default enterprise choice for over a decade.

The AI layer added on top is real, but it's routing intelligence inside the same project structure. LILT is an adaptive MT platform where machine translation learns from human feedback in real time, with every translator correction improving future output. Lokalise and similar platforms use confidence scoring so that AI highlights risky segments and routes them for review, with these scores functioning as continuous quality gates where low-confidence text triggers human QC. These are genuine improvements in translation quality and reviewer efficiency. None of them change the fact that content still has to arrive as a project, get matched to a workflow template, and move through a queue with named stages and named owners.

That model breaks down in three specific, predictable ways at enterprise scale.

Project setup is the bottleneck, not translation. Every new content type, every new source system, every ad hoc request needs a project or workflow configured before the AI or the linguist ever touches it. At the volume a large enterprise generates content in 2026, API responses, chatbot output, dynamically generated product descriptions, agent-drafted documents, the setup step doesn't scale linearly. It scales with headcount.

The unit of work is the ticket, not the call. A TMS is built around discrete jobs with a beginning and an end. That's the right unit for a marketing campaign or an app release. It's the wrong unit for a system that needs to localize on every request, indefinitely, without a human deciding "this is a project now."

Governance lives in the workflow, not in the request. Approval chains, glossary enforcement, and brand voice rules are configured per project or workflow template. If a new caller, a different team, a different system, an AI agent nobody scoped for, shows up outside that template, governance has to be rebuilt for them.

The callable model, and the forcing function that makes it necessary

The forcing function is simple and already visible in production systems: AI agents default to English. Ollang's own framing of the problem is direct, every AI agent, every app, every workflow is still English-first by default. An agent drafting a contract, summarizing a support ticket, or generating a product description doesn't pause to ask which of your forty markets needs a localized version. It produces English and moves on, unless localization is something it can call the way it calls any other tool, a database, a search index, or a payment processor.

That's the design Ollang builds toward. The platform is positioned as the AI language execution layer for enterprise, deploying, adapting, and operationalizing content across 240+ languages without fragmenting your workflow. The access model reflects that: APIs, MCP server, SDK, Skills, and platform concepts for AI-native localization, exposing AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, and exposing everything through APIs, an MCP server, an SDK, and agent Skills.

Concretely, this changes what happens operationally in three places.

Invocation replaces intake. Instead of a localization coordinator creating a project in a TMS, a build pipeline, a CMS webhook, or an agent running in Claude Code, Cursor, or a similar environment calls Ollang directly. Ollang describes this as native integration where Claude Code, Cursor, Cline, Codex, and 15+ agents can localize files directly from their workflow. There is no ticket to open. The request itself carries the source asset and the target languages.

Governance travels with the request, not with the project. Rather than configuring an approval chain per workflow, terminology and tone rules are attached to the account and applied automatically. Ollang's stated approach is that the system uses project context, custom instructions, and terminology memory to help agents localize content with the right regional tone, idioms, and cultural nuance, adapting each string based on product, audience, and market rather than translating text in isolation. The rules are pre-applied at the point of the call, not re-derived every time a new team or system starts sending requests.

Delivery is production output, not a file to route. In the ticket model, a completed translation still has to be routed back into the source system, often manually. In the callable model, the response from the API is the asset, ready for deployment rather than a deliverable waiting for a second handoff.

Operationally, this is where developer and business workflows converge rather than sit in separate tools. Developers integrate localization directly into applications and workflows, while business teams manage reviews, approvals, and publishing through a shared operational interface. That matters for a VP of Localization specifically because it removes the recurring negotiation between engineering and localization ops over who owns the intake step. Ollang frames the deployment path as running inside infrastructure you already trust: ship translated content through APIs, MCP, automation, and CI/CD pipelines, so localization runs inside the deployment workflow you already use.

Where the callable model breaks down

The callable model isn't a free upgrade. It trades one bottleneck for a different risk. When content moves through a human-staffed project, every deliverable has an implicit checkpoint: someone assigned the work, someone reviewed it, someone approved delivery. When content moves through an API call, that checkpoint has to be engineered into the system itself, or it doesn't exist. If governance is thin, no terminology enforcement, no routing for high-risk content, no audit trail, a callable model produces fast, ungoverned output at scale, which is worse than slow, governed output at scale.

This is why review and sign-off can't be treated as an afterthought bolted onto a fast API. Ollang's own positioning acknowledges this directly: AI turned translation into a commodity, anyone can generate it in seconds, but a translated string isn't a localized product, and enterprise localization requires speed at scale, native-speaking quality, workflow control, and accountable sign-off. The workspace layer exists to keep human accountability in a model that no longer routes everything through a manual project: run review, approvals, publishing, and visibility from a visual workspace, driving quality and sign-off on the same engine, no engineering handoff required.

[citation needed]

A framework for which model fits which team

Not every workflow needs to be callable, and treating all of them as if they do is its own failure mode. Three questions determine which model, or which mix, a given team should run.

Is the requester a human or a system? Marketing campaigns, brand launches, and one-off legal filings are initiated by people who benefit from a visible project, a named owner, and a review cycle they can inspect. These stay well served by project-based workflows, whether run inside a traditional TMS or inside Ollang's workspace interface. Content generated by pipelines, agents, or recurring system events, product catalog updates, support content, continuously shipped app strings, dynamically generated documents, has no human in the loop to open a ticket, and forcing one in creates the bottleneck described above.

Is the volume recurring and system-driven, or intermittent and judgment-driven? High-frequency, structurally similar content such as i18n strings, subtitle batches, or document sets that update on a schedule benefits from being called programmatically because the governance rules don't change request to request. Low-frequency, high-judgment content benefits from a human deciding scope before translation starts.

Where does the risk sit, in the output or in the absence of a checkpoint? For most enterprise content, the risk is inconsistent terminology or missed cultural context, which pre-applied governance and review workflows handle inside a callable model. For a narrow set of content, regulated filings, contracts with legal exposure, the risk is the absence of an explicit human checkpoint, and that content should route through review regardless of which model handles the translation itself.

The realistic enterprise deployment in 2026 is not a binary choice. It is a callable execution layer handling the volume that AI agents and systems generate by default, with human review and project-based workflows retained for the narrower set of content where a named owner and a visible approval chain are required.

The structural argument, restated

The vendors adding AI on top of ticket-based systems are optimizing the queue. An agent-native execution layer is eliminating the queue for content that no longer has a human to stand in it. This is not a matter of who has better MT quality or a cleaner glossary editor, most of the established platforms are competent on both counts. It is a matter of whether your localization infrastructure assumes a person opens a ticket, or assumes a system makes a call. As more of your content originates from agents rather than authors, that assumption stops being a technical detail and becomes the ceiling on how much of your global content operation can run without someone standing at the intake desk.