techlist.io
KREN

AI Agents

171 posts

line4 min readCurated summary

Unifying Analysis Through the Power of Analytics Agents: Work Innovation and Role Transformation in the Generative AI Era at a Professional Organization

PJ One Piece is LY Corporation’s initiative to connect business questions, data analysis, insight generation, and next-action planning through generative AI. Its analysis agent reduced typical turnaround times from about two weeks to roughly 10 minutes, enabling hundreds of analyses each month and adoption by more than half of an early-adopter business unit. The project treats AI not as a chat interface, but as an analysis platform that connects data, knowledge, people, and organizational processes. ## Three Disconnects Behind the Project - **Business and data:** Even with a data warehouse and BI tools, business users still needed to understand SQL, tables, column definitions, KPI rules, and result interpretation. - **Within the analysis process:** Task definition, analysis design, execution, review, and action planning were often handled by different people or tools, causing context loss, rework, delays, and inconsistent quality. - **Across domains:** Useful analysis patterns and domain knowledge remained isolated because services used different KPIs, table structures, business assumptions, and review criteria. ## The Analysis Agent as a Connector - Users ask questions in natural language without needing to know SQL or database structures. - The agent: - Clarifies the business objective and missing assumptions. - Finds relevant data and creates an analysis plan. - Executes queries and specialized analyses. - Interprets results and produces visualizations or reports. - Suggests further analysis and possible next actions. - The platform consists of: - A user-facing application. - An LLM-based agent for reasoning and tool use. - Tools for SQL, Python, document search, and visualization. - A knowledge base containing domain information, skills, and table metadata. - Logging, feedback, monitoring, and evaluation systems. - Domain knowledge is added through a plugin-like structure, while logs and feedback continuously improve the system. ## Turning Business Questions into Analysis Requirements - Natural-language questions often leave important assumptions unspecified, such as: - Target population or campaign definition. - Analysis period and comparison group. - KPI definitions. - Aggregation level. - Exclusion conditions. - Rather than requiring users to write detailed prompts, the agent uses domain knowledge to determine what can be inferred and asks only about unresolved points. - Knowledge bases document service context, KPI definitions, aggregation cautions, policy information, and review requirements. - Table metadata explains available tables, columns, appropriate use cases, samples, partition requirements, and usage restrictions. ## Reaching Data Safely and Reliably - Table metadata is revealed progressively: - The agent first narrows down relevant tables. - It then retrieves detailed definitions and usage rules only for those tables. - Analysis-oriented wide tables or logical views combine transaction data with commonly needed attributes, reducing complicated joins and SQL-generation errors. - SQL is checked before and after execution to enforce: - `SELECT`-only access. - Approved tables and usage rules. - Required partition conditions. - Restrictions on sensitive or personal data. - Result-size limits. - These guardrails allow the agent to perform analysis flexibly without exposing data or infrastructure to unnecessary risks. ## Preserving Context Across the Analysis Process - PJ One Piece uses a supervisor-style multi-agent architecture. - A main agent maintains: - The user’s request and business objective. - The current analysis plan. - Findings and constraints discovered so far. - Remaining questions and decision points. - Specialized sub-agents handle tasks such as statistical testing, time-series analysis, clustering, and independent review. - This separates complex or specialized work from the main context while preserving overall continuity. - Progress updates expose discoveries, design decisions, data limitations, and constraints so users can adjust direction during longer analyses. ## Building Reusable Organizational Capability - Logs record agent actions, assumption checks, analysis designs, generated SQL, errors, and outputs. - User and analyst feedback helps identify whether improvements are needed in prompts, tools, data, or reusable skills. - Repeated workflows are formalized as skills, including: - General-purpose methods such as time-series and clustering analysis. - Domain-specific workflows such as monthly reporting or policy monitoring. - Skills document required assumptions, comparison axes, cautions, and interpretation methods. - Over time, isolated domain knowledge becomes reusable organizational analysis capability. ## Business Impact - In early deployment, the platform expanded data use beyond data scientists to product owners and frontline employees. - More than half of the participating business unit’s members use it. - Analysis turnaround fell from an average of approximately two weeks to about 10 minutes. - The platform now supports hundreds of analyses per month and serves as a daily starting point for business questions. PJ One Piece’s main recommendation is to design AI analysis as an end-to-end operating platform—not merely an automated SQL or chatbot tool. Combining structured domain knowledge, safe data access, contextual multi-agent workflows, reusable skills, and continuous evaluation can make analysis faster while steadily improving its quality and organizational reach.

Read original(opens in new tab)
AI AgentsLarge Language ModelsGenerative AIPython+4
github3 min readCurated summary

