A new tool from Google Cloud aims to improve the accuracy of AI agents querying databases in multi-agent systems or applications.

QueryData, which translates natural language into database queries with what the company claims is “near 100% accuracy,” is being pitched as an alternative to direct generation of queries by large language models (LLMs), which Google says can introduce inaccuracies due to their limited understanding of database schemas and their probabilistic reasoning.

However, to create that necessary understanding, enterprise teams using QueryData first need to define what Google describes as “context” describing how data should be accessed and queried, which involves encoding details about database schemas, including descriptions of tables, relationships, and business meaning, along with deterministic instructions that guide how queries are generated or executed.

Once the context and the guidelines are configured, teams can use the Context Engineering Assistant, a dedicated agent in Gemini CLI, to iteratively review the accuracy of queries against the Evalbench framework until they’re satisfied with the results.

After that, QueryData can be integrated into agent-driven workflows, where it acts as the execution layer between user requests and underlying databases.

It can be used within Google Cloud’s own data agents, currently available in BigQuery, or invoked via APIs by enterprises building custom agents and multi-agent systems. It currently supports AlloyDB, CloudSQL for MySQL, CloudSQL for PostgreSQL, and Spanner.

In custom setups, the agents handle reasoning and orchestration, while QueryData is responsible for generating, validating, and executing queries against data sources, returning results that can be used in downstream actions or decision-making, Google explained in a blog post.

Creates new workload category

The new tool, according to Pareekh Jain, principal analyst at Pareekh Consulting, marks a shift from tool-based AI to outcome-bound agents with built-in guardrails, which should help enterprises move multi-agentic systems and applications into production, and enable “decision-grade use cases” across finance, operations, and supply chain departments.

However, he cautioned, though QueryData reduces the need for prompt engineering for developers and improves reliability at runtime, it shifts the burden to upfront design and ongoing maintenance.

“It requires explicit schema understanding, deterministic instructions per data source, and ongoing maintenance as schemas evolve,” he pointed out. “This effectively creates a new workload category of data access engineering for agents.”

He said, “the tradeoff is clear. Without QueryData, systems are faster to build but unreliable in production, and with it, they are slower to build but viable at scale.”

This tradeoff, according to Jain, will ultimately influence enterprise usage patterns, with adoption likely to be strongest in regulated and mission-critical environments, while remaining slower in lightweight or experimental use cases.

Targets data layer as rivals bet on connectors, copilots

Further, Jain noted that the new tool also signals a broader strategic play by Google Cloud.

 “QueryData shows Google is trying to create a standard way for AI agents to safely access and use data. While OpenAI focuses on APIs, AWS on connectors, and Microsoft on apps like Copilot, Google is focusing on the data layer itself, on how agents actually talk to databases,” Jain said.

“This approach has strengths, especially with tight integration into Google BigQuery and Google’s data expertise. But it also has challenges, as it needs more upfront setup and is less flexible across platforms. Microsoft, in this case, seems to have an edge, because its tools are already built into everyday apps that people use,” he noted.

The risk for Google, Jain added, is that simpler approaches from AWS or Microsoft could confine QueryData to advanced use cases instead of making it a mainstream standard.

QueryData is currently in preview.

A critical pre-authentication remote code execution vulnerability in Marimo, an open-source Python notebook platform owned by AI cloud company CoreWeave, was exploited in the wild less than 10 hours after its public disclosure, according to the Sysdig Threat Research Team.

The vulnerability, tracked as CVE-2026-39987 with a severity score of 9.3 out of 10, affects all Marimo versions before 0.23.0.

It requires no login, no stolen credentials, and no complex exploit. An attacker only needs to send a single connection request to a specific endpoint on an exposed Marimo server to gain complete control of the system, the Sysdig team wrote in a blog post.

The flaw allows an unauthenticated attacker to obtain a full interactive shell and execute arbitrary system commands on any exposed Marimo instance through a single connection, with no credentials required, the post said.

“Marimo has a Pre-Auth RCE vulnerability,” the Marimo team wrote in its GitHub security advisory. “The terminal WebSocket endpoint /terminal/ws lacks authentication validation, allowing an unauthenticated attacker to obtain a full PTY shell and execute arbitrary system commands.”

Marimo is a Python-based reactive notebook with roughly 20,000 stars on GitHub and was acquired by CoreWeave in October 2025.

How the flaw works

Marimo’s server includes a built-in terminal feature that lets users run commands directly from the browser. That terminal was accessible over the network without any authentication check, while other parts of the same server correctly required users to log in before connecting, the post said.

“The terminal endpoint skips this check entirely, accepting connections from any unauthenticated user and granting a full interactive shell running with the privileges of the Marimo process,” the post added.

In practical terms, anyone who could reach the server over the internet could walk straight into a live command shell, often with administrator-level access, without ever entering a password, the team at Sysdig said.

Credentials stolen in under three minutes

To track real-world exploitation, deployed honeypot servers running vulnerable Marimo instances across multiple cloud providers and observed the first exploitation attempt within 9 hours and 41 minutes of disclosure. No ready-made exploit tool existed at the time. The attacker had built one using only the advisory description, Sysdig researchers wrote.

The attacker worked in stages across four sessions. A brief first session confirmed the vulnerability was exploitable. A second session involved manually browsing the server’s file system. By the third session, the attacker had located and read an environment file containing AWS access keys and other application credentials. The entire operation took under three minutes, the post said.

“This is a complete credential theft operation executed in under 3 minutes,” the Sysdig team wrote.

The attacker then returned over an hour later to re-check the same files. The behavior was consistent with a human operator working through a list of targets rather than an automated scanner, the post said.

Part of a widening pattern

The pace of exploitation aligns with a trend seen across AI and open-source tooling. A critical flaw in Langflow was weaponized within 20 hours of disclosure earlier this year, also tracked by Sysdig. The Marimo case cut that window roughly in half, with no public exploit code in circulation at the time.

“Niche or less popular software is not safer software,” the Sysdig post said. Any internet-facing application with a published critical advisory is a target within hours of disclosure, regardless of its install base, it added.

The Marimo case had no CVE number assigned at the time of the first attack, meaning organizations dependent on CVE-based scanning would not have flagged the advisory at all, Sysdig noted.

The flaw also fits a pattern of critical RCE vulnerabilities in AI-adjacent developer tools — including MLflow, n8n, and Langflow — in which code-execution features built for convenience become dangerous when exposed to the internet without consistent authentication controls.

What organizations should do

Marimo released a patched version, 0.23.0, which closes the authentication gap in the terminal endpoint. Organizations running any earlier version should update immediately, Sysdig said.

Teams that cannot update right away should block external access to Marimo servers using firewall rules or place them behind an authenticated proxy, the post said. Any instance that has been publicly reachable should be treated as potentially compromised.

“Credentials stored on those servers, including cloud access keys and API tokens, should be rotated as a precaution,” Sysdig advised.

CoreWeave did not immediately respond to a request for comment.

The article originally appeared in CSO.

This week in New York, my Oracle team ran workshops for enterprise developers on building retrieval-augmented generation and agentic applications. Interest was so strong that we quickly had to figure out how to double the room’s capacity (much to the fire marshal’s chagrin). Interest in AI was clearly off the charts. But AI fluency was not. It was a different vibe (and audience) from what we’ve seen in a course we built with DeepLearning.ai, which attracts a more advanced audience ready to build memory-aware agents.

I recently argued that enterprise AI is arriving unevenly across companies and even across teams within the same company. But after watching developers plow through these different workshops, I believe this uneven adoption points to something even more telling: uneven engineering capability.

Put differently, the real divide in enterprise AI isn’t just between companies moving fast and companies moving slow. It’s between teams treating AI as a prompt-driven demo and teams learning, often painfully, that production AI is mostly a data and software engineering problem. Enterprise AI isn’t really in the agent era yet. We’re in the prerequisite era.

Building the building blocks

What do I mean by “engineering capability”? I definitely don’t mean model access. Most everyone has that—or soon will. No, I mean the practical disciplines that turn a model into a system: data modeling, retrieval, evaluation, permissions, observability, and memory. You know, the unsexy, “boring” stuff that makes enterprise projects, particularly enterprise AI projects, succeed.

This informed how my team built our workshops. We didn’t start with “here’s how to build an autonomous employee.” We started with the AI data layer: heterogeneous data, multiple representations, embeddings, vector indexes, hybrid retrieval, and the trade-offs among different data types (relational, document, etc.). In other words, we started with the stuff most AI marketing tries to skip. Much of the AI world seems to think AI starts with a prompt when it actually begins with things like multimodel schema design, vector generation, indexing, and hybrid retrieval.

That matters because enterprise data isn’t tidy. It lives in tables, PDFs, tickets, dashboards, row-level policies, and 20 years of organizational improvisation. If you don’t know how to model that mess for retrieval, you won’t have enterprise AI. You’ll simply achieve a polished autocomplete system. As I’ve pointed out, the hard part isn’t getting a model to sound smart. It’s getting it to work inside the weird, company-specific reality where actual decisions are made.

For example, the industry talks about retrieval-augmented generation as if it were a feature. It’s not. It’s an engineering discipline. Chunking strategy, metadata design, retrieval quality, context packing, precision and recall, correctness and relevance: those aren’t implementation details to clean up later. They’re the thing. The whole point. If your retriever is weak, your model will confidently elaborate on bad context. If your chunking is sloppy, your answer quality degrades before the model ever starts reasoning. If your metadata is thin, filtering breaks. And if you have no evaluation loop, you won’t know any of this until a user tells you the system is wrong.

This is also where permissions and observability are so critical. In a demo, nobody asks the annoying questions like where an answer came from, or what the agent was authorized to touch. But in real-world production, those questions are the whole game. An enterprise agent with vague tool access isn’t sophisticated. It’s a massive security problem. In short, using AI tools is not the same thing as knowing how to build AI systems. Plenty of teams can prompt, but far fewer can measure retrieval quality, debug context assembly, define tool boundaries, or create feedback loops that improve the system.

Catching up with the enterprise

The contrast with the recent DeepLearning.AI short course on agent memory is useful here. That course is explicitly aimed at developers who want to go beyond single-session interactions, and it assumes familiarity with Python and basic concepts of large language models. In other words, that audience is already up the curve, talking about memory-aware agents as a next step. By contrast, my NYC enterprise-heavy audience was generally earlier in the journey. That’s not a criticism of enterprise developers. It’s a clue. Much of the “AI gap” in enterprise isn’t about willingness. It’s about how much explicit learning the teams still need before the tools become muscle memory.

That, in turn, is why I keep coming back to a much older argument I’ve made about MLops. Back then, I wrote that machine learning gets hard the moment it leaves the notebook and enters the world of tools, integration, and operations. That was true in 2022, and it’s even more true now. Agentic AI has not repealed the basic law of enterprise software. It has simply added more moving parts and a bigger blast radius. The demo may be easier than ever, but the system is emphatically not.

I’d also caution that you probably shouldn’t tell enterprises they’re “behind” because they haven’t yet embraced multi-agent architectures or whatever the current fashion demands. In many cases, they’re learning exactly what they need to know: how to structure data for retrieval, how to evaluate outputs, how to constrain tools, how to inspect failures, and how to manage state. That may not make for sexy conference talks. It does, however, look suspiciously like how real platforms get built. As I’ve noted, most teams don’t need more architectural cleverness but do need much more engineering discipline.

So yes, uneven adoption is still a real thing. But I think the deeper, more useful story is this: Uneven adoption is mostly the surface expression of uneven AI engineering literacy. The real winners in AI will be those that teach their teams how to ground models in business data, evaluate what those models return, constrain what agents can do, and remember only what matters. That is, the winners will be those that know how to make AI boring.

Right now, boring is still very unevenly distributed.

