techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

spotify3 min readCurated summary

Building a Natural Language Interface to the Spotify Ads API with Claude Code Plugins | Spotify Engineering

The post describes an open-source Claude Code plugin that lets users manage Spotify advertising campaigns through natural-language requests. It translates high-level intent into validated, multi-step Spotify Ads API calls, handling targeting lookups, budget conversions, entity dependencies, and missing information. The authors favor a Markdown- and CLI-based design over MCP because it keeps the system transparent, lightweight, customizable, and grounded in Spotify’s OpenAPI specification. ## Natural-Language Campaign Creation - Users can request campaigns conversationally, such as creating an audio campaign targeting a specific age range and location with a daily budget. - The agent orchestrates the campaign lifecycle: - Creates the campaign. - Creates an ad set with targeting and budget. - Creates the ad and attaches creative assets. - It handles implementation details automatically: - Looks up geographic targeting IDs. - Converts dollar amounts into API micro-units. - Validates audience size. - Passes entity IDs between dependent API calls. - Prompts for missing required information. ## Claude Code Plugin Architecture - **Skills** provide slash commands, with each command defined in Markdown alongside its endpoints, request formats, and output behavior. - **Agents** interpret freeform requests and decompose them into the necessary API operations. - **Hooks** intercept tool calls to refresh OAuth tokens and inject HTTP headers. - **Settings** store local user configuration, including credentials, ad accounts, and environment preferences. - Because all components are human-readable Markdown, the plugin has no compilation, bundling, or package-management step. - API behavior can often be corrected by updating documentation or instructions rather than changing compiled code. ## CLI and OpenAPI Instead of MCP - The authors avoided MCP because the Spotify Ads API has more than 30 resource types and complex nested schemas. - Defining every endpoint as an MCP tool would create a large static registry and consume context even when most tools were irrelevant. - The plugin loads only the API documentation needed for a particular task. - API calls are issued as visible `curl` commands, allowing users to inspect, copy, modify, and reproduce them. - Spotify’s roughly 8,600-line OpenAPI v3 specification serves as the single source of truth. - Updating one bundled specification file is simpler than maintaining a separate translation into MCP schemas. ## Domain-Specific Agent Behavior - The request-builder agent is defined in `agents/spotify-ads-request-builder.md`. - It teaches the model Spotify-specific conversions, including: - Dollar values to micro-amounts. - Natural-language dates to ISO 8601. - Platform names to API enum values. - It performs multi-step orchestration for campaign, ad set, and ad creation. - It resolves locations such as “Connecticut” through geo-targeting search endpoints and builds the required `geo_targets` structure. - It performs pre-flight audience estimates to ensure targeting meets minimum size requirements. - It is designed to control execution carefully and validate requests before making changes that could affect advertising budgets. ## Practical Implication The plugin demonstrates that a large advertising API can be made approachable without hiding its mechanics. A Markdown-based Claude Code integration, backed by the official OpenAPI specification and transparent CLI requests, offers a practical balance between natural-language convenience, developer control, auditability, and maintainability.

Read original(opens in new tab)
Database DesignPythonNatural Language ProcessingClaude Code+4
google2 min readCurated summary

It's all about the angle: Your photos, re-composed

Google’s new Auto frame feature in Google Photos re-composes photos by changing the apparent camera viewpoint after capture. It combines 3D scene reconstruction with generative AI to adjust framing, reduce wide-angle distortion, and generate background areas that were outside the original frame. The result is a more natural perspective while preserving the visible content and subjects’ identities. ## Why Traditional Editing Falls Short - Cropping and zooming cannot change the original camera perspective or parallax. - They also cannot reveal areas hidden outside the captured frame. - This is especially limiting for portraits, selfies, and “almost perfect” photos with poor framing or lens distortion. ## Two-Stage 3D-Aware Editing - **3D scene and camera estimation** - A machine-learning model creates a 3D point map from the 2D image using monocular depth estimation. - Each pixel is associated with an estimated 3D surface point. - The system estimates the original focal length and reconstructs human faces and bodies carefully to reduce identity-distorting artifacts. - Semantic analysis detects subjects’ face positions and 3D orientations to determine better camera parameters. - **Generative completion and retouching** - Classical 3D rendering produces an image from the modified camera position, orientation, and focal length. - Moving the virtual camera exposes “holes” where the original image contained no information. - A latent diffusion model fills these missing regions and corrects the rendered result. - Classifier guidance with regional scaling helps preserve original content while allowing generation in newly revealed areas. ## Automatic Framing and Distortion Correction - The system automatically selects camera parameters for improved portrait composition. - It can adjust both camera pose and intrinsic properties such as focal length. - For wide-angle selfies, it detects perspective distortion that enlarges features close to the lens. - By effectively moving the virtual camera backward and adjusting the optics, it produces more natural facial proportions. ## Availability in Google Photos - The technology is now integrated into the Auto frame feature. - It applies to eligible photos containing people. - Users receive the re-composed image as a second Auto frame candidate. - The enhancement requires only a single action and automatically changes the viewpoint while retaining the original scene. The feature demonstrates how combining geometric 3D reconstruction with controlled generative inpainting can perform edits that conventional cropping and retouching cannot. For portraits and selfies, Auto frame offers a practical way to improve composition and perspective after the moment has passed.

