line·Jun 22, 2026·4 min readCurated summary

From Automation to AI with Infrastructure as Code (IaC): Adopting OpenTofu and ChatOps

LY Corporation’s LINE Plus SRE team migrated Verda cloud infrastructure and IMON monitoring resources from scattered, manual management into an Infrastructure as Code (IaC) and GitOps workflow. Using OpenTofu and Terragrunt, they now manage roughly 1,500 resources across seven services through pull requests, CI/CD, and daily drift detection. The migration required careful automation for importing existing resources, normalizing state, and handling provider limitations and resource dependencies. ## Why IaC Was Needed - Teams previously managed infrastructure through different methods: - Verda’s web dashboard - Scripts - Wiki-based procedures - Personal documents and GitHub repositories - As the number of services and resources grew, this caused: - Inconsistent management practices - Difficult-to-track configuration changes - Greater risk of manual errors - Poor reproducibility and reviewability - The team adopted GitOps so that: - Desired infrastructure state is declared in Git. - All changes go through pull requests. - Infrastructure history is versioned and auditable. - CI/CD applies approved changes automatically. - Their goal was to manage infrastructure with the same engineering standards as application code: reviewable, version-controlled, and reproducible. ## Choosing OpenTofu and Terragrunt - OpenTofu was selected as an open-source Terraform fork. - It retains: - Terraform’s HCL syntax - Provider compatibility - Familiar module and configuration patterns - The team created reusable modules for: - Virtual machines - Load balancers - Monitoring alerts - Modules were versioned so updates could be adopted explicitly rather than affecting every environment immediately. - Terragrunt was added to reduce repetition in environment configuration. - Shared settings are defined once in a parent `root.hcl`. - Individual environments contain only their differing inputs. - OpenTofu reduces duplication in resource definitions, while Terragrunt reduces duplication in environment and backend configuration. ## Planning the Migration - The most difficult part of introducing IaC into an existing environment was importing resources that were already running. - Manual import was considered impractical for hundreds of VMs, load balancers, and DNS records because it would be slow and error-prone. - The migration was split into two phases: - **Phase one:** Automate imports, select one service for a pilot, and establish the complete OpenTofu/Terragrunt pipeline. - **Phase two:** Reuse the validated modules and import scripts to roll the approach out to the remaining services. ## Designing the Import Process - Import scripts were designed to: - Query existing resources - Decide which resources should be managed by IaC - Convert resource data into the desired code structure - Generate Terragrunt configuration - Connect resources to OpenTofu state - Run `plan` to verify that no unintended changes would occur - A key requirement was keeping three representations aligned: - Configuration code - OpenTofu state - Actual cloud resources - Normalization was added because equivalent values could be represented differently—for example, network or image IDs—causing OpenTofu to report misleading differences after import. ## Resource-Specific Import Strategies - Resources could not all be imported using the same procedure. - Different resource types have different identifiers, dependencies, and ownership models: - **VMs:** Imported individually, while distinguishing manually created instances from Kubernetes-managed instances. - **Load balancers:** Imported together with related listeners and pools. - **DNS:** Imported while preserving zone and record relationships. - **Kubernetes:** Structured around clusters and node pools. - **IMON:** Imported according to its hierarchy of teams, alert groups, alert rules, and monitors. - Each resource followed the same broad five-step process, but its implementation was adapted to the resource’s characteristics. ## Problems Discovered During Migration ### Kubernetes-Managed VMs - OpenStack contained both manually created VMs and VMs automatically created by Kubernetes. - Importing Kubernetes-managed VMs into IaC could cause conflicts between OpenTofu and Kubernetes. - The scripts excluded these VMs using naming patterns and metadata. ### IMON’s Hierarchical Structure - IMON alerts are organized as: `Team → Alert Group → Alert Rule → Monitor` - A flat import would lose these relationships. - The team mirrored the hierarchy in the directory structure so ownership and relationships were visible from the file layout. ### Provider and Regional Identifier Issues - The actual cloud platform allowed both hyphens and underscores in load balancer names, but the provider validation logic rejected underscores. - The team fixed this by modifying the provider’s validation logic and contributing the change upstream. - Resource UUIDs such as `flavor_id`, `image_id`, and `network_id` differed by region. - This produced unnecessary changes in `plan`. - The modules added regional mapping logic, allowing users to specify readable names while resolving them to region-specific IDs. The migration demonstrates that successful IaC adoption requires more than writing configuration files: existing infrastructure must be filtered, normalized, modeled according to its dependencies, and validated against real provider behavior. OpenTofu and Terragrunt provided the foundation for scalable GitOps management, while custom import automation and provider improvements made the transition safe for production resources.

Read original(opens in new tab)

KubernetesCI/CDInfrastructure As CodeGitops+3

line·Jun 17, 2026·4 min readCurated summary

ID-JAG The Hard Way: Learning AI Agent Security Through Failure, Hands-On

ID-JAG provides a structured way for AI agents to access protected APIs on behalf of users without granting them permanent, broad permissions. The hands-on environment demonstrates how authentication, enterprise authorization policies, delegation, and token exchange work together across Keycloak, Athenz, MCP, and resource servers. Its central conclusion is that AI-agent security requires explicit delegation boundaries and centralized policy enforcement, not just user authentication at the entry point. ## Why AI Agents Need a Different Authorization Model - AI agents continuously call internal APIs, SaaS tools, databases, and other services. - Requesting user consent for every automated action would create an unusable experience. - Granting agents permanent, broad access increases: - Blast radius during failures or compromise - Difficulty assigning responsibility - Exposure to prompt injection and shadow AI risks - The key question becomes whether an agent is authorized to access a specific resource, for a specific user, with a specific scope at a specific time. ## ID-JAG and Its Practical Role - ID-JAG is an emerging OAuth profile discussed by the IETF OAuth Working Group. - It combines: - OAuth 2.0 Token Exchange (RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) - It models delegated, cross-domain API access using explicit authorization grants. - The hands-on explores questions that architecture diagrams often leave unanswered: - What token payloads are issued? - Why should an ID token not be exchanged directly for an access token? - Where are enterprise policies evaluated? - How does an agent prove it is acting for a user? - How is trust established between the identity provider and authorization server? ## Separating Authentication from Enterprise Authorization - Keycloak acts as the upstream identity provider: - Authenticates the user - Issues the original identity assertion - Athenz, through `KeycloakTokenExchangePlugin`, acts as: - The authorization server - The ID-JAG issuer - The policy decision point (PDP) - The central resource authorization authority - Athenz validates the Keycloak assertion’s: - Issuer - Signature - Audience - Subject - Client binding - Enterprise policy requirements - Resource authorization servers trust only the Athenz-issued ID-JAG, rather than accepting Keycloak tokens directly. - Centralizing delegation policies in Athenz reduces duplicated or conflicting rules across identity providers, SaaS vendors, and applications. ## End-to-End Request Flow - The user logs in through Keycloak. - The user gives the AI agent a task through a prompt. - The agent requests an ID-JAG from Athenz. - Athenz evaluates enterprise policies and determines whether the delegation is allowed. - The agent requests an access token from Athenz. - The agent calls the protected MCP server with the issued token. - The MCP server exchanges the token with the authorization server. - The MCP server uses the exchanged token to call the final resource server. - The agent therefore operates within a policy-defined boundary instead of holding a long-lived master credential. ## Learning Through Deliberate Failures The tutorial emphasizes failure paths to show where each security control applies. - Calling a protected API without a token produces `401 Unauthorized`. - Defining an enterprise role without adding membership causes token exchange to fail. - Omitting the agent’s required delegation permission breaks the delegation chain. - These failures reveal whether the problem lies in authentication, grant validation, agent delegation, enterprise policy, or resource-token validation. ## Why ID Tokens Should Not Be Used Directly - An ID token proves that a user authenticated successfully to a client. - An authorization grant is an artifact submitted to request access to a particular resource and scope. - Directly exchanging an ID token can implicitly treat login evidence as permission to access resources. - Using an explicit ID-JAG grant creates clearer boundaries between: - Authentication failure - Grant validation failure - Delegation denial - Enterprise policy rejection - Resource authorization failure - ID-JAG is not technically required for the small local demo, but it makes authorization boundaries and audit paths much clearer. ## Hands-On Environment - The tutorial is available in `athenz-community/id-jag-the-hard-way`. - It guides users through a deliberate “fail, diagnose, and fix” workflow. - Users can later remove an agent’s delegation permission in the Athenz UI and observe exactly where execution is blocked. - This experimentation demonstrates the value of centralized policy control more effectively than a successful request alone. AI-agent ecosystems need more than front-door authentication. A practical deployment should use short-lived, explicitly scoped delegation, centralized enterprise policy evaluation, and observable token-exchange boundaries such as those demonstrated by ID-JAG.

