LegalOn Technologies' Agent-Ready Golden Path on GKE

This blog is an abbreviated writeup of the LegalOn Technologies platform team’s Platform Engineering Premised on AI Agents: An Agent-Ready Golden Path Built with GKE talk at Google Cloud Next Tokyo, 2026.

AI agents have made writing code fast. Writing code was never the bottleneck.

That was the starting point for LegalOn Technologies’ platform engineering team, which presented its work at Google Cloud Next Tokyo ‘26. The team had mapped its development pain points before agents entered the picture, and the heaviest concentration sat in deployment and release, not coding. Faster code generation put more load on exactly those stages.

“However fast AI agents become at writing code, writing code was never the bottleneck to begin with.” Toshinori Sugita · Director of Platform Engineering, LegalOn Technologies

The team’s answer was an evolution of Akupara, LegalOn’s internal application platform on GKE, redesigned around the assumption that AI agents are platform users in their own right. The work is organized into three pillars: Context Engineering, Connection, and Guardrail. This case study covers all three, with the deepest look at Connection: how LegalOn restructured validation around the inner and outer loops of its development lifecycle, so developers and agents get high-fidelity feedback before the merge instead of after deploy.

The platform: Akupara on GKE

LegalOn builds AI software for legal and contract work, serving more than 9,000 customers with a development organization of roughly 200 engineers. Its products run on Akupara, an internal application platform the team operates as a product, with a stated vision of giving developers a golden path and robust infrastructure.

Two facts about the infrastructure are relevant to what follows:

• Applications run on GKE and Cloud Service Mesh, with a shared GKE Fleet and separate gateways and clusters per region across Japan, the US, the EU, and Singapore
• Deployment goes through Argo CD, which runs alongside GitHub self-hosted runners in a single consolidated operations cluster

Two kinds of platform users

The redesign started from one premise: the developer is no longer a single entity. There is the human directing an AI agent, and there is the agent itself doing the implementing. Akupara now treats both as platform users.

That premise surfaced three problems:

• Context. Agent output quality depends on getting the right context in the right amount, and the context window saturates, causing agents to drift from instructions.
• Feedback. Local environments are separated from runtime environments, so much of the meaningful validation only happens after deploy.
• Safety. Autonomous agents need boundaries and audit trails that prompts alone can’t enforce.

The three pillars

LegalOn’s response mapped one pillar to each problem. Context Engineering answers the context problem by classifying static and dynamic context and supplying the right amount at the right time. Connection answers the feedback problem by tying local development to the execution environment, so validation happens before the merge instead of after deploy. Guardrail answers the safety problem with layered quality gates, scoped permissions, and audit trails.

The structure matters as much as the parts. Context Engineering makes agents useful, Connection makes their output verifiable, and Guardrail makes the whole arrangement safe to run without a human watching every step.

Context Engineering and Guardrail, briefly

LegalOn’s diagnosis behind the first pillar was that most of what an agent needs to work correctly already exists inside the company. Provisioning relationships lived in engineers’ heads, design guidelines lived in Notion, and dependency knowledge was spread across repositories. None of it was in a form an agent could reliably find, so agents guessed, and the same review comments repeated. The Context Engineering work was a set of conversions of that knowledge into structures that agents can consume:

• A Product Catalog YAML declares each product’s intended state, read by agents and Terraform alike as a shared source of truth, with a derived Resolved Catalog supplying convention-correct resource names
• A knowledge graph converts Terraform HCL and Kubernetes configs into a SQLite graph served over an MCP server, so agents trace the blast radius of a change through resource relationships instead of searching the repository. On review-task benchmarks, this cut token consumption by roughly 25%
• Design guidelines that lived in Notion and design docs became Skill references that route agents to the applicable review criteria. Against an infrastructure repository that sees around 300 PRs on a busy day, LegalOn is approaching a state where more than half need no human review
• For work that outlives one session, the issue tracker doubles as a state machine. A controller selects the next runnable issue and launches a short-lived executor job that holds no long-lived credentials

The Guardrail pillar started from a framing the team was careful about: the goal was not to add prohibitions that stop AI, it was to make explicit what can be entrusted to agents and where human judgment is required. Before deployment, a QA Toolkit of four Agent Skills standardizes test planning through case generation. After deployment, just-in-time access through Backstage grants pre-approved permission sets that expire automatically via IAM Conditions on Google Cloud and an in-house Temporary RoleBinding CRD on Kubernetes. The team is also connecting audit evidence and infrastructure code to an internal security platform that prioritizes actionable risks and proposes fixes, while leaving the final merge decision to humans.

Connection: moving validation before the merge

Connection is the pillar that addresses the bottleneck directly.