Artificial intelligence has moved from the research lab into the boardroom, the data center and virtually every business function in between. Nearly 80 percent of organizations now use AI in at least one core business process, according to McKinsey, yet widespread adoption has surfaced a persistent problem: a deep shortage of professionals who can translate AI tools into measurable business results. That gap is driving extraordinary interest in AI certifications, and for good reason. The question most IT professionals are asking is not whether AI skills matter, but which credentials deliver the greatest return on investment.

The AI job market has responded accordingly. AI and machine learning hiring grew 88 percent year-over-year in 2025, according to Ravio’s 2026 Compensation Trends report, while administrative role hiring simultaneously dropped 35 percent. This is not a niche trend. Dice.com reports that approximately 36 percent of tech job postings now require AI skills, with major consulting firms such as Deloitte, Accenture, PwC and KPMG among the top 25 AI hirers in the United States. The window for early movers is open, but it will not remain so indefinitely.

The most valuable AI certifications for business

Not all AI credentials carry equal weight with employers. The certifications that consistently appear in job postings, command hiring manager attention and translate into measurable salary gains share a few common characteristics: they come from recognized vendors or institutions, require hands-on project work and address real-world business problems rather than theoretical exercises alone. The following credentials rank among the most valuable for professionals entering or advancing within AI-focused roles.

Google Professional Machine Learning Engineer

This certification is widely considered one of the highest-value credentials available for professionals working with cloud-based machine learning systems. At a $200 exam fee, it requires three to five months of focused preparation for most candidates, though experienced engineers sometimes complete preparation in under 30 days. Holders report average salaries near $130,318, and professionals already working in data or engineering roles frequently cite a salary bump of approximately 25 percent following certification, according to community data compiled by Nucamp. Google and AWS certifications appeared in 40 percent more job postings than competing credentials, with demand increasing 21 percent year-over-year, according to an analysis of more than 15,000 job postings from Q4 2025 through Q1 2026 published by Skillupgradehub.

AWS Machine Learning Specialty

Amazon Web Services offers one of the most employer-recognized AI credentials for professionals working in enterprise environments. The $300 exam assumes substantial hands-on experience with Amazon SageMaker and the broader AWS data stack, and most candidates invest four to six months in preparation. Hiring surveys consistently associate this certification with roughly a 20 percent salary boost in existing data and engineering roles, particularly within organizations that have standardized on AWS infrastructure, according to Nucamp’s certification ROI analysis.

Microsoft Certified: Azure AI Engineer Associate (AI-102)

For professionals operating within Microsoft-centric enterprises, the Azure AI Engineer Associate certification validates the ability to build and deploy AI solutions using Azure Cognitive Services, Azure Machine Learning and related tools. The exam costs approximately $165, and study typically requires three to six months. DigitalOcean’s 2025 analysis of top AI credentials lists this certification among the most recognized across Microsoft ecosystem environments, which represent a large share of the enterprise market.

IBM AI Developer Professional Certificate

IBM’s professional certificate program, available through Coursera for approximately $49 per month, functions as a comprehensive entry point for professionals transitioning into AI roles. The program covers machine learning, prompt engineering, data analysis, neural networks, Python libraries and deploying large language models. IBM refreshed the generative AI content in March 2025, keeping the curriculum current with production-grade techniques. For career changers, the ROI can be dramatic. Skillupgradehub’s 2026 analysis documents cases in which professionals moved from $52,000 salaries to $78,000 AI engineering positions following completion of this program.

PMI AI+ Certification

Launched in 2025 after PMI acquired Cognilytica, the PMI AI+ is the first major project management credential specifically designed for AI initiatives. It targets project managers, program managers, product owners and scrum masters who lead or support AI deployments. A distinctive feature is that preparation earns candidates 21 PDUs toward other PMI certifications, covering more than a third of PMP renewal requirements. Unlike most credentials in this space, it currently carries no expiration date, eliminating ongoing renewal fees. For business-side leaders who need credibility when overseeing AI programs without building models themselves, this certification fills a critical gap, according to Dataquest’s 2026 certification guide.

NVIDIA Deep Learning Institute Certifications

NVIDIA’s credential portfolio addresses advanced technical roles focused on computer vision, GPU optimization and deep learning model development. Costs vary by course, ranging from $2,500 to $4,700 per course, with a $325 application fee and a requirement to complete 16 or more days of coursework within 36 months. DigitalOcean lists NVIDIA credentials among the most recognized for highly specialized technical positions where deep learning and GPU-accelerated computing are central to the role.

The salary impact: What the data shows

The financial case for AI certification is compelling, though professionals should approach salary estimates with realistic expectations. The gains are real, but they vary significantly based on prior experience, role type, geographic market and the specific certification earned.

According to Payscale data cited by Dumpsgate, the average salary of a certified AI professional in the United States is approximately $144,000. Entry-level roles typically begin around $80,000, while experienced practitioners can reach $162,000 or more. Glassdoor data, reported by Coursera in February 2026, shows median total base pay ranging from $99,578 for AI researchers to $134,188 for AI engineers.

Certified AI professionals earn between 23 and 47 percent more than their non-certified peers in 2026, according to salary analysis by Skillupgradehub drawn from more than 10,000 job postings. PassItExams research documents that AI-certified professionals command salary premiums reaching 47 percent above non-certified peers in some roles. However, Ravio’s 2026 Compensation Trends report provides a more moderate benchmark from actual payroll data: AI and ML roles command a 12 percent salary premium at the Professional/Individual Contributor level and a 3 percent premium at the Management level compared to non-AI roles. The smaller premium for managers reflects employer emphasis on hands-on contributors who can directly integrate AI into workflows.

For specific certifications, estimated salary impacts include the following ranges. The Google Professional Machine Learning Engineer is associated with a target salary of approximately $130,318 and a 25 percent bump for data and engineering professionals. The AWS Machine Learning Specialty carries a target salary range of roughly $120,000 to $155,000 and a 20 percent boost for existing practitioners. Entry-level credentials such as the IBM AI Developer program can produce career transitions that lift salaries from the $65,000 to $75,000 range into the $90,000 to $115,000 range for junior AI engineering roles. Data engineers who add AI capabilities through specialized credentials command 25 to 35 percent salary premiums over traditional data engineering peers, according to PassItExams.

Indeed data indicates that generative AI skills specifically can boost salaries by as much as 47 percent, cited by USAII, reflecting employer urgency around LLM deployment skills that remain scarce in the market.

The pros: Why AI certifications deliver real value

The business case for AI certification extends well beyond salary projections. Pearson VUE’s 2025 Value of IT Certification Candidate Report, based on survey responses from nearly 24,000 IT professionals globally, documented organizational impacts that go directly to the bottom line.

• Quality improvement: 79 percent of certified respondents reported a better quality of work output following certification.
• Innovation: 76 percent reported an increased ability to innovate and enhance work processes and outcomes.
• Productivity: 70 percent reported greater on-the-job productivity.
• Career advancement: 82 percent of respondents gained concrete career benefits, including promotions, salary increases and expanded responsibilities.
• Lifelong learning signal: 84 percent of certified professionals planned to pursue another IT certification within 12 months.

For hiring managers, certifications from recognized vendors and institutions function as trusted quality signals in a market flooded with self-reported AI experience. LinkedIn research highlights that candidates listing well-known certifications see higher recruiter engagement compared to those without them, according to DigitalDefynd’s 2026 analysis of AI certification value.

Certifications also address a structural problem that employers cite repeatedly. While 79 percent of organizations now use AI, DigitalOcean’s 2025 Currents report found that 41 percent struggle to integrate AI into existing workflows, 35 percent face challenges in model selection and 30 percent navigate data privacy minefields. Certified professionals are specifically trained to solve these problems, which is why demand for them consistently outpaces supply.

The cons: Limitations and honest cautions

AI certifications are valuable tools, but they are not magic credentials. Professionals and employers alike should understand their limitations before making significant investments.

• Time commitment is substantial: Comprehensive AI certification programs frequently require 10 to 15 hours of study per week over several months. For full-time professionals, this means evenings and weekends dedicated to coursework. Coursera’s Global Skills Report and Statista both rank time constraints among the top three barriers to professional upskilling.
• Cost can be prohibitive: Exam fees range from approximately $100 for entry-level credentials to $8,780 for multi-day intensive programs. Premium programs through institutions such as MIT Sloan can reach $2,500 to $4,700 per course. Not all employers reimburse these costs upfront, creating a financial barrier for some professionals.
• No universal accreditation standard: Unlike regulated professions such as law or medicine, AI certifications remain largely market-driven. Two programs with similar titles may differ dramatically in academic depth and practical rigor. This creates information asymmetry that forces learners to do careful due diligence before committing time and money.
• Experience still matters most: Employer surveys consistently show that hiring decisions prioritize experience, problem-solving ability and demonstrated business impact over certifications alone, according to LinkedIn and McKinsey data cited by DigitalDefynd. One hiring manager quoted by The Interview Guys put it plainly: ‘We are desperate for people who actually understand RAG architecture, not just people who have used it through an API.’
• Rapid obsolescence risk: AI technology evolves faster than most certification bodies can update their curricula. A credential earned in 2023 may reflect concepts that have already been superseded by newer techniques. Professionals should prioritize programs with documented update cycles and verify content currency before enrolling.
• Theory-practice gap: Programs that lack hands-on labs, capstone projects or real-world datasets can leave learners with theoretical knowledge that does not transfer to production environments. Without applied components, certification may signal effort without demonstrating actual capability.

Choosing the right credential for your role

The best AI certification depends on where a professional is starting and where they want to go. DigitalOcean outlines a practical decision framework: consider your technical foundation, your time and financial investment capacity, the industry recognition of the credential and your specific career trajectory.

For hands-on technical roles such as machine learning engineer, data scientist or AI engineer, vendor certifications from Google, AWS, Microsoft or NVIDIA carry the greatest market weight. For business leaders, product managers and project managers who need to speak credibly about AI without building models, credentials such as the PMI AI+ or IBM’s business-focused programs provide a more appropriate entry point. Andrew Ng’s AI for Everyone, offered through Coursera, remains one of the most effective programs for non-technical professionals who need AI literacy without programming requirements, completing the program in under ten hours.

For cybersecurity professionals specifically, the AI security credential landscape is expanding rapidly. AI security roles are paying between $180,000 and $280,000 in 2026, according to Practical DevSecOps, driven by demand for professionals who can secure LLM deployments, prevent prompt injection attacks and lock down AI pipelines. Specialized credentials such as the Certified AI Security Professional carry a salary premium of 15 to 20 percent over peers holding only generalist security certifications.

AI certification learning path: Beginner to expert

Here is a learning path you can explore, with each tier showing the certifications, typical timeframe and cost estimates. The path is built around four tiers that map to experience level rather than time in tech, so someone coming from a non-technical background can still progress through it systematically.

Tier 1 is about AI literacy and foundational awareness. Andrew Ng’s AI for Everyone is the fastest on-ramp for business professionals, while the IBM AI Developer and cloud foundational certs (AWS AI Practitioner, Azure AI-900) begin building hands-on vocabulary. These do not require prior coding experience.

Paul Frenken

Tier 2 moves into applied skills, where professionals start building and deploying real solutions. The Microsoft AI-102 and TensorFlow Developer credentials are natural follow-ons for cloud engineers and developers. The PMI AI+ is the right branch for project managers and business leaders who want to lead AI initiatives rather than build them.

Paul Frenken

Tier 3 is where serious salary premiums kick in. The Google Professional ML Engineer and AWS ML Specialty are the two most employer-recognized advanced credentials and are tied to documented 20–25% salary bumps for professionals already working in data and engineering roles.

Paul Frenken

Tier 4 represents specialization tracks rather than a single next step. NVIDIA’s DLI targets computer vision and GPU-intensive work, the CAISP is the path for cybersecurity professionals pivoting into AI security and Stanford’s graduate certificate is the academic credentialing route for those targeting research leadership or senior advisory roles.