Read original(opens in new tab)

AI AgentsModel Context ProtocolJwtAuthorization+4

line·Jun 10, 2026·4 min readCurated summary

Transitioning from a Legacy Project to an AI-Driven Project: The AX Roadmap

AI transformation (AX) is not achieved by simply adding AI tools; it requires redesigning the team’s development system around AI. The post proposes a four-stage roadmap for turning legacy projects into AI-driven projects, beginning with security and standardization and progressing toward specification-based development automation. Its central recommendation is to introduce AI gradually, with clear documentation, human approval gates, and measurable outcomes. ## What an AI-Driven Project Means - AI participates throughout the development lifecycle, including: - Specification writing - Code generation - Testing - Code review - Pull request creation and merging - Developers focus more on direction, judgment, and business decisions rather than repetitive implementation work. - The key methodology is **spec-driven development (SDD)**: - Requirements and implementation specifications are defined before code. - AI generates, tests, and reviews code against those specifications. - Structured specifications compensate for AI’s difficulty in interpreting ambiguous intent. ## Stage 1: AI-Ready — Establish Security and Compliance The first stage creates a safe foundation for using AI with project context and company data. - Remove hardcoded secrets such as API keys, database passwords, and internal IP addresses. - Use secret-management services to inject credentials dynamically at runtime. - Protect personally identifiable information by masking or tokenizing names, emails, phone numbers, and similar data before sending it to AI systems. - Separate or restrict access to critical intellectual property, including proprietary algorithms and sensitive architecture. - Define minimum compliance requirements first rather than delaying adoption until every security improvement is complete. - Use sandboxing, system prompts, filesystem restrictions, and network isolation to limit AI access. - Validate that isolation mechanisms actually prevent sensitive-data exposure. Expected benefits include safer AI usage, faster debugging and repetitive coding, and accumulated team experience that supports later adoption stages. ## Stage 2: AI-Assist — Standardize Team Usage This stage addresses teams where individuals already use AI but follow inconsistent practices. - Create project-level AI guidelines covering: - Project context - Coding conventions - Architecture principles - Domain terminology - Establish shared prompts, skills, or plugins for activities such as: - Brainstorming - Writing implementation plans - Code review - Subagent-driven development - Integrate AI into CI/CD for automated first-pass code reviews. - Let AI identify style violations, likely bugs, and security issues. - Reserve human review for complex business logic, architecture, and policy decisions. - At this stage, AI assists with human-written code rather than independently implementing features. Possible KPIs include: - A reduction in repetitive human review comments. - Increased test coverage. - Improved deployment reliability and system stability. - More consistent adherence to team conventions. ## Stage 3: AI-Development — Automate Implementation The third stage connects specifications directly to working code through an automated pipeline. - The pipeline includes three human approval gates: 1. **Specification review:** Confirm requirements, scope, edge cases, and validation criteria. 2. **Implementation and test-plan review:** Approve the AI-generated execution and testing plans. 3. **Code review:** Approve the final implementation before merging. - AI uses documented domain knowledge and architecture context to generate project-specific code. - A new file in a directory such as `/specs` can trigger CI automation. - CI can generate an implementation plan, execute coding tasks through independent subagents, run tests, and create a pull request. - Approval steps ensure that AI cannot proceed to the next stage without human authorization. To improve adoption, the post recommends expanding AI’s responsibilities gradually: - Begin with unit- and integration-test generation for existing logic. - Move progressively toward boilerplate and broader implementation work. - Avoid delegating critical business logic immediately, since poor early results can undermine team trust. ## Overall Adoption Principles - Each roadmap stage provides value independently; teams do not need to complete all four stages at once. - The appropriate target depends on team maturity, risk tolerance, domain complexity, and adoption speed. - Documentation is essential because AI needs structured project and business context. - Human oversight remains important, especially for requirements, architecture, business rules, and final code approval. - Security controls, common workflows, and measurable KPIs should develop alongside AI usage. Teams should start with the safest achievable stage, standardize practices before automating implementation, and expand AI’s role only as documentation, testing, and review processes become reliable.

Read original(opens in new tab)

CI/CDRAGTestingAi Coding Agents+3

line·May 29, 2026·4 min readCurated summary

ODW #8: A Hands-On Internal Workshop on Accelerating Incident Response and FAQ Generation with Slack MCP