How we built an internal data analytics agent

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

Read original(opens in new tab)
AI AgentsModel Context ProtocolSlackGithub Copilot+4
cloudflare2 min readCurated summary

Temporary Cloudflare Accounts for AI agents

Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted. ## Why Frictionless Deployment Matters - Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA. - Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle. - Throwaway environments let agents test code cheaply and independently. - Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services. ## How Temporary Accounts Work - The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects. - When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option. - Running `wrangler deploy --temporary` provisions: - A temporary Cloudflare account - An API token for Wrangler - A claim URL that can be returned to the user - The temporary account can be reused for multiple deployments during the 60-minute window. ## Agent Deployment and Iteration - An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result. - It can then modify the source and redeploy without repeating account setup. - Agents can use this loop to test and refine applications autonomously. ## Claiming or Expiring the Account - Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account. - Claiming includes associated Workers, databases, and other bindings. - Unclaimed accounts are automatically deleted after 60 minutes. ## Broader Agent Provisioning Efforts - Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry. - Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards. - Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use. Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.

Read original(opens in new tab)
AI AgentsTypeScriptCloudflare WorkersStripe+4
cloudflare3 min readCurated summary

Build your own vulnerability harness

A scalable AI vulnerability program should be built around a model-agnostic harness rather than a single model, prompt, or agent session. The harness must preserve state, support resumable investigations, cross-check findings with different models, and trace issues across repositories. The authors recommend starting small with database-backed Recon, Hunt, and Validate stages, expanding only when operational bottlenecks justify it. ## Why a Harness Is Needed - Generic coding agents are poorly suited to large-scale security analysis because they: - Hold only one hypothesis at a time. - Exhaust their context windows while exploring real repositories. - Lose important information during context compaction. - Subagents help, but they do not provide the persistence, deduplication, resumability, and cross-run coordination required for security investigations. - The system should treat models as interchangeable components: - One model can discover vulnerabilities. - Another can independently validate them. - Different models expose different classes of bugs and reduce shared blind spots. - The harness, rather than any particular frontier model, is intended to be the durable investment. ## The Original Security-Audit Skill The authors began with an approximately 450-line skill designed to audit one repository in a single session. Its seven-phase workflow included: - Three parallel reconnaissance agents producing `architecture.md`. - Hunter agents attacking the code by vulnerability class. - Adversarial validators attempting to disprove findings. - A human-readable vulnerability report for surviving findings. - A schema-checked `findings.json` file. - Mechanical validation of referenced functions and line numbers. - A fresh agent independently re-verifying every finding before submission to an ingest API. This skill became the blueprint for the later pipeline: - Recon agents became the Recon stage. - Attack-class hunters became Hunt. - Adversarial reviewers became Validate. - Reports became structured findings. - Independent re-verification remained a separate validation step. ## Limitations of Single-Session Audits A single run found only about half of the bugs discovered across multiple runs, and it tended to find simpler vulnerabilities rather than subtle ones. Repeating the skill many times and manually diffing results quickly became impractical. The authors identified three major bottlenecks: - **Context exhaustion:** Long sessions cause the model to forget previously investigated bugs. The solution is to externalize state and use the model as a stateless computation engine. - **Poor persistence:** Crashes, rate limits, and connection failures can erase hours of progress if work is not stored incrementally. - **Lack of cross-repository reasoning:** Auditing one repository in isolation misses vulnerabilities at the interfaces between applications and shared components. ## Recommended Minimal Architecture The authors advise building only the infrastructure needed to address current problems: - Store Recon, Hunt, and Validate stages in a database. - Use a separate validator that cannot submit its own findings, reducing confirmation bias. - Defer cross-repository tracing until multiple important repositories need to be analyzed together. - Defer a dedicated deduplication agent until the system produces too much duplicate or low-quality output. - Begin with a well-tuned development skill, then add pipeline stages only when a specific limitation is slowing the work. ## Enterprise-Scale Direction A mature vulnerability harness should continuously scan a fleet of repositories, trace dependencies across them, and reduce thousands of raw candidates to a smaller queue of verified, actionable fixes. Frequent model interchange and independent validation are central to maintaining coverage as models change or become unavailable. The practical recommendation is to invest first in durable orchestration and state management, not allegiance to a particular model. A simple, resumable Recon–Hunt–Validate pipeline is the appropriate starting point, with cross-repository analysis and advanced deduplication added only as scale demands.

Read original(opens in new tab)
AI AgentsVulnerability ScanningSecurity AuditLlm Orchestration+3
stripe2 min readCurated summary

What Link data tells us about AI spending

