Ten agents, one translation

A team ships an agent. It works, so they ship another, then a third that runs on a different model. A year later there are ten agents: support, sales, onboarding, billing, a docs assistant, a voice bot, and a few workflows nobody remembers building. Each one talks to customers in more than one language.

Ask all ten to say "Your order has shipped and will arrive on Thursday." in Spanish, and you'll get several answers. They are all fine Spanish. They are not the same Spanish.

Why the same sentence comes out differently

Language models don't look translations up. They write them, fresh, each time. Three things move the result:

• The model. Model A prefers Su pedido ha sido enviado. Model B writes Tu pedido fue enviado. Neither is wrong.
• The prompt. A support prompt that says "be warm" and a billing prompt that says "be formal" push the same sentence in different directions.
• The day. Even one model changes between versions, and between runs.

Each agent is doing its job. The inconsistency isn't a bug in any of them; it's what happens when ten independent writers each translate for themselves.

What it costs

For a single chat message, almost nothing. Across a company, it adds up:

• Customers see your brand speak differently. The shipping notice in the app, the one in the email, and the one the voice bot reads out don't match.
• Review doesn't stick. Someone fluent checks a phrase, approves it, and the next agent writes a different version. The approval covered one wording, not the sentence.
• Switching models changes your voice. Moving an agent to a newer model rewrites every translation it produces, including the ones you already approved.
• Policy language drifts. Fees, returns and eligibility wording that should read identically end up with small differences that customers notice.

One translation per sentence

The fix is to take translation out of the agents. Instead of every agent translating for itself, every agent calls one translation layer, and that layer returns the same words for the same text.

FluentC works this way:

1. The first request translates. FluentC translates the text and stores the result.
2. The result is stored against the target language and the exact text. The key is a hash of those two things.
3. Every later request returns the stored translation. Same text, same language, same words, no matter which agent or model asked.

Here is that in practice. Any agent, on any model, sends the same request:

curl -X POST https://api.fluentc.ai/ai_agent/translate \
  -H "Authorization: $FLUENTC_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Your order has shipped and will arrive on Thursday.",
    "input_format": "text",
    "target_language": "es",
    "mode": "real-time"
  }'

The first call returns a translation. Every call after it, from any of your ten agents, returns the same one.

The agents can reach FluentC in whichever way suits them: MCP for agents that use tools, LangChain for Python agents, the n8n node for workflows, or the REST API from anywhere else. They all land on the same stored translation.

What changes

• Switch models freely. The wording customers have already read doesn't change when an agent's model does.
• Review once. A reviewer reads the translation of a sentence once. Every agent that sends that sentence afterwards sends those words.
• Repeats are faster. A string that has been translated before comes back from memory instead of being translated again.

What consistency does not mean

It helps to be exact about the promise, because it is narrower than it sounds.

• The match is exact, not fuzzy. The same text and target language return the same translation. Change one character, or one agent's paraphrase of the sentence, and it is a new string with a new translation. There is no near-match substitution.
• It starts with the English. If your agents each word the English differently ("Your order shipped" versus "We've sent your order"), they send different strings and get different translations. Standardise the sentences you care about, such as status messages, policy lines and greetings, and have agents send those as written.
• It doesn't write your content for you. FluentC makes the translation of a given string stable. What your agents decide to say is still up to them.
• It isn't a substitute for review where it matters. For regulated or high-stakes content, keep your own review process. The benefit is that you review each phrase once instead of once per agent.

Where to start

You don't need to migrate everything. Pick the sentences that matter most, the ones customers see in every channel, and route those through FluentC first. A shipping notice, a returns policy, a greeting. Then add more as it pays off.

1. Get an API key and make the request above.
2. Point one agent's translation step at FluentC, then a second.
3. Compare what each agent now sends for the same sentence.

If you run many agents and want to talk it through, get in touch. The enterprise page has the short version.