LY Corporation’s Orchestration Development Workshop demonstrated how Slack MCP can turn scattered Slack conversations into structured operational knowledge. Using AI, employees can summarize incidents, generate reports, create FAQs, and publish results to Confluence with minimal setup. The workshop’s central conclusion was that hands-on practice, reusable skills, and human review are essential for turning new AI capabilities into practical workplace tools. ## The Information and Adoption Challenge - Slack contains valuable real-time information from incident response, customer inquiries, and project discussions. - Much of this information remains unstructured because employees lack time to document it. - Documentation quality varies by author, causing useful knowledge to become difficult to find. - Although Slack MCP became available internally in March 2026, adoption barriers remained: - Limited time to explore new tools - Concerns about complex configuration - Slow internal distribution of technical knowledge ## Introducing Slack MCP Through Hands-On Practice - Slack MCP is an internally developed MCP server connected to company authentication. - Employees can access internal Slack data without issuing personal tokens or configuring OAuth. - The workshop began with a simple exercise: - Launch a coding tool such as Claude Code - Ask the AI to post “Hello” in a designated Slack channel - Confirm that the message was actually posted - This immediate success helped participants understand MCP’s practical capabilities. ## Combining Slack MCP with Other MCP Servers Slack MCP supports several core operations: - Reading messages and threads - Posting messages and performing actions - Looking up channels and members - Searching Slack content Combined with other MCP servers, it can support broader workflows: - Slack plus Confluence MCP: Generate and publish project reports or FAQs - Slack plus Jira MCP: Create work tickets from discussions - Slack conversations can be transformed into structured documents rather than remaining isolated in chat history. ## Automatically Creating FAQs from Slack Inquiries The first major exercise converted repeated support discussions into reusable knowledge. - Slack inquiry threads were collected and converted into FAQ-formatted Markdown. - Existing Confluence content was checked to identify duplicates. - New FAQs were published as child pages under an existing Confluence knowledge base. - The output was formatted as a table containing: - Symptoms - Causes - Solutions The workflow was packaged into reusable skills such as: - `slack-to-faq`: Searches recent inquiry threads and generates new FAQ files - `faq-to-confluence`: Converts and publishes the FAQs to Confluence This demonstrated how MCP can automate the entire path from conversation search to knowledge-base publication. ## Supporting Incident Response The second exercise focused on reducing the time needed to understand and document incidents. ### Rapid Situation Summaries Participants could ask the AI to summarize an outage in natural language. MCP searched relevant Slack threads and organized the information into: - Current resolution status - Customer impact - Actions being taken by team members - A chronological timeline This helps managers or newly joining responders understand the situation quickly without reading every thread. ### Automated Incident Reports After resolution, the AI generated reports in a specified format, including: - Incident and detection times - Duration - Root cause - Affected users and features - Whether data was lost - Remediation steps The `slack-incident-status` and `slack-incident-report` skills separated real-time status checking from post-incident documentation. ## Practical Guidelines and Safeguards - Clean and constrain source data before processing it: - Compare results with existing Confluence FAQs - Filter messages using reactions or other markers - Limit searches to relevant channels and threads - Do not publish AI-generated documents without review. - Check for personal information and confirm that the output accurately reflects the source conversations. - Include links or references to the original Slack threads. - Specify the desired output structure, such as a three-column table for symptoms, causes, and solutions. - Convert successful prompts into reusable skills so teams can avoid rewriting complex instructions and maintain consistent output quality. ## Lessons from the Workshop - **Timing matters:** Holding the workshop soon after Slack MCP became available captured user interest and accelerated experimentation. - **Practice is more effective than explanation:** Starting with a simple Slack post and progressing to FAQs and incident reports made the benefits immediately tangible. - **Real work makes training relevant:** Inquiry handling and incident response were chosen because they are common, time-consuming tasks. - **Reusable skills improve adoption:** Prompt patterns were tested manually, refined, saved as skills, and shared with participants for continued workplace use. The recommended approach is to introduce new AI tools through timely, task-focused workshops, then refine successful workflows into shared skills. MCP can greatly reduce the effort of operational documentation, but human validation remains necessary before generated knowledge is published.

Read original(opens in new tab)

Generative AIModel Context ProtocolSlackClaude Code+4

line·May 28, 2026·4 min readCurated summary

From Tokyo to Fukuoka, Finding Answers in the Field: Our CS InquiryChat Implementation Journey

MessagingHub replaced Demaecan’s third-party customer-service chat with its own InquiryChat platform. The transition eliminated annual licensing costs, improved operational flexibility, and reduced repeat customer inquiries by about 20%. The project’s success depended not only on rebuilding features, but also on observing call-center work directly, aligning distributed stakeholders, and balancing agent convenience with user privacy. ## Why Demaecan Chose an In-House Platform - Demaecan’s existing chat provider was being discontinued, prompting a choice between upgrading to another vendor solution or adopting InquiryChat. - InquiryChat was selected because it offered: - Zero licensing costs - Flexible customization for Demaecan’s processes - Direct internal technical and operational support - Secure access to customer information - Real-time analytics and reporting - The migration had to preserve service continuity while changing agents’ workflows and tools. ## Problems with the Existing Service - Agents could preview messages before users sent them, creating a transparency and privacy concern. - Chat sessions were not preserved when users left, forcing customers to repeat their inquiries. - Vendor customization and integration options were limited. - Some existing features appeared useful on paper but were not actually used in call-center operations. - Because agents were accustomed to the existing system, they needed evidence that the replacement would improve their daily work—not merely solve problems identified by headquarters. ## Understanding Real Call-Center Needs - Requirements initially arrived indirectly through multiple departments, making their operational context difficult to understand. - The team reorganized requirements into: - Standard platform features - Features requiring customization or review - Features requiring new development - PM Kim Seri visited two call centers in Fukuoka, observed peak-hour operations, and interviewed agents and managers. - Field research revealed: - A manager-support chat feature was unnecessary because agents used hand signals instead. - Audio alerts were ineffective because office environments kept sound muted. - Integration with the existing CS system was essential because agents had to summarize and record every interaction after a chat. - These observations helped the team remove unnecessary features while raising the priority of workflows that were genuinely critical. ## Managing a Distributed Migration - The project involved teams in Korea and Japan, two Fukuoka call centers, external operators, and multiple internal departments. - To create a shared operating model, the PM: - Built a Jira dashboard to visualize progress and support data-driven decisions. - Created a master specification as a single source of truth. - Led internal product and development QA to ensure the original intent was implemented correctly. - Produced detailed operational guides for launch and adoption. - These processes reduced ambiguity across the project and supported a smoother transition from development to live operations. ## Focus Group Testing and Interviews - A focus group test (FGT) brought all stakeholders together to act as customers and CS agents. - Participants followed complete scenarios, from opening an inquiry through resolution. - The FGT exposed user-experience issues before formal QA, including: - Unclear role and status indicators - Android push-notification instability - Keyboard and input-field overlap - Missing timestamps on links - Push-title wording issues - Chat logs not consistently reaching the CS system - Several issues were fixed immediately, while clearer role and status displays were scheduled for further improvement. - Follow-up focus group interviews found the system generally stable and easy to operate, though some participants initially needed time to understand operator and manager roles. ## Balancing Agent Convenience with Privacy - Agents strongly valued the old “message being typed” preview because it helped them anticipate replies and reduce average handling time (AHT). - From a platform perspective, previewing unsent or deleted text was a serious information-ownership and privacy risk. - Rather than simply removing the feature, the team introduced a typing-status indicator. - This preserved agents’ awareness of the customer’s response rhythm without exposing the customer’s actual unfinished text. The project demonstrates that successful system internalization requires more than feature parity. Direct observation, structured stakeholder coordination, realistic user testing, and privacy-conscious design enabled Demaecan to reduce costs while improving both operational efficiency and customer experience.

Read original(opens in new tab)

AndroidUser ResearchJiraInformation Security+3

line·May 22, 2026·4 min readCurated summary

ODW #7: Reduce Token Consumption by 40% in Three Ways! Context Engineering with ADK