Paul Frenken

Note: The salary figures in the tables above are based on 2025–2026 market data from Glassdoor, Indeed, Payscale, PassItExams and Ravio. Individual outcomes vary by location, experience and employer. Costs reflect exam fees unless otherwise noted.

The bottom line

AI certifications represent one of the highest-return professional investments available to IT professionals in 2026. The market is generating enormous demand, the skills gap remains wide and salary data consistently confirms that certified professionals out-earn their non-certified counterparts. For entry-level professionals, the right credential can produce a $20,000 to $30,000 salary lift within the first year. For experienced practitioners adding AI specialization to an existing technical foundation, gains of 20 to 47 percent above current compensation are well-documented in the literature.

The cautions are real. Certification alone will not substitute for demonstrated experience, hands-on project work and business acumen. The best candidates combine credentials with portfolios, practical skills and the ability to translate AI capabilities into organizational outcomes. For professionals willing to make the investment, the question is not whether AI certification is worth it. The data answers that plainly. The real question is which credential best positions you for the role you are targeting, and whether you are prepared to back it up with the practical skills that employers are urgently seeking.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

The Google Agent Development Kit (ADK) is a flexible and modular open-source framework for developing and deploying AI agents. It is optimized for Gemini and the Google ecosystem, but the ADK is model-agnostic, deployment-agnostic, and built for compatibility with other frameworks. The ADK was designed to make agent development feel more like software development, to help developers create, deploy, and orchestrate agentic architectures.

Google recommends deploying your ADK agent to its own Vertex AI Agent Engine Runtime, which is a fully managed Google Cloud service designed for deploying, managing, and scaling AI agents built with frameworks such as ADK. Alternatively, you can containerize your agent and deploy it essentially anywhere, including Google Cloud Run.

Direct competitors to the ADK include Amazon Bedrock AgentCore, Azure AI Foundry Agents, and Databricks Agent Bricks. Additional competitors include the OpenAI Agents SDK, LangChain/LangGraph, CrewAI, and SmythOS. I reviewed Amazon Bedrock AgentCore in March.

ADKs for Python, Go, Java, and TypeScript

There are currently four Google ADK languages: Python, Go, Java, and TypeScript. In addition, there is an ADK for Web that is a developer UI, which we will discuss later.

The Python ADK seems to be the oldest of the four, based on its commit history, and has the most samples. It features a rich tool ecosystem, code-first development, agent config (which lets you build an ADK workflow without writing code), a tool confirmation flow (HITL), modular multi-agent systems, and near-universal deployment. The newest features include custom service registration, the ability to rewind a session to before a previous invocation, and a class that supports executing agent-generated code using the Vertex AI Code Execution Sandbox API. The ADK supports the A2A protocol for remote agent-to-agent communication.

You can install the latest stable version of the Python ADK using pip (or pip3, depending on your Python installation):

pip install google-adk

There are quite a few dependencies. You can also install the ADK with uv, as demonstrated in some of the samples. Using a virtual environment is recommended.

The Go ADK offers essentially the same features as the Python ADK, plus idiomatic Go. You can add ADK Go to your project, by running: 

go get google.golang.org/adk

The Java ADK boasts the same features, development UI, and interface as the Python ADK. The installation requires adding google-adk to your Maven dependencies.

The TypeScript ADK has the same features, development UI, and interface as the Python ADK. To install it, you can run:

npm install @google/adk

ADK Quickstarts

There are at least five quick starts for the ADK. One is for Python and the Vertex AI SDK. The other four, as you might expect, are for Python, Go, Java, and TypeScript. Those four follow the same pattern.  Basically, you install the ADK, use the ADK to create an agent project, add a little code to the agent project, set your Gemini API key, and run your agent both as a CLI and using a web interface.

Foundry

Foundry

ADK Web: Local development environment

ADK Web is the built-in dev UI that comes with the ADK for easier development and debugging. The prerequisites are npm, Node.js, Angular CLI, google-adk (Python), and google-adk (Java). To install, you clone the ADK Web repo, install its node dependencies, then run both the ADK Web and ADK API servers, in separate terminals.

If all is well, the UI will be at localhost:4200. It shows you events, traces, artifacts, and evaluations, and offers you an agent builder and assistant.

Foundry

Core ADK concepts and capabilities

ADK agents can either use language models or be deterministic workflow agents or custom agents, which allow you to define arbitrary orchestration logic. Agents can call tools to interact with external APIs, search, or run code. They can also load and save artifacts.

You can provide callbacks to run at specific points in the agent’s process. The ADK handles the context of a session, its events, and the agent’s short-term state, much like a web server supports a web application. The ADK also supports long-term memory across multiple sessions.

Planning is a way to break down goals before trying to accomplish them. Runners manage the execution flow and orchestrate agent interactions.

The ADK supports applications composed of multiple, specialized agents that can interact. 

The ADK includes a command-line interface (CLI) and a developer UI for running agents, inspecting execution steps (events, state changes), debugging interactions, and visualizing agent definitions.

The framework includes tools to create multi-turn evaluation data sets and run evaluations. It also strives to be open and extensible. As I mentioned earlier, the ADK is optimized for Gemini and the Google ecosystem, but is nevertheless model-agnostic, deployment-agnostic, and compatible with other frameworks.

Agent skills

Agent skills are a simple, open format for giving agents new capabilities and expertise. They are folders of instructions, scripts, and resources that agents can discover and use. Skills provide the context that agents need to do real work. Skills can enable domain expertise, new capabilities, repeatable workflows, and interoperability.

The agent skills format was originally developed by Anthropic and released as an open standard. It is supported by many AI development tools in addition to the ADK, such as Visual Studio Code, GitHub, Frontier LLMs, agentic coding tools, and AI-capable databases such as Snowflake and Databricks.

Agent runtimes

ADK offers several ways to run your agents for development and test. These include:

1. adk web, which launches a browser-based interface
2. adk run, which lets you interact with your agents in the terminal, and
3. adk api_server, which exposes your agents through a RESTful API.

ADK samples and community repos

The ADK Samples Repo contains ADK sample agents for the four supported languages, although Python agents dominate. The ADK Python community repo is home to a growing ecosystem of community-contributed tools, third-party service integrations, and deployment scripts that extend the core capabilities of the ADK.

Examining the customer service sample

The ADK Samples Customer Service example is a conversational, multimodal Python agent for a fictional big-box retailer specializing in home improvement, gardening, and related supplies. I chose it as the sample closest to the customer service agent I tried for my Amazon Bedrock AgentCore review. The agent’s flow diagram is below.

The customer service agent uses mocks for its tools, so not everything works exactly as you’d expect. To implement this agent with actual back-end integration, you will need to edit customer_service/tools/tools.py, which is where all the agent tools are currently mocked with wired-in responses, and replace the mocks with API calls.

customer_service/tools/agent.py imports those tools and lists them all in its root_agent/tools array, part of the Agent constructor. The tools/config.py logic defines this agent as deployable to Vertex AI in the us-central region, and deployment/deploy.py defines a Vertex AI bucket and agent wheel file.

Comparing this sample to the Amazon Bedrock AgentCore sample, I find the ADK sample more capable in general. The one feature of AgentCore that the ADK seems to lack is policies external to the agent that are implemented in the framework; in the ADK example, a limit on discounts is implemented in Python code, which seems like a more reasonable approach to me, and probably to most programmers.

Foundry

The bottom line

The Google Agent Development Kit is a capable and mostly complete framework for developing agents. It can build workflow agents and custom agents in addition to LLM agents, supports multi-agent architectures, and allows you to extend your agent capabilities with AI models, artifacts, tools, integrations, plug-ins, skills, and callbacks. An ADK agent can act as a Model Context Protocol (MCP) client, and you can expose ADK tools via an MCP server. The downside of all those capabilities would be the time and effort needed to learn the framework.

Overall, I like the Google ADK, and its architecture makes more sense to me than Amazon Bedrock AgentCore. The ADK also offers more programming language options than AgentCore, as well as better development tooling.

For my review, I only went deep on the Python ADK and its customer service example. If there are deficiencies in the other three language ADKs other than a paucity of examples, I wouldn’t know about them.

Cost

The Google ADK framework is free open source; Vertex AI Agent Engine pricing is primarily usage-based.

Platform

Development requires Python, TypeScript, Go, or Java environments. You can deploy to the Vertex AI Agent Engine, to Google Cloud Run, to Google Kubernetes Engine, or to any other container or Kubernetes environment.

Pros

1. Capable and mostly complete framework for developing agents
2. Supports Python, TypeScript, Go, and Java
3. Optimized for Gemini models, but model-agnostic
4. Many Python examples

Cons

1. Few TypeScript, Go, or Java examples
2. Extensive framework has a significant learning curve

The Swift for Visual Studio Code extension, which brings language support for Apple’s Swift programming language to Microsoft’s Visual Studio Code editor, now is available on the Open VSX Registy, an Eclipse Foundation-hosted open source registry for VS Code extensions.

The Swift for Visual Studio Code extension adds first-class language support for projects built with Swift Package Manager, enabling seamless cross-platform development on macOS, Linux, and Windows, according to Apple. The extension brings Swift language support including code completion, refactoring, full debugging support, a test explorer, as well as DocC support to both VS Code and a broad ecosystem of compatible editors and allows agentic IDEs like Cursor and Antigravity to automatically install Swift. No manual download is required.

Capabilities of the Swift for VS Code extension include:

• Jump to definition, peek definition, find all references, and symbol search
• Error annotations and fix suggestions
• Automatic generation of launch configurations for debugging with LLDB DAP
• Automatic task creation
• A Project Panel to quickly run actions and view dependencies
• Test Explorer view

Most features of the Swift for VS Code extension, however, only work with projects that build with Swift Package Manager. These projects will have a Package.swift file in their root folder. Support for Xcode projects (.xcodeproj) is limited. The Swift extension for VS Code also is available on the Visual Studio Marketplace.

AWS is expanding its Amazon Bedrock AgentCore portfolio with a new managed service, Agent Registry, designed to help enterprises catalog, manage, and govern their growing fleets of AI agents and their associated tools.

The service provides a unified directory of agents, capturing metadata such as capabilities, identities, and integrations, and is designed to support agents built with different models and frameworks, AWS wrote in the offering’s documentation.

The move addresses a growing structural gap around AI agent sprawl in enterprises that has emerged as they try to move pilot cases to production, analysts say.

“Agent Sprawl is an emerging structural problem. What we see consistently across enterprises is that agents proliferate much faster than traditional applications because they are easier to build. As a result, ownership becomes ambiguous as they move into production while increasing costs, risks, and duplication until finance, security, or related incidents force attention,” said Gaurav Dewan, research director at Avasant.

With the addition of a centralized Agent Registry-like offering, discovery, orchestration, governance, lifecycle management, and standardization of agents become easier, Dewan added, noting that in effect, a registry transforms agents from isolated artifacts into managed, composable enterprise assets.

A control plane play with trade-offs?

The service comes with what analysts describe as a “strategic” limitation: While it can track agents interacting with external systems, the registry itself operates within AWS.  

This approach, according to Forrester principal analyst Charlie Dai, reinforces the company’s push to position Bedrock as the control plane for enterprise AI agent deployment and oversight.

More so because other cloud providers are taking a similar approach. 

Google Cloud, for instance, is extending Vertex AI with capabilities to orchestrate and monitor agents, including a governance layer within Vertex AI Agent Builder and integrations with its Agent Registry via Apigee.

Microsoft, meanwhile, is positioning Azure AI and Copilot Studio as a unified platform for building and governing enterprise AI agents, complemented by Agent 365 and Entra Agent ID for discovery and identity management.