Read original(opens in new tab)
Machine LearningGenerative AI3d RenderingImage Editing+4
meta2 min readCurated summary

Modernizing the Facebook Groups Search to Unlock the Power of Community Knowledge

Facebook has re-architected Groups Search to make community knowledge easier to discover, understand, and validate. Its new hybrid retrieval system combines keyword matching with semantic search, while automated model-based evaluation measures relevance at scale. The result is improved search engagement and relevance without increasing error rates. ## Friction in Community Search - **Discovery:** Traditional lexical search depends on exact words, so a query for “small individual cakes with frosting” might miss posts discussing “cupcakes.” Semantic matching helps connect different phrasing with the same intent. - **Consumption:** Users often must read dozens of comments to identify consensus or useful advice, creating an “effort tax.” - **Validation:** Relevant expertise is frequently scattered across group discussions, making it difficult to evaluate purchases or decisions using community knowledge. ## Hybrid Retrieval Architecture - Queries are tokenized, normalized, and rewritten before retrieval. - The **lexical path**, powered by Facebook’s Unicorn inverted index, retrieves exact or closely matching terms and preserves precision for proper nouns and quotations. - In parallel, the **semantic path** uses a 12-layer, 200-million-parameter Search Semantic Retriever to encode queries into dense vectors. - Approximate nearest-neighbor search over a Faiss index retrieves conceptually similar posts, even when they use different words. ## Multi-Task Ranking - Results from lexical and semantic retrieval are merged for ranking. - The ranking model combines traditional signals such as TF-IDF and BM25 with semantic cosine-similarity scores. - A multi-task, multi-label model jointly optimizes for clicks, shares, and comments. - This approach balances theoretical relevance with the likelihood of meaningful community engagement. ## Automated Relevance Evaluation - Semantic similarity scores can be difficult to interpret, so evaluation was integrated into build verification testing. - Llama 3 with multimodal capabilities acts as an automated judge of search results. - Evaluation recognizes nuanced outcomes, including “somewhat relevant” results that share a broader domain or theme. - This enables scalable measurement of conceptual matching and result diversity without relying entirely on human labeling. ## Results and Future Work - The hybrid system outperformed the keyword-only baseline in offline quality and search-engagement metrics. - Facebook reports improved relevance without higher error rates. - Future plans include using LLMs directly during ranking and dynamically adapting retrieval parameters to query complexity. The approach demonstrates that combining lexical precision with neural semantic understanding can make community search more effective. Further LLM integration may help the system interpret post content and tailor retrieval more intelligently.

Read original(opens in new tab)
Database DesignMachine LearningNatural Language ProcessingSemantic Search+4
kakao3 min readCurated summary

Kanana Scala 1st Seminar On-site Sketch

Kakao’s first Kanana Scholar seminar brought together seven leading AI professors and Kakao researchers to discuss the company’s independent AI strategy. Kakao presented its from-scratch Kanana foundation models, emphasizing data efficiency, Korean-language capability, and multimodal processing. The discussion concluded that Kakao should focus less on generic benchmark scores and more on technology sovereignty, personalized agents, and practical execution in real services. ## Kanana Foundation Models - Kakao is developing its own foundation-model lineup to strengthen competitiveness and reduce dependence on overseas providers. - Kanana reportedly achieved strong performance using 11 trillion training tokens, compared with 23 trillion tokens for a similarly sized global-target model. - Kakao attributed this efficiency to the quality and refinement of its training data. - The company also demonstrated **Kanana-o**, an omni model capable of processing text, images, and audio in real time. - The model handled emotional speech and multi-speaker conversations naturally, receiving praise for its Korean fluency. ## Technology Sovereignty and Customization - Kakao argued that proprietary models protect it from external risks such as changing licensing policies and closed technologies. - Owning the technology enables Kakao to build efficient, customized models optimized for its services. - Participating professors agreed that control over Korean cultural context and local issues is essential for technological sovereignty. - They viewed an independent model as a strategic asset for long-term service stability. ## Digital World Models and Personalized Agents - Kakao aims to understand users’ behavioral context within KakaoTalk and provide highly personalized assistance. - On-device AI could protect private conversations while allowing agents to respond immediately to user needs. - The professors suggested expanding the idea of “physical AI” into a **digital world model** that predicts interactions and causal relationships across a platform. - This direction could create an area of AI differentiation uniquely suited to Kakao’s ecosystem. ## Evaluating Practical Agentic Intelligence - Kakao is prioritizing AI systems that can create multi-step plans, call necessary tools, and complete tasks independently. - It plans to use an internally developed orchestration benchmark to evaluate real-world problem-solving ability. - The professors cited Claude as an example of how users perceive intelligence through successful completion of complex requests, not merely high benchmark scores. - They recommended competing through practical execution in real service environments rather than focusing only on text-generation performance. ## Industry-Academic Cooperation - Kakao plans to explore GPU support for university research labs and undergraduate AI clubs. - Possible support could include credits, project-based resources, and other forms of infrastructure assistance. - The seminar marked the beginning of a broader collaboration aimed at advancing Korea’s AI ecosystem and developing future talent. Kakao’s recommended path is to combine proprietary, efficient models with privacy-preserving personalization and strong agentic execution. Success will depend on how effectively Kanana turns technical depth into useful intelligence that users can experience in everyday services.

