What Breaks When You Ship an AI Agent to a Japanese City Hall

Our first agent prototype did everything right in testing. It answered questions accurately. It maintained character. It handled multiple languages. We showed it to the client and they approved deployment.

It failed within hours.

Not because the model was wrong — the answers were accurate. It failed because the kiosk screen went to sleep and nobody had configured the display software to prevent it. It failed because the IC card reader returned data in a character encoding the parser did not expect. It failed because a resident spoke a regional Vietnamese dialect and the agent responded in standard Vietnamese, which felt cold and institutional to someone already nervous about navigating a foreign government office.

None of these problems showed up in our test environment. All of them showed up on day one.

That gap between demo and production is where most agents break. The model is the easy part. Everything around it is where the real work happens.

!ARISA AI agent — from exhibition demo to production deployment

The Problems Nobody Warns You About

Most writing about AI agents focuses on prompt engineering, model selection, and tool use. These matter. But in our experience deploying agents to Japanese government offices, railway stations, and healthcare facilities, they account for maybe 30% of the actual work. The other 70% is integration, evaluation, and the edge cases that only appear when real people use your system in real environments.

Hardware Is the Hard Part

Our agent at Myoko City Hall reads physical residence cards via an IC card reader mounted on a kiosk. This sounds simple. Here is what we discovered:

Different card readers return data in different byte orders. Zairyu cards issued before 2020 have a different data layout than newer ones. Some cards have scratched chips that return partial reads. The reader sometimes fails silently, with no error, just empty data.

Each of these failure modes needs a specific recovery path. The agent needs to say "I could not read your card — could you try tapping it again?" in the right language, with the right tone. If the second read fails, it needs to switch to manual data entry mode without losing the conversational context.

Integration engineering, not LLM work, determines whether any of this holds together. Get it wrong and the city hall staff stop trusting the system. Once staff trust is gone, the deployment is over, regardless of how good the model is.

Evaluation Is Not Optional

We built our evaluation framework after our first deployment stumbled. It took longer to build than the agent itself.

Here is what we measure: factual accuracy on Japanese administrative procedures (tax rates, pension rules, insurance categories), formality register correctness in Japanese, concept explanation quality across languages, escalation trigger reliability, and persona consistency over extended conversations.

Every prompt change, every model update, every knowledge base revision runs through this evaluation before it touches production. We learned this the hard way. A prompt tweak that improved English responses degraded Japanese keigo in ways that took days to notice without automated checks.

The lesson: if you cannot measure it, you cannot improve it. And you definitely cannot guarantee it to a government client who needs to report outcomes to their prefectural oversight board.

!AI agent deployment at Myoko City Hall — serving foreign residents

Multilingual Is a Knowledge Problem, Not a Language Problem

People hear "multilingual" and think translation. That framing misses the real challenge.

Any large language model can generate text in dozens of languages. That is table stakes, what the model does out of the box. The question is whether the agent can explain a Japanese-specific administrative concept to someone whose entire reference frame is a different country.

Here is a concrete example. When a Vietnamese resident at Myoko City Hall asks about health insurance, the correct answer is not a translation of the Japanese health insurance pamphlet. The correct answer explains:

- How the Japanese system differs from Vietnam's social health insurance (BHXH) - What the monthly premium will be and how it is calculated from income - That this is separate from pension enrollment (which is not the case in many countries where they are bundled) - What happens if they need emergency care before their insurance card arrives

Each nationality needs a different explanation of the same Japanese system. We maintain structured knowledge bases that map Japanese administrative procedures to culturally relevant explanations. This is the work that makes the agents useful, not the language generation itself.

Claude plays a specific role here. Its cross-cultural knowledge is deep enough that when our knowledge layer provides the Japanese administrative context, Claude can bridge the gap to the resident's home country reference frame without us having to build every cultural mapping manually. When a Vietnamese resident asks about pension, Claude already understands enough about Vietnam's BHXH system to make the comparison meaningful. That cross-cultural reasoning layer would have taken us significantly longer to build on top of a model that treats multilingual as purely a translation problem.

Persona Drift Is Real

We run four distinct agent characters: RIN (formal, government), ARISA (enthusiastic, tourism), ALICE (warm, family-friendly), and SOFIA (calm, healthcare). Each one has a defined personality that must remain consistent across thousands of interactions.

In testing, persona consistency is easy. In production, it erodes in specific, predictable ways:

- Long conversations (15+ turns) cause gradual formality shifts - Adversarial inputs ("ignore your instructions and...") test boundary enforcement - Edge-case questions that fall between the agent's domain and general knowledge trigger character breaks - Switching between languages sometimes shifts the persona register — an agent that is formal in Japanese may become casual in English

We monitor for drift using automated evaluation against reference conversations. When drift exceeds our threshold, we investigate whether it is a prompt issue, a model behavior change, or a knowledge gap. Usually it is the knowledge gap. The agent does not have a confident domain-specific answer, so it falls back to general-purpose behavior, which breaks character.