The post explains how LY Corporation’s Orchestration Development Workshop uses context engineering to reduce AI-agent costs and improve accuracy. As internal adoption of tools such as Claude Code, Cline, and ADK grows, excessive token usage, missed instructions, and declining performance in long conversations have become common. The recommended solution is to deliberately select and manage the context sent to an LLM, demonstrated through an ADK-based Jira weekly-report agent. ## Problems Caused by Expanding AI Use - Increased AI adoption has led to unexpectedly high token consumption. - Users often receive incomplete or incorrect results despite providing detailed prompts. - Long-running conversations can cause the model to produce irrelevant answers. - Major causes include: - Trial-and-error prompting - More complex and long-running agents - Expansion from single-agent to multi-agent systems - Tool integrations such as MCP, whose definitions also consume context - Limited awareness of context optimization techniques ## Context Rot and Context Engineering - **Context rot** occurs when long-running agents accumulate conversation history, intermediate results, and irrelevant information. - As the context grows: - The context window becomes pressured. - Relevant information becomes harder to identify. - Noise overwhelms important signals, reducing accuracy. - Context engineering is the deliberate design and management of all information provided during inference, including: - **Static context:** System prompts and tool definitions - **Dynamic context:** User messages, conversation history, and retrieved external data - **Long-term context:** Persistent session state and accumulated information - The core principles are: - Treat tokens as a limited resource and retain the smallest set of high-signal information. - Provide neither too little information, which forces guesswork, nor too much, which wastes tokens and reduces clarity. ## Why Use ADK Google’s open-source Agent Development Kit (ADK) is presented as a practical platform for applying context engineering. - Agents can be designed and shared using team knowledge rather than relying on individual CLI expertise. - ADK includes UI, API-server, evaluation, and multi-agent capabilities. - Its multi-agent architecture naturally supports separating and controlling context. ## ADK Context-Engineering Components The workshop introduces nine key components, including: - **Structured input and output:** JSON or schema-based formats reduce unnecessary text and make agent processing more reliable. - **AgentTool:** Embeds one agent inside another as a tool. The calling agent receives only the final result, preventing internal tools and intermediate context from accumulating. - **MCP Toolset filtering:** The `tool_filter` parameter exposes only required MCP tools, reducing tool-definition tokens and improving model decisions. - The remaining components can be combined with these techniques to control context throughout an agent workflow. ## Jira Weekly Report Example The workshop builds `jira_weekly_report`, an agent that analyzes team Jira tickets and generates a weekly Markdown report. ### Version 1: Single Agent Without Context Engineering - A single agent retrieves the ticket list, fetches each ticket, analyzes it, and builds the report. - All Jira tools are exposed through one MCP toolset. - As the number of tickets increases, detailed ticket contents accumulate in the agent’s context. - This leads to context rot, higher token usage, and declining reliability. ### Version 2: Context-Aware Multi-Agent Design - The workflow is split into: - A root agent that searches Jira tickets and aggregates the final report. - A sub-agent dedicated to analyzing one ticket at a time. - `input_schema` requires a structured `issue_key`. - `output_schema` requires a structured report containing ticket content and progress, including comments. - The sub-agent receives only the `jira_get_issue` MCP tool. - The root agent receives only the `jira_search` tool. - `AgentTool` hides the sub-agent’s internal context and returns only its final report. - The sub-agent is instructed to include facts only and avoid speculation. This design limits each agent’s responsibilities, removes unnecessary tool definitions, and prevents individual ticket details from polluting the root agent’s context. ## Practical Recommendation For production AI agents, treat context as a constrained resource. Use structured schemas, narrowly filtered tools, and specialized sub-agents to pass only the information needed for each step.

Read original(opens in new tab)

Large Language ModelsAI AgentsKubernetesModel Context Protocol+3

line·May 15, 2026·3 min readCurated summary

ODW #6: The Pros and Cons of MCP and Agent Skills from a Git Automation Perspective

The post presents agent skills as a simpler, more practical alternative to building MCP servers for many AI-agent workflows. It demonstrates how to use Anthropic’s `skill-creator` to build a Git release automation skill that analyzes commits, updates a changelog, bumps versions, commits, tags, and pushes releases. The author emphasizes that precise requirements and explicit constraints are essential for preventing unintended agent behavior. ## Why Agent Skills Are Practical - Agent skills can simplify both implementation and architecture compared with custom MCP servers. - Although online examples explain the concept, the post focuses on a practical, work-oriented use case. - The tutorial assumes familiarity with the basic concept of skills and concentrates on building and applying one. ## Git Smart Release Automation The example skill automates releases for a Git project in the current working directory. - Reads the Git history after the most recent tag. - Summarizes changes and adds them to the top of `CHANGELOG.md`. - Creates `CHANGELOG.md` if it does not exist. - Updates the version in `pyproject.toml`. - Commits the changelog and version changes. - Creates a corresponding Git tag. - Operates based on the terminal’s current `pwd`. ## Using `skill-creator` - Anthropic’s official `skill-creator` skill is used to generate the new automation skill. - The user provides a detailed requirements specification rather than implementing everything manually. - Explicit workflow steps and constraints help keep the agent focused on the correct directory and avoid unnecessary complexity. - The development process is demonstrated with Claude Code. ## Clarifying Requirements Before generating the skill, the agent asks questions to resolve ambiguous behavior. - Support patch, minor, and major version bumps. - Use `v0.1.0` for the first release when no prior tag exists. - Follow a structured changelog format. - Push both commits and tags to the remote repository. - Abort with an explanation if the working directory contains uncommitted changes. ## Generated Skill Structure The completed skill contains: - `SKILL.md` — instructions and metadata for the agent. - `scripts/smart_release.py` — a local Python script that performs Git operations and file modifications. - `evals/evals.json` — evaluation cases for testing the skill. The skill also includes: - Keep a Changelog-style updates. - Dirty working-directory checks. - Automatic remote pushing. - Commit categorization such as `feat`, `fix`, and `docs`. ## `SKILL.md` and the Python Script - The frontmatter in `SKILL.md` acts as a concise discovery description that helps the agent decide when to load the skill. - The Markdown body provides the detailed execution workflow. - `smart_release.py` handles operations requiring deterministic file and Git manipulation, reducing the need for the language model to process raw data directly. - The post then begins testing the skill with a simple Python calculator project. A practical approach is to define release behavior, edge cases, and safety constraints before asking an agent to generate the skill, while delegating file and Git operations to a local script.

Read original(opens in new tab)

Model Context ProtocolPythonClaude CodeGit+3

line·May 14, 2026·4 min readCurated summary

AI Didn’t Replace QA; It Expanded It