Read original(opens in new tab)
AIAI AgentsMultimodal AIOrchestration+4
cloudflare3 min readCurated summary

Moving past bots vs. humans

The distinction between bots and humans is becoming too blurry to serve as the foundation of web protection. Browsers, accessibility tools, proxies, and AI agents can all behave differently while representing legitimate users, while human activity can also be malicious. Website owners should instead focus on intent, behavior, resource usage, and trust. ## The Web’s Original Balance - Browsers act as user agents, mediating between people and websites. - Websites rely on browser conventions to: - Present content correctly across devices. - Support purchases, logins, media, and accessibility. - Deliver advertising and control user experiences. - The web has historically balanced publisher interests with user freedoms through browser standards, extensions, and accessibility requirements. - AI agents disrupt this balance by fetching raw content without rendering pages like browsers. - Publishers often cannot tell whether a request supports one private summary or large-scale model training, making traffic and monetization less predictable. ## The Client-Server Model - Clients request resources from servers, which respond with the requested content. - Websites can scale through additional servers, caching, and CDNs. - The model’s openness allows many types of clients to interact with servers without requiring servers to understand their internal software. - That flexibility creates uncertainty: servers generally cannot see whether a response is: - Rendered for one person using a browser. - Automatically collected, archived, indexed, or reused by another system. ## Why Bot Management Exists - Websites must decide which requests they can afford to serve when capacity, CPU, or cost limits are reached. - Randomly dropping requests is possible but risks blocking legitimate users. - Access controls are also used to: - Separate attacks from normal traffic. - Manage non-malicious load. - Prevent data extraction and fake account creation. - Limit ad fraud and automated actions. - Web clients are unauthenticated by default, so services infer identity and intent from partial signals such as request volume and IP addresses. - A high-volume IP may indicate abuse, a VPN, or multiple users sharing one address, making simple bot-versus-human classifications unreliable. ## Toward Intent and Behavior-Based Protection - The important questions are whether traffic represents an attack, whether crawling is proportional to returned traffic, whether a login from a new country is expected, or whether advertisements are being manipulated. - “Bots” encompass two separate concerns: - Whether known crawlers should receive access when they provide little traffic or value in return. - Whether emerging clients behave unlike traditional browsers, affecting systems such as private rate limits. - Automation detection remains necessary, but protection systems should be designed for a future where automation is common among both legitimate and malicious actors. Website protection should evolve from identifying “bots” to evaluating intent, behavior, proportionality, and risk. The goal is not to determine whether a client is human, but whether its activity is expected, sustainable, and trustworthy.

Read original(opens in new tab)
AI AgentsBot ManagementWeb BrowsersZero Trust Security+4
line3 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
figma2 min readCurated summary

How AI Leaders Are Borrowing From the Design Playbook | Figma Blog

AI transformation requires more than deploying new tools; it requires redesigning how organizations work. Figma argues that the most effective AI leaders adopt design practices—hands-on experimentation, close observation of workflows, and rapid prototyping—to turn adoption and innovation into meaningful business change. ## AI Leadership as Organizational Design - New AI innovation and acceleration roles are emerging to improve workflows, speed product launches, and expand tool adoption. - These leaders often coordinate AI strategy across product, support, internal operations, and technology investments. - A major risk is “performative progress”: adopting tools for appearances without changing the underlying systems and processes. - Effective leaders connect technology, teams, workflows, and business outcomes. ## Learn the Material by Using It Yourself - Leaders need firsthand experience with AI tools rather than relying only on strategic or executive-level perspectives. - Prompting, building agents, and experimenting across different tools reveals practical limitations, trade-offs, and adoption barriers. - Personal projects—such as planning travel, organizing events, or managing volunteer work—can provide low-risk opportunities to develop AI fluency. - Leaders cannot effectively guide organizations through probabilistic technologies without understanding how those technologies behave in real situations. ## Observe How Teams Actually Work - Understanding AI use across the business requires studying workflows, not just tools and their outputs. - Useful signals include Slack discussions, survey responses, usage patterns, frustrations, and points where employees get stuck. - An automation may appear successful technically but fail because it adds friction to an already complicated process. - When adoption stalls, teams may be routing around the official solution and creating unofficial alternatives; observing this behavior helps identify the real problem. ## Turn Ideas Into Prototypes - Ideas often fail because teams cannot visualize or evaluate them, not because the ideas themselves are flawed. - Prototyping converts abstract AI concepts into tangible experiences that teams can discuss and test. - Tools such as Figma Make can help leaders and teams explore concepts quickly and make early possibilities easier to understand. - Design combines observation with action: leaders should learn from real behavior, then use prototypes to test potential solutions. AI leaders should therefore combine technical curiosity with design discipline: use the tools personally, study how people work, and prototype proposed changes before attempting broad implementation.