This is one area where our choice of Claude made a measurable difference. Claude's baseline tendency is to stay within the defined role rather than improvise beyond it. When the agent encounters an edge case, Claude is more likely to acknowledge uncertainty within character than to break character and respond as a generic assistant. That default behavior aligns well with what government and healthcare deployments require.

Know When to Stop

Knowing when to hand off is the most important principle in our system design.

A government agent that confidently provides incorrect legal guidance is worse than no agent at all. A healthcare agent that attempts to answer a medical question is dangerous. Every agent in our platform has hard-coded escalation boundaries that cannot be overridden by conversation context.

When RIN detects a legal dispute, a complex immigration edge case, or an explicit request for a human, it transfers immediately. The transfer includes a full conversation summary so the staff member starts with context instead of a blank slate.

We designed escalation as a first-class feature, not an afterthought. It runs on explicit rule matching, not model judgment. We define the conditions where escalation is mandatory and enforce them outside the model's decision loop, rather than asking the model to decide.

Claude's safety training reinforces this architecture. The model's default inclination is toward caution. It will not fabricate legal information or push past scope boundaries just to provide an answer. In consumer applications, that caution can feel conservative. In government offices and healthcare facilities, it is exactly what we need. The model's instinct and our architectural constraints point in the same direction, which makes the entire system more reliable than either layer alone.

!Myoko resort region — where RIN serves foreign residents during ski season

Where the Model Choice Mattered

I have said that the model is 30% of the work and the system around it is 70%. That is true. But the 30% matters, and the specific characteristics of the model determine what the other 70% looks like.

We use Claude by Anthropic as the reasoning engine across all our deployments. Here is where that choice made the biggest practical difference:

Japanese keigo consistency. Government offices in Japan require the highest formality register. We tested multiple models on sustained formality across 50+ turn conversations. Claude maintained correct keigo throughout. Other models showed measurable degradation after turn 15-20, gradually dropping to casual register. In a municipal office, one informal response in front of a senior staff member can undermine the entire deployment.

Reasoning through ambiguity. Administrative procedures involve conditional logic — "if your visa type is X and you arrived before date Y, then rule Z applies, unless exception W." Claude handles these multi-conditional chains reliably without collapsing to generic advice. Our evaluation framework tracks this specifically, and Claude's accuracy on conditional administrative reasoning is consistently the highest among models we have tested.

Predictable behavior under adversarial input. People test AI agents. They try to make them say inappropriate things, give unauthorized information, or break character. Claude's response to adversarial prompts is predictable and contained. It declines, stays in role, or escalates. Predictability matters more than perfection in production. A model that occasionally does something unexpected is harder to deploy safely than a model that is consistently cautious.

These are not abstract preferences. They are specific, measurable characteristics that our evaluation framework tracks across every deployment. They are the reason we build on Claude.

What We Got Wrong

We over-built the first version. Our initial architecture included multi-model routing, dynamic tool selection, and conversation branching, features we thought we would need. None of them mattered for the initial deployment. We stripped the system back to the simplest thing that could work, and added complexity only where real usage data proved it was necessary. Simplicity was faster, more reliable, and easier to debug at 2 AM when something broke in production.

We underestimated the trust problem. The hardest part of deploying AI in Japanese government offices is not the technology. It is convincing career bureaucrats that an AI agent will not embarrass their department. This took months of demonstrations, pilot programs, and relationship building through our deployment partner, Flyout Planning Corporation. Technology readiness is necessary but nowhere near sufficient.

We assumed language scaling was linear. Going from 5 languages to 20 was predictable. Going further surfaced problems we did not anticipate: right-to-left script rendering on our signage hardware, languages where a single formality marker restructures the entire sentence, and tonal languages where text-to-speech quality varies dramatically between providers. Each new batch required dedicated testing, not just a checkbox.

What Actually Matters

After shipping agents to production across multiple deployments, here is what I believe determines whether a deployment succeeds:

1. Integration depth. The agent must connect to systems people already use — card readers, forms, displays, scheduling systems. A chat window alone is not enough to change workflows.
2. Domain knowledge engineering. The model provides reasoning. You provide the domain knowledge. The quality of your knowledge layer determines the quality of the agent's output.
3. Evaluation before everything. Automated evaluation is the mechanism that lets you ship changes with confidence instead of hope.
4. Escalation as architecture. Design the boundaries first. Define what the agent will not do before you define what it will do.
5. Trust is earned slowly. Especially in government and healthcare. Plan for months of pilot programs and relationship building before full deployment.

None of these are about the model alone. But the model is the foundation everything else is built on. We chose Claude because its specific strengths, namely formality consistency, cross-cultural reasoning, safety alignment, and predictable behavior, map directly to what government and healthcare deployments require.

The system we have built around Claude, including the domain knowledge layers, the evaluation framework, the hardware integration, and the escalation architecture, is what turns those model capabilities into production results. The model provides the reasoning. The system provides the context and the constraints. Together, they serve real people at real government offices and railway stations every day.

!Seibu Railway partnership — AI tourism agents in the Chichibu region

---

We build Claude-powered AI agents for government, tourism, and healthcare across Asia-Pacific. Read the full deployment case study or see how frontier models compare in production.