Link’s survey and transaction data show rapidly growing consumer engagement with AI. Among 250 million Link customers, spending on AI products—especially AI app-building platforms—has surged, with top spenders nearly doubling their monthly AI spending in one quarter. Stripe argues this growth points toward a need for payment infrastructure that allows AI agents to transact on users’ behalf. ### Growing Spending on AI Products - A survey of 394 Link customers found: - 80% had used a chat-based AI agent in the previous month. - 50% used AI for shopping research at least monthly. - The top 10% of AI spenders increased monthly spending from: - $183 in December 2025 - $359 in March 2026 - This cohort previously took 22 months to grow from $84 to $183, but doubled that amount in only three months. - Median spending also rose, from $60 to $72 per month. ### Strong Demand for AI App Builders - Spending growth was even greater for platforms such as Replit, Lovable, and Bolt. - The highest-spending Link customers now spend five times more each month on AI app-building platforms than they did in January 2025. - This suggests users are investing not only in AI tools, but also in platforms that let them create software with AI. ### Payments for AI Agents - As AI agents become more capable and common, they will need to purchase goods and services from businesses and potentially from one another. - Stripe’s Link wallet for agents is designed to support this activity by: - Letting users authorize agent payments. - Providing configurable spending controls. - Giving agents purchasing access across Stripe sellers. - Providing businesses with verified transactions without requiring custom integrations. Stripe’s data indicates that AI adoption is translating into substantial spending, particularly on AI development platforms. Businesses preparing for agent-driven commerce may benefit from supporting secure, user-authorized agent payments.

Read original(opens in new tab)
AI AgentsStripeAgentic CommerceReplit+4
gitlab2 min readCurated summary

AI Catalog updates for governance and operations

GitLab 19.1 expands the AI Catalog from a manually triggered tool into a governed automation platform. New event-driven Duo Flow triggers, configuration validation, agent restrictions, and model allowlists help enterprises run AI workflows continuously while maintaining security and operational control. The release is designed to make agentic automation safer and more reliable at production scale. ## Event-Driven Duo Flow Automation - Four new triggers let flows respond automatically to GitLab events: - Merge request code conflicts - Draft merge requests becoming ready for review - Merge request approvals - New work item creation - These triggers enable automated conflict summaries, compliance checks, deployment readiness checks, notifications, triage, labeling, and routing. - Pipeline triggers can now filter for specific states: failure, success, or cancellation. - Conflict-detected and draft-to-ready triggers are enabled by default. - A beta pattern-based approval tier lets developers approve repeated tool uses for an entire session instead of approving each invocation individually. ## Governance for Agents and Flows - Instance administrators and top-level group owners gain controls over which AI content users can run. - **Disable custom agents and flows** prevents users from creating or enabling custom-built content. - **Restrict the AI Catalog to your group hierarchy** blocks AI Catalog items from outside the organization’s namespace, including community and third-party contributions. - These controls help prevent unapproved agents and workflows from entering regulated or production environments. ## Pre-Save Flow Configuration Validation - GitLab now validates AI Catalog flow configurations against the Duo Workflow Service before saving them. - Errors such as missing inputs or invalid tool parameters appear directly in the UI. - This moves troubleshooting to configuration time, reducing the risk of broken or overly active flows running in production. ## Approved AI Model Controls - A public beta lets administrators define an allowlist of approved AI models. - Organizations can also set an organization-wide default model. - Teams retain flexibility within approved boundaries while meeting provider, compliance, or data-residency requirements. - The first version applies to GitLab Duo Agentic Chat, with broader coverage planned. Overall, GitLab 19.1 recommends treating AI workflows like production automation: trigger them from real events, validate them before deployment, and govern both the agents and models they use. Enterprises adopting the AI Catalog should configure the new restrictions and model policies before enabling widespread automated flows.

Read original(opens in new tab)
AI AgentsCI/CDGitlabDevSecOps+3
gitlab3 min readCurated summary

GitLab 19.1 release notes | GitLab Docs