Read original(opens in new tab)
AIAI AgentsPrototypingAutomation+2
datadog3 min readCurated summary

Steganography at scale: Embedding share URLs in Datadog widget screenshots

Datadog is building a way for screenshots to preserve the context normally available through share links. The system invisibly embeds a compact widget identifier into screenshot pixels, while storing the full widget definition in Redis. This approach aims to combine screenshots’ convenience with share links’ ability to restore queries, time ranges, and dashboard state, at massive scale. ## From Share Links to Context-Aware Screenshots - Copying a Datadog widget creates a backend record and places a unique share URL on the clipboard. - Pasting the URL into a dashboard or notebook restores the widget. - Slack and Teams integrations can render a live preview linking back to Graph Explorer. - Screenshots remain popular because they are quick, intuitive, and visually consistent. - However, screenshots normally lose: - The time range - Underlying queries - Visualization type - Dashboard state - Template variables and other configuration ## Storing a Compact Snapshot Reference - A complete widget definition can be about 2 kB, including queries, display settings, legends, titles, time ranges, dimensions, and deep links. - Encoding all of that directly into an image would be impractical. - Instead, Datadog stores the full definition in Redis and embeds only a randomly generated snapshot ID in the screenshot. - Snapshot records are retained for one hour because screenshots are typically pasted within seconds or minutes. - The frontend generates IDs optimistically so watermarks appear immediately, before the backend cache operation completes. - Redis keys include the organization ID, preventing collisions between different customers. - An 8-byte identifier provides roughly 2⁶⁴ possible values; under the stated traffic assumptions, the estimated collision risk is about one in 37 million. ## Encoding Data in Widget Borders - Every dashboard widget has a uniform, 1-pixel border, making it a reliable place to add metadata without visualization-specific code. - An initial design used individual pixels with two colors to represent bits, but encoding 64 bits would require at least 64 pixels and could become visible. - The chosen approach stores multiple bits in each pixel’s RGB channels. - Each color channel is offset from the base border color by up to seven values, allowing up to nine bits per pixel. - Two sentinel pixels, encoded with maximum RGB offsets, mark the beginning and end of the watermark. - Because the encoded pixels remain close to the border’s original color, the watermark is intended to remain imperceptible while remaining recoverable by software. ## Scaling and Collision Considerations - Datadog renders more than one billion widgets per day, with peaks of roughly 35,000 widgets per second. - The watermark design therefore has to minimize payload size while supporting high throughput. - Shorter identifiers are easier to hide but increase collision risk, requiring organization-scoped keys and carefully chosen identifier sizes. Datadog’s design uses screenshots as lightweight carriers for references rather than embedding complete widget data. By combining subtle border-based pixel encoding with short-lived Redis snapshots, screenshots can potentially regain the contextual and interactive benefits of share links without changing their appearance.

Read original(opens in new tab)
DatadogPerformance OptimizationRedisWatermarking+3
datadog3 min readCurated summary

Steganography at scale: Embedding share URLs in Datadog widget screenshots