In fact, Dewan cautioned enterprise teams planning to embrace AWS’ Agent Registry because of its close integration with AWS-native services, particularly in areas such as identity and runtime.

“As a result, while the service will natively index and manage agents deployed within AWS environments, integration with external or on-prem agents will likely require manual registration. Cross-cloud or federated discovery capabilities are not yet clearly established,” Dewan said.

This limitation, in itself, could introduce a new risk: registry sprawl across hyperscalers, Dewan noted, adding that enterprises adopting AWS, Microsoft, and Google registries in parallel could end up recreating the very fragmentation these tools are meant to solve.

Accessing the Agent Registry and adding agents

The registry is accessible through multiple entry points, including the AgentCore console, APIs, SDKs, and even as a Model Context Protocol (MCP) server, allowing compatible clients and developer tools to query it directly.

This multi-access design, according to an AWS blog post, is deliberate as it allows teams to integrate the registry into existing development environments or build custom discovery interfaces using OAuth-based authentication, without being tied strictly to AWS-native tooling.

When it comes to adding agents and related resources, AWS provides two primary approaches.

The first is a manual registration path, where developers or platform teams create records via the console, APIs, or SDKs by supplying structured metadata such as capabilities, ownership, compliance attributes, and usage documentation.

The second is a more automated ingestion route, where teams can point the registry to an MCP or Agent2Agent (A2A) endpoint, allowing it to pull in agent details automatically, AWS wrote in the blog post.

Agent Registry is currently available in preview across five AWS Regions, including US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Sydney), Europe (Ireland), and US East (N. Virginia).

The service is expected to start supporting external registries soon, AWS said.

That, the hyperscaler added, will help enterprises connect multiple registries and search across them as one.

“You will be able to define categories and taxonomies that match how your organization thinks about agents, backed by structured metadata schemas capturing ownership, compliance status, cost center, and whatever else your governance model requires,” it further detailed in the blog post.

Our multi-agent AI system was impressive in demos. One agent handled customer inquiries. Another managed scheduling. A third processed documents. Each worked beautifully in isolation.

In production, they fought each other. The scheduling agent would book appointments while the inquiry agent was still gathering requirements. The document agent processed files using outdated context from a conversation that had moved on two turns ago. End-to-end latency crept from roughly 200 milliseconds to nearly 2.4 seconds as agents waited on each other through ad-hoc API calls that nobody had designed for scale.

The problem was not the agents. Every individual agent performed well within its domain. The problem was the missing coordination infrastructure between them, what I now call the “Event Spine” that enables agents to work as a system rather than a collection of individuals competing for the same resources.

Among my peers running production AI at enterprise scale across telecommunications and healthcare, the same pattern keeps surfacing. Agent proliferation is real. The tooling to coordinate those agents is not keeping up.

Sreenivasa Reddy Hulebeedu Reddy

Why direct agent-to-agent communication breaks down

The intuitive approach to multi-agent systems is direct communication. Agent A calls Agent B’s API. Agent B responds. Simple point-to-point integration. It mirrors how most teams build microservices initially, and it works fine when you have two or three agents.

The math stops working quickly. As agent count grows, connection count grows quadratically. Five agents need 10 connections. Ten agents need 45. Twenty agents need 190. Each connection is a potential failure point, a latency source and a coordination challenge that someone must maintain.

Worse, direct communication creates hidden dependencies. When Agent A calls Agent B, A needs to understand B’s state, availability and current workload. That knowledge couples the agents tightly, defeating the entire purpose of distributing capabilities across specialized components. Change B’s API contract, and every agent that calls B needs updating.

We have seen this movie before. Microservices went through the same evolution — from direct service-to-service calls to message buses, to service meshes. AI agents are following the same trajectory, just compressed into months instead of years.

The Event Spine pattern

The Event Spine is a centralized coordination layer with three properties designed specifically for multi-agent AI systems.

First, ordered event streams. Every agent action produces an event with a global sequence number. Any agent can reconstruct the current system state by reading the event stream. This eliminates the need for agents to query each other directly, which is where the latency was hiding in our system.

Second, context propagation. Each event carries a context envelope that includes the originating user request, current session state and any constraints or deadlines. When an agent receives an event, it has the full picture without making additional calls. In our previous architecture, agents were making three to five round-trip calls just to assemble enough context to act on a single request. Third, coordination primitives. The spine provides built-in support for common patterns: sequential handoffs between agents, parallel fan-out with aggregation, conditional routing based on confidence scores and priority preemption when urgent requests arrive. These patterns would otherwise need to be implemented independently by each agent pair, duplicating logic and introducing inconsistency.

from collections import defaultdict
 import time
  class EventSpine:
      def __init__(self):
          self.sequence = 0
          self.subscribers = defaultdict(list)
       def publish(self, event_type, payload, context):
          self.sequence += 1
          event = Event(
              seq=self.sequence,
              type=event_type,
              payload=payload,
              context=context,
              timestamp=time.time()
          )
          for handler in self.subscribers[event_type]:
              handler(event)
          return event
      def subscribe(self, event_type, handler):
            self.subscribers[event_type].append(handler)

Sreenivasa Reddy Hulebeedu Reddy

3 problems the Event Spine solves

Problem one: race conditions between agents. Without coordination, our scheduling agent would book meetings before the inquiry agent had finished collecting requirements. Customers received calendar invitations for appointments that were missing critical details. The Event Spine solved this by enforcing sequential processing for dependent operations. The scheduling agent subscribes to requirement-complete events and only acts after receiving confirmation that the inquiry agent has gathered everything needed.

Problem two: context staleness. Agents making decisions based on outdated information was our second most common failure mode. A customer would correct their phone number during a conversation, but the document agent — which had pulled context three turns earlier — would generate paperwork with the old number. The Event Spine solved this by attaching the current context envelope to every event. When the inquiry agent publishes an update, the attached context reflects the latest state. Downstream agents never operate on stale data.

Problem three: cascading failures. When one agent in a direct-call chain fails, downstream agents either hang waiting for a response or fail themselves. A single document processing timeout would cascade into scheduling failures and inquiry timeouts. The Event Spine introduced dead-letter queues, timeout policies and fallback routing. When the document processing agent experienced latency spikes, events automatically rerouted to a simplified fallback handler that queued work for later processing instead of failing the entire pipeline.

Sreenivasa Reddy Hulebeedu Reddy

Results

The combined impact reshaped our system’s performance profile. End-to-end latency dropped from approximately 2.4 seconds back to roughly 180 milliseconds. The improvement came primarily from eliminating the cascading round-trip calls between agents. Instead of five agents making point-to-point requests to build context, each agent receives exactly what it needs through the event stream.

Agent-related production incidents dropped 71 percent in the first quarter after deployment. Most of the eliminated incidents were race conditions and stale context bugs that are structurally impossible with event-based coordination.

Agent CPU utilization decreased approximately 36 percent because agents stopped performing redundant work. In the old architecture, multiple agents would independently fetch the same customer data from shared services. With context propagation through the spine, that data is fetched once and shared through the event envelope.

Duplicate processing was eliminated entirely. Our previous architecture had no reliable way to detect when two agents were acting on the same request simultaneously. The Event Spine’s global sequence numbering provides natural deduplication. Developer productivity improved as well, though this is harder to quantify. Adding a new agent to the system now requires subscribing to relevant events rather than integrating point-to-point with every existing agent. Our most recent agent addition took two days from prototype to production, compared to the two weeks our previous additions required.

# Example: Sequential handoff with fallback
  class AgentCoordinator:
      def __init__(self, spine: EventSpine):
          self.spine = spine
          spine.subscribe('inquiry.complete', self.on_inquiry_complete)
          spine.subscribe('scheduling.complete', self.on_scheduling_complete)
          spine.subscribe('agent.timeout', self.on_agent_timeout)
 
      def on_inquiry_complete(self, event):
          # Sequential: scheduling only starts after inquiry
          self.spine.publish(
              'scheduling.request',
              payload=event.payload,
              context=event.context  # Fresh context propagated
            )
        def on_agent_timeout(self, event):
          # Fallback: route to dead-letter queue
          self.spine.publish(
              'fallback.process',
              payload=event.payload,
              context={**event.context, 'fallback_reason': 'timeout'}
	}

What this means for enterprises scaling AI agents

Multi-agent AI is not a future concept. It is a present reality in any enterprise running more than two AI-powered capabilities. If you have a chatbot, a recommendation engine and a document processor, you have a multi-agent system, whether you designed it as one or not.

The coordination challenge will only grow as agent counts increase. Every enterprise I speak with is adding AI capabilities faster than they are adding coordination infrastructure. That gap is where production incidents live.

The Event Spine pattern provides the architectural foundation that prevents agent proliferation from becoming agent chaos. It is the same lesson the industry learned with microservices a decade ago: distributed systems need explicit coordination infrastructure, not just well-intentioned API contracts between teams.

The enterprises that will scale AI successfully are the ones investing in coordination architecture now, before the complexity becomes unmanageable. The ones that wait will eventually build it anyway — just under more pressure, with more incidents and at higher cost.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

A recent article on transfer-friendly online cloud computing degree programs highlights a shift in how cloud professionals are educated, credentialed, and hired. This trend moves well beyond a few schools experimenting with digital delivery. An impressive number of accredited colleges and universities now offer online cloud-focused degrees, allowing students to enter the profession without traditional college programs. They earn valid degrees, develop real skills, and gain recognized credentials. The process is becoming more efficient, focused, and far less costly.

A move that mirrors cloud itself

Cloud computing is not a profession tied to physical locations. It relies on digital platforms, distributed systems, virtual infrastructure, remote management, automation, and architecture that exist beyond the confines of any single building. The work is done in the cloud, through the cloud, and increasingly for businesses that operate in hybrid or fully distributed models.

In fact, the online format is typically better aligned with the job itself. Students in these programs learn in environments that more closely resemble where they will eventually work. They gain exposure to cloud consoles, lab simulations, collaborative tools, remote problem-solving, and digital workflows that mirror real enterprise practice. That exposure matters. Education is always stronger when the delivery model reinforces the substance of what is being taught, and cloud computing may be one of the clearest examples of that principle.

Lower costs mean broader access

The most immediate advantage is expense, and this is where the old model is increasingly difficult to defend. A traditional college education includes lecture halls, dormitories, housing, transportation, facilities, and indirect costs that often don’t relate to cloud skills. While some find value in this experience, many, especially working adults and career-focused learners, see it as a financial burden they don’t need.

Online cloud programs offer a different model. Students can often work while studying, avoid relocating, cut incidental costs, and transfer credits to prevent paying again for completed coursework. This good news enables more people to join the cloud computing field without incurring the heavy student debt that has long been associated with higher education.

It also allows students to be more intentional. They can pursue a college education focused on what they actually want to do. If their goal is cloud engineering, cloud architecture, cloud operations, or cloud security, they no longer have to buy the entire traditional college package to earn a credible degree. It’s a better use of both time and money.

Career-relevant curriculum

The more effective online programs are aligned with the skills that businesses need. For years, one of the biggest frustrations in enterprise technology was the gap between academic training and real-world operations. Graduates lacked enough familiarity with the tools, disciplines, and patterns that define modern IT. Cloud computing quickly exposed this weakness because the market moved faster than many institutions could adapt.

That is beginning to change. Online cloud degree programs are now often designed with a clearer understanding of the profession itself. Students learn about cloud architecture, networking, security, governance, automation, systems design, and platform-specific thinking in ways that relate more directly to actual job roles. Training is integrated into the curriculum—exactly how it should be.

That integration creates value on multiple levels. In addition to their degree, students also gain preparation that is more immediately practical. They develop familiarity with the technologies and operating models that define real cloud environments. They start thinking less like passive learners and more like future practitioners. This makes the transition from school to work smoother and much more effective.

The benefits to employers