The starting point was measurement, not agents. LegalOn had already mapped collected developer pain points and user interview results onto its software development lifecycle, across product managers, QA teams, and engineers. The heaviest cluster sat on deploy and release. Agents didn’t create that bottleneck. They raised its cost.

The team identified three specific costs:

• Release speed. Implementation got fast and accurate once agents had sufficient context, but slow validation and deployment kept end-to-end delivery slow
• Validation fidelity. Local environments couldn’t reproduce real permissions, networking, dependencies, data, or runtime behavior
• Cycle length. A problem found after deploy sent the fix back through the entire merge-and-deploy path

The response was a policy: make it possible to verify application behavior on GKE before the PR merges. To implement it, LegalOn split the lifecycle at the pull request. The inner loop is everything local up to opening a PR. The outer loop runs from PR through CI, review, and deployment onto GKE. Each loop got its own mechanism, and the team sequenced the work by weighing feedback impact against setup effort, inner loop first.

The inner loop: connect local to the cluster

For the inner loop, LegalOn adopted a local-connection pattern, implemented with mirrord. The developer’s local process is wired into the remote GKE cluster at the network level, so code running on a laptop uses the same ConfigMaps and Secrets as in-cluster workloads, reaches the GKE metadata server, and calls databases and other Google Cloud services with real tokens. A developer, or an agent working alongside one, gets cluster-fidelity feedback before a PR exists.

The outer loop: a preview environment per PR

For the outer loop, LegalOn adopted preview environments using Signadot: attach a label to a PR, and the platform duplicates the affected workloads and issues a dedicated URL for that change.

LegalOn already runs Argo CD and Argo CD Image Updater, so Argo CD PR Generator was the first candidate. The team passed on it because it fit poorly with how they manage Argo CD Application resources through existing Terraform modules, and selected Signadot instead. The networking coverage matters when a frontend preview needs to reach a backend preview.

“We adopted Signadot for its operability and for how thoroughly it handles networking, from URL provisioning to connecting preview environments to each other.” Toshinori Sugita · Director of Platform Engineering, LegalOn Technologies

This was the heavier build of the two. Preview environments required coordination with application repositories, not only the infrastructure repository, and backends added database connections and frontend-to-backend preview wiring. The rollout was therefore staged, starting with frontend use cases the local-connection approach doesn’t cover.

The use cases extend past the developer who opened the PR:

• Developers verifying their own changes
• Designers running design checks
• QA teams testing against a real environment
• Automated test suites
• Demos for business teams

A local environment is confined to one laptop. A preview environment with a URL can be opened by anyone involved in the change.

The two mechanisms divide by audience and by feedback profile. Local connection serves an individual developer coding and debugging, with feedback in tens of seconds against existing Pods. Preview environments serve the team around the developer, with feedback in minutes and partial workload replication per PR.

The team’s summary of the pillar was concrete: connect execution-environment context to local development, and front-load production-equivalent validation to before the PR. The target for feedback is tens of seconds, in a form both AI and humans can read. Today the inner loop meets that target, while preview environments return feedback in minutes. Either way, the team’s conclusion held: however fast implementation gets, delivery does not get faster while validation and deployment stay slow.

The current work connects this back to agents. Preview environments are already in use across multiple products. LegalOn is now building Agent Skills for both mechanisms, so an agent can run the cycle itself: set up the environment, validate by running tests, then fix based on feedback from the runtime environment and the test results. If agents write the code, agents also wait on validation. Those skills will make preview environments a feedback mechanism agents use to check and fix their own work, not only a review surface for people.

The golden path is for agents too

Context Engineering hands agents the knowledge to decide. Connection moves validation to before the merge. Guardrail makes quality gates, permissions, and audit trails systematic, so humans concentrate on release judgment.

“An Agent-Ready Golden Path is a redesign of platform engineering so that not only human developers but AI agents too can safely travel the same road.” Toshinori Sugita · Director of Platform Engineering, LegalOn Technologies

The problem Connection tackles is worth examining in your own organization: whether developers and agents can validate changes against a real environment, and how fast that feedback arrives. Signadot supports both local-development and pre-merge validation workflows. At LegalOn, mirrord serves the inner loop, while Signadot provides preview environments for the outer loop.

---

This post is based on the customer session Platform Engineering Premised on AI Agents: An Agent-Ready Golden Path Built with GKE, presented at Google Cloud Next Tokyo '26 by LegalOn Technologies, a legal AI company headquartered in Tokyo with offices in San Francisco, London, Munich, and Singapore. The session came from the Japan-based platform team: Toshinori Sugita, Director of Platform Engineering, Rihito Ito, Site Reliability Engineer, and Takahiro Koichi, Engineering Manager for the product platform section. The session was delivered in Japanese, and quotes in this post are translated. The full deck, also in Japanese, is available on SpeakerDeck.