How Japan Airlines Got 741 AI Agents Running Before Most Companies Finished Their Pilot

November 07 2026 02:12
Most companies talk about AI agents in the future tense. At the Google's Agentic AI Summit '26 conference session in Japan, members of the JAL Digital team talked about them in the present tense, with numbers attached. They covered how Japan Airlines picked its tools, how it ran a proof of concept, what employees are actually building, and where the group wants to be by 2030.

The speakers described a network of 211 routes and roughly 1,000 flights a day, carrying about 48 million passengers a year. The group employs around 39,000 people, and about 9,000 of them do desk work. The rest are pilots, cabin crew, airport staff and mechanics, which matters because an AI rollout that only works for office workers would miss most of the company.


The speakers pointed to a shrinking working age population in Japan and said that doing the same things the same way will not hold up. The goal they described is to move past a phase where people type a prompt every time, toward a setup where AI carries out parts of the work on its own. If AI takes over some of the routine tasks, they argued, employees can spend more time on work that only people can do.


This sits inside a larger plan. JAL has put DX, short for digital transformation, in its long term management vision, and the group announced its Management Vision 2035 earlier this year. In April 2025 it merged its digital teams into one company, JAL Digital, so that people and know how that used to be scattered across departments and subsidiaries sit in one place.




Before agents, there was a long stretch of getting ordinary employees comfortable with generative AI. JAL launched an internal tool called JAL AI in 2023, built around company specific work like drafting documents and searching huge piles of maintenance material. In 2025 it added Gemini as a general purpose assistant, including the side panels inside Google Workspace apps.

The numbers the speakers shared are strong. Monthly usage across the whole group, field staff included, is about 70 percent, and the average person uses AI around 50 times a month. For comparison, a Nikkei Business feature reported that 65 percent of all JAL employees, including flight crew, cabin crew, airport and maintenance staff, were using AI for work by the end of fiscal 2025. The speakers' figure suggests the habit has kept growing.


How did they get there? They described problems that will sound familiar to anyone who has run an internal rollout:

• Big gaps in AI skills between employees
• Only a small group of enthusiasts using the tools
• People who had access but could not see how it applied to their own job

Their answer was a four level training curriculum based on skill, plus separate hands on programs for specific departments and group companies. The training meant a mechanic and a marketer each got examples from their own day, not a generic tour. That is also why employees stopped treating the tool as a novelty.

The wider context helps here. A Fujitsu cabin crew case study on JAL noted that only 42.7 percent of companies in Japan have defined AI usage policies, compared with more than 80 percent in the US, Germany and China. JAL's early investment in rules and education put it ahead of that curve before agents entered the picture.


The agent project started in April 2026 with information gathering. By July the team had cut the field down to three candidates. After roughly two months of testing with real users, they chose a tool in September and began wider rollout in November. The speakers said they deliberately avoided waiting for the market to settle, because it changes every month. Instead they made a decision every few months with the information they had, then repeated the cycle.


The team was built for speed. Three groups worked together from day one: an adoption team that talks to non IT employees every day, a system architecture team that handles the gateway, Gemini Enterprise and the surrounding setup, and a security and company wide standards team. The speakers credited that early mix with avoiding rework later, since the people who could say no were in the room from the start.

Here is the part I found most useful. With countless tools on the market and no budget to try them all, the team wrote down about 30 comparison criteria. Several of them were dealbreakers, and most of those were about security. A tool that failed one was out, no matter how impressive the demo.

The criteria they described fell into a few groups:

• User needs, such as whether an agent built by one employee can be shared with a team instead of staying personal
• Cost, such as whether token usage can be tracked and capped so budgets do not blow up
• Long term strategy, such as whether agents inside and outside the company can eventually talk to each other
• Governance, which they weighted most heavily, including stopping sensitive data from leaking through prompts, protecting data on devices, and forcing a human to approve risky actions like changing important data or connecting to outside systems

That last item is worth underlining. Requiring a human to approve consequential actions was not a nice extra. It was a condition for being considered at all.


The proof of concept had two hard problems. Testers needed some technical comfort to give useful feedback, and nobody had settled how much freedom an agent should get. For testers, the team recruited the DX leaders who already exist in each department. These are people who lead digital projects in their own areas and talk with IT staff regularly. Because they understood the tools, their feedback was sharper than a random volunteer's would have been.