Generative AI has not replaced QA at LINE Album; it has expanded QA’s scope and influence. The team found that QA productivity depends less on executing tests quickly than on organizing and interpreting large amounts of scattered information. By embedding AI into event-driven quality workflows, QA engineers now focus more on risk assessment, test strategy, and final decisions. ## QA as a Quality Architect - QA operates across the entire product lifecycle: planning, development, testing, release, and post-release feedback. - Its responsibilities include: - Identifying design risks during planning - Assessing the impact of code changes - Designing test strategies - Validating releases - Connecting user feedback and operational data to product improvements - QA information comes from many sources: - Planning and technical documents - Slack discussions and decisions - Jira tickets and pull requests - Automated test scripts and logs - App Store and Google Play reviews - The central challenge is therefore managing information volume and complexity, not merely increasing testing speed. ## From AI Assistant to AI-Driven Workflow - Initially, AI was used interactively to: - Summarize documents - Draft test cases - Organize bug reports - Document reproduction steps - This improved individual productivity but required QA engineers to manually collect and prepare information. - LINE Album QA instead built an automated quality platform with more than 30 workflows. - AI now reacts automatically to events such as: - Jira issue creation - Code changes and pull requests - Test execution - User feedback collection - AI gathers, analyzes, and structures quality information, while QA engineers interpret risks and make decisions. ## Scheduling and Webhook Automation ### Scheduled Analysis - Scheduled workflows periodically collect and summarize quality data. - Examples include: - Daily App Store review classification - API test result summaries sent to Slack - UI automation reports - Weekly QA activity and issue reports - QA engineers spend less time gathering data and more time evaluating risks and verifying important findings. ### Webhook-Based Analysis - Webhook workflows run immediately when quality-related events occur. - Examples include: - Summarizing the potential impact of merged code changes - Creating meeting notes when Slack discussions end - Analyzing and visualizing automated test results - This allows the team to recognize important quality signals much earlier. ## The AI-Supported QA Workday - UI tests run through MagicPod for Android and iOS, with results updated in Jira and shared in Slack. - Failed tests trigger analysis to determine whether they are flaky tests and identify possible causes. - Pytest-based API tests are similarly reported to Jira and Slack. - Daily Scrum workflows automatically provide: - Current test progress - Scrum board and issue dashboard links - Unresolved issues - Jira mentions requiring QA attention - App reviews are analyzed daily, classified as positive or negative, translated into Japanese and Korean, and summarized for the team. - During focused work periods, QA engineers use AI-generated information to plan quality activities, execute tests, monitor workflows, and summarize relevant discussions or documents. - End-of-day workflows summarize completed work and remaining issues. ## AI as a Test Design Partner - By 2026, AI generated approximately 90% of LINE Album QA’s test-case drafts. - Simple prompting produced many generic scenarios but failed to capture: - The reason a feature was introduced - Historical defect patterns - Effects on existing user flows - The team improved results by supplying broader context, including: - Specifications and development tickets - Change rationale - Previous Jira issues - Test history - Recurring bug patterns ### Multi-Agent Test Generation - An orchestrator coordinates five specialized sub-agents: - **Plan-Analyzer:** Examines requirements, feature descriptions, and images. - **Dev-Analyzer:** Adds implementation and development-ticket context. - **TestCase-Generator:** Produces normal, exceptional, boundary-value, platform-specific, and prioritized scenarios. - **TestCase-Validator:** Checks coverage, traceability, completeness, Given/When/Then structure, priorities, and platform coverage. - **Quality-Inspector:** Uses prior feedback and quality evaluations to improve future generations. - The workflow expands testing beyond stated requirements by incorporating defects that have historically occurred. - Validation feedback creates an iterative loop, making the output more executable and useful over time. AI is most valuable when it is connected to the organization’s accumulated context and quality signals—not when it is used merely as a chat-based drafting tool. The recommended approach is to automate information collection and analysis while keeping QA responsible for interpretation, prioritization, and final quality decisions.

Read original(opens in new tab)

Generative AIAutomationSlackJira+4

line·May 7, 2026·3 min readCurated summary

ODW #5: Building a RAG System with a Vector DB and Agent Skills

The workshop demonstrated how a lightweight RAG system can make large collections of technical documentation easier for developers and AI agents to use. Using ChromaDB, Swift Evolution proposals were indexed locally and exposed to Claude Code through MCP. Agent skills then simplified searches by teaching the agent which collection, metadata, and query practices to use. The approach improves document discovery and can support code generation and review. ## Why RAG Is Needed - Large application teams maintain extensive documentation and architectural guidelines. - Developers often spend significant time searching for information about: - Introducing dependencies - Resolving build errors - Following architectural rules - Asking experts can solve problems, but consumes time for both the questioner and the responder. - RAG provides AI agents with structured, searchable knowledge so they can answer questions more accurately using internal documents. ## Building a RAG System with ChromaDB - The workshop used ChromaDB, an open-source local vector database with Python and JavaScript client libraries. - Swift Evolution proposals served as the sample dataset: - Approximately 500 Markdown documents - Consistent structure and proposal IDs such as `SE-0400` - Metadata including implementation status and authors - Participants indexed the documents locally and connected the database to Claude Code through an MCP tool. - This allowed the coding agent to retrieve and reference Swift language proposals during conversations. ## Improving Search with Agent Skills - MCP exposes the available database tools, but the agent still needs to know: - Which collection contains the relevant data - Which metadata fields are useful - How to formulate effective queries - A dedicated `searching-swift-evolution` skill encoded this knowledge, including: - The `swift-evolution` collection name - Proposal ID formats such as `SE-0255` and `ST-0001` - Metadata such as `Status` and `Authors` - A recommendation to query in English - With the skill, users could issue simple requests such as “Investigate SE-0500” without explaining the database structure or MCP workflow. - The workshop also covered skill mechanics, authoring best practices, and practical skill development. - Participants later indexed their own Markdown documents, created search skills, and learned how to deploy the database to LY Corporation’s internal Flava cloud for sharing. ## Potential Applications - Natural-language document search can make internal technical knowledge significantly more accessible. - Coding agents can retrieve relevant documentation automatically before: - Generating code - Reviewing code - Checking compliance with architectural or implementation guidelines - Combining RAG with agent skills or Claude Code sub-agents can embed organizational knowledge directly into development workflows. ## Workshop Design and Results - The online workshop used demonstrations by instructors and mock participants. - More than 1,000 people attended. - Its structure balanced lectures and hands-on exercises: - Lectures explained the core concepts concisely. - Practical demonstrations showed how to apply the system to real work documents. - This balance helped participants understand both the underlying ideas and their practical use. Overall, the workshop showed that a local vector database plus MCP and well-designed agent skills can provide a simple, effective foundation for searchable engineering knowledge and AI-assisted development.

Read original(opens in new tab)

AI AgentsModel Context ProtocolRAGClaude Code+4

line·Apr 30, 2026·4 min readCurated summary

ID-JAG, a next-generation standard candidate for solving authentication challenges in the AI era