Datadog developed invisible pixel-level watermarks so screenshots can retain the context normally preserved by share links. The system embeds a compact widget snapshot ID into a widget’s border, while the full metadata remains in a Redis cache. This approach preserves screenshots’ convenience while enabling recovery of queries, time ranges, settings, and deep links at Datadog’s scale. ## Share Links Versus Screenshots - Copying a Datadog widget creates a backend record and places a unique share URL in the clipboard. - Pasting the URL into a dashboard or notebook restores the widget. - Slack and Teams integrations can render a live preview and link to Graph Explorer. - Screenshots are easier to use and provide a consistent visual snapshot, but normally lose: - Time range - Underlying queries - Visualization type - Dashboard state - Configuration and context ## Encoding Only a Snapshot ID - A complete widget definition averages about 2 kB and may include queries, display settings, legends, time-frame overrides, template variables, dimensions, and deep links. - Rather than embedding all of that data in the image, Datadog stores it in Redis and embeds only a randomly generated key. - The frontend generates the snapshot ID optimistically before the cache write completes, allowing watermarking without waiting for a backend response. - Records are retained for one hour because screenshots are usually shared within seconds or minutes. - At more than 1 billion widget renders per day, IDs must be compact while avoiding cross-customer collisions. - Datadog prefixes the cache key with the organization ID. An 8-byte ID provides roughly 2⁶⁴ possible values, producing an estimated collision probability of about 1 in 37 million under the stated usage assumptions. ## Watermarking the Widget Border - Every dashboard widget has a consistent 1-pixel border, making it a reliable location for encoding data regardless of visualization type. - An initial design represented each bit with a separate colored pixel, but 64 pixels were needed for 8 bytes and could become visible. - The final design stores data in RGB color adjustments: - Each pixel encodes up to 9 bits by offsetting the red, green, and blue channels. - The base color is calculated by subtracting 3 from each channel. - Channel offsets of up to 7 represent the encoded values. - Two sentinel pixels, using a `+7/+7/+7` offset, mark the beginning and end of the watermark. - Eight pixels between the sentinels encode one byte each: - 3 bits in red - 3 bits in green - 2 highest bits in blue ## Design Constraints - The watermark must remain nearly invisible and avoid adding interface elements. - It must work across different widget sizes, color profiles, display densities, and copy-paste workflows. - The border-based method avoids visualization-specific implementations while keeping the encoded region short. Datadog’s approach combines cached metadata with subtle RGB-level encoding, allowing screenshots to function like context-preserving share links without changing their appearance or the user’s workflow.

Read original(opens in new tab)
DatadogRedisIncident ManagementWatermarking+3
google2 min readCurated summary

ReasoningBank: Enabling agents to learn from experience

ReasoningBank is an agent-memory framework designed to help deployed agents learn continuously from both successful and failed task attempts. Rather than storing exhaustive action histories or only successful workflows, it distills reusable reasoning strategies, decision rationales, and preventative lessons. Evaluations on WebArena and SWE-Bench-Verified show higher success rates and fewer execution steps, especially when combined with memory-aware test-time scaling. ## Distilling Generalizable Reasoning - Each memory contains: - A concise title - A brief description - Detailed reasoning steps, rationales, or operational insights - The agent retrieves relevant memories before acting. - After completing a task, an LLM judge evaluates the trajectory and identifies useful success or failure signals. - The agent converts those signals into new memories and appends them to the ReasoningBank. - Failure analysis is central: mistakes become counterfactual guidance and strategic guardrails, such as verifying the current page before repeatedly clicking “Load More.” ## Memory-Aware Test-Time Scaling - Memory-aware test-time scaling (MaTTS) connects inference-time exploration with long-term memory. - **Parallel scaling:** Multiple trajectories are generated and compared, allowing the agent to distinguish robust strategies from flawed reasoning. - **Sequential scaling:** The agent progressively refines a single trajectory, preserving useful intermediate insights from trial and error. - This creates a feedback loop: better memories guide exploration, while richer exploration produces better memories. ## Benchmark Results and Strategic Maturity - Against memory-free ReAct agents using Gemini-2.5-Flash: - Success rates improved by 8.3% on WebArena. - Success rates improved by 4.6% on SWE-Bench-Verified. - SWE-Bench-Verified tasks required nearly three fewer execution steps on average. - Adding MaTTS with parallel scaling factor **k=5** produced further gains: - A 3% success-rate increase over ReasoningBank alone on WebArena. - 0.4 fewer steps per task. - Over repeated tasks, simple procedural checklists evolved into more sophisticated memories containing compositional and preventative logic. ReasoningBank suggests that effective agent scaling requires more than additional inference compute or stored trajectories. Agents should systematically learn from both outcomes and mistakes, using structured reasoning memories to become more capable and efficient after deployment.

Read original(opens in new tab)
Database DesignLarge Language ModelsPostgreSQLContrastive Learning+4
gitlab3 min readCurated summary

GitLab + Amazon: Platform orchestration on a trusted AI foundation

