In Japan, platform engineering has moved from a buzzword to something teams actually practice. What people need now isn't another explanation of the concept but practical know-how. At the same time, AI agents are changing what a platform has to do. That's why the theme of Platform Engineering Kaigi 2026 (PEK2026), held on September 26 in Tokyo, was AI Native Platform Engineering. We didn't set out to hand down the answers. We wanted a place where practitioners could bring real examples and find the answers together.
PEK is Japan's one-day, volunteer-run community conference for people who build and run internal platforms, and this was our third edition, held at Nakano Central Park Conference. This post looks back at the day from the organizers' side. It covers the state of platform engineering in Japan, the keynote and talks, and Platform City, a live experiment where more than a hundred attendees pointed their AI coding agents at the same platform and watched their apps rise as buildings in a shared 3D city. If you're reading from outside Japan, we hope it also gives you a window into what's happening here.
Platform engineering in Japan, and why we went AI Native
Platform engineering started drawing attention in Japan in late 2022. Our community began in 2023 as the Platform Engineering Meetup, when most of the work was explaining what the term meant, and we held the first Platform Engineering Kaigi ("kaigi" means "conference") in 2024. Today most teams have heard of it, but adoption is still early. When we asked this year's registrants where their organization stands:
- 29.6% know about platform engineering and are considering adopting it
- 23.3% have started offering a minimal platform
- 18.3% have several teams using their platform
- 16.0% say their platform is the de facto standard inside the company
- 12.8% have no plans yet
So many Japanese teams are building their first platforms right now, just as AI agents are changing how software gets written. That raises new questions. How do you give an agent the right guardrails? How do you give it feedback it can act on? What does a platform look like when its most active users aren't human? Those were the questions we wanted PEK2026 to take on.
The community felt the same way. 76 of our 90 talk proposals (up from 70 last year) mentioned AI, LLMs, or agents. The next most common topics were about keeping that power in check: guardrails and governance (34), identity and access control (26), and cognitive load (22).
PEK2026 by the numbers
Most attendees were hands-on engineers, led by infrastructure engineers and SREs.
Highlights
Keynote: Architecting Agentic Development Platforms
We opened with a keynote from Kaspar von Grünberg, co-founder of PlatformCon and co-author of Thinking in Platforms. His talk, "Architecting Agentic Development Platforms," looked at AI's impact on a platform in three roles: as a user of the platform, as an interface to it, and as a capability inside it. He then described how today's Internal Developer Platforms evolve into Agentic Engineering Platforms.
Kaspar spoke in English with real-time AI Japanese captions. For the Q&A, attendees posted questions in Japanese on Live Q&A, an open-source tool built by one of our organizers, which translated them into English within seconds. It handled more than 5,000 requests in 15 minutes, and any conference can self-host it (GitHub, the story behind it).
After the keynote, Kaspar signed copies of Thinking in Platforms, which we also sold on-site at a discount. Inspired by his talk, attendees lined up to get their copies signed, and the books sold out in no time.
Platform City: a live experiment in agent-first platforms
The main attraction of PEK2026 was Platform City, a live experiment that we, the organizers, designed and ran ourselves.
The idea was simple. Attendees used their own coding agents (Claude Code, Codex, Cursor, and others) to build and deploy apps onto a platform we built for the day. Each deployed app appeared as a building in a 3D city shown on the big screen at the venue. To join, you added a single MCP server URL to your agent and asked it to onboard you. A minute or two later you had your own repository, a working CI pipeline, a Kubernetes namespace, and a public URL. You didn't need to know Kubernetes or Docker.
From there, the city reflected the real state of each app:
- Scaffolding went up while a new version was rolling out.
- Windows lit up once the app passed its health check.
- Smoke, and sometimes fire, appeared when an app crashed or stopped responding.
We didn't fix broken apps behind the scenes. Each participant's own agent diagnosed and repaired the app, using the status and log information the platform returned. And buildings did catch fire throughout the day, so this was put to a real test: each time, it was the owner's agent that put the fire out. Participants could also publish APIs for one another to use, which gave the city its own small economy, and visitors could "like" buildings to make them grow into skyscrapers.
Some buildings linked to the live streams of the talks, and about 200 session views came through them.
Platform City was also our way of testing a few hypotheses about AI-native platforms:
- If you give an agent the platform's knowledge through MCP, onboarding becomes almost free.
- If the platform defines clear contracts (a health check path, a port, an API catalog), the ecosystem can grow on its own.
- AI agents can be a platform's best users, if the platform's feedback is good enough for them to act on.
Building it taught us a lot. The quality of a platform's feedback mattered more than how capable the model was. Guardrails had to be built into the structure of the platform rather than added as human approval steps, because no one can manually approve 100 people deploying at once. And keeping the platform's own checks deterministic made the non-deterministic work of AI agents safe to run. If you want the details, our pre-event posts cover the agent-first design, the infrastructure behind it, and why we made it a city.
Several attendees told us that getting hands-on in Platform City deepened their understanding far more than listening alone would have. That was exactly what we hoped for.
Talks
After the keynote, 23 talks ran across three tracks, and the program reflected the proposals. AI was the biggest thread: putting guardrails and governance around coding agents, bringing SRE agents into operations, and running the GPU clusters behind it all. The classic platform topics were there too, including internal developer platforms, safe Infrastructure as Code, Kubernetes controllers, observability, and running a platform as a product.
Many of the talks were practical stories from inside real organizations, and attendees told us in the survey that they valued seeing how other companies are actually approaching these problems. The session slides, and the videos once they're up, are the best way to find the ones that match your own situation.
Books for beginners and practitioners
Every registered attendee received a free copy of はじめてのプラットフォームエンジニアリング (roughly, Your First Platform Engineering), an introductory book with manga illustrations, written by members of the Cloud Native Conference organizing committee. For practitioners, there was the Thinking in Platforms signing with Kaspar.
Booths, yatai, and the networking party
A conference day packed with talks is long, so we wanted the venue itself to feel welcoming. We brought in yatai, the traditional Japanese food stalls you'd normally find at a local festival, where attendees could grab freshly made food between sessions. For anyone whose shoulders were stiff from a morning of laptops and talks, a shiatsu massage corner offered a few minutes of relief. And a local barista brewed fresh coffee for attendees. All three became natural gathering spots, and they started plenty of hallway conversations. The sponsor booths were busy all day too, and a stamp rally, where attendees collect a stamp at each booth on a card, sent people around the whole exhibition area.
The day ended with a networking party, where speakers, sponsors, attendees, and staff mixed freely. For many of us, those conversations were the best part of the day.
Behind the scenes
PEK is a community-driven event, and every member of our core staff is a volunteer. That includes the people you might assume are hired professionals. Our 20 core organizers plan the event over several months. A volunteer NOC team of 20 builds and runs the venue Wi-Fi, and a volunteer streaming crew handles all of the live broadcasts. On the day, 26 day staff help with reception and guide attendees around the venue. Platform City and Live Q&A were also built by organizers in their spare time, using the same platform engineering ideas the conference is about.
Thank you, and what's next
Thank you to everyone who made PEK2026 happen: the speakers, the sponsors, the staff, and every attendee who joined in person or online.
We're already planning Platform Engineering Kaigi 2027. Until then, slides are on the PEK2026 sessions page (videos coming soon), and the Platform Engineering Meetup runs regularly throughout the year. Both are mainly in Japanese. Follow @cnia_pfem on X and #pek2026 for news.
See you next time!