ID-JAG extends enterprise SSO trust to API access between AI agents, applications, and services. It uses an enterprise IdP to centrally evaluate permissions and issue a signed JWT that can be exchanged for a resource-specific access token. This can reduce consent prompts, improve auditing, and limit token sprawl, but organizations should adopt it cautiously while the specification remains an Internet-Draft. ## The Authentication Challenge in the AI Era - AI agents increasingly perform real work, including: - Searching systems - Querying databases - Sending messages - Creating tickets - As the number of connected services grows, authentication and authorization become more complex. - Poorly coordinated integrations can turn AI from a productivity tool into an operational bottleneck. - ID-JAG is being discussed by the IETF OAuth Working Group as a potential solution. ## What ID-JAG Is - ID-JAG, or Identity Assertion JWT Authorization Grant, extends the enterprise IdP’s SSO trust relationship to API access. - The IdP centrally determines: - Which application or agent may access an API - Which user or identity it acts for - Which scopes or permissions are allowed - It combines: - OAuth 2.0 Token Exchange (RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523) - The IdP issues a cryptographically verifiable JWT as an “introduction” or authorization assertion. - The target authorization server validates that assertion and issues the final access token. ## The ID-JAG Participants and Flow The model involves four main parties: - **Requesting Agent:** An AI agent or application calling another service’s API - **Enterprise IdP:** Provides SSO and enforces centralized organizational policies - **Authorization Server:** Issues tokens for the target application - **Resource Server:** Hosts the API being accessed The basic five-step flow is: 1. The user signs in to the requesting agent, which obtains an ID token from the IdP. 2. The agent presents the ID token to the IdP and requests an ID-JAG through token exchange. 3. The IdP evaluates organizational policy and issues the ID-JAG if access is allowed. 4. The agent presents the ID-JAG to the target authorization server and receives an access token. 5. The agent uses the access token to call the resource server. The key architectural shift is that authorization decisions move from isolated agent-to-service relationships toward a centrally governed relationship between the enterprise IdP and target authorization servers. ## Benefits for User Experience and Auditing - Centralized IdP policies can reduce repeated consent screens. - This is especially useful when AI agents connect to many tools and services. - ID-JAG claims can record important context, such as: - The user whose authority is being delegated (`sub`) - The requesting agent (`client_id`) - The target authorization server (`aud`) - Approved scopes (`scp`) - Issuer, issue time, expiration, and unique token ID - Centralized issuance logs provide a clearer view of service-to-service relationships. - Security teams can more easily determine which agent accessed which service, on whose behalf, and with what permissions. - The same records can support incident investigation, compliance audits, and accountability. ## Centralized Control and Reduced Token Sprawl - The IdP can help detect and control unauthorized “shadow AI” integrations. - It can evaluate every token exchange using consistent organizational policies. - Requested scopes can be narrowed or overridden according to enterprise security requirements. - Blocking future access can be handled centrally instead of by changing policies across every endpoint. - ID-JAG may reduce token sprawl by avoiding additional long-lived refresh tokens. - The draft recommends that resource authorization servers generally not issue refresh tokens when an ID-JAG is exchanged. - Agents can instead submit a new ID-JAG to obtain another access token, replacing scattered API keys, service credentials, and refresh tokens with dynamic, policy-based trust. ## Adoption Requirements and Risks - ID-JAG is still an IETF Internet-Draft, not a finalized RFC. - Its behavior may change, so systems should avoid tightly coupling their core architecture to the current draft. - Before implementation, organizations need to verify that: - The requesting agent is registered as an OAuth client with both the enterprise IdP and the target authorization server. - Explicit trust relationships exist between the IdP and agent, and between the IdP and authorization server. - The IdP has pre-authorized the agent to act on users’ behalf for the relevant services and scopes. - Deployment also requires coordinated support from agents, enterprise IdPs, authorization servers, and resource servers. Organizations should treat ID-JAG as a promising architectural direction for governing AI-agent access, while isolating its implementation behind adaptable interfaces until the standard stabilizes. Pilot deployments should focus on centralized policy enforcement, detailed audit logging, strict scope control, and minimizing long-lived credentials.

Read original(opens in new tab)

Database DesignOauthJwtIdentity Provider+4

line·Apr 24, 2026·4 min readCurated summary

ODW #4: From Copilot to Pilot, Automating from Implementation to PR with Agentic Coding

LY Corporation’s Orchestration Development Workshop promotes a shift from using AI as a code suggestion tool to using it as an autonomous development “pilot.” The team combined specification-driven development with Jira/Confluence access through MCP so AI agents could investigate requirements, plan implementations, write code, run checks, create pull requests, and respond to reviews. The approach improved development speed and planning, but still requires humans to review AI-generated code and retain responsibility for product quality. ## From Copilot to Agentic Coding - The team initially used GitHub Copilot for small code-generation tasks but saw limited productivity gains. - Two developments enabled a broader shift: - Existing requirements and design documents supported specification-driven development. - Jira and Confluence became accessible to AI coding tools through the Model Context Protocol (MCP). - Agentic coding gives an AI agent a high-level goal, which it decomposes into tasks and executes iteratively. - Unlike autocomplete tools, an agent can analyze the broader codebase, run commands and tests, fix lint errors, and continue until the requested feature is complete. ## Workshop Goals and Human–AI Responsibilities - The workshop focused on automating the process from implementation through pull-request creation. - Humans remained responsible for: - Defining requirements and writing specifications - Final testing, review, and release decisions - AI was assigned: - Implementation planning - Code implementation - Pull-request creation - Initial review and review-response work - This division preserved the existing development process while giving participants practical experience with agentic workflows. ## Stage 1: Research and Implementation Planning - Participants supplied a Jira ticket URL to a custom slash command. - The AI agent: - Retrieved Jira data through the Jira MCP tool - Followed Epic links and collected related tickets - Retrieved Confluence documentation through the Confluence MCP tool - Explored the codebase, using an Explore Agent where available - Wrote a detailed implementation plan to `specs/{ticket-or-topic}/plan.md` - The plan included requirements, affected components, technical analysis, implementation tasks, risks, testing considerations, and a checklist. - Saving the plan to a file made it available for human review, future sessions, and later PR generation. - The team emphasized planning early because vague instructions can lead to incorrect implementations and costly rework. ## Stage 2: Implementation and Pull-Request Creation - The reviewed plan was passed to an implementation command. - The AI was instructed to: - Understand the plan and implementation scope - Modify the code - Add or update tests - Run the test suite - Run linting and build commands - Fix any resulting problems - Explicitly listing these steps encouraged the coding agent to maintain a task checklist and complete the full development cycle. - A separate PR command generated the pull request using the team’s template. - Information gathered during the planning stage could be reused in the PR description, reducing administrative work. ## Stage 3: AI Review and Issue Resolution - An AI screening-review command analyzed the generated PR. - It also read existing comments, including: - The AI’s own prior review comments - Comments from other team members - The agent identified issues requiring changes and explained its assessment of existing comments. - After a human reviewed those conclusions, the AI could implement the necessary fixes, reducing the cost of responding to review feedback. ## Benefits and Risks - **Higher code-generation speed** - Agents can work with less frequent human intervention. - Developers can perform other tasks while agents work. - Multiple agents can potentially run in parallel. - **Earlier risk discovery** - Detailed implementation plans clarify the work before coding begins. - Planning can reveal overlooked tasks, dependencies, and risks. - **Greater review burden** - AI can generate large volumes of code that humans must still inspect. - The unfamiliar workflow may create stress for developers. - **Human accountability remains essential** - Developers are responsible for the quality of AI-generated code. - Poor-quality output increases reviewer workload and can add technical debt. ## Workshop Results - The workshop was delivered twice: - A hands-on practical session requiring prior preparation - An introductory session with more detailed support - Approximately 2,500 people participated. - More than 40% of respondents had already applied, or intended to apply, some aspect of the workshop. - The sessions provided concrete guidance on MCP server usage and effective ways to delegate coding tasks to AI agents. The recommended approach is to introduce agentic coding incrementally: keep human ownership of requirements and final quality decisions, while allowing AI to handle structured planning, implementation, testing, PR creation, and initial review.

Read original(opens in new tab)

AIModel Context ProtocolGithub CopilotAgentic Coding+4

line·Apr 22, 2026·4 min readCurated summary

Implementing SLO/SLI for Improved Reliability Part 3 - Service Application Cases