GitLab 19.1, released June 18, 2026, focuses heavily on AI governance, security scanning, and compliance automation. The release adds AI-assisted false-positive detection for secrets, centralized controls for GitLab Duo, stronger approval guardrails for agents, and broader secret detection in feature branches. It also streamlines code review and compliance setup through automatic Code Owner assignment and framework templates. ## Security and Secret Detection - **GitLab Duo secret false-positive detection** is generally available for Ultimate users. - Automatically analyzes critical and high-severity secret detection findings after scans. - Provides reasoning and confidence scores directly in vulnerability reports. - Supports manual analysis from individual vulnerability pages. - Helps security teams prioritize real threats and reduce alert fatigue. - **Improved feature branch secret detection** scans every commit from the branch’s divergence point from the default branch through the latest commit. - Previously, new branches or existing branches could leave secrets in earlier commits undetected. - The broader scan helps identify leaked credentials before they reach shared branches or production. ## GitLab Duo Administration and AI Governance - **Always-on availability mode** lets instance and top-level group administrators require GitLab Duo to remain enabled. - Project, subgroup, and group owners cannot disable Duo when this policy is active. - This complements the existing “always off” setting and supports centralized governance. - **Tool approval guardrails for Duo agents** introduce three policy modes for individual tools: - **Allow:** execute without user interaction. - **Ask:** require inline human approval. - **Deny:** block the tool entirely. - Approval decisions generate audit events. - The beta applies to Agentic Chat, IDE integrations, and flows. - **Custom and external AI feature controls** allow administrators and top-level group Owners to: - Prevent users from creating or enabling custom agents and flows. - Block agents and flows owned outside the organization’s group hierarchy. - **Custom flow YAML validation** checks configurations when flows are saved or updated. - Errors such as missing inputs or invalid tool parameters are reported before runtime. - This avoids discovering configuration problems only after a CI job begins. - **Pattern-based tool approval for Agentic Chat** is also introduced in the Agentic Core updates, extending administrative control over how agent tools can be used. ## Code Review and Compliance - **Automatic Code Owner reviewer assignment** removes the need to manually select reviewers for merge requests. - GitLab assigns all Code Owners matching the changed files. - Assignment occurs when a merge request is created as ready or when a draft becomes ready. - Existing reviewer selections are preserved. - **Compliance framework templates** are available in beta for Ultimate users. - Teams can create frameworks from predefined requirements and controls. - Templates can be previewed and customized before being applied. - Nineteen templates are available, including ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, and TISAX. ## Contributor Recognition - GitLab recognizes **Pishel65** as the month’s Notable Contributor. - The Level 3 contributor had 19 merged merge requests and nine additional open merge requests since joining in October 2025. GitLab 19.1 is particularly valuable for organizations adopting AI at scale: enable centralized Duo policies, require approval for sensitive agent actions, validate flows before execution, and use the expanded security and compliance features to reduce operational risk.

Read original(opens in new tab)
AI AgentsCI/CDGitlabYaml+4
github3 min readCurated summary

Getting more from each token: How Copilot improves context handling and model routing

GitHub is improving Copilot’s efficiency by optimizing both how context is handled and which model performs each task. Prompt caching and deferred tool loading reduce repeated overhead in long agentic sessions, while Auto selects models based on task complexity and real-time system conditions. The goal is to preserve quality while using tokens, compute, and cost more intelligently. ## Prompt Caching and Deferred Tools - Copilot sessions repeatedly include instructions, repository context, conversation history, tool definitions, and task state. - Prompt caching allows repeated prompt prefixes to reuse model state instead of being recomputed on every request. - Tool search loads tool definitions only when needed, rather than placing every full schema into context on every turn. - This is especially valuable for sessions involving MCP tools, terminal commands, file operations, workspace search, and other actions. - The approach reduces fixed per-turn overhead while preserving access to a broad toolset. ## Auto Model Selection - Copilot Auto chooses a model based on the task rather than requiring developers to select one manually. - Quick explanations, focused edits, and complex multi-file changes often benefit from different levels of reasoning. - Evaluations found that no single model consistently performs best across all tasks. - Auto uses more efficient models when they can achieve comparable results and selects stronger reasoning models when the task demands them. - The objective is not simply lower cost, but matching model capability to the work. ## How Auto Routes Tasks Auto combines two signals: - **Real-time model health** - Considers availability, utilization, response speed, error rates, and cost. - Avoids selecting a model that is technically capable but currently overloaded or unreliable. - **Task-aware routing with HyDRA** - Evaluates reasoning depth, code complexity, debugging difficulty, and tool-orchestration requirements. - Identifies models capable of meeting the task’s quality threshold, then chooses the best fit among them. - The system can be tuned toward maximum quality or greater cost savings. ## Cache-Aware Routing - Switching models during every turn can reduce efficiency by invalidating cached prompt prefixes. - Auto therefore keeps the same model during a conversation so the cache can continue building. - It changes models at natural cache boundaries: - The first turn, when no cache exists yet. - After context compaction, when older turns are summarized and the prompt prefix resets. ## Multilingual Routing - Copilot’s routing system was trained on conversations spanning 16 language families, including CJK and European languages. - Evaluations covered production VS Code chat data across 19 languages. - Routing accuracy remained within four points of the English baseline across language groups. - No statistically significant quality gap was observed between the language groups. Copilot’s efficiency strategy combines smarter context management with adaptive model selection. Caching and on-demand tools reduce repeated work, while cache-aware Auto routing chooses an appropriate model without unnecessarily sacrificing quality or session efficiency.

