Connectors vs. agent-native: two competing architectures for enterprise localization automation

A CTO evaluating localization infrastructure eventually asks a question that vendor demos rarely answer well: what happens when the system you need to connect to isn't one of the pre-built integrations? The dominant translation management platforms answer with a roadmap ticket. That answer is a symptom of an architecture, not a temporary gap, and it's worth understanding before you commit engineering cycles to either model.

The thesis here is straightforward. Established enterprise localization platforms extend their reach through a connector hub: dozens of point-to-point integrations and CI/CD plugins bolted onto a central portal, each one built and maintained by the vendor for a specific CMS, commerce platform, or code repository. Ollang takes a different position, it exposes a hosted MCP server and file-based Skills so any compliant AI agent can call localization as a native tool, reasoning its way to the right API call rather than waiting for a vendor to ship a connector. These are different bets about who does the integration work: the vendor's engineering team, in advance, for known systems, or the agent itself, at runtime, for whatever system it's actually working in.

The connector-hub model

Every major TMS platform is built around a central portal, and the portal's utility scales with the number of systems that can push content into it and pull translations back out. That's why platform vendors invest heavily in pre-built integrations. To help automate the translation process, these platforms offer a range of pre-built connectors that integrate with a variety of software platforms, including content management systems and marketing automation tools. The bigger players quantify this as a selling point: one platform advertises 35+ pre-built connectors, a web translation proxy, and a full API as a core differentiator.

Each connector in that catalog is a discrete engineering artifact. It has to be built against the target system's own API, versioned as that system changes, and maintained indefinitely. Hosted connectors are hosted on the vendor's servers, connected and configured within the portal. Once connected, source content is automatically visible, translations are requested and managed centrally, and completed translations are delivered back to the connecting software automatically. The workflow is convenient when your CMS is one of the supported systems. It is also, structurally, a curated allowlist: you get frictionless localization for the platforms the vendor chose to prioritize, and a support ticket or custom integration project for everything else.

Some vendors clearly invest in keeping connectors reliable, and one platform markets itself on connectors that actually work, keeping translations moving automatically, with quality tracked at every step. The point is architectural: the connector model treats integration as a library of known adapters, built ahead of demand, for a finite and named set of systems. It's an N-to-1 model, N systems, one portal, and every new system on that list is vendor-side work.

The agent-native model

Ollang doesn't try to out-build that catalog. Instead of shipping a growing list of named connectors, it exposes the localization engine itself as something any AI agent can call directly, through two complementary mechanisms documented at https://api-docs.ollang.com/home.

The first is a hosted MCP server. It's a hosted Model Context Protocol server authenticated via OAuth 2.0 with PKCE, built to drop into Claude, Cursor, Claude Code, Devin, Replit, Windsurf, and more. Because it's hosted rather than something a team stands up and operates, there's no server to run or maintain on the customer side, the agent authenticates through a standard OAuth consent flow and gets a set of localization tools it can call directly inside its existing session. OAuth with PKCE is the pattern the broader MCP ecosystem has converged on because it fits how agents actually behave: MCP servers sit at a unique intersection, they handle requests from multiple clients such as Claude Desktop, Cursor, custom agents, and automation scripts that act on behalf of different users, and the server needs to know who is asking for what. PKCE closes a real attack surface in that flow; it binds the authorization code to the client that requested it, so an intercepted code cannot be exchanged for a token by an attacker.

The second mechanism is Skills, local instruction files rather than a running service. Skills teach an agent how to call the Ollang REST API directly, with no proxy server or MCP connection needed. Teams that prefer a server-based integration with OAuth use MCP instead. Skills give coding agents procedural knowledge rather than raw API documentation: they are reusable capability packages that provide step-by-step instructions and API details so an agent can accomplish domain-specific tasks without a developer writing custom prompts. In practice this means a developer working inside Cursor, Claude Code, Windsurf, Cline, or Codex can say "upload this video and order Japanese and German dubbing" and the agent walks itself through the documented sequence: upload a file to get a project ID, create an order to get an order ID, poll status until completed, run a quality check, and create revisions if issues surface, all authenticated with an API key from the account dashboard.

Underneath both mechanisms sits the same REST API, which handles programmatic uploads, orders, projects, revisions, QC, human review, and webhooks, along with a TypeScript SDK for teams that want typed, in-process control rather than agent-mediated calls. MCP and Skills do not replace the API, they sit on top of it, translating an agent's natural-language intent into the same documented calls a developer would otherwise write by hand.

The net-new tool test

The clearest way to see the architectural difference is to ask what happens when a genuinely new tool or system enters the picture, something the vendor hasn't built a connector for.

In a connector-hub architecture, a net-new system means a net-new integration. Someone on the vendor's engineering team or a systems integrator has to study the target system's API, build an adapter that maps its content model onto the TMS's internal representation, handle authentication, test it, and ship it as a supported connector, or the customer builds and maintains a custom one themselves. Either path is a project with a timeline. It's the reason connector catalogs top out at "35+" or "dozens" rather than "every system that exists": each entry represents standing engineering investment, not a configuration toggle.