Businesses should see this development as positive news, too. Many organizations already invest in some form of employee education, but not all educational spending offers the same value. When a company funds an employee’s accredited online cloud degree, the business will benefit in a tangible way. That’s important because cloud skills are expensive to hire on the open market. It’s still hard to find enough experienced professionals in architecture, operations, migration, security, and platform management.

A smart approach is to develop that expertise internally. When a company helps a systems administrator, network engineer, developer, or support professional pursue a cloud-focused degree, the benefits to the business can be substantial. The employee continues working and can apply their new knowledge to real projects even before the degree is completed. This makes education funding appear less like a perk and more like a strategic investment in modernization, retention, and workforce development. At a time when businesses are pressured to do more with the talent they already have, those are powerful outcomes.

A market with real options

This trend would be less meaningful if students had only one or two isolated options. That is no longer the case. Purdue Global, Franklin University, and Thomas Edison State University all offer a Bachelor of Science degree in cloud computing. Strayer University offers a cloud computing concentration within its online information technology degree. Western Governors University has a cloud and network engineering program that reflects how closely cloud and network infrastructure now intersect in the real world.

These programs collectively mark the rise of a new category within higher education. Accredited institutions are recognizing that students want flexible, online, career-oriented degrees connected to cloud computing, and they are developing programs to meet that demand. This indicates that the education market is maturing. For many students, this path may soon become the preferred route to their careers. The economics are too favorable, the employer demand is too persistent, and the subject matter is too naturally suited to online delivery. Students want lower-cost pathways that lead directly to careers. Employers want workers who can contribute practical cloud knowledge sooner rather than later. Colleges and universities, however slowly they move, eventually respond to such market pressure.

Cloud computing sits at the center of all these forces. It is a modern profession built on digital access, continual learning, and applied knowledge. Accredited online education is the logical evolution.

Microsoft officials have confirmed, and are trying to correct, a reauthentication snafu with developers in its Windows Hardware Program which has blocked an unknown number of independent software vendors (ISVs) from access to Microsoft systems. That in turn has interrupted operations for the their customers globally.

The process started in October, when Microsoft began account verification for its Windows Hardware Program. Notices were sent to corporate email accounts, or at least they were supposed to have been, and account holders were suspended if they didn’t respond to the request by the deadline. Suspended accounts included a mix of businesses that never received the Microsoft notices, those that received the email but either didn’t notice it or didn’t act on it, and some ISVs who claim they were fully reauthenticated but had services cut off anyway.

Microsoft executives communicating with customers on the X social media platform were quick to confirm that glitches had occurred, but noted that the company wasn’t entirely at fault. 

Scott Hanselman, a Microsoft VP overseeing GitHub, posted on X: “Hey, I love dumping on my company as much as the next guy, because Microsoft does some dumb stuff, but sometimes it’s just ‘check emails and verify your accounts.’ Not every ‘WTF micro$oft’ moment is a slam dunk. I’ve emailed [one major ISV] personally and we’ll get him unblocked. Not everything is a conspiracy. Sometimes it’s literally paperwork.”

At one point in the discussion, Hanselman seemed frustrated with users complaining that Microsoft enforced the deadline it had been telling people about since October. “It’s almost like deadlines are date based,” he said. 

Hanselman also said the flood of urgent requests made the reinstatement process seem to move more slowly. 

“In all these scenarios, [the ISVs] either didn’t see emails or didn’t take action on emails going back to October of last year and until now. Spam folder, didn’t see them, lots of valid reasons that can be worked on. Then they open tickets and the tickets don’t move fast enough–days or weeks, not hours,” Hanselman said. “Once the deadlines hit, then folks complain on social and then folks have to manually unblock accounts with urgency. Things become urgent, but were not always urgent.”

A more senior Microsoft executive, Pavan Davuluri, the EVP overseeing Windows and Devices, also weighed in on X. “We worked hard to make sure partners understood this was coming, from emails, banners, reminders. And we know that sometimes things still get missed,” Davuluri said. “We’re taking this as an opportunity to review how we communicate changes like this and make sure we’re doing it better. If anyone needs help with reinstatement, they can request support here.”

Making the problem worse was the cascading effect on global businesses. As the developer companies were locked out, their customers would also feel the pain as their operations were also disrupted due to reliance on the vendors.

Developers also complained about the limited Microsoft support available to unravel the mess. The company told visitors on X that they could use that app to message it and ask to be reinstated.

Onus on both vendors and ISVs

Consultant Brian Levine, executive director of FormerGov, said some of the onus has to fall on the ISVs.

“Developers should treat vendor recertification as a mission‑critical dependency and implement redundant monitoring, such as multiple emails, portal checks, and automated reminders, to avoid silent lockouts,” Levine said. “This poses real operational risk because a sudden vendor lockout can break integrations, halt workflows, and create cascading outages that look like internal failures rather than upstream policy triggers.”

He noted that vendors should surface critical compliance alerts directly inside their portals and consoles, where developers actually work, “so no one’s business hinges on whether a single automated email landed in [the] spam [folder].”

Carmi Levy, an independent technology analyst, said enterprises often give insufficient attention to their suppliers’ software suppliers. Enterprise IT and developers “need to be asking the hard questions” about vendor dependencies. “Ideally, vendor relations capabilities would be far more proactive,” he noted.

Asked if that means that enterprise IT should be asking their suppliers’ suppliers questions such as “Have you recertified with Microsoft yet? The deadline is almost here,” Levy said that might be asking too much. “Most organizations do not communicate at that level, unfortunately,” Levy said. 

“Summarily having an account terminated after years of regular and proper use is an unthinkable outcome for a developer whose very lifeblood relies on access to that very same account,” Levy said. “Likewise, the countless customers of this developer, who rely on [their ISV] for their own careers and businesses, are potentially left in the dark because Microsoft either can’t or won’t implement better development management technologies and protocols. This case reinforces the power imbalance between major tech platformers like Microsoft and the independent developers who rely on them to keep their own lights on.”

Implicit trust

Another complicating factor is the increasing reliance that systems have on other systems and executables, said Flavio Villanustre, CISO for the LexisNexis Risk Solutions Group. That is what forces Microsoft to be so strict in re-authenticating the players that control these software elements. 

There is “implicit trust put on those organizations providing computing components that must be executed before the operating system loads. Since all anti-malware controls are part of and start with the loading of the operating system, anything that executes before [them] could potentially jeopardize the integrity of the entire system,” Villanustre said. “To do this, UEFI requires those components executed at boot time, including the operating systems, to be cryptographically signed with private keys whose certificates are known and can be validated by the UEFI system.”

This is what puts so much power in the hands of the OS vendor, he noted. “Unfortunately, developers have little recourse. If their software component relies on pre-boot execution, they will need a key signature, and that’s tightly controlled by the UEFI/OEM manufacturers and Microsoft,” Villanustre said. “Even Linux distributions rely on Microsoft for key signature. This situation effectively creates a monopoly, where Microsoft controls what runs at boot time through their Certificate Authority.”

However, he observed, “it would probably require regulatory pressure to force that responsibility to be split among more organizations, but you could argue that doing so could potentially weaken the security of the overall system.” 

Anthropic has announced Claude Managed Agents, a suite of composable APIs for building and hosting cloud-hosted agents. The intent is to give any company building on the Claude Platform the full production stack for shipping AI agents at scale.

Launched April 8 in a public beta on the Claude Platform, Claude Managed Agents is purpose-built for Claude, enabling better agent outcomes with less effort by providing sandboxed code execution, checkpointing, credential management, scoped permissions, and end-to-end tracing, according to Anthropic. Users define an agent’s tasks, tools, and guardrails and deploy it on Anthropic infrastructure. A built-in orchestration harness decides when to call tools, how to manage context, and how to recover from errors, the company said.

Claude Managed Agents includes the following:

• Production-grade agents with secure sandboxing, authentication, and tool execution handled for the user.
• Long-running sessions that operate autonomously, with progress and outputs that persist through disconnections.
• Multi-agent coordination that allows agents to spin up and direct other agents to parallelize complex work.
• Trusted governance that gives agents access to real systems with scoped permissions, identity management, and execution tracing built in.

Notion, Rakuten, and Sentry are already building on Claude Managed Agents, Anthropic said. In internal testing around structured file generation, Claude Managed Agents improved outcome task success by as much as 10 points over a standard prompting loop, with the largest gains on the hardest problems, Anthropic said.

Meta’s new “small and fast” AI model, Muse Spark, is an acknowledgement that as enterprises scale AI systems beyond millions of users and for use on a greater variety of devices, they must make things more efficient and more application-specific.

Muse Spark now powers the Meta AI assistant on the web and in the Meta AI app, and the company plans to roll it out across WhatsApp, Instagram, Facebook, Messenger, and the company’s smart glasses. It will also offer select partners access to the underlying technology through an API, initially as a private preview.  “We hope to open-source future versions of the model,” it said in a blog post announcing Muse Spark.

While Meta did not disclose the model’s size or much about its architecture, it described Muse Spark as being capable of balancing capability with speed.

That positioning, even without explicit enterprise deployment guidance, aligns with priorities CIOs and developers are increasingly grappling with as they move generative AI from pilots to production, focusing on efficiency, responsiveness, and seamless integration into user-facing software.

The model’s other capabilities, including support for multimodal inputs, multiple reasoning modes, and parallel sub-agents for complex queries, could help enterprises build faster, task-focused AI for customer support, automation, and internal copilots without relying on heavier models.

Meta said it has worked with physicians to improve responses to common health-related questions, underscoring the model’s applicability across a range of use cases, including reasoning tasks in science, math, and healthcare.

It said it had conducted extensive pre-deployment safety evaluations, with particular attention to higher-risk domains such as health and scientific reasoning. The company also touted said it had made improvements in refusal behavior and response reliability, aimed at reducing harmful or unsupported outputs.

It published the results of 20 AI benchmarks for Muse Spark, positioning it as competitive in several areas while not claiming across-the-board leadership. In particular, it highlighted strong performance on health-related assessments, reflecting its focus on improving responses in that domain through targeted training and evaluation.

The model also scored well on multimodal and reasoning-oriented benchmarks, sometimes a little ahead of rivals such as Claude Opus 4.6, Gemini 3.1 Pro, GPT 5.4 or Grok 4.2, sometimes a little behind.

Meta frames the model as part of a broader roadmap, with future models expected to extend capabilities further, suggesting a staged approach rather than a single model designed to lead on all benchmarks.

Generative AI has revolutionized the space of software development in such a way that developers can now write code at an unprecedented speed. Various tools such as GitHub Copilot, Amazon CodeWhisperer and ChatGPT have become a normal part of how engineers carry out their work nowadays. I have experienced this firsthand, in my roles from leading engineering teams at Amazon to working on large-scale platforms for invoicing and compliance, both the huge boosts in productivity and the equally great risks that come with GenAI-assisted development.

With GenAI, the promise of productivity is very compelling. Developers who use AI coding assistants talk about their productivity going up by 15% to 55%. But most of the time, this speed comes with hidden dangers. To name a few, AI-generated software without good guardrails could open up security issues, lead to technical debt and introduce bugs that are difficult to detect through traditional code reviews. According to McKinsey research, while GenAI tools allow developers to be more productive at a higher level but also require rethinking of software development practices to maintain code quality and security.

The answer is not to abandon these awesome tools altogether. In fact, it is about combining them with reliable engineering practices that the teams already know and trust. In fact, the proper application of traditional Agile methodologies generates the precise guidelines that allow you to benefit from GenAI while also controlling its hazards. In this article, I consider the five basic Agile methodologies: Test-driven development (TDD), behavior-driven development (BDD), acceptance test-driven development (ATDD), pair programming and continuous integration together provide the guardrails to GenAI development, not just to make it quicker, but also of higher quality.

The GenAI code quality crisis: Real-world issues