For permissions, the company had no firm rules yet, so the team negotiated settings with the security group. Having a security colleague on the same project made it easier to learn what worried them and to bring the right decision makers in quickly. The team also asked the vendor directly for reference material and training support, which let them get up to speed in a short window. At the end, they trimmed the 30 criteria down to the critical ones and updated results as the tools changed, so the evaluation stayed fast.


This is where the talk got concrete. Using an admin API, the platform team analyzed what employees had built inside Gemini Enterprise. The count was 741 agents. A few findings stood out:

• 44 percent use several agents working together
• 96 percent are personal and unshared, while 4 percent are shared
• 77 percent run on a Gemini Flash model, which the speaker described as the 3.5 version
• Roughly a quarter to a third of new agents run on a schedule instead of waiting for a person to ask

The use cases ranged from the practical to the playful. Field teams built agents to help with work specific to aviation, such as handling duty schedules for mechanics, and there are about 39 agents that answer internal questions. In the digital group, someone made a "digital twin" of a manager, a prompt that captures the manager's values so a team member can use it as a sounding board. Others handle forms, review work and manage secretarial tasks. The most common category was email, scheduling and task management, which mostly connect to Google Workspace products.


That last point reveals the current limit. Because most connected data lives in Google tools, most agents are about office productivity. Some teams link Confluence and Jira too. The plan is to add custom connectors that reach the systems field teams actually use.



The first connects an agent to flight data. It is built with Google's Agent Development Kit, deployed to an agent runtime, and linked to internal flight records through the Model Context Protocol. People can ask it to total up delayed flights or look into how one delay affects the next flight. The clever bit is a sandbox that filters the huge response from the flight system before the model sees it. In the example they gave, raw flight data came to about 135,000 tokens, and after filtering it was about 8,300, a cut of roughly 94 percent. That protects accuracy and keeps costs down.




The second is an analysis agent for AI usage itself. Gemini usage logs go into BigQuery, a data agent is built there, and it is then published into Gemini Enterprise using the Agent to Agent protocol. An employee can ask questions about usage by week or by department from the usual Gemini screen. The plan is to add JAL AI usage later.



The third is an audit of important systems. Reviewing documents against a checklist used to take about four months. A small trial using NotebookLM with retrieval got an agreement rate of 76 to 83 percent with human reviewers, but repeating it by hand was tiring. So the team is now building a coordinating agent that reads documents from a Drive folder, uses several sub agents, and runs a newer workflow feature to step through each check. A number like 76 to 83 percent is not good enough to replace a person, which is why this is framed as a way to share the load.


Google's own announcements help explain why this is possible. At Cloud Next in April, Google renamed Vertex AI to the Gemini Enterprise Agent Platform and folded Agentspace into a single Gemini Enterprise product. It also pushed two open standards: MCP covers how an agent connects to tools and data, while Agent to Agent covers how agents talk to each other. JAL's examples use both.


One of the more honest parts of the talk was about what could go wrong after launch. JAL already has Gemini across the group, so employees could reasonably ask why they need an agent license too. If nobody can explain the difference, licenses will sit unused. And without connectors to company data and proper training, the useful ideas from the field will not appear.

The team's response has three parts:

1. Explain clearly to anyone who asks how the agent tool differs from regular Gemini.
2. Take licenses back from people who have not used them for a set period and give them to people who need them.
3. Keep building connectors for field systems and keep expanding training, while sorting out the organizational approvals those connectors need.

The speakers said the goal is not installing a tool. They plan to put at least as much effort into training and operations as they did with the first generative AI rollout.



The roadmap rests on three ideas: more data, more autonomy, and tighter guardrails.

On data, today's agents mostly sit inside Workspace. JAL's real data lives in many places, including on premises systems and other clouds. The plan is to connect it through standard protocols and to prioritize connectors for flight operations, reservations and maintenance, because those are what the field cares about.

On autonomy, the aim is for agents that notice something and act, not just reply when asked. The speaker said that in autumn 2025 the field was asking for timers and for agents that could work with each other. Both now exist, and the next step is more hands off work.

On security, the speakers were direct that more data multiplied by more autonomy means more risk. Their answer is fast, flexible guardrails: human approval, filtering of personal information, control over what agents may do, and records of what they did. They asked Google for continued support of open protocols, a platform that can act ahead of the user, and a control layer sturdy enough that JAL's team can focus on business logic.

Looking toward 2030, JAL pictures its own agents in flight operations, maintenance, customer service and the cabin, connecting to agents in the wider world, such as airports and local transport. The stated aim is to become an AI native airline that customers choose and love.