LY Corporation's AI Agent Platform: Agent Builder, Agent Runtime, and Going From 7 to 22 Domains

On August 26, 2026, LY Corporation — the company behind LINE and Yahoo! JAPAN — published the design of the platform powering its AI agent service, Agent i, on its official engineering blog.

The most instructive part of this case is not the technology but the fact that the team reversed its order of work. It set out to solve multi-agent coordination, on the assumption that agents would proliferate and connecting them would be the hard part. What it found instead was that building even one agent was still too difficult, so it built the platform for creating agents first.

This article covers only what is stated in LY Corporation's official engineering blog and official press releases as of September 2, 2026. No inferred architecture is included.

What is actually running

Agent i is the brand created by merging two previously separate products: the "AI Assistant" in Yahoo! JAPAN and "LINE AI" in LINE. It launched on April 20, 2026.

• ▸At launch on April 20, 2026 there were 7 domain agents (including beta). Shopping, outings and weather were among them; automotive, relationships, work advice and recipes shipped as beta
• ▸By June 30, 2026 the cumulative count had grown to 22 domains (including beta). A finance agent launched that day
• ▸It is delivered as a web service reachable with one tap from both LINE and Yahoo! JAPAN
• ▸The company states it draws on proprietary data from more than 100 of its services

That is 7 domains to 22 in a little over two months. The platform published in August is what makes that rate possible.

Starting at multi-agent, then backing up to "can we build one?"

According to the engineering blog, the team had previously worked in a different AI area and pivoted to AI agents as LLMs advanced. At the point of the pivot, what to build had not been decided; the team started by mapping the problems.

Its first hypothesis was that agents would multiply quickly, making agent-to-agent coordination the first thing worth solving.

Investigation broke that premise. The blog is direct about it: building a single agent required writing code, which limited the work to engineers. Branching and execution paths were hard to follow, so designs were hard to reason about, and getting an agent deployed and running took real effort.

In other words, the things to be coordinated could not be produced fast enough. Coordination was reclassified as something to tackle later, and the team switched to building an environment where an agent could be assembled and tried quickly.

How the platform is put together

The platform consists of Agent Builder (the authoring tool) and Agent Runtime (the execution layer). The team rejected adopting an existing tool as-is, judging that it could not simultaneously satisfy "connect safely to internal data" and "keep extending it to fit our own service requirements," and built both in-house.

Agent Builder — assembling with nodes and edges

• ▸A graph-based no-code editor where workflows are assembled by placing and connecting nodes and edges. The editor is built on React Flow
• ▸LLM steps, branching and loops are combined on screen, and the flow runs from testing through publishing and deployment in one place
• ▸Each workflow is compiled into a proprietary intermediate representation (IR), which is validated for structure and settings before being saved
• ▸Validation checks reachability and connectivity using graph theory, and returns feedback to the author before publication — the point being to stop structurally broken workflows from failing at runtime
• ▸Structured Outputs are handled by auto-generating a JSON Schema from the output fields configured on screen, so no schema authoring is required
• ▸Of the LLM API parameters, the ones whose effect is easy to understand — such as Verbosity and Reasoning Effort — are surfaced prominently and can be tuned per step alongside model selection

Worth noting: this is not a "make everything no-code" design. The blog states plainly that the supported use cases were deliberately narrowed to keep the tool usable, and that complex control and advanced customization remain the engineers' job. Incoming feature requests are also not adopted wholesale — each is weighed on whether it is clear to a broad set of users and resistant to misconfiguration.

Agent Runtime — compiling the IR into an execution graph

Agent Runtime exists to run published workflows stably under service load, and scales on Kubernetes. The gap between design-time and run-time data representations is absorbed by the IR as a shared model. The flow is as follows.

• ▸1. An internal user defines a workflow in Agent Builder
• ▸2. The workflow is compiled into the IR, validated for structure and settings, and saved
• ▸3. When Agent Runtime receives an execution request, it loads that IR
• ▸4. The IR is converted and compiled into a LangGraph execution graph and run — LangGraph was chosen because it handles conditional branching, loops and inter-node state management, which makes the IR straightforward to map onto it
• ▸5. A Gateway in front converts each service's differing connection style into Agent Runtime's common interface, absorbing specification differences and handling authentication

The division of labour at the Gateway is spelled out. For Agent i, Agent Builder provides a shared Structured Outputs template for controlling output, and the Gateway converts only the common portion that Agent Runtime needs. The UI definitions — cards, forms, tables — are passed straight through to Agent i, so adding a new UI component on the Agent i side requires no change to the Gateway's conversion logic.

The stated direction is to support A2A (Agent2Agent) for agent-to-agent connections and MCP for LLM clients, but the current protocol is proprietary. The blog gives the reason: A2A had only just been announced when development started and its specification was not yet stable.

Reconciling "anyone can build" with "it runs safely"

Widening the set of people who can build things also widens the variance in what ends up running in production. How that is contained is the other instructive half of this case.

• ▸Kubernetes namespaces are separated per execution environment and treated as logical sandboxes
• ▸Each environment restricts outbound destinations with network ACLs, and access to MCP servers, documents and internal APIs is verified at execution time
• ▸Credentials and API keys are not stored in workflow definitions. They are fetched at the moment they are needed to connect to internal data or external services
• ▸Namespace separation also localizes load per environment, so a surge against one group of workflows is less likely to spread, and replica counts and resources can be tuned for just that scope
• ▸Pre-publication IR validation (reachability and connectivity) stops structurally broken workflows before they reach runtime

The load-testing account is concrete: after revisiting CPU and memory, raising the replica count to handle concurrency made network bandwidth the next bottleneck. The lesson drawn is that the execution platform needs continuous monitoring and the ability to retune resources as bottlenecks move.

During root-cause work the team also delegated stub creation, log and code investigation, cause analysis, and drafting fixes and test criteria to a coding agent, while people kept ownership of the design and verification approach and the final check.

What changed for the people doing the work

• ▸Even when engineers are still needed for the final implementation, planning and sales staff can build a prototype to make an idea concrete
• ▸Steps can be added or reordered on screen, so the result of one experiment feeds directly into the next revision
• ▸A workflow validated in the tool connects straight through to the service, shortening the path from idea to end user
• ▸Planning and sales staff can express their own domain knowledge as prompts and process flows, so know-how that never survived translation into requirements now shows up in the running behaviour
• ▸Existing prompts and workflows can be reused, lowering the entry cost for new authors
• ▸With internal data connected, agents can reach the data they need autonomously through MCP and RAG

The blog closes by noting that the team has "finally reached the stage where we can move on to the multi-agent design we envisioned when the project started." It arrived back at its original problem only after building the foundation underneath it.

What to take away from this case

Question the cost of building the first one before you plan for coordination. AI roadmaps tend to be drawn from a future state in which many AIs work together. In this case the binding constraint sat earlier: only engineers could build anything at all. When the people who want to try something cannot try it themselves, volume never materializes. If you are running the same evaluation internally, measuring how many days it takes to *start* building — not to finish — will tell you more.

Anything that widens who can build must be designed together with runtime isolation. A platform anyone can build on means production runs code of varying provenance. That is why this case pairs it with environment separation, restricted egress, and keeping credentials out of workflow definitions. "More people can use it" and "it runs safely" are treated here as one design problem, not two projects.

If the future connection standard is unsettled, put a translation layer in front and keep going. Rather than waiting for A2A to stabilize, the team absorbed the difference at the Gateway and shipped on a proprietary protocol. Not blocking on a standard, and instead building the place where it can be swapped later, generalizes well beyond this company.