Before we jump into solutions, it is worth naming the problem. The issues with AI-generated code aren’t theoretical. They’re appearing in production systems across the industry:

• Security vulnerabilities: In 2023, researchers at Stanford found that developers using AI assistants were more likely to introduce security vulnerabilities into their code, particularly injection flaws and insecure authentication mechanisms. A study published in IEEE Security & Privacy demonstrated that GitHub Copilot suggested vulnerable code approximately 40% of the time across common security-critical scenarios. At one major financial institution, an AI-generated SQL query bypassed parameterization, creating a critical injection vulnerability that wasn’t caught until penetration testing.
• Hallucinated dependencies: AI models sometimes generate suggestions for libraries, functions or APIs that don’t exist. A group from a healthcare company invested three days in finding the bug in their microservice compiling issue, only to learn that the AI had suggested a nonexistent AWS SDK method. The code seemed legitimate, went through the first review, but the method signature was completely made up.
• Subtly incorrect business logic: Most misleading of all are mistakes in the business logic that look good on the surface but have subtle defects in them. For example, we came across a line, item tax calculation on an invoice that was AI-generated, which looked perfect, but upon close inspection, it was discovered that rounding was applied at the level of each item rather than at the level of the subtotal. While a brief inspection of the logic indicated that it was correct, the difference in the sequence of rounding would have resulted in the final invoice totals being different from the legal requirements for tax reporting, thus leading to compliance risks and reconciliation errors from millions of transactions.
• Technical debt accumulation: AI tools focus on producing working code rather than maintainable code. They frequently recommend very nested conditional logic, duplicated code patterns and excessively complex solutions when simpler alternatives are available. Gartner research warned that without strong governance, early GenAI adopters can accumulate cost, complexity and technical debt.
• Compliance and licensing issues: AI models trained from public code repositories can, at times, generate code that is basically a copy of the code with certain licenses that are incompatible. For industries that are heavily regulated, such as healthcare and finance, this kind of situation poses very serious risks of noncompliance. A pharmaceutical company, as an example, came across AI-generated codes that were very similar to the GPL-licensed open-source software and if the company relies on such a platform, it would be legally exposed.

The root cause: Speed without clear specification

These problems arise from the same root, which is AI producing code based on patterns it has seen, without real understanding of requirements, context or whether the code is correct. It works on probability, for example, “what code pattern from the prompt is most likely” rather than correctness or suitability for the particular case.

Traditional code review, although essential, is not enough to protect against errors from AI-generated code. Most people find it difficult to spot subtle errors in code that looks legitimate and the volume of AI-generated code can easily overwhelm the review capacity. We must have automated, systematic methods that check correctness and not just quick visual inspection.

Agile practices as GenAI guardrails

One can find the answer in the methods that have been around for a long time, even before GenAI, and yet they are great at fixing its flaws. Every one of these methods provides a different type of safety net:

1. Test-driven development (TDD): The correctness validator

The TDD cycle, Red, Green, Refactor provides the most direct protection against incorrect AI-generated code. By writing tests first, you create an executable specification of correctness before the AI generates any implementation.

How it works with GenAI:

• Red: Write a failing test that specifies the exact behavior you need. This test becomes your requirement specification in executable form.
• Green: Ask the AI to generate code that makes the test pass. The AI now has a clear, unambiguous target.
• Refactor: Use AI to suggest improvements to the working code while ensuring tests still pass.

Real-world impact: We applied very strict TDD alongside GenAI-assisted development. Before developers accept any AI suggestions, they should write extensive unit tests that detail all the aspects. This caught a critical line-item tax calculation error, while the AI suggested a simple multiplication that “looked” correct, the test specifically checked for legal rounding requirements (rounding at the subtotal level rather than the line level). Because the test specified these precision requirements, the AI’s initial code failed immediately. Without TDD, this discrepancy would have reached production, resulting in significant compliance risks and revenue reconciliation failures.

Moreover, TDD solves the problem of hallucination of dependencies. For example, if AI offers a method or a library that does not exist, the test will not be able to compile or run, thus providing immediate feedback instead of finding out the issue after several days.

2. Behavior-driven development (BDD): The business logic guardian

BDD extends TDD by focusing on system behavior from the user’s perspective using Given-When-Then scenarios. This is particularly powerful for GenAI-assisted development because it creates human-readable specifications that bridge the gap between business requirements and code.

BDD scenarios serve two critical functions with AI-generated code:

First, they provide context-rich prompts for the AI. Instead of asking “write a function to calculate tax,” you provide a complete scenario: “Given a customer in California, when they purchase a $100 item, then the tax should be $9.25.” The AI has more context to generate correct code.

Second, they create executable business logic tests that catch subtle errors humans might miss. The scenarios are written in plain language by product owners and domain experts, then automated using frameworks like Cucumber or Cypress.

Real-world impact: Compliance platform processes invoices across multiple tax jurisdictions. When we started using AI assistance, we first created comprehensive BDD scenarios covering all tax rules, edge cases and regulatory requirements. These scenarios, written by our tax compliance specialists, became the specification for AI code generation. The AI-generated code that passed all BDD scenarios was correct 95% of the time, far higher than code generated from vague prompts.

3. Acceptance test-driven development (ATDD): The stakeholder alignment tool

ATDD involves customers and stakeholders early in defining automated acceptance tests before development begins. This practice is crucial when using GenAI because it ensures the AI is solving the right problem, not just generating plausible-looking code.

The ATDD workflow with GenAI:

• Specification Workshop: Product owners, developers and testers collaborate to define acceptance criteria in a testable format. This creates a shared understanding of “done.”
• Test Automation: Convert acceptance criteria into automated tests before writing implementation code. These tests represent the customer’s definition of success.
• AI Assisted Implementation: Use GenAI to implement features that satisfy the acceptance tests. The tests prevent the AI from drifting away from actual requirements.

Real-world impact: For a volume-based discount feature, we held ATDD workshops to define a specific requirement: “Buy 10, Get 10% Off” must apply only to the qualifying line items, not the entire invoice total. These became our automated acceptance tests. When developers used GenAI to implement the logic, the AI suggested a simple, global discount function that subtracted 10% from the final balance, a common coding pattern for retail, but incorrect for our B2B contractual rules. Because the ATDD test validated the discount at the line-item level, the AI’s “perfect-looking” code failed immediately. This prevented a logic error that would have resulted in significant over-discounting and lost revenue across thousands of bulk orders.

4. Pair programming: The human-AI collaboration model

Traditional pair programming involves two developers working together, often one writing tests and the other writing implementation. With GenAI, this model evolves into a powerful three-way collaboration: Developer A writes tests, Developer B reviews AI-generated code and the AI serves as a rapid implementation assistant.

The enhanced pair programming workflow:

• Navigator Role: One developer focuses on writing comprehensive tests and thinking about edge cases, security implications and architectural fit. They are not distracted by implementation details.
• Driver Role: The other developer works with the AI to generate implementation code, critically evaluating each suggestion. They serve as the quality filter for AI output.
• AI Assistant: Generates implementation suggestions based on tests and context, accelerating the coding process while the human pair ensures quality.

Real-world impact: A recent study by GitClear found that code quality metrics declined when developers used AI tools in isolation but improved when used in pair programming contexts. We recommend pair programming for any AI-assisted development of critical systems. The navigator catches security issues and architectural mismatches that the driver, focused on AI output, might miss. We have seen a 60% reduction in post-deployment bugs compared to solo AI-assisted development.

5. Continuous integration (CI): The automated safety net

Continuous integration runs automated test suites every time code is merged. It becomes even more critical with GenAI-assisted development. CI provides the final safety net that catches issues before they reach production.

Enhanced CI pipeline for GenAI code:

• Comprehensive test execution: Run all unit tests, integration tests, BDD scenarios and acceptance tests on every commit. AI-generated code must pass the entire suite.
• Static analysis: Include additional static analysis tools that check for common AI-generated code issues like security vulnerabilities, code complexity metrics and licensing compliance.
• Performance benchmarks: Automated performance tests catch AI-generated code that works correctly but performs poorly at scale.

Real-world impact: Our CI pipeline is configured with specialized checks designed to catch the unique risks of AI-assisted coding. For the invoicing platform, we integrated automated business-rule validators that specifically verify logic like tax rounding and discount applications.

The synergistic effect: Practices working together

The real power emerges when these practices work together. Each creates a different layer of protection:

• TDD ensures the code works correctly for specified inputs.
• BDD ensures it implements the right business behavior.
• ATDD ensures it meets stakeholder expectations.
• Pair programming ensures human oversight and critical thinking.
• CI ensures all these checks run automatically and consistently.

Consider a typical user story for an e-commerce platform: “As a customer, I want to apply discount codes so that I can save money on purchases.”

Without Agile practices, a developer might prompt an AI: “Write a function to apply discount codes to shopping carts.” The AI generates plausible-looking code, the developer briefly reviews it and it ships. Hidden issues might include: discount stacking vulnerabilities, floating-point rounding errors, failure to validate expiration dates or SQL injection in the discount code lookup.

With Agile practices:

• ATDD: Product owner, developer and tester define acceptance criteria: “Given a valid 10% discount code, When applied to a $100 cart, Then the total should be $90.”
• BDD: Business analyst writes scenarios covering edge cases: expired codes, invalid codes, maximum discount limits, combination rules.
• TDD: Developer pair writes unit tests first, including security tests for injection attacks, tests for decimal precision and tests for all edge cases.
• Pair programming: One developer writes tests, the other works with AI to implement, both review the generated code critically.
• CI: All tests run automatically on commit, plus static analysis for security issues, performance benchmarks and compliance checks.

This multi-layered approach catches issues at different stages: tests catch functional errors, pair programming catches architectural mismatches, CI catches regressions and security issues.

Implementation recommendations

Based on our experience implementing these practices across multiple teams, here are practical recommendations for organizations adopting GenAI development tools:

• Start with TDD as the foundation: Make test-first development non-negotiable when using AI assistance. This single practice prevents the majority of AI-generated code issues. Invest in training developers on TDD if they’re not already proficient.
• Enhance code review processes: Traditional code review checklists need updating for AI-generated code. Add specific review criteria: Does the code handle edge cases? Are there obvious security vulnerabilities? Does it match our architectural patterns? Is the complexity appropriate for the problem?
• Invest in test infrastructure: Strong CI pipelines become even more important. Ensure your pipeline can run comprehensive test suites quickly. Slow test execution discourages frequent commits and reduces the effectiveness of CI as a safety net.
• Create AI usage guidelines: Document when and how to use AI assistance. Some scenarios might be high risk (security-critical code, financial calculations) and require extra scrutiny. Others might be low-risk (boilerplate code, standard CRUD operations) and benefit most from AI acceleration.
• Measure and monitor: Track metrics specific to AI-assisted development, such as defect rates in AI-generated vs. human-written code, test coverage trends, time-to-production and post-deployment issues. Use data to refine your practices.

Conclusion: Speed with safety

Generative AI is a fundamental change in how we write software that can be compared to the introduction of high-level programming languages or integrated development environments. It brings real and huge productivity gains. But speed without quality is not progress; it is technical debt accumulation at an accelerated rate.

The great thing is that we don’t have to come up with new methods to make use of GenAI safely. The Agile methods that have been used for decades, such as TDD, BDD, ATDD, Pair Programming and CI, are exactly the safety measures we need. These methods have quality at their core through automation, collaboration and continuous verification. They are even more impressive with AI help because they provide objective, automated checks that don’t have the same pattern-matching biases as humans, who are poor at reviewing AI-generated code, have.

Companies that use GenAI tools but keep up with strict software development practices will get the best results. For example, faster development without sacrificing quality, reduced defect rates despite increased velocity and sustainable productivity gains that don’t create future maintenance issues.