GitLab Duo Agent Platform and Amazon Bedrock combine GitLab’s software-lifecycle orchestration with AWS’s governed foundation-model infrastructure. Duo coordinates agents across planning, development, security, pipelines, and remediation, while Bedrock provides secure inference within AWS boundaries. The pairing aims to reduce shadow AI, fragmented tooling, unclear data flows, and unplanned cloud spending. ## The Enterprise AI Governance Problem - Teams often adopt unapproved AI tools, creating unknown prompt and code-data paths. - AI tooling and model choices become fragmented across developers and departments. - Security teams may lack control over logs, data residency, and access policies. - Existing AWS and Amazon Bedrock investments can be underused when teams rely on external point solutions. - The proposed division of responsibility is: - GitLab Duo Agent Platform: workflow and agent orchestration. - Amazon Bedrock: approved models and inference. - The organization: IAM, VPC, regional, security, and policy controls. ## GitLab Duo Agent Platform as the Control Plane - Duo provides specialized agents and flows that operate asynchronously across the software lifecycle. - Agents use shared GitLab context, including: - Issues - Merge requests - Pipelines - Security findings - It extends beyond a single conversational assistant by coordinating multiple agents across continuous workflows. - Potential tasks include planning, code development, merge-pipeline work, security scanning, and vulnerability remediation. ## Amazon Bedrock as the AI Foundation - Bedrock is a managed, serverless foundation-model layer operating within AWS. - Customer inputs and outputs are encrypted, not shared with model providers, and not used to train base models. - It supports compliance requirements including GDPR, HIPAA, and FedRAMP High. - Organizations can use native Bedrock models or import fine-tuned models through Custom Model Import. - Bedrock Guardrails can provide content filtering, hallucination detection, and sensitive-data protection. ## Deployment Options The core Duo capabilities remain consistent, but control and infrastructure ownership vary across three patterns: - **Self-hosted models with Amazon Bedrock** - Intended for GitLab Self-Managed deployments. - Uses a self-hosted AI Gateway. - Keeps inference traffic, prompts, logs, and lifecycle data within the organization’s AWS environment. - **GitLab-operated Bedrock models with GitLab-owned keys** - Intended for GitLab Self-Managed deployments. - Uses GitLab’s hosted AI Gateway. - GitLab operates the model layer while the deployment remains self-managed. - **GitLab.com with GitLab-operated Bedrock models** - Uses GitLab’s hosted AI Gateway and GitLab-owned keys. - Suits organizations that prefer the SaaS GitLab experience while using Bedrock-backed models. ## Practical Enterprise Uses - Platform teams can standardize models for code suggestions, security analysis, and pipeline remediation. - Centralized guardrails and logging reduce independent, unmanaged AI adoption. - Security agents can propose and validate fixes directly within GitLab. - Routing AI workloads through Bedrock helps organizations align usage with existing AWS agreements and spending commitments. The recommended approach is to treat GitLab Duo Agent Platform as the orchestration layer and Amazon Bedrock as the governed inference foundation, selecting the deployment model that matches the organization’s compliance, hosting, and control requirements.

Read original(opens in new tab)
Machine LearningGitlabDevSecOpsAmazon Bedrock+4
aws3 min readCurated summary

AWS Weekly Roundup: Claude Opus 4.7 in Amazon Bedrock, AWS Interconnect GA, and more (April 20, 2026) | Amazon Web Services

The roundup highlights major AWS advances in AI, networking, developer tooling, and security. Claude Opus 4.7 is now available through Amazon Bedrock with stronger agentic coding and research capabilities, while AWS Interconnect simplifies private connectivity across clouds and remote locations. Additional launches improve container supply-chain security, application modernization, database access, cost attribution, and quantum-resistant encryption. ## Anthropic Claude Opus 4.7 in Amazon Bedrock - Anthropic’s latest Opus model improves: - Agentic coding and long-running tasks - Complex code reasoning - Document creation, financial analysis, and multi-step research - It scores: - 64.3% on SWE-bench Pro - 87.6% on SWE-bench Verified - Bedrock features include: - Dynamic capacity allocation - Adaptive thinking and request-specific token budgets - A 1-million-token context window - High-resolution image support for charts, documents, and screen interfaces - The model launched in US East, Tokyo, Ireland, and Stockholm, supporting up to 10,000 requests per minute per account and Region. ## AWS Interconnect Reaches General Availability - **AWS Interconnect – Multicloud** provides Layer 3 private connectivity between AWS VPCs and other clouds. - Google Cloud is supported initially; Azure and OCI are planned. - Traffic uses private networks and the AWS global backbone rather than the public internet. - Includes MACsec encryption, multi-facility resilience, and CloudWatch monitoring. - The underlying specification is open source under Apache 2.0. - **AWS Interconnect – Last Mile** connects branches, data centers, and remote sites to AWS through network providers. - Automatically provisions four redundant connections across two physical locations. - Configures BGP, MACsec, and Jumbo Frames. - Supports adjustable bandwidth from 1 to 100 Gbps. - Launches in US East with Lumen. ## Developer, Database, and Modernization Updates - Amazon ECR pull-through cache now discovers and synchronizes OCI referrers such as signatures, SBOMs, and attestations. - AWS Transform is available directly in Kiro and VS Code for migrations such as language-version upgrades and AWS SDK updates. - Aurora DSQL’s PHP connector supports IAM authentication, SSL, connection pooling, and optional optimistic-concurrency retries. - AWS Transform Custom can modernize VB6 applications into C# ASP.NET Core applications, including COM, ADO, and UI migration challenges. ## Security, Access Control, and Cost Management - Amazon Q for Google Drive now enforces document-level permissions using indexed ACLs and real-time access checks. - AWS Secrets Manager supports hybrid post-quantum TLS using ML-KEM through updated agents, Lambda extensions, and CSI drivers. - Amazon Bedrock can attribute inference costs to individual IAM principals, with reporting through CUR 2.0 and aggregation by teams, projects, or cost centers. ## Compute, Kubernetes, and Storage - EC2 C8in and C8ib instances use sixth-generation Intel Xeon processors and AWS Nitro cards. - C8in offers up to 600 Gbps networking. - C8ib provides up to 300 Gbps EBS bandwidth. - Both scale to 384 vCPUs. - EKS Auto Mode automates networking components such as VPC CNI, load balancers, and DNS while retaining enterprise security controls. - EBS Volume Clones provide immediately usable point-in-time copies for development, disaster recovery testing, and CI/CD workflows. ## Additional AWS Guidance - CloudFront Functions and CloudFront KeyValueStore can support zero-downtime API decomposition using user-aware routing and the Strangler Fig pattern. - The roundup also points readers to AWS events, weekly Power Hour training, and Community.aws meetups. The most significant developments are Bedrock’s expanded AI capabilities and Interconnect’s managed private networking. Teams should evaluate Claude Opus 4.7 for complex AI workflows, use Interconnect where multicloud or resilient connectivity is required, and consider the new security and cost-attribution features for stronger governance.