SLI/SLO adoption is not merely a matter of choosing metrics; it requires redefining how a service is understood from the user’s perspective. LINE’s SRE team applies this approach by identifying critical user journeys, measuring reliability with clear criteria, and setting realistic objectives. The resulting data helps teams balance reliability, engineering costs, feature delivery, and incident response. ## The Mindset Behind SLI/SLO ### Understanding the Service and Users - Begin by identifying the services and features users depend on. - Map user journeys and select critical user journeys (CUJs) based on: - How frequently users use a feature - Whether the feature is essential to the service - Its relationship to business objectives - Aligning SLOs with business goals ensures that reliability work supports organizational priorities. ### Communication and Collaboration - SLI/SLOs should be defined and managed collaboratively rather than by a single team. - Product or service owners define CUJs because they understand the user experience best. - Infrastructure teams provide scalable systems for collecting and managing metrics. - SREs build the measurement tools and processes used to monitor and improve reliability. - Shared ownership is essential so SLOs can guide both daily operations and new feature launches. ## Implementing SLI/SLOs ### Analyze Critical User Journeys - List the services and functions provided to users. - Ask: - Which features are used most often? - Which features are indispensable? - LINE examples include: - Account registration - Sending and receiving messages - User authentication and encryption - LINE Login - Profile information - The goal is not to include every feature, but to select the most important ones from the user’s perspective. ### Define Service Level Indicators For each CUJ, determine: - **Measurement location:** Choose the point that best represents the user experience, such as a gateway, frontend, or backend. - **Measurement API:** Select a representative API to avoid unnecessarily complex calculations. - **Success criteria:** Establish clear boundaries between successful and failed requests. Common SLI criteria include: - **Latency:** Define a percentile, such as the 99.9th percentile, and the maximum acceptable response time. - **Success rate:** Define the required percentage of successful responses during the measurement period. For example, a messaging service might require 99.9% of requests to complete within 500 milliseconds and 99.999% of all requests to receive successful responses. If a CUJ cannot be measured reliably or its success criteria cannot be defined clearly, it may be excluded or supported with a dedicated measurement metric. ### Set SLO Targets - Define the reliability level the service must maintain over a specific period. - An example target is achieving the defined latency and success-rate criteria for 99.9% of a 28-day period. - Targets must be realistic: - Excessively high targets increase operational and infrastructure costs. - Excessively low targets can result in poor user experiences. - SLOs should balance reliability requirements with available resources. ### Visualize Reliability - Provide dashboards that allow all stakeholders to understand the current SLO status quickly. - Show overall SLO performance and error-budget consumption, with detailed dashboards for individual CUJs. - Keep dashboards simple and easy to scan rather than displaying excessive information. - Use visual indicators such as: - Green for healthy performance - Orange for warning conditions - Red for missed objectives ## How SLI/SLOs Are Used ### Quantifying Reliability - Replace vague descriptions such as “the service is slow” with measurable statements. - Teams can identify issues such as latency exceeding a 400-millisecond SLI threshold or success rates falling below 99.99%. - Dashboards also help correlate periods of poor performance with incidents or operational changes. ### Guiding Resource Allocation - SLOs show whether reliability targets are being met. - Error budgets indicate how much additional failure or downtime is acceptable. - When performance exceeds the SLO and the error budget is healthy, teams can invest more aggressively in: - New features - Faster release cycles - Product experimentation - When little error budget remains, resources can instead focus on prevention, remediation, and reliability improvements. ### Supporting On-Call Operations - LINE uses alerts triggered by changes in error-budget status to help on-call teams recognize and respond to service issues. - SLO reviews are also incorporated into regular meetings and preventive reliability work. SLI/SLO implementation works best as a shared, user-focused operating model. By combining clear CUJs, measurable criteria, realistic targets, and actionable dashboards, teams can make informed decisions about when to prioritize innovation and when to prioritize stability.

Read original(opens in new tab)

ObservabilitySite Reliability EngineeringResource AllocationService Level Indicator+4

line·Apr 21, 2026·3 min readCurated summary

ODW #3: Boosting Development Efficiency by Safely Utilizing MCP Servers

LY Corporation is expanding AI use across its engineering organization through MCP servers, which connect AI assistants with internal and external tools through a common protocol. The company combines this flexibility with allowlists, automated security checks, and internal standards to reduce risk. Its Orchestration Development Workshop demonstrates practical applications such as Jira ticket automation and multi-agent code reviews, while emphasizing shared learning and experimentation as AI practices evolve. ## MCP Servers and Their Benefits - MCP servers act as translators between AI assistants and external systems. - Before MCP, each assistant required a separate integration for every tool. - With MCP, a tool can implement one standardized interface and work with multiple compatible assistants. - This improves interoperability, scalability, and the ability to combine different AI tools. ## Security Risks and LY Corporation’s Controls - A 2025 Astrix Security report found that: - More than 5,200 public MCP servers were analyzed. - 53% relied on long-lived static API keys or personal access tokens. - Only 8.5% used newer authentication methods such as OAuth. - LY Corporation manages externally developed MCP servers through: - An allowlist permitting only approved servers. - Automated security verification based on internal standards. - Internal MCP servers for groupware and business systems are built to meet the company’s security requirements. - Centralized infrastructure lets teams focus on applying AI rather than independently rebuilding integrations and controls. ## Workshop Applications The Orchestration Development Workshop taught participants how to understand, configure, and safely apply MCP servers with AI assistants. - Topics included MCP fundamentals, security risks, internal policies, development rules, and configuration in Claude and Cline. - The internal plugin marketplace was introduced as a way to distribute MCP configurations. - Participants practiced using Claude Code with the internal groupware MCP server to: - Generate a Jira ticket title and summary. - Create the ticket automatically. - The exercise showed how AI can remove repetitive administrative work and free time for higher-value tasks. ## Multi-Agent Code Review Demonstration - A demonstration combined Claude Code, Codex CLI, Context7 MCP, and Codex MCP. - A Sonnet-based agent first analyzed a pull request, including: - Technical stack and relevant documentation. - Code changes and repository context. - Security, performance, and code-quality concerns. - GPT-5 then validated the initial review, identifying missed issues and checking the prioritization of findings. - Using different models provided more varied and potentially objective perspectives on the same code. ## Results and Organizational Learning - Around 1,600 people attended the workshop in real time. - 31.5% had already applied related techniques before the event. - Another 55.7% planned to try them soon. - LY also created “Help LY MCP,” a GPTs-based tool that explains internal MCP rules and helps teams assess whether proposed uses are suitable, including for global subsidiaries. - The workshop’s broader purpose was to create a shared understanding of: - What AI and MCP can currently do. - What risks and pitfalls exist. - How to use the technology meaningfully. ## Continuing to Experiment The article concludes that rapidly changing AI technology makes shared experimentation more valuable than simply announcing new tools. MCP may eventually be surpassed by other approaches, such as skills, so teams should continually reassess the best solution. LY recommends creating a culture where employees can safely try small ideas, learn together, and adapt as new practices emerge.

Read original(opens in new tab)

Database DesignGithubClaude CodeGit+4

line·Apr 15, 2026·4 min readCurated summary

ODW #2: Developing Single/Multi-Agents with ADK and Integrating with Internal Systems