Read original(opens in new tab)
AI AgentsModel Context ProtocolGithub CopilotVisual Studio Code+3
aws3 min readCurated summary

Top announcements of the AWS Summit in New York, 2026 | Amazon Web Services

AWS Summit New York 2026 focused on making AI agents more capable, secure, autonomous, and easier to operate in production. Announcements spanned Amazon Bedrock AgentCore, security automation, developer tooling, workplace agents, and S3 data management. The overall direction is toward agents that can access governed knowledge, act independently, and continuously improve while remaining subject to enterprise controls. ## Building More Capable Agents - **Amazon Bedrock Managed Knowledge Base** simplifies enterprise RAG with native data connectors, Smart Parsing for multi-format data, and an Agentic Retriever for complex, multi-step queries. - **Web Search for Bedrock AgentCore** provides managed, current, cited web knowledge while keeping data within the customer’s secured AWS environment. - **Bedrock AgentCore harness** is now generally available, allowing developers to define an agent’s model, tools, skills, and instructions through configuration rather than custom orchestration loops. - **AWS Context**, coming soon, will map relationships across organizational data into a knowledge graph. Agents will be able to use governed relationships, business rules, and domain knowledge at runtime. - **AWS WAF Bot Control** lets publishers and content owners price, meter, and collect payment from AI bots accessing content and APIs, with scoped access enforced at the edge. ## Securing Agents and Applications - **AWS Continuum**, available in gated preview, aggregates vulnerability findings, ranks them by business impact, verifies exploitability, and routes fixes through existing development processes. - **AWS Security Agent**, now part of Continuum, adds: - Threat modeling based on the STRIDE framework - Pull-request code scanning and remediation across major Git platforms - IDE integrations through Kiro, Claude Code, and MCP - These tools are intended to let developers perform security reviews and address vulnerabilities without leaving their normal workflows. ## AI-Assisted Software Development - **Kiro for iOS**, in gated preview, lets developers start, monitor, steer, and approve Kiro sessions from a phone, including reviewing diffs and approving changes without keeping a laptop running. - **AWS DevOps Agent** adds release readiness reviews and autonomous release testing. It evaluates changes against natural-language standards and tests them in production-like environments. - **AWS Transform continuous modernization**, in preview, scans repositories against configurable technical-debt baselines and can autonomously generate remediation pull requests. ## Autonomous Workplace Agents - New **Amazon Quick autonomous agents** can work in the background with defined expertise, tone, permissions, and tools. - Example use cases include: - A finance agent processing incoming orders - A sales agent analyzing CRM, email, and Slack activity - Agents drafting follow-ups, identifying risks, and recommending next steps - A new **activity feed** combines email, messaging, calendars, and tasks into a prioritized view that adapts to the user’s communication and work patterns. ## Richer Metadata for Amazon S3 - **S3 annotations** allow up to 1 GB of mutable, queryable context to be attached directly to an object. - The feature targets AI agents and autonomous workflows that need to discover and interpret data without maintaining separate metadata systems. AWS’s announcements point toward an agent ecosystem that combines managed knowledge retrieval, web access, security automation, autonomous development workflows, and persistent workplace assistance. Organizations adopting these capabilities should pair autonomy with strong governance, scoped permissions, and continuous validation in production.

Read original(opens in new tab)
AI AgentsAmazon BedrockRAGAmazon S3+4
aws3 min readCurated summary

Introducing Amazon Bedrock Managed Knowledge Base for faster, more accurate enterprise AI applications | Amazon Web Services

