The infrastructure buyer's scorecard: 12 questions to separate real AI execution layers from repainted TMS platforms

Every localization vendor now claims to be an "AI execution layer." Look at ten vendor homepages and you'll find the same paragraph nine times: agentic, automated, AI-native, built for the future of work. Strip the adjectives and most of what's underneath is the same architecture that ran localization in 2015, a project management dashboard, a translation memory database, and a REST API that exists mainly so your engineering team can push files in and pull files out on a schedule.

That's not infrastructure. That's a TMS with a chatbot bolted on the side.

The problem for a CTO evaluating this category is that the marketing layer is now uniform, so it tells you nothing. You can't distinguish vendors by reading their websites. You have to test them the way you'd test any other piece of infrastructure you're about to depend on, by checking what a program can actually do to it without a human in the loop. This article is that test, twelve concrete questions, framed so you can score any vendor, including Ollang, without taking a sales deck's word for it.

Why "Can a program call it?" is the only question that matters

A dashboard is a UI for humans. An API wrapper around that dashboard is still a UI for humans, it just has a curl command attached. The distinction that actually separates infrastructure from software-with-an-API is whether the system was designed to be invoked programmatically as its primary interface, with the dashboard as an optional view into that same engine, or whether the API was added later to let engineering "integrate" with what is fundamentally a ticket-based service.

You can tell the difference in about ten minutes of technical diligence. Ask each vendor to show you, live, what happens when an AI agent, not a human clicking buttons, needs to localize a file mid-workflow. If the honest answer involves a support ticket, a project manager, or a multi-day turnaround estimate, you're looking at a TMS. If the answer is, "the agent calls this endpoint and gets a result," you're looking at infrastructure.

The scorecard

1. Does the vendor expose an MCP server, or only a dashboard with an API wrapper?

This is the most informative question on the list. A REST API tells you a vendor built for engineers. An MCP server tells you a vendor built for agents. Ollang's documentation covers APIs, MCP server, SDK, Skills, and platform concepts for AI-native localization, with the platform orchestrating AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place, exposed through APIs, an MCP server, an SDK, and agent Skills. That's four distinct programmatic surfaces to the same underlying engine, not four marketing names for one API.

Ask the vendor directly, can Claude Code, Cursor, or a custom agent connect to your MCP server and run a localization workflow without you writing integration code first? If the answer requires a professional services engagement, mark it zero.

2. Can content ship through your existing CI/CD pipeline without an engineering handoff?

Legacy TMS platforms treat CI/CD as an integration to build, not a native mode of operation. Ollang positions itself the other way, ship translated content through APIs, MCP, automation, and CI/CD pipelines, localization runs inside the deployment workflow you already use. The test here is operational, not architectural, does a string change in a pull request trigger translation and return a reviewable diff without anyone leaving the repo, or does it require exporting a file, emailing a vendor, and waiting for a delivery notification?

3. Is there an SDK to scan and apply translations across a codebase, or only file-by-file upload?

File-based translation management assumes someone manually identifies what changed. An SDK-grade execution layer scans the codebase itself. Ollang describes this explicitly as part of its programmatic surface, use MCP to let AI agents run workflows, SKILLS for reusable agent actions, the SDK to scan and apply translations, and the API to build end-to-end localization pipelines. The distinction matters operationally, an SDK that scans means new strings get caught automatically as engineers write code, instead of surfacing weeks later when someone runs a manual export.

4. Are reusable agent Skills available so Claude Code, Cursor, Codex, and similar tools can localize files inline?

This is where the "AI-native" claim gets tested against reality. A growing set of coding agents, Claude Code, Cursor, Codex, Cline, and others, now support the Agent Skills standard, meaning a skill written once should run the same way across tools. Ollang has built for this directly, native MCP/SKILLS integration lets Claude Code, Cursor, Cline, Codex and 15+ agents localize files directly from their workflow. Practically, this means a developer working inside their editor can ask the agent to localize a component's strings inline, and the agent invokes the skill rather than the developer stopping to open a separate vendor portal.

Ask any vendor claiming agent compatibility for the actual SKILL.md files. If they don't have any, they've described a future roadmap item as a present capability.

5. Does governance and human review sit inside the same engine as automation, or as a bolted-on separate system?

This is the question that exposes the most repainted TMS platforms. Automation without governance is a compliance liability at enterprise scale, legal, brand, and regulatory review can't be an afterthought bolted onto an automation pipeline as a separate approval tool with its own login and its own data model. Ollang's documentation frames review as native to the same execution path as the automated output, not a downstream system, the platform orchestrates AI dubbing, subtitle translation, captions, transcription, document and visual translation, and human review workflows in one place. Ollang's own product framing reinforces this, Ollang provides a shared workflow that keeps every team aligned while maintaining visibility, quality control, and delivery speed across languages, with control over where native-speaking reviewers participate in the localization process.

The test, when a reviewer flags a translation for correction, does that correction feed back into the same engine that generated the automated output, updating terminology memory and future runs, or does it live in a separate review tool that never talks to the automation layer at all?

6-12: the remaining diligence items

1. Step count from change to shipped translation, is it a single request/response cycle, or a ticket that enters a queue?
2. Modality coverage at the API layer, not just the UI, can you call the same programmatic surface for documents, video, and audio, or are video and audio locked behind a separate system with its own contract and its own turnaround time?
3. Async completion via webhooks/callbacks, not dashboard polling, production pipelines need event-driven completion signals, not a human checking a status page.
4. Programmatic access to terminology and style memory, if your glossary only lives in a settings screen, your agents can't enforce it consistently across a codebase.
5. Inline review, not export-to-portal review, can a reviewer comment directly in the pipeline (a PR, a ticket) or must content be exported into a separate review environment and re-imported?
6. Enterprise authentication, scoped API keys, SSO, and audit logs, or one shared key everyone on the team uses?
7. New capability lands at the API first, when the vendor ships a new language or modality, does it appear in the programmatic surface immediately, or does the dashboard get it months before the API does, a strong signal of which one is actually the product.

What changes operationally

Score a vendor honestly against these twelve and the pattern becomes obvious fast. A TMS with an AI feature set will pass three or four items, usually the API and maybe webhooks, and fail the rest, because its core data model was built around human project managers assigning tickets to human translators. Retrofitting an MCP server or a Skills pack onto that model produces something that technically responds to agent calls, but still routes through the same queue-based backend underneath, with the same latency and the same handoff points.

An execution layer built for programmatic access from the start doesn't have that ceiling. The operational shift is that translation stops being a project with a start date and a delivery date and becomes a callable step inside whatever workflow already exists, a CI/CD pipeline, an agent session, a content system's publish action. Governance does not get added back in afterward as a compliance patch, it's part of the same call path, so a reviewer's correction updates the engine agents already call, not a disconnected archive.

The closing argument

Any vendor can put "AI execution layer" in a headline. Very few can survive a CTO actually calling their MCP server, pointing an SDK at a real codebase, and watching what happens when a Claude Code or Cursor session tries to localize a file inline mid-task. That's the test that matters, because it's the only one that can't be faked with a slide. Run this scorecard against every vendor on your shortlist before you sign anything, not because Ollang needs you to, but because it's the only diligence that tells you whether you're buying infrastructure or renting a translation agency with better branding.