Software development in the future is not about just humans or AI. It is humans and AI cooperating within established quality assurance that is protected by proven frameworks. The combination of AI’s speed and the safety of Agile methods allows us to do software development that is both really efficient and of high quality on a large scale.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Forms remain one of the most important interaction surfaces in modern web applications. Nearly every product relies on them to capture user input, validate data, and coordinate workflows between users and back-end systems. Yet despite their importance, forms are also one of the areas where front-end complexity tends to accumulate quietly over time.

For simple scenarios, Angular forms feel straightforward to work with. A handful of controls, a few validators, and a submission handler can be implemented quickly and confidently. But the situation changes as applications grow. Nested form groups, dynamic controls, conditional validation, and cross-field dependencies gradually introduce layers of behavior that are difficult to visualize as a single coherent system.

Developers often reach a point where a form technically works but becomes difficult to explain. Adding a new rule or modifying a validation condition can require tracing through observables, validators, and control states that are spread across multiple components. The challenge is rarely a missing feature. Instead, it is the growing difficulty of reasoning about how the system behaves as a whole.

This is not a criticism of Angular forms themselves. The framework has evolved powerful abstractions that solve real problems: keeping view and model synchronized, enforcing validation rules, coordinating asynchronous operations, and maintaining accessibility. These capabilities are essential for production-scale applications.

The more interesting question is architectural rather than technical. What mental model should developers use when reasoning about form behavior in modern Angular applications?

In this article, we step away from specific APIs and instead examine forms from first principles. By looking at forms primarily as state systems rather than event pipelines, we can better understand where complexity originates and why newer reactive primitives such as Angular Signals align naturally with the underlying structure of form logic.

Over the past decade, Angular forms have been shaped primarily by event-driven abstractions and observable streams. As the framework evolves toward signal-based reactivity, it is worth reconsidering whether forms should continue to be modeled primarily around events at all.

Forms are not fundamentally event systems. They are state systems that happen to receive events. This distinction becomes clearer as front-end systems grow larger and validation logic becomes increasingly intertwined with application state.

Many front-end systems have gradually adopted an event-centric mental model, where application behavior is primarily expressed through chains of reactions and emissions. As discussed in my recent InfoWorld article, “We mistook event handling for architecture”, this approach can blur the distinction between reacting to change and representing the underlying state of an application. Forms are one of the areas where that distinction becomes particularly visible.

Why forms became complicated (and why that was reasonable)

To understand why a signal-first approach matters, it is worth briefly revisiting how Angular forms evolved and why complexity was an unavoidable outcome.

Early Angular forms were primarily about synchronization. Input elements need to remain synchronized with the model, and updates must flow in both directions. Template-driven forms relied heavily on two-way binding to achieve this. For small forms, this approach felt intuitive and productive. However, as forms grew larger and more complex, the need for structure became apparent. Validation rules, cross-field dependencies, conditional UI logic, and testability all pushed developers toward a more explicit model.

Reactive forms addressed this need by modeling forms as trees of controls. Each control encapsulated its own value, validation state, and metadata. RxJS observables provided a declarative way to respond to changes over time. Validators, both synchronous and asynchronous, could be attached to controls, and Angular automatically tracked interaction state, such as whether a control was dirty, touched, or pending.

This architecture solved many real problems. It also shifted the dominant mental model from state to events. That shift was reasonable at the time, but it also encouraged developers to think of form behavior primarily as a sequence of reactions rather than as a system defined by state. Developers began reasoning about forms in terms of streams: when a value emits, when a status changes, when a validator runs, and when subscriptions are triggered. In simple cases, this was manageable. In larger forms, it often became difficult to trace why a particular piece of logic executed or why a control entered a specific state.

The deeper issue is not that reactive forms rely on RxJS, but that they often conflate state with coordination. RxJS excels at coordinating asynchronous workflows and reacting to events. It is less well-suited to serve as a primary representation of the state. Forms, however, are overwhelmingly state-driven. At any given moment, a form has a well-defined set of values, validation rules, derived errors, and UI flags. Much of this information can be computed deterministically, without reference to time or event ordering.

As form logic grows, the cost of mixing state representation with event coordination increases. Debugging requires tracing emissions across multiple observables. Understanding behavior requires knowing not only what the state is but also how it arrived at that state. This is the context in which Angular Signals becomes interesting, not as a replacement for RxJS, but as a better fit for modeling form state itself.

Defining form state from first principles

Before introducing any APIs or framework constructs, it is useful to strip the problem down to its essentials and ask a basic question: what is form state?

At its core, a form exists to collect data. This data is typically represented as a plain object composed of strings, numbers, booleans, or nested structures. These values form the canonical source of truth for everything else the form does. Without values, there is no form.

Validation rules operate on those values. They define constraints such as whether a field is required, whether a value conforms to a particular format, or whether multiple fields satisfy a cross-field condition. Importantly, validation rules do not store state. Given the same input values, they always produce the same outcome. They are pure functions of state, not state themselves.

From values and validation rules, we derive validity and error information. A field is either valid or invalid, and specific error messages may apply. At the form level, validity is typically derived by aggregating field-level results. This information is deterministic and can be recalculated at any time from the underlying values.

Forms also track interaction metadata. Whether a field has been touched or modified influences when feedback is shown to the user, but it does not affect the correctness of the data. This metadata exists to improve user experience, not to define business logic.

Finally, there are side effects. Submitting data to a server, persisting drafts, performing asynchronous validation, or navigating to another view are all reactions to state changes. These actions matter, but they are not the state. They are consequences of the state.

Seen through this lens, most of what we consider “form complexity” is not inherent complexity. It is organizational complexity. Derived information is often stored as a mutable state. Validation logic is scattered across imperative callbacks. UI flags are toggled in response to events rather than derived from underlying conditions.

Signals encourage a different organization. They make it natural to treat values as the only mutable input, to express validity and UI state as derived data, and to isolate side effects as explicit reactions. This separation does not introduce new ideas, but it makes existing best practices easier to apply consistently.

Understanding this distinction is essential before adopting any signal-based form API. Without it, signals risk becoming just another abstraction layered on top of existing complexity. With it, they become a tool for simplifying how form behavior is expressed and understood.

The cost of treating the state as events

As reactive forms evolved, the complexity in form logic related to  event coordination soared. Value changes emitted events. Validation status emitted events. Asynchronous validators emitted events. Subscriptions responded to these emissions, producing additional side effects. This model is powerful, but it subtly shifts how developers reason about form behavior.

When form logic is expressed primarily through events, understanding behavior requires temporal reasoning. Developers must ask not only what the current state of the form is, but also how the form arrived at that state. Questions such as “Which emission triggered this validator?” or “Why did this error appear now?” become common. The answers often depend on subscription order, life-cycle timing, or intermediate states that no longer exist.

This event orientation creates an asymmetry in how form behavior can be inspected. Current state, values, errors, and validity can be logged or displayed. The sequence of events that produced that state cannot. Once an emission has passed, it leaves no trace beyond its effects. Debugging becomes an exercise in reconstruction rather than observation.

Over time, the focus on events leads to a common anti-pattern: derived information is promoted to a mutable state. Validation results are stored rather than computed. UI flags are toggled imperatively rather than derived from underlying conditions. These shortcuts reduce immediate friction but increase long-term complexity. The form begins to carry not only its current state but also the historical residue of its manipulation.

The problem becomes more pronounced as forms grow. Cross-field validation introduces dependencies that span multiple controls. Conditional logic ties UI behaviour to combinations of values and interaction states. At this scale, the cost of reasoning in terms of events compounds. Understanding behavior requires tracing emissions across multiple observables, each representing a partial view of the system.

This is not a failure of RxJS or reactive forms. RxJS excels at coordinating asynchronous workflows and reacting to external data streams. The issue arises when event-driven coordination is used as the primary representation of state. Forms, by their nature, are overwhelmingly state-driven. At any given moment, a form has a well-defined configuration of values, rules, and derived outcomes.

Recognizing this mismatch is an important step. It allows us to separate coordination concerns from state representation, and to ask whether some of the complexity we experience is inherent or simply a consequence of the mental model we apply.

Gaining a state-first perspective

Many of the challenges developers encounter when building complex forms are not the result of missing framework features. They arise from how form behavior is structured and reasoned about. When validation rules, UI state, and side effects are coordinated primarily through event flows, understanding the system often requires reconstructing the sequence of events that produced the current state.

A state-first perspective approaches the problem differently. Form values become the central source of truth. Validation rules operate deterministically on that state. Error messages, validity flags, and UI behavior emerge as derived information rather than independently managed pieces of mutable state.

This shift does not invalidate existing Angular Forms patterns, nor does it diminish the usefulness of RxJS where coordination of asynchronous workflows is required. Instead, it clarifies the distinction between two different concerns: representing the state and reacting to events.

Teams that model forms explicitly around state tend to build systems that are easier to inspect, easier to refactor, and easier to reason about as they grow. Angular’s evolving reactivity model opens the door to expressing these ideas more directly.

In the next article in this series, we will examine Angular Signals themselves—what they are, how they differ from observable-driven reactivity, and why their design aligns naturally with the way form state behaves in real applications. From there, the series will explore how signal-driven models can simplify validation, derived state, and large-scale form architecture.

Running databases on Kubernetes is popular. For cloud-native organizations, Kubernetes is the de facto standard approach to running databases. According to Datadog, databases are the most popular workload to deploy in containers, with 45 percent of container-using organizations using this approach. The Data on Kubernetes Community found that production deployments were now common, with the most advanced teams running more than 75 percent of their data workloads in containers.

Kubernetes was not built for stateful workloads originally—the project had to develop multiple new functions like StatefulSets in Kubernetes 1.9 and Operator support for integration with databases later. With that work done over the first 10 years of Kubernetes, you might think that all the hard problems around databases on Kubernetes have been solved. However, that is not the case.

Embracing database as a service with Kubernetes

Today we can run databases in Kubernetes successfully, and match those database workloads alongside the application components that also run in containers. This makes the application development side easier as all the infrastructure is in one place, and can be controlled from one point. While that approach makes the “Day 1” issues around application development easier, it does not deal with many of the “Day 2” issues that still have to be addressed.

Day 2 issues include all the tasks that you need to have running so your application operates effectively over time. That includes looking at resiliency, security, operational management, and business continuity. For developers looking at databases, that means tasks like backup, availability, and failover. Some of these elements are easier in containers. Kubernetes was built to monitor containers in pods and restart images if a problem took place. However, stateful databases require more planning than stateless applications.

Kubernetes Operators can automate some of these processes for you, allowing Kubernetes to work through a database to trigger a cluster to carry out a backup task automatically. But that doesn’t go through the whole process, and it relies on the developer making decisions around how best to follow that process. If you are not an expert in backup or availability, you might be tempted to hand all these concerns over to a third-party provider for them to take care of.

That approach works. Cloud-based database as a service (DBaaS) offerings grew at nearly twice the rate of on-premises deployments according to Gartner — 64% to 36% — as developers went for the easy option. However, this locked them into that particular cloud provider or service. Even when developers might choose an open source database to base their application on, they would still be tied to the provider and their way of doing things. From a mobility perspective, that can represent a serious cost to run a DBaaS rather than doing it yourself.

The future for Kubernetes and database as a service

Automating Kubernetes workloads with Operators can provide the same level of functionality as DBaaS, while still avoiding lock-in to a specific provider. This should fit into how teams want to run internal developer platforms or platform engineering for their developers. However, getting that to work for all databases in a consistent way is its own challenge.

At Percona, we did some of this work around our own project, Everest. But this only supported the databases that we are interested in — namely, MySQL, PostgreSQL and MongoDB. What about other databases that have Operators? How about other systems for managing and observing databases? While the idea of a fully open source database as a service option is great in theory, in practice it needs a community that is willing to get involved and support how that gets built out.