Amazon Bedrock Managed Knowledge Base is a managed service for building enterprise generative AI applications over proprietary data. It abstracts storage, retrieval, embeddings, reranking, and model selection while adding native connectors, automated parsing, and agentic retrieval. The result is a faster way to create scalable, accurate RAG-based agents without maintaining the underlying infrastructure. ## Enterprise Knowledge Base Challenges - Enterprise data is distributed across systems with different formats, permissions, and access controls. - RAG accuracy requires ongoing experimentation with parsing, chunking, embedding models, and retrieval behavior. - Organizations must support either massive knowledge bases containing millions of documents or thousands of smaller ones while controlling cost and enforcing security. - These infrastructure tasks divert developers from building application functionality. ## Managed RAG Infrastructure - Managed Knowledge Base combines storage, retrieval, embeddings, reranking, and foundation model selection into one managed primitive. - The service automatically selects and manages default embedding, reranking, and foundation models. - It can scale end-to-end RAG pipelines with only a few lines of code. - Through Amazon Bedrock AgentCore Gateway, it is available as a pre-built target with automatically generated role-based permissions, observability, and evaluation metrics. ## Native Data Connectors - Six built-in connectors ingest enterprise content and permissions directly from: - Amazon S3 - SharePoint - Confluence - Web Crawler - Google Drive - OneDrive - Connectors eliminate the need to build and maintain application-specific ingestion logic. - IAM roles are created automatically, with the option to customize permissions. ## Smart Parsing Smart Parsing automatically chooses ingestion and parsing techniques based on the source and content type. - Connector-specific models preserve important structure: - Web Crawler retains HTML structure, embedded images, and tables. - SharePoint preserves document hierarchies and relationships. - Multimodal processing detects document content types, identifies bounding boxes, and uses foundation models for extraction and captions. - Optimized chunking uses document structure and content type to balance retrieval quality and performance. - Developers can rely on defaults or customize chunking strategies for advanced use cases. ## Agentic Retriever Agentic Retriever is designed for complex questions requiring multi-step reasoning and retrieval. - It decomposes a query into a sequence of subquestions. - It performs multihop retrieval within one knowledge base or across multiple knowledge bases. - It evaluates intermediate results and stops once sufficient relevant passages have been found. - For example, it can connect a team’s cloud budget with an expense policy governing annual prepayments—something a single retrieval step might miss. - Retrieved context can then support more accurate, grounded responses from enterprise agents. ## Getting Started - Create a Managed Knowledge Base from the Amazon Bedrock AgentCore or Amazon Bedrock console. - Choose **Create Managed KB** and select **Unstructured Vector Store KB**. - Select a supported data connector and accept the optimized defaults. - After synchronization, connect the knowledge base to an agent or expose it as a tool for a foundation model. Managed Knowledge Base is best suited to teams that want production-ready enterprise RAG without assembling and operating every component themselves, while retaining customization options for specialized accuracy or governance requirements.

Read original(opens in new tab)
AI AgentsGenerative AIAmazon BedrockRAG+2
aws3 min readCurated summary

Announcing Web Search on Amazon Bedrock AgentCore: Ground your AI agents in current, accurate web knowledge | Amazon Web Services

Amazon Bedrock AgentCore Web Search is now generally available, giving AI agents access to current, cited web information without sending prompts or queries outside a customer’s AWS environment. Built into AgentCore Gateway through the Model Context Protocol (MCP), it combines Amazon’s web index with structured knowledge graph data to provide relevant snippets, URLs, titles, dates, and verified facts. The service lets developers ground agent responses in up-to-date information without building or managing search infrastructure themselves. ## How Web Search Works - Agents submit natural-language queries through an AgentCore Gateway. - The tool returns: - Relevant web snippets - Source URLs - Page titles - Publication dates - Results are powered by: - Amazon’s web search index - Amazon Knowledge Graph data - The combination of web results and structured facts is intended to improve relevance and accuracy over conventional search alone. - Retrieved information can support both grounded responses and follow-up agent actions. ## Secure, Managed Agent Integration - Web Search is a fully managed connector target for Bedrock AgentCore Gateway. - Customer prompts and retrieval queries remain within the AWS environment rather than being sent to external search API providers. - Developers avoid implementing search integrations and operating related infrastructure. - The service supports enterprise governance requirements and secured data workflows. ## Getting Started - Create or open a Bedrock AgentCore Gateway in the AWS console. - Select: - **MCP** as the target protocol - **Connectors** as the target type - **Web Search** as the preconfigured target - After the Gateway URL is created, interact with the tool using: - API calls - AWS CLI - MCP Python SDK - Strands MCP Client - MCP Inspector - MCP Inspector can be used to connect to the Gateway, enter a query, and run the Web Search tool for testing and debugging. - Web Search can also be added to an existing Gateway. ## Early Customer Use Cases - **Benchling** uses Web Search to combine institutional scientific data with published literature, helping researchers generate more complete answers and hypotheses in a governed environment. - **Gen Digital** uses the tool in Norton Revamp to create current online reputation content based on real-world developments. - Customers highlighted the value of current information, AWS-native security, and keeping search queries within their trusted environment. ## Availability and Pricing - Web Search is generally available in **US East (N. Virginia)**. - It is offered at no additional cost initially. - Customers pay applicable Gateway data transfer charges. - New AWS customers may receive up to $200 in Free Tier credits. Developers can try Web Search through the Amazon Bedrock AgentCore console and consult the Gateway documentation for implementation details.

Read original(opens in new tab)
AI AgentsModel Context ProtocolAmazon Bedrock AgentcoreKnowledge Graph+2
line4 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
aws3 min readCurated summary