Read original(opens in new tab)
KubernetesPostgreSQLAmazon BedrockDevOps+4
cloudflare3 min readCurated summary

Building the agentic cloud: everything we launched during Agents Week 2026

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

Read original(opens in new tab)
CloudflareDocker & ContainersServerlessGit+4
cloudflare4 min readCurated summary

The AI engineering stack we built internally — on the platform we ship

Cloudflare built an internal AI engineering stack that now supports AI coding tools for 93% of its R&D organization. The system combines centralized authentication and model routing with internal knowledge, automated review, and sandboxed agent execution. Cloudflare argues that building these capabilities on its own platform improved security, visibility, cost control, and developer velocity, while also serving as a proving ground for products it ships publicly. ## Adoption and Impact - Over the previous 30 days: - 3,683 employees used AI coding tools, representing 60% of the company and 93% of R&D. - AI tools generated 47.95 million requests. - 295 teams used agentic AI tools or coding assistants. - AI Gateway handled 20.18 million requests and routed 241.37 billion tokens. - Workers AI processed 51.83 billion tokens. - The four-week rolling average of merge requests increased from roughly 5,600 per week to more than 8,700. - The week of March 23 reached 10,952 merge requests, nearly twice the Q4 baseline. - Cloudflare’s initial focus was MCP servers, but the effort expanded to standards, code review, onboarding, and propagating changes across thousands of repositories. ## Architecture at a Glance Cloudflare organized the stack into three layers: - **Platform layer:** Authentication, model routing, inference, MCP access, and code execution. - **Knowledge layer:** System context and repository guidance through Backstage and `AGENTS.md`. - **Enforcement layer:** Automated quality controls using AI Code Reviewer and the Engineering Codex. The stack uses Cloudflare products including: - **Cloudflare Access** for zero-trust authentication. - **AI Gateway** for centralized LLM routing, cost tracking, bring-your-own-key support, and zero-data-retention controls. - **Workers AI** for open-weight model inference. - **Workers and Access** for an MCP Server Portal with single OAuth. - **Dynamic Workers** for sandboxed agent-generated code execution. - **Agents SDK and Durable Objects** for stateful, long-running agent sessions. - **Sandbox SDK** for isolated cloning, building, and testing environments. - **Workflows** for durable, multi-step processes. - **Backstage** for a 16,000-plus-entity knowledge graph. ## Centralized Authentication and AI Routing - Cloudflare Access authenticates users and enforces zero-trust policies. - Every LLM request passes through AI Gateway, providing a single control point for: - Provider credentials - Usage and cost attribution - Model selection - Data-retention policies - Provider permissions - In the past month, frontier providers handled 91.16% of requests, while Workers AI handled 8.84%. - Cloudflare routes requests through a proxy Worker rather than connecting clients directly to AI Gateway. - The proxy enables later additions such as per-user attribution, model catalogs, permission enforcement, and support for new coding tools without changing client configurations. ## Workers AI and Open-Weight Models - Workers AI runs open-source models on GPUs distributed across Cloudflare’s global network. - Keeping inference on the same network as Workers, Durable Objects, and storage reduces latency, network failures, and cross-cloud configuration. - Kimi K2.5, with a 256,000-token context window, tool calling, and structured outputs, processes more than 7 billion tokens per day for a Cloudflare security agent. - Cloudflare estimates that running this workload on Workers AI is 77% cheaper than using a mid-tier proprietary model. - Workers AI is also used for: - Documentation review in CI - Generating `AGENTS.md` files - Lightweight inference where latency matters more than maximum model capability - Cloudflare expects open-source models to handle an increasing proportion of its internal workloads. ## One-Command Client Configuration - Engineers begin setup with: ```bash opencode auth login https://opencode.internal.domain ``` - The command uses an OpenCode discovery endpoint at: ```text https://opencode.internal.domain/.well-known/opencode ``` - The Worker-hosted endpoint provides authentication and configuration information. - This mechanism is designed to configure providers, models, MCP servers, agents, commands, and permissions without requiring engineers to edit configuration files manually. ## Overall Recommendation Cloudflare’s experience suggests that organizations adopting AI coding tools should build a centralized control plane early: authenticate users consistently, route model traffic through one managed gateway, maintain shared system knowledge, and enforce quality through automated review and isolated execution. Using the same production platform for internal tooling can also expose product gaps and accelerate improvements to the platform itself.