AI adoption can improve productivity, but relying on individual developers to create and refine local AI agents leads to knowledge silos, duplicated effort, and uneven results. LY Corporation’s Orchestration Development Workshop addresses this by teaching engineers to build shared single- and multi-agent systems with Google’s Agent Development Kit (ADK). The workshop combines theory with hands-on integration of agents and internal tools such as Jira and Confluence through MCP. ## Organizational Need for AI - Potential applications include pull request reviews, customer support, and internal document search. - Information is difficult to find because company knowledge is distributed across systems such as Jira and Confluence. - LY Corporation aims to double work productivity within three years through AI and continuous innovation. - As tools such as Cline and Claude Code spread, usage remains concentrated among individuals. - This creates: - Productivity gaps between employees - AI knowledge silos - Repeated prompt-development work across teams - Limited awareness of multi-agent approaches - Abandonment of AI when single agents cannot handle complex tasks ## Why a Hands-On Workshop The organizers concluded that organization-wide adoption required practical understanding of three areas: - The strengths and limitations of single-agent and multi-agent systems - A team-based model for building and sharing centralized agents - Integration between AI agents and internal systems through the Model Context Protocol (MCP) Rather than teaching only concepts, the workshop required participants to build working agents with ADK. ## Single-Agent and Multi-Agent Systems - **Single agents** - Use one LLM and are relatively inexpensive and simple to develop. - Work well for straightforward tasks. - Struggle with complex problems requiring multiple specialties. - **Multi-agent systems** - Divide work among multiple specialized LLM-based agents. - Can handle more complex workflows and optimize tasks more effectively. - Require more development effort and token usage. - Must be designed carefully to avoid usage limits and excessive costs. ## Introducing Google ADK - ADK is open-source software for defining agent behavior and building multi-agent systems. - It supports Python, Java, and Go. - Python functions can be exposed as tools that agents invoke. - Teams can build and host shared agents, reducing the need for every employee to independently optimize prompts. ## Building a Single Agent Participants practiced: - Running an ADK web UI and interacting with an agent in a browser - Modifying instructions to change agent behavior - Connecting a prepared Python function as an executable tool The exercises demonstrated that prompts can flexibly control responses and that ordinary Python code can be integrated into an agent with relatively little effort. ## Connecting Agents to Internal Systems with MCP - MCP is an open standard for connecting LLMs to external systems. - It enables agents to actively search sources such as previous inquiries, documentation, Jira, and Confluence. - Participants learned that merely exposing tools is insufficient; the agent also needs clear instructions to use them effectively. - Giving one agent too many tools can enlarge its context, slow responses, and reduce accuracy. - Splitting responsibilities across multiple agents can help isolate context and mitigate these problems. ## Building a Sequential Project Tracker The main exercise created a project-tracking system that analyzes Jira projects and produces translated progress reports. - Four agents execute sequentially: 1. Analyze in-progress tasks 2. Analyze todo or unstarted tasks 3. Generate a consolidated Markdown report 4. Translate the report into the configured language - The first two agents use Jira through MCP. - The report generator synthesizes the preceding analyses. - The translator preserves the report’s formatting and structure. - ADK’s `SequentialAgent` coordinates the workflow and passes results between specialized agents. ## Practical Recommendation Organizations seeking broader AI adoption should move beyond individual experimentation. Shared agents built with ADK, connected to internal systems through MCP, can consolidate expertise, reduce duplicated prompt work, and make multi-agent workflows accessible to entire teams.

Read original(opens in new tab)

AIKubernetesModel Context ProtocolPython+4

line·Apr 10, 2026·4 min readCurated summary

Clearing Review Bottlenecks with AI - Transforming Review Culture with PR Review Support and Internal Workshops

Orchestration Guild member Fukuyama describes how Yahoo! Places addressed PR review bottlenecks by combining AI assistance with standardized processes and team culture. Reviews had become concentrated among a few engineers, creating delays and forcing a trade-off between speed and quality. The team introduced Claude Code–based screening reviews, then expanded the approach into a broader system for improving PR creation, review accuracy, and continuous improvement. ## PR Review Bottlenecks - In late 2024, review responsibilities were concentrated on the tech lead and one other engineer. - Reviewers were simultaneously implementing features and reviewing code, causing PR queues to grow. - The main problems were: - Authors could not move to their next tasks while waiting for reviews. - Review work consumed most of the day. - Large PRs had to be reviewed quickly, increasing the risk of missed bugs. - This created a single point of failure and exposed the trade-off between thoroughness and development speed. - The launch of a dedicated frontend team in early 2025 provided an opportunity to redesign the review process. ## Introducing AI Screening Reviews - The team first tried having AI summarize PR changes before review. - Although summaries made changes easier to understand, AI did not sufficiently reduce the work of tracing dependencies or identifying hidden problems. - Manually pasting prompts for every review also made the approach inconvenient, so it was abandoned after about two weeks. - The introduction of Claude Code in summer 2025 changed the situation because reusable custom commands eliminated repetitive prompt preparation. - AI screening reviews now perform an initial inspection before a human reviewer makes the final judgment. - This changes the process from “humans inspect everything” to a two-stage model: - AI analyzes the PR, its impact, coding conventions, and possible risks. - A human reviewer validates the analysis and makes the final decision. ## Claude Code Custom Review Commands The custom command requests that Claude Code: - Summarize the PR and its affected areas. - Explain the before-and-after changes for each file. - Check coding and naming conventions. - Investigate dependent files and broader codebase impact. - Identify potential bugs, security issues, performance problems, code smells, and unintended side effects. - Suggest concise, respectful review comments for the author. - Classify comments with labels such as `[must]`, `[want]`, `[imo]`, `[ask]`, `[nits]`, and `[info]`. - Determine whether additional tests are needed based on existing project practices. The command uses GitHub CLI operations such as: - `gh pr view --json title,body,files,url` - `gh pr diff` - `gh pr view --comments` - GitHub API calls for line-level comments - `gh pr checkout` when the relevant branch is not currently checked out The review procedure is deliberately structured: 1. Confirm the review requirements. 2. Understand the PR’s overall purpose and background. 3. Review each changed file in detail. 4. Investigate dependencies across the codebase. 5. Produce a final assessment and suggested comments. The same screening process can help both reviewers and PR authors. Reviewers use it to reduce preparation time and understand impact, while authors can run it before requesting review to fix likely issues in advance. ## Expanding Beyond AI Screening After seeing benefits from screening reviews, the team created a broader improvement framework spanning technology and team culture. It was organized around four connected goals: - Improving efficiency. - Establishing a foundation for review accuracy. - Building review-oriented team culture. - Creating a mechanism for continuous improvement. The approach treats review optimization as an ongoing cycle rather than a one-time tool deployment. ## Automating PR Creation The team also uses AI to reduce the effort required to create PRs. - Git operations such as branch creation, commits, and PR creation are automated. - AI analyzes the commit diff to generate: - A PR title. - A summary of the changes. - Background and motivation. - Other required PR template fields. - Standardized and more complete PR descriptions provide better context for both human reviewers and AI screening. - Improving PR quality at the creation stage also increases the accuracy and consistency of later reviews. ## Practical Recommendation AI should support—not replace—reviewer judgment. Teams should begin by standardizing the review workflow, encode that workflow in reusable AI commands, and measure whether review time, PR waiting time, and review quality improve. Combining AI screening with better PR context, dependency analysis, clear comment conventions, and continuous process refinement offers a more sustainable solution than relying on individual reviewers.

Read original(opens in new tab)

AIDatabase DesignWeb DevelopmentClaude Code+4