Amazon S3 annotations: attach rich, queryable context directly to your objects | Amazon Web Services

Amazon S3 annotations let organizations attach rich, mutable context directly to objects without rewriting the underlying data. Each object can have up to 1,000 named annotations, with a combined limit of 1 GB, in formats such as JSON, XML, YAML, or plain text. The annotations move with objects during copying and replication, can be queried through S3 Metadata tables, and are intended to support large-scale analytics and AI-driven workflows. ## Richer Metadata at Object Scale - Annotations address limitations of existing S3 metadata features: - System metadata describes properties such as size and storage class. - Object tags support operational tasks but are limited to 10 immutable tags. - User-defined metadata is limited to approximately 2 KB of headers and must be supplied during upload. - Annotations can be modified or deleted independently without rewriting the object. - Each annotation has a unique name and can hold up to 1 MB, with up to 1 GB total per object. - Supported content includes structured formats such as JSON, XML, and YAML, as well as plain text. ## Supporting AI and Industry Workflows - AI-generated transcripts, summaries, classifications, ratings, and technical specifications can remain attached to the relevant data. - Media companies can store transcripts, moderation results, subtitles, licensing information, and media specifications alongside video assets. - Financial institutions can attach investment summaries and sentiment analysis to research documents for autonomous discovery. - Life sciences organizations can add regulatory status, cohort information, and approval chains to clinical-trial data. - Annotations remain available for objects in archival storage classes without restoring the objects or paying retrieval charges. ## Object Lifecycle and Synchronization - Annotations automatically move with objects during copy, replication, and cross-Region transfers. - S3 removes annotations when the associated object is deleted. - This reduces dependence on separate metadata databases or sidecar files and avoids synchronization overhead. - Different teams or enrichment processes can maintain separate annotations on the same object without overwriting one another. ## Working with Annotations - IAM or bucket policies must grant: - `s3:PutObjectAnnotation` - `s3:GetObjectAnnotation` - The main APIs are: - `PutObjectAnnotation` to create or update an annotation - `GetObjectAnnotation` to retrieve one annotation - `ListObjectAnnotations` to view all annotations on an object - `DeleteObjectAnnotation` to remove an annotation - Reusing an annotation name with `PutObjectAnnotation` updates its content. - For multipart uploads, annotations are added after the upload is completed. - The example uses separate `mediainfo` JSON and `ai_summary` text annotations on a video object. ## Querying Through S3 Metadata - When S3 Metadata is enabled, annotations automatically populate managed annotation tables. - These tables can be queried with Amazon Athena and other analytics engines. - The S3 Tables MCP server provides a standardized interface for AI models and agents to query annotation data using natural-language workflows. - This enables discovery across large collections of S3 objects without retrieving the objects themselves. S3 annotations are most useful when object context is large, frequently updated, and needed for cross-object search or AI automation. Organizations should use them to keep business and machine-generated metadata directly associated with the data while using S3 Metadata tables for scalable querying.

Read original(opens in new tab)
AI AgentsAmazon S3JsonAws Cli+3
figma2 min readCurated summary

4 Ways We’re Using Our MCP Server at Figma | Figma Blog

Figma’s MCP server has expanded beyond design-to-code workflows to support Slides, FigJam, Figma Make, and the Figma design agent. The post argues that agents can now create and update production-ready artifacts while preserving team context, design systems, custom fonts, and brand consistency. In practice, humans still provide review and polish, but agents can complete much of the initial content and formatting work. ## Broader MCP capabilities - Agents can create or update: - Figma Slides presentations - FigJam boards - Figma Make prototypes - Canvas designs through the Figma agent - The server supports: - Custom fonts uploaded from a user’s computer - Downloading assets as SVG, PDF, JPG, or PNG through `download_assets` - Reusable MCP skills that encode team decisions and workflows - These capabilities connect external context and coding tools with Figma’s design environment. ## Creating and refreshing Figma Slides decks - Designer advocate Mallory Dean maintains an evergreen deck about Figma’s AI product launches. - She prompted an agent to: - Update the deck with the new Figma agent - Gather information from Slack, Google Drive, Shortcut blog posts, and release notes - Suggest content updates and new slides - The agent used the `use_figma` tool and `/figma-use-slides` skill to modify the existing deck template. - The first 80% of the content work was completed before human review. - Mallory still needed to replace images, edit copy, and approve the final slides. - Uploaded custom fonts allowed the deck to use the correct brand typefaces rather than web-safe substitutes. - Similar workflows can support: - Product kickoff decks - Design explorations - Go-to-market presentations - Sales decks with current product information - The stated benefit is faster production of presentations that remain aligned with a team’s design system and brand. ## Generating FigJam boards from live data - Product manager Prasant Lokinendi frequently prepares feature kickoff workshops. - Building an engaging FigJam board requires collecting company context and formatting the board for each session. - To streamline this process, he created the `/figjam-builder` skill. - Figma describes skills as a way to make agent outputs more consistent and context-aware. - Teams can use community-created skills or submit their own through Figma’s community-resources repository. Figma’s MCP workflows are most useful for accelerating repetitive preparation and production work while leaving humans responsible for review, judgment, and final creative decisions.