If you really love something, sometimes you have to set it free. Like Woody in Toy Story 3, you just have to say, “So long, partner” with the hope that things go “To Infinity and Beyond” a la Buzz Lightyear. That is what we have done with Everest — or to use its new name, OpenEverest. OpenEverest is now a fully open source project that anyone can get involved in. With the project donated and accepted by the Cloud Native Computing Foundation, this will make running databases on Kubernetes easier for everyone. Over time, OpenEverest will support more databases based on what the community wants to see and where they help with more contributions or support.

For developers, getting Kubernetes and databases together helps them be more productive. But for those running infrastructure or dealing with Day 2 problems around Kubernetes, databases still remain potentially challenging to manage. Dealing with edge cases, automation, and resilience at scale is still a significant hurdle for databases on Kubernetes, yet this approach remains essential if you want to implement platform engineering or internal developer platforms without lock-in. This new open source project is a strong starting point to delivering on that requirement. Making it a community open source software project under a foundation, rather than the preserve of one company, will help this approach to succeed.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

New York NY: Secure container images startup Minimus, today announced the appointment of Yael Nardi as Chief Business Officer (CBO). In this newly established role, Nardi will lead the company’s next stage of scaling, overseeing growth strategy, operations, and corporate development.

As the market landscape evolves and AI impacts customer acquisition, Minimus is introducing an operational model to scale marketing and strategic alliances, which Nardi will manage.

“We are entering a phase of aggressive expansion that requires rigorous execution and a completely new playbook. Traditional marketing strategies are no longer enough in today’s fast-moving environment. We need an operational powerhouse at the helm. Yael is a world-class operator accustomed to zero-error environments and high-stakes execution. We are choosing intelligence, speed, and strategic alignment, and there is no one I trust more to run this machine.” – Ben Bernstein, CEO at Minimus

Nardi joins Minimus with over 15 years of experience advising startups, global investors, and technology corporations. Most recently, she served as Director at Meitar NY Inc. and Partner at Meitar Law Offices. Nardi was the lead corporate lawyer behind several significant M&A transactions, like Twistlock’s acquisition by Palo Alto Networks (PANW) – a deal in the container image hardening and runtime security space, and others like Wiz, Sales, JFrog Salesforce, and others.

“I have worked with the Minimus team through some of their most critical milestones, and I know firsthand the massive potential of their technology. The demand for near-zero CVE container images and minimal container images with built-in security is only accelerating. Scaling a company in today’s environment requires the same 24/7 rigor, vendor accountability, and strategic precision as closing a major M&A deal. I am thrilled to step into this operational role and build the growth engine that will drive Minimus’s next chapter.” – Yael Nardi, Chief Business Officer, Minimus

Nardi, a Bachelor of Laws (LLB) graduate from Tel Aviv University, will be based at Minimus’s New York City headquarters. In her capacity as CBO, she will work alongside the executive leadership team to achieve the company’s growth targets.

About Minimus

Minimus provides hardened container images and hardened Docker images engineered to achieve near-zero CVE exposure. Built continuously from source with the latest patches and security updates, Minimus images undergo rigorous container image hardening and attack surface reduction, delivering secure container images with seamless supply chain security and built-in compliance for FedRAMP, FIPS 140-3, CIS, and STIG standards. Through automatically generated SBOMs and real-time threat intelligence, Minimus empowers teams to prioritize remediation and avoid over 97% of container vulnerabilities – making it a compelling Chainguard alternative for teams seeking production-hardened, distroless container images at scale. 

For more information, visit minimus.io.

Media Contact

Minimus Public Relations

contact@minimus.io

minimus.io

Visual Studio Code 1.115, the latest release of the Microsoft’s extensible code editor, previews a companion app called Visual Studio Code Agents, optimized for agent-native development. Additionally, the agent experience in the editor is improved for running terminal commands in the background, according to Microsoft.

Introduced April 8, Visual Studio Code 1.115 can be downloaded from the Visual Studio Code website for Windows, Mac, or Linux.

Available as a Visual Code Insiders early access capability, the VS Code Agents app allows developers to run agentic tasks across projects, by kicking off multiple agent sessions across multiple repos in parallel. Developers can track session progress, view diffs inline, leave feedback for agents, and create pull requests without leaving the app, Microsoft said. Additionally, custom instructions, prompt files, custom agents, Model Context Protocol (MCP) servers, hooks, and plugins all work in the Agents app, along with VS Code customizations such as themes.

VS Code 1.115 also introduces two changes designed to improve the agent experience for running terminal commands in the background. First, a new send_to_terminal tool lets an agent continue interacting with background terminals. For example, if an SSH session times out while waiting for a password prompt, the agent still can send the required input to complete the connection. Previously, background terminals were read-only, with only the get_terminal_output available to the agent to check the terminal’s status. This was particularly limiting when a foreground terminal timed out and moved to the background, because the agent could no longer interact with it.

Second, a new experimental setting, chat.tools.terminal.backgroundNotifications, allows an agent to automatically be notified when a background terminal command finishes or requires user input. This also applies to foreground terminals that time out and are moved to the background. The agent then can take appropriate action, such as reviewing the output or providing input via the send_to_terminal tool. Previously, when a terminal command was running in the background, the agent had to manually call get_terminal_output to check the status. There was no way to know when the command completed or needed input.

Also in VS Code 1.115, when an agent invokes the browser tool, the tool calls now have a more descriptive label and a link to go directly to the target browser tab, Microsoft said. Plus, the Run Playwright Code tool has improved support for long-running scripts. Scripts that take longer than five seconds to run (by default) now return a deferred result for the agent to poll.

VS Code 1.115 follows VS Code 1.114 by a week, with that release featuring streamlined AI chat. Updates to VS Code now arrive weekly instead of monthly, a change in cadence that Microsoft introduced with the VS Code 1.111 release on March 9.

Visual Studio Code 1.115, the latest release of the Microsoft’s extrensible code editor, previews a companion app called Visual Studio Code Agents, optimized for agent-native development. Additionally, the agent experience in the editor is improved for running terminal commands in the background, according to Microsoft.

Introduced April 8, Visual Studio Code 1.115 can be downloaded from the Visual Studio Code website for Windows, Mac, or Linux.

Available as a Visual Code Insiders early access capability, the VS Code Agents app allows developers to run agentic tasks across projects, by kicking off multiple agent sessions across multiple repos in parallel. Developers can track session progress, view diffs inline, leave feedback for agents, and create pull requests without leaving the app, Microsoft said. Additionally, custom instructions, prompt files, custom agents, Model Context Protocol (MCP) servers, hooks, and plugins all work in the Agents app, along with VS Code customizations such as themes.

VS Code 1.115 also introduces two changes designed to improve the agent experience for running terminal commands in the background. First, a new send_to_terminal tool lets an agent continue interacting with background terminals. For example, if an SSH session times out while waiting for a password prompt, the agent still can send the required input to complete the connection. Previously, background terminals were read-only, with only the get_terminal_output available to the agent to check the terminal’s status. This was particularly limiting when a foreground terminal timed out and moved to the background, because the agent could no longer interact with it.

Second, a new experimental setting, chat.tools.terminal.backgroundNotifications, allows an agent to automatically be notified when a background terminal command finishes or requires user input. This also applies to foreground terminals that time out and are moved to the background. The agent then can take appropriate action, such as reviewing the output or providing input via the send_to_terminal tool. Previously, when a terminal command was running in the background, the agent had to manually call get_terminal_output to check the status. There was no way to know when the command completed or needed input.

Also in VS Code 1.115, when an agent invokes the browser tool, the tool calls now have a more descriptive label and a link to go directly to the target browser tab, Microsoft said. Plus, the Run Playwright Code tool has improved support for long-running scripts. Scripts that take longer than five seconds to run (by default) now return a deferred result for the agent to poll.

VS Code 1.115 follows VS Code 1.114 by a week, with that release featuring streamlined AI chat. Updates to VS Code now arrive weekly instead of monthly, a change in cadence that Microsoft introduced with the VS Code 1.111 release on March 9.

Microsoft’s ASP.NET Core 2.3, a version of the company’s open source web development framework for .NET and C#, will reach end of life support on April 7, 2027.

Following that date, Microsoft will no longer provide bug fixes, technical support, or security patches for ASP.NET Core 2.3, the company announced on April 7, exactly a year before the cessation date. ASP.NET Core 2.3 packages—the latest patched versions only—are supported currently on .NET Framework, following the support cycle for those .NET Framework versions. After April 7, 2027, this support will end regardless of the .NET Framework version in use, according to Microsoft. Support for ASP.NET Core 2.3 packages including the Entity Framework 2.3 packages will end on the same date.

Microsoft recommends upgrading to a currently supported version of .NET, such as .NET 10 LTS. To help with the upgrade process, Microsoft recommends using GitHub Copilot modernization, which provides AI-powered assistance in planning and executing migrations to a modern .NET version.

Microsoft detailed the release of ASP.NET 2.3 in February 2025. The company lists the following impacts as a result of its end of support:

• Applications will continue run; end of support does not break existing applications.
• No new security updates will be issued for ASP.NET Core 2.3.
• Continuing to use an unsupported version may expose applications to security vulnerabilities.
• Technical support will no longer be available for ASP.NET Core 2.3.
• The ASP.NET Core 2.3 packages will be deprecated.

ASP.NET Core is the open-source version of ASP.NET that runs on macOS, Linux, and Windows. ASP.NET Core first was released in 2016 and is a re-design of earlier Windows-only versions of ASP.NET.

Amazon Web Services is making its S3 object storage service easier for AI agents to access with the introduction of a native file system interface. The new interface, S3 Files, will eliminate a longstanding tradeoff between the low cost of S3 and the interactivity of a traditional file system or of Amazon’s Elastic File System (EFS).

“The file system presents S3 objects as files and directories, supporting all Network File System (NFS) v4.1+ operations like creating, reading, updating, and deleting files,” AWS principal developer advocate Sébastien Stormacq wrote in a blog post.

The file system can be accessed directly from any AWS compute instance, container, or function, spanning use cases from production applications to machine learning training and agentic AI systems, Stormacq said.

Analysts saw the change in accessibility as a strategic move by AWS to position S3 as a primary data layer for AI agents and modern applications, moving beyond its traditional use cases in data lakes and batch analytics.

“AWS is aligning S3 with AI, analytics, and distributed application needs where shared, low-latency file access is required on object-resident data. This addresses growing demand from machine learning training, agentic systems, and multi-node workloads that require concurrent read/write access without moving data out of S3,” said Kaustubh K, practice director at Everest Group.

Without a file system in S3, enterprises developing and deploying agentic systems and other modern applications typically had to either use a separate storage system or copy, synchronize, and stage data stored in S3, introducing latency, inconsistency, and operational overhead, said Pareekh Jain, principal analyst at Pareekh Consulting.

Some developers, said Kaustubh, turned to FUSE-based tools such as s3fs or Mountpoint to simulate file systems on top of S3, but these often lacked proper locking, consistency guarantees, and efficient update mechanisms.

In contrast, S3 Files addresses those limitations through native support for file operations, including permissions, locking, and incremental updates, Jain said.

This reduces friction for developers, he said, as they will no longer need to rewrite applications for object storage: existing file-based tools will just work. “Agents also become easier to build, as they can directly read and write files, store memory, and share data. Overall, it reduces the need for extra glue code like sync jobs, caching layers, and file adapters,” Jain said.

This also implications for CIOs, as it simplifies data architecture by bringing everything, including data lakes, file systems, and staging layers, into Amazon S3.

“This approach lowers costs by removing duplication, reducing pipelines, and cutting operational overhead, while also improving governance with a single source of truth and no scattered copies,” Jain said.

S3 Files is now generally available and can be accessed through the AWS Management Console or the Command Line Interface (CLI), where users can create, mount, and deploy file systems.