Read original(opens in new tab)
Database DesignCI/CDOpen SourcePostgreSQL+4
cloudflare3 min readCurated summary

Orchestrating AI Code Review at scale

Cloudflare built a CI-native AI code review system to reduce review bottlenecks without overwhelming engineers with noisy or generic model feedback. Instead of using one large prompt, it orchestrates up to seven specialized agents for areas such as security, performance, compliance, and documentation, then uses a coordinator to deduplicate and assess findings. The system now reviews tens of thousands of merge requests, approving clean changes and blocking serious bugs or vulnerabilities. ## Why Naive AI Review Wasn’t Enough - Traditional code review can leave merge requests waiting for hours and creates repeated context switching. - Commercial AI review tools provided useful functionality but lacked the flexibility and customization required across Cloudflare’s organization. - A basic “send the Git diff to an LLM” approach produced: - Vague recommendations - Hallucinated syntax errors - Repetitive advice such as adding error handling where it already existed - Complex codebases required specialized analysis rather than generic summarization. ## Specialized Agents and Coordination - The system launches up to seven focused reviewers covering: - Security - Performance - Code quality - Documentation - Release management - Internal Engineering Codex compliance - A coordinator agent: - Deduplicates overlapping findings - Evaluates the actual severity of issues - Produces one structured review comment - The system can actively block merges when it detects serious defects or security vulnerabilities. ## Plugin-Based Architecture - The platform uses composable plugins so it can support different: - Version-control systems - AI providers - Internal standards - Repository-specific requirements - Each plugin implements a `ReviewPlugin` interface with three lifecycle phases: - `bootstrap`: Runs concurrently and is non-fatal. - `configure`: Runs sequentially and is fatal if essential configuration fails. - `postConfigure`: Handles asynchronous work after configuration assembly. - Through `ConfigureContext`, plugins can: - Register agents and AI providers - Set environment variables - Inject prompt sections - Configure agent permissions - Plugins contribute through the context API rather than accessing the final configuration directly. - The core assembler combines these contributions into `opencode.json`. - This separation prevents unrelated components from becoming tightly coupled; for example, GitLab logic does not need to understand Cloudflare AI Gateway settings. ## Plugin Responsibilities - `@opencode-reviewer/gitlab` - Provides GitLab merge request data and a comment server. - `@opencode-reviewer/cloudflare` - Configures AI Gateway model tiers and fallback chains. - `@opencode-reviewer/codex` - Checks compliance with internal engineering RFCs. - `@opencode-reviewer/braintrust` - Adds distributed tracing and observability. - `@opencode-reviewer/agents-md` - Verifies that repository `AGENTS.md` instructions are current. - `@opencode-reviewer/reviewer-config` - Retrieves remote model overrides for individual reviewers. - `@opencode-reviewer/telemetry` - Tracks reviews asynchronously. ## Why OpenCode - Cloudflare already used OpenCode extensively and understood its behavior. - Its open-source implementation allows engineers to: - Investigate problems directly - Contribute fixes upstream - Extend the system through its SDK - Cloudflare engineers had contributed more than 45 upstream pull requests at the time of writing. - Its server-first design was especially important: - Review sessions can be created programmatically. - Prompts can be sent through an SDK. - Multiple concurrent sessions can be managed without scraping or wrapping a CLI interface. ## Coordinator Process - The coordinator runs OpenCode as a child process using `Bun.spawn`. - Its prompt is passed through `stdin` rather than a command-line argument. - This avoids Linux’s `ARG_MAX` limit, which previously caused `E2BIG` failures for unusually large merge requests containing extensive descriptions or logs. - OpenCode runs with `--format json`, emitting JSONL events through standard output. - This event-based interface allows the orchestration layer to collect and process results from concurrent reviewer sessions. A practical takeaway is to treat AI review as an orchestrated CI system rather than a single LLM prompt. Specialized agents, strict plugin boundaries, structured outputs, and observability are essential for making automated review reliable enough to influence merge decisions at organizational scale.

Read original(opens in new tab)
Database DesignLarge Language ModelsCI/CDGitlab+4