In an agent-native architecture, the same scenario looks different because the agent is not limited to a pre-mapped list of tools. It has direct access to the REST API and enough procedural context to reason about it. Analysis of MCP-versus-REST tradeoffs converges on this point: a new class of API consumer has arrived in LLM-powered agents, which need to discover what an API can do, reason about which operation to use, and maintain context across multi-step workflows, all at runtime, without a human writing integration code in advance. That's the mechanism at work when a coding agent encounters a localization need inside an unfamiliar codebase or CMS: given the Skills files or MCP tool definitions, it can compose the right sequence of calls, upload, order, poll, QC, revise, without a vendor having pre-built a named connector for that specific surrounding system. The "new tool" in this context is whatever agent framework a customer adopts next, and because that agent speaks REST and MCP, it doesn't need Ollang to ship anything new to use it. The TypeScript/Node.js SDK exists for asset scanning, i18n workflows, and CMS capture for teams that want to build that connective tissue themselves in code, which is the deterministic-integration counterpart to the agent-reasoning path.

Tradeoffs: curated reliability vs. reasoning flexibility

Neither model is strictly superior, and a CTO evaluating this space should resist framing it that way.

The connector hub's advantage is predictability for known systems. A connector built and tested against a specific CMS version behaves the same way every time; there is no reasoning step that could introduce ambiguity about which API call an LLM decided to make. For an enterprise whose entire content estate lives in two or three well-supported platforms, that determinism has real value, and it's why deterministic pipelines are generally the right call when every run must execute steps A, B, C in order with specific parameters. The cost is breadth and pace: reach is capped by the vendor's build queue, and any system outside the catalog is, by definition, second-class.

The agent-native layer's advantage is flexibility. It does not require the vendor to have anticipated your stack. The tradeoff is that it depends on agent reasoning quality and on the discipline of the tool definitions the agent is given, which is why well-scoped Skills and a well-designed MCP tool surface matter more than raw API coverage. Industry guidance on this junction is consistent: MCP earns its keep when three or more integrations feed an AI workflow, while a traditional API is the right tool for a single-purpose automation script. MCP wraps existing APIs as an AI-friendly layer rather than replacing them. Ollang's architecture reflects that division directly: API documentation covering REST, MCP, SDK, and Skills exists specifically to explain when to use each and how they fit together, rather than presenting one integration pattern as universally correct.

There's also a governance dimension a CTO can't ignore. A connector hub concentrates governance in the portal: access, approvals, and audit trails live in one place, which is simple to reason about but also means every new integration surface has to be modeled inside that same central system before it's usable. An agent-native layer distributes execution to wherever the agent runs, which demands that authentication and scoping be handled correctly at the protocol level, since the agent, not a human clicking through a portal, is the one calling the API. This is why OAuth 2.0 with PKCE, rather than a shared static API key, is the right primitive for the MCP server: it produces a user-approved, time-boxed permission, exactly what's needed when AI agents act on an organization's behalf, and access can be revoked centrally without touching every downstream integration individually.

Why English-first agents need this pattern

The strongest argument for the agent-native pattern is a specific, growing category of workflow that connector hubs weren't designed to serve: AI coding assistants and autonomous agents that generate content and code as their default output in English, with no localization step built in.

This is a structural gap, not an edge case. Every AI agent, every app, every workflow is still English-first by default, and closing that gap the traditional way is expensive: getting to 240+ languages means stitching together five or more separate APIs, managing file conversions, and handling dubbing, subtitles, and i18n files separately, all while keeping quality consistent. A connector hub doesn't solve this, because the entity that needs localization isn't a CMS with a content model to map, it is an agent mid-task, inside an editor, that just generated a UI string, a document, or a video script and now needs it in twelve languages before the task is considered done. There is no portal for the agent to log into and no connector for "Claude Code mid-refactor."

An MCP server and Skills meet the agent where it already operates. The Skills layer is designed to be framework-agnostic, and once connected to an agent like Cursor, Claude Code, Devin, Replit, or Lovable, the agent can use Ollang's capabilities on the fly, understanding the surrounding tech stack and workflow context to trigger the right multimodal localization actions. For continuous internationalization specifically, this matters at the file-format level: a coding agent can hand a strings file to the localization layer and get back a properly localized version without a human ever routing it through a separate vendor portal, and Ollang's documentation on continuous i18n workflows exists to support that pattern.

This is where the category shift becomes concrete rather than aspirational. Localization stops being a project a human kicks off in a portal and becomes a callable step inside whatever pipeline, human or agentic, is already producing the content. A coding agent that would otherwise ship an English-only string, a document-generation agent that would otherwise stop at one language, or a video pipeline that would otherwise hand off to a separate dubbing vendor can instead treat translation, dubbing, subtitling, and document localization as a tool call with the same status as any other function it invokes mid-task.

The argument

Connector hubs and agent-native layers answer different questions. The connector hub answers how do we make localization convenient for the systems we already know about? The agent-native layer answers how do we make localization callable by anything that can reason about an API? Both are legitimate engineering strategies, and an enterprise with a stable, well-known content stack running through a handful of major platforms may be better served by curated connectors that a vendor has tested and stands behind.

But the center of gravity in enterprise software is moving toward agents that operate across unpredictable, fast-changing toolchains: coding assistants, autonomous pipelines, and orchestration frameworks that didn't exist eighteen months ago and will be joined by others eighteen months from now. A connector catalog, however large, is always a step behind that pace by construction: it can only support what's already been built. An architecture built on OAuth-secured MCP access and portable Skills files does not need to predict which agent shows up next, because it was never a list of named integrations in the first place, it is a REST API and a protocol that any compliant agent already knows how to speak. That is the distinction a CTO should weigh: not which vendor has more connectors today, but which architecture stops needing new ones tomorrow.