Read original(opens in new tab)
AI AgentsDesign SystemsFigjamFigma Make+2
kakao4 min readCurated summary

Automating KakaoTalk Recommendation Metric Analysis with an AI Agent

The post describes Kakao’s use of an AI agent to automate repetitive analysis of KakaoTalk recommendation metrics on an existing Hadoop environment. Rather than building a new platform or granting the model broad permissions, the team documented existing procedures, data definitions, and decision rules in Markdown-based agent skills and context files. The resulting system helps analysts produce draft reports and explore follow-up questions, while humans remain responsible for validating results and making final decisions. ## Repetitive Analysis Is an Ideal Automation Target - Recommendation analysis often begins with simple questions about CTR changes, experiments, or user-group anomalies. - Answering them typically requires: - Connecting to the analysis environment - Finding the right tables - Writing and executing queries - Interpreting results - Repeating the process across dimensions such as age, category, and time - Much of the effort lies in data preparation and extraction rather than interpretation. - The initial goal was for the AI to follow these steps and produce a first-pass analysis without requiring users to handle queries directly. ## Teaching the Agent to Use Hadoop - The team did not build a new analytics platform or add an MCP integration layer. - Existing Hadoop access scripts were sufficient; the missing component was documentation explaining how to use them. - These procedures were packaged as Agent Skills—Markdown files such as `SKILL.md` describing: - How to connect to Hadoop - How to submit queries - How to retrieve and organize results - The `hadoop-butler` plugin bundled these skills for internal use. - The main lesson was that existing infrastructure can often be extended by converting undocumented operational knowledge into instructions an agent can follow. ## Context Documents Improve Analytical Accuracy - Access to data does not guarantee correct analysis. - Context files such as `CLAUDE.md` or `AGENTS.md` documented: - Relevant tables and clusters - Feature definitions, such as `watch_length` and `valid_view` - User and session aggregation rules - Standard metric definitions - This prevented the agent from repeatedly guessing which tables, columns, or aggregation rules to use. - The documentation also captured institutional knowledge that could help new team members, not only AI systems. - Output quality was determined by the quality and precision of the available context. ## AI Produces Drafts; Analysts Continue the Investigation - Natural-language analysis was most useful for recurring tasks such as: - Detecting anomalies - Comparing experiments - Reviewing weekly performance - The agent’s first report helped identify areas for deeper investigation. - Analysts could then ask follow-up questions and refine the analysis conversationally. - AI-generated reports were treated as reviewable drafts, not final conclusions. - Query logic, selected columns, metric definitions, and interpretations still required human verification. ## Plausible but Incorrect Results The agent’s most dangerous errors were not syntax failures; they were queries that executed successfully but produced misleading results. - **Semantic errors** - To count users, the correct field was `user_id`. - The agent once selected the similarly named `session_user_id`, which represented a session-oriented identifier. - The query ran normally, but the resulting user count was wrong. - **Performance errors** - The agent combined several `COUNT(DISTINCT ...)` expressions in one Hive query. - Although valid SQL, this could force processing through a single reducer and make the query extremely slow. - The better approach was to split the calculations by column and run them in parallel. ## Documentation and Regression Testing - Explicit rules were added to context files and skills, including: - Which identifier to use for user-level aggregation - Wrapping column names in backticks - Splitting multiple `COUNT(DISTINCT)` operations into separate queries - Because natural-language instructions can break other behaviors when modified, the team tested them like software. - An MLflow-based end-to-end evaluation pipeline: - Defines expected behavior for each skill - Runs the agent headlessly with `claude -p` - Uses an LLM judge to evaluate tool-call order, execution traces, and final output - Runs regression scenarios before deployment - This made it possible to catch unintended behavior changes before release. The recommended architecture combines four elements: an AI model, precise domain context, an existing execution environment such as Hadoop, and a verification loop. Organizations should first document their established procedures and analytical definitions, then connect the agent to existing tools and test its behavior systematically.

Read original(opens in new tab)
AI AgentsSqlContext EngineeringHadoop+4