The promise of static application security testing (SAST) has always been the “shift-left” dream, catching vulnerabilities before they ever hit production. But for too long, that promise has been undermined by a frustrating reality with an overwhelming volume of alerts and high false-positive rates. This noise can lead to alert fatigue, wasted developer time and a loss of trust in the very tools designed to protect our codebase.

Meanwhile, large language models (LLMs) have emerged as powerful code analysis tools, capable of pattern recognition and code generation. Yet, they suffer from their own weaknesses, slow processing, inconsistency, and the potential for hallucination.

In our opinion, the path to next-generation code security is not choosing one over the other, but integrating their strengths. So, along with Kiarash Ahi, founder, Virelya Intelligence Research Labs and the co-author of the framework, I decided to do exactly that. Our novel hybrid framework combines the deterministic rigor and the speed of traditional SAST with the contextual reasoning of a fine-tuned LLM to deliver a system that doesn’t just find vulnerabilities, but also validates them. The results we achieved were stark: A 91% reduction in false positives compared to standalone SAST tools, transforming security from a reactive burden into an integrated and more efficient process.

The core problem: Context vs. rules

Traditional SAST tools, as we know, are rule-bound; they inspect code, bytecode, or binaries for patterns that match known security flaws. While effective, they often fail when it comes to contextual understanding, missing vulnerabilities in complex logical flaws, multi-file dependencies, or hard-to-track code paths. This gap is why their precision rates and the percentage of true vulnerabilities among all reported findings remain low. In our empirical study, the widely used SAST tool, Semgrep, reported a precision of just 35.7%.

Our LLM-SAST mashup is designed to bridge this gap. LLMs, pre-trained on massive code datasets, possess pattern recognition capabilities for code behavior and a knowledge of dependencies that deterministic rules lack. This allows them to reason about the code’s behavior in the context of the surrounding code, relevant files, and the entire code base.

A two-stage pipeline for intelligent triage

Our framework operates as a two-stage pipeline, leveraging a SAST core (in our case, Semgrep) to identify potential risks and then feeding that information into an LLM-powered layer for intelligent analysis and validation.

1. Stage 1, initial SAST findings: The Semgrep SAST engine runs and identifies all potential security risks. For each flag, it extracts the intermediate representations, such as the data flow path from source to sink.
2. Stage 2, LLM-powered intelligent triage: This is the critical step for filtering noise. The framework embeds the relevant code snippet, the data flow path and surrounding contextual information into a structured JSON prompt for a fine-tuned LLM. We fine-tuned Llama 3 8B on a high-quality dataset of vetted false positives and true vulnerabilities, specifically covering major flaw categories like those in the OWASP Top 10 to form the core of the intelligent triage layer. Based on the relevant security issue flagged, the prompt then asks a clear, focused question, such as, “Does this user input lead to an exploitable SQL injection?”

By analyzing the context that traditional SAST rules miss, the LLM can reliably determine if a finding is truly exploitable, acting as an intelligent triage layer. This is the key mechanism that allows the framework to convert a mountain of alerts into a handful of verified, actionable findings.

The metrics, from noise to actionable intelligence

The following empirical results validate our hybrid approach. Our test dataset had 25 diverse open source projects based on their active development and language diversity (Python, Java, JavaScript), with 170 vulnerabilities as ground truth, sourced from public exploit databases and manual expert verification.

• Precision: In our implementation, we found the precision jumped to 89.5%. This is a massive leap not only over Semgrep’s baseline of 35.7%, but also over a purely LLM-based approach (GPT-4), which achieved 65.5%.
• False positive reduction: Semgrep generated a total of 225 false positives. Our framework filtered this down to just 20, representing an approximately 11x improvement in the signal-to-noise ratio.
• Time to triage: This reduction in noise translated directly to developer efficiency, reducing the average triage time for security analysts by a stunning 91%.

Furthermore, the contextual reasoning of the LLM layer enabled the discovery of complex vulnerability types that traditional scanners miss, such as multi-file dataflow bugs.

Beyond detection, validation, and remediation

The LLM’s role doesn’t stop at filtering. It transforms the final output into actionable intelligence.

• Automated exploit generation: For vulnerabilities confirmed as exploitable, our framework automatically generates a proof-of-concept (PoC) exploit. This capability is crucial for verifying existence and providing concrete evidence to developers. In our evaluation, our framework successfully generated valid PoCs for approximately 70% of exploitable findings, significantly reducing the manual verification burden on security analysts.
• Dynamic remediation suggestion: LLMs, with their ability to understand code and generate text, produce comprehensive, human-readable bug descriptions and concrete repair suggestions. This streams raw security findings directly into the developer workflow, accelerating the time to fix and minimizing the window of vulnerability.

A SAST and LLM synergy marks a necessary evolution in static code security. By integrating deterministic analysis with intelligent, context-aware reasoning, we can finally move past the false positive crisis and equip developers with a tool that provides high signal security feedback at the pace of modern development with LLMs.

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

Enterprises need data, and data needs to be stored, with a flexible, portable environment that scales from developers’ laptops to global clouds. That storage also needs to be able to run on any OS and any cloud without breaking the bank.

There aren’t many options. You might be able to use MySQL or any of its forks for most purposes, but it struggles to support large databases that run over multiple data centers. Plus there are licensing issues with proprietary tools like Microsoft’s SQL Server, with its hyperscale Azure SQL variant only available on Microsoft’s own cloud.

PostgreSQL is everywhere

It’s not surprising that developers have become increasingly dependent on the open source PostgreSQL, the nearly 30-year-old successor to the University of California Berkeley’s Ingres (hence its name). It’s a flexible tool that works well across a wide range of platforms and, thanks to an extensible architecture, can support most workloads.

Microsoft has been supporting PostgreSQL on Azure since 2017, with its 2019 acquisition of Citus Data bringing significant experience with scaling and performance. Since then, Microsoft has begun to build out a family of PostgreSQL platform-as-a-service implementations, with a hyperscale version as part of its Cosmos DB platform and a managed flexible server for most day-to-day operations. It even supports you running your own PostgreSQL instances on Azure VMs.

Microsoft has adopted PostgreSQL as a key part of its growing data platform, and the company has been a major contributor and sponsor of the open source project. There are 19 contributors who work for Microsoft, and code is already being delivered for the next major release in 2026.

Introducing Azure HorizonDB

This week at Ignite 2025, Microsoft announced the latest member of its PostgreSQL family: Azure HorizonDB. Designed to be a scale-out, high-performance database, it’s intended to be a place for a new generation of PostgreSQL workloads, for when you need an operational database that’s fast and can scale automatically without requiring complex sharding operations.

In advance of Ignite, I spoke to Shireesh Thota, CVP Databases at Microsoft, about the new service. He described the rationale for a new PostgreSQL variant:

I think increasingly what we notice is that people either go into the bucket of, “I want to lift and shift my PostgreSQL that’s working in the community version on-premises, or maybe another cloud.” They want to move it to Azure. They want 100% Postgres. They want all extensions working. They just want something that really has the flexibility of performance and speed. Then Azure Database for PostgreSQL, the existing version is perfect. Somebody who wants to build an AI-native, cloud-native kind of a workload that may need a lot of storage, wants really fast latencies, significantly higher IOPS. Then you go to HorizonDB.

Certainly, the published performance data for Azure HorizonDB is impressive: Microsoft is claiming a three-times increase in throughput over the open source release when running transactional workloads. You can scale up to 3072 cores, with 128TB of storage and sub-millisecond commits. HorizonDB builds on Azure’s multiregion architecture with data replicated in multiple availability zones and automated maintenance and backups with minimal impact on operations. Such performance is needed for AI applications and for large-scale Kubernetes. As Thota notes, “These cloud-native workloads can really succeed on HorizonDB.”

Key to the performance boost are changes to the architecture of the database, separating compute and storage and allowing them to scale independently. If you need more compute, Horizon DB will give it to you. If you need more read replicas, it’ll provision them.

Using Azure HorizonDB for AI

On top of compatibility with most standard PostgreSQL features, Microsoft has added its own features that support modern AI applications, with fast DiskANN-based vector search as part of retrieval-augmented generation (RAG) applications and model tuning. Using DiskANN’s new advanced filtering will give you a significant performance boost over PostgreSQL’s standard vector search, and its hybrid in-memory and disk search allow you to work with the largest vector indexes without significant performance impairments. Also, using the new filtered graph traversals makes queries up to three times faster.

Microsoft’s tools help you bring AI models inside your queries, using Microsoft Foundry to conduct AI operations as part of a SQL query. Managed models let you pick and choose from a list of default models in the Azure Portal, or you can bring your own Microsoft Foundry models. This allows you to do things like generating embeddings for query results as you write them to a vector index table without leaving the database. Other options let you use AI-based semantic searches or summarize results and provide insights into customer comments. Thota describes the process as a simple one: “You keep your SQL structure and invoke our semantic operators in the right places.”

It has built-in integration with Azure’s enterprise tools, adding support for encryption, Entra ID, and private endpoints so that cloud-hosted data can only be accessed by your own systems and applications. Added security comes from support in Azure Defender for Cloud to keep sensitive data protected. “Our core cohort of our customers are enterprises, and I want to make sure that we build something for both enterprises as well as developers,” Thota says. HorizonDB will initially be available in a small number of Azure regions, with limited access to the preview release.

Managing PostgreSQL in VS Code

Outside the database, Microsoft has released a general availability version of its Visual Studio Code PostgreSQL extension. This adds database development and management tools to your development environment, connecting to on-premises and in-cloud PostgreSQL instances, including HorizonDB. It’s important to note that this is a tool for any and all PostgreSQL implementations. You’re not limited to working only in Azure; you can use it with any database that implements the PostgreSQL APIs.

Tools in the extension allow you to visualize database schema, drilling into tables and displaying joins. You can display complex data structures and zoom in to specific tables as needed. Another set of visualizations delivers a server dashboard that drills down into various metrics to help you understand how your database is running and where you can improve performance.

With Microsoft positioning Visual Studio Code as its AI development tool, both for creating AI applications and using AI, the PostgreSQL tool provides an agent for its GitHub Copilot tools. Natural language queries help you refine queries and design databases, and they use the same metrics as the server dashboard to help improve operations.

Bringing Oracle to PostgreSQL

HorizonDB’s performance improvements make it a good target for migration from existing relational databases, which can reduce licensing costs—especially for databases that have a per-core licensing model. Tools in the Visual Studio Code PostgreSQL extension help migrate Oracle schemas to Azure-hosted PostgreSQL, using AI tools to handle transformations based on best practices. To avoid problems, it allows you to validate its output in a Scratch database before you deploy the resulting database structure.

The tool works with more than just databases; it also helps you update application code to work with the new schema. Not everything will be updated automatically. To reduce the risks of hallucinations, it flags elements and code that can’t be migrated so you can perform manual updates. Not all Oracle features will migrate, as proprietary SQL extensions may not map to PostgreSQL’s standards-based approach.

Mirroring in Fabric

Data is increasingly important for businesses, with the growing capabilities of analytical platforms like Microsoft’s Fabric. HorizonDB and other operational databases are part of this approach, as they will mirror their tables into Fabric without affecting your applications. This brings near-real-time business data into an analytical platform for use in dashboards and AI applications. There’s no need for complex ETL to go from a row-based store to a column-based one, as it’s all handled by the platform. Microsoft won’t detail a timeline for bringing HorizonDB to Fabric, but it is part of the road map.

PostgreSQL is an important part of Microsoft’s data platform. Its open source foundations make it easy to develop outside Azure and then configure as part of deploying an application. HorizonDB takes it further, with support for at-scale cloud-native applications and for embedded AI. At the same time, mirroring operational, transactional data from PostgreSQL into Fabric ensures that your analytic applications have access to up-to-date information, making it easier to make business decisions without having to wait for data.

Data science and machine learning teams face a hidden productivity killer: annotation errors. Recent research from Apple analyzing production machine learning (ML) applications found annotation error rates averaging 10% across search relevance tasks. Even ImageNet, computer vision’s gold standard benchmark, contains a 6% error rate that MIT CSAIL discovered in 2024—errors that have skewed model rankings for years.

The impact extends beyond accuracy metrics. Computer vision teams spend too much of their time on data preparation and annotation, with quality issues creating development bottlenecks where engineers spend more time fixing errors than building models. Teams implementing manual quality control report five to seven review cycles before achieving production-ready data sets, with each cycle requiring coordination across annotators, domain experts, and engineers.

The financial implications follow the 1x10x100 rule: annotation errors cost $1 to fix at creation, $10 during testing, and $100 after deployment when factoring in operational disruptions and reputational damage.

Why current annotation tools fall short

Existing annotation platforms face a fundamental conflict of interest that makes quality management an afterthought rather than a core capability. Enterprise solutions typically operate on business models that incentivize volume—they profit by charging per annotation, not by delivering performant downstream models. This creates incentives to annotate ever increasing amounts of data with little motivation to prevent errors that would reduce billable work. Their black-box operations provide minimal visibility into QA processes while demanding $50,000+ minimum engagements, making it impossible for teams to understand or improve their annotation quality systematically.

Open-source alternatives like Computer Vision Annotation Tool (CVAT) and Label Studio focus on labeling workflows but lack the sophisticated error detection capabilities needed for production systems. They provide basic consensus mechanisms—multiple annotators reviewing the same samples—but don’t offer prioritization of which samples actually need review or systematic analysis of error patterns.

These shortcomings force a telling statistic: 45% of companies now use four or more annotation tools simultaneously, cobbling together partial solutions that still leave quality gaps. The result is a costly, multi-step process where teams cycle through initial annotation, extensive manual QA, correction rounds, and re-validation. Each step adds weeks to development timelines because the underlying tools lack the intelligence to identify and prevent quality issues systematically.

Modern ML development demands annotation platforms that understand data, not just manage labeling workflows. Without this understanding, teams remain trapped in reactive quality control cycles that scale poorly and consume engineering resources that should be focused on model innovation.

A data-centric annotation solution

Voxel51’s flagship product, FiftyOne, fundamentally reimagines annotation quality management by treating it as a data understanding problem rather than a labeling workflow challenge. Unlike traditional platforms that focus on creating labels, FiftyOne helps teams work smarter by identifying which data actually needs annotation attention and where errors are most likely to occur.

Our data-centric approach represents a paradigm shift from reactive quality control to proactive data intelligence. Instead of blindly labeling entire data sets or reviewing random samples, the platform uses ML-powered analysis to prioritize high-impact data, automatically detect annotation errors, and focus human expertise where it matters most.

FiftyOne leverages machine learning to identify specific, actionable quality issues. This methodology recognizes that annotation errors aren’t random—they follow patterns driven by visual complexity, ambiguous edge cases, and systematic biases that can be detected and corrected algorithmically.

This intelligence transforms annotation from a cost center into a strategic capability. Rather than accepting 10% error rates as inevitable, teams can systematically drive down error rates while reducing the time and cost required to achieve production-quality data sets. FiftyOne is backed by an open-source community with three million installs and teams from Microsoft, Google, Bosch, Ford, Raytheon, Berkshire Grey, and more.

Automated error detection with mistakenness scoring

FiftyOne’s compute_mistakenness() capability identifies potential annotation errors by analyzing disagreement between ground truth labels and model predictions. This ML-powered approach ranks errors by likelihood and impact, transforming weeks of manual review into hours of targeted correction.

import fiftyone.brain as fob

# Automatically detect likely annotation errors
fob.compute_mistakenness(dataset, "predictions", label_field="ground_truth")

The system generates several error indicators:

• mistakenness: Likelihood that a label is incorrect (0-1 scale)
• possible_missing: High-confidence predictions with no ground truth match
• possible_spurious: Unmatched ground truth objects likely to be incorrect

from fiftyone import ViewField as F

# Show most likely annotation mistakes first
mistake_view = dataset.sort_by("mistakenness", reverse=True)

# Find highly suspicious labels (>95% error likelihood)
high_errors_view = dataset.filter_labels("ground_truth", F("mistakenness") > 0.95)

# Identify samples with missing annotations
missing_objects_view = dataset.match(F("possible_missing") > 0)

FiftyOne’s interactive interface enables immediate visual verification of flagged errors. Teams can quickly confirm whether detected issues represent actual annotation mistakes or model limitations, focusing human expertise on genuine problems rather than reviewing random samples.

Voxel51

This intelligent prioritization typically achieves significantly faster convergence to accurate labels compared to random sampling approaches, with customers like SafelyYou reporting a 77% reduction in images sent for manual verification.

Patch embedding-based pattern discovery

FiftyOne’s patch embedding visualization exposes quality issues invisible to traditional metrics. The platform’s similarity analysis projects samples into semantic space, revealing clusters of similar images with inconsistent annotations.

In other words, embeddings finds groups of similar objects that should be labeled the same way but aren’t (consistency-driven error detection).

import fiftyone as fo
import fiftyone.brain as fob
import fiftyone.zoo as foz

# Path to BDD100k dataset files
source_dir = "/path/to/bdd100k-dataset"

# Load dataset 
dataset = foz.load_zoo_dataset("bdd100k", split="validation", source_dir=source_dir)

# Compute patch embeddings using pre-trained model
model = foz.load_zoo_model("mobilenet-v2-imagenet-torch")

gt_patches = dataset.to_patches("detections")
gt_patches.compute_patch_embeddings(
    model=model, patches_field='detections',
    embeddings_field='patch_embeddings',
)


# Generate embedding visualization
results = fob.compute_visualization(
    gt_patches, embeddings='patch_embeddings',  brain_key="img_viz"
)

# Launch interactive visualization
session = fo.launch_app(gt_patches)

Clusters can be used to identify vendor-specific annotation errors invisible to statistical quality metrics—errors that only became apparent when visualizing the semantic similarity of misclassified samples.

Voxel51

Similarity search for quality control

Once you find one problematic annotation, similarity search becomes a powerful tool to find all related errors. Click on a mislabeled sample and instantly retrieve the most similar images to check if they have the same systematic labeling problem.

FiftyOne’s similarity search transforms “find more like this” from manual tedium into instant discovery. Index your data set once, then instantly retrieve visually similar samples through point-and-click or programmatic queries.

import fiftyone as fo
import fiftyone.brain as fob
import fiftyone.zoo as foz

# Load dataset
dataset = foz.load_zoo_dataset("quickstart")

# Index images by similarity
fob.compute_similarity(
    dataset,
    model="clip-vit-base32-torch",
    brain_key="img_sim"
)

# Sort by most likely to contain annotation mistakes
mistake_view = dataset.sort_by("mistakenness", reverse=True)

# Query the first sample and find 10 most similar images
query_id = mistake_view.take(1).first().id
similar_view = dataset.sort_by_similarity(query_id, k=10, brain_key="img_sim")

# Launch App to view similar samples and for point-and-click similarity search
session = fo.launch_app(dataset)

Key capabilities include instant visual search through the App interface, object-level similarity indexing for detection patches, and scalable back ends that switch from sklearn to Qdrant, Pinecone, or other vector databases for production.

Remove problematic samples before they’re sent to annotators

FiftyOne’s Data Quality workflow scans data sets for visual issues that commonly lead to annotation mistakes. The built-in analyzer detects problematic samples—overly bright/dark images, excessive blur, extreme aspect ratios, and near-duplicates—that annotators often label inconsistently.

How the Data Quality workflow prevents annotation errors:

• Brightness/blur detection: Identifies low-quality images where annotators guess labels
• Near-duplicate finder: Reveals inconsistent annotations across visually identical samples
• Extreme aspect ratios: Flags distorted images that confuse annotators about object proportions
• Interactive thresholds: Adjusts sensitivity to explore borderline cases where quality degrades

Voxel51

Teams like Berkshire Grey achieved 3x faster investigations by using the tagging system to quarantine problematic samples, preventing bad annotations from contaminating model training. This transforms quality control from reactive debugging into proactive prevention.

Works with existing annotation tools and pipelines

Rather than forcing teams to abandon existing annotation infrastructure, FiftyOne can integrate seamlessly with any platform including CVAT, Labelbox, Label Studio, and V7 Darwin. The platform’s annotate() API uploads samples directly to these services while maintaining complete provenance tracking. After correction, load_annotations() imports updated labels back into FiftyOne for validation.

This integration extends throughout the platform. FiftyOne works natively with PyTorch, TensorFlow, and Hugging Face, enabling quality assessment within existing ML pipelines. Moreover, FiftyOne’s plugins architecture enables rapid development of custom functionality tailored to specific workflows.

FiftyOne’s data-centric approach offers automated error detection that reduces quality assessment time by 80%, improves model accuracy by 15% to 30%, and delivers up to 50% operational efficiency gains. By emphasizing understanding and improving data set quality through ML-powered analysis, FiftyOne differentiates itself from traditional labeling platforms—all while maintaining an open-core foundation that ensures transparency and flexibility.

For engineering teams drowning in annotation quality issues, the solution isn’t better labeling tools—it’s better data understanding. FiftyOne transforms annotation quality from a manual bottleneck into an automated, intelligent process that scales with modern ML development needs.

—

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.

Microsoft Agent 365 has been introduced as a control plane to help organizations deploy and manage AI agents at scale.

Unveiled November 18, Agent 365 is available through Microsoft’s Frontier program for early access to AI technologies. Agent 365 lets users manage an organization’s agents at scale, regardless of where these agents are built or acquired, Microsoft said. Agent 365 integrates with Microsoft productivity and business tools, allowing employees to work smarter, faster, and more creatively with agents, according to Microsoft.

Agent 365 integrates with Microsoft’s security solutions including Microsoft Defender, Microsoft Entra, and Microsoft Purview to protect and govern agents; integrates with the Microsoft 365 productivity apps including Word, Excel, Outlook, and the Work IQ intelligence layer to provide work context and accelerate productivity; and integrates with the Microsoft 365 admin center to manage agents. The suite delivers unified observability across an entire agent fleet through telemetry, dashboards, and alerts, allowing IT organizations to track every agent being used, built, or brought into the organization, Microsoft said.

IT administrators can get early access to Agent 365 by signing up online. Microsoft said that Agent 365 unlocks five capabilities intended to make enterprise-scale AI possible:

• Registry, to view all agents in an organization, including agents with agent ID, agents registered by the user, and shadow agents.
• Access control, to bring agents under management and limit access only to needed resources.
• Visualization, to explore connections between agents, people, and data, and monitor agent performance.
• Interoperability, by equipping agents with applications and data to simplify human-agent workflows. They would be connected to Work IQ to provide context of work to onboard into business processes.
• Security, to protect agents from threats and vulnerabilities and remediate attacks that target agents.

With Fabric IQ, Microsoft is adding new semantic intelligence capabilities to its unified data and analytics platform, Fabric, that it says will help enterprises maintain a common data model and automate operational decisions.

We’ll be hearing a lot more about “IQ” from Microsoft, which has also just introduced Work IQ, the semantic intelligence layer for Microsoft 365, and Foundry IQ, a managed knowledge system for grounding AI agents via multiple knowledge repositories, that together with Fabric IQ form what Microsoft calls a “shared intelligence layer” for the enterprise.

Fabric IQ will offer five integrated capabilities, Microsoft said: the ability to create an ontology or shared model of business entities, relationships, rules, and objectives; a semantic model extending business intelligence definitions beyond analytics to AI and operations; a native graph engine to enable multi-hop reasoning with data; virtual analysts called data agents that can answer business questions; and autonomous operations agents that can reason, learn, and act in real time.

The ontology is the foundation of all of this, a living structure capturing key business concepts, the company said. It contrasted it with traditional data modelling, saying that it can be created and evolved by business experts using a no-code tool (still in preview), without support from engineers — yet still offering IT managers the control to secure, approve, version, and manage it.

Constellation Research principal analyst Michael Ni was skeptical: “There is upfront work for IT. Ontologies don’t build themselves,” he said.

IT teams may be able to capitalize on work they have already done: Organizations using Power BI can import its data models as the basis for their ontology, Microsoft said.

From ontology to autonomy

For organizations not already invested in the Fabric ecosystem, adoption of IQ will likely take longer, warned Suhas AR, associate practice leader at HFS Research. “Key hurdles include agreeing on shared business definitions, ensuring that data permissions are carried through to AI agents, and maintaining clean and reliable real-time data feeds for automation. Teams also need some new skills and processes to govern these agents as they evolve.”

The endgame of all this describing of data is to ensure that workers, both human and AI, have a shared understanding of what the data means in the real world, so that they can analyze and act on it together.

Operations agents “monitor the business in real time, reason over live conditions, evaluate trade-offs, and take actions automatically to advance business outcomes,” Microsoft said in a blog post announcing Fabric IQ.

Such agents are capable of much more than just alerting or simple workflow automation, Microsoft said, enabling decisions at scale in seconds, without the need for interminable meetings.

Who benefits?

While successfully implementing Fabric IQ is likely to involve IT teams in some up-front heavy lifting, they’ll benefit from a longer-term reduction of operational effort, analysts say.

Microsoft-first enterprises with strong central governance stand to gain the most, Suhas said, cautioning enterprises with low data-maturity, or not committed to Microsoft’s data stack, to “wait and watch.”

Constellation Research’s Ni sees good reasons for adopting Fabric IQ: “These benefits include consistent semantics, fewer one-off models, less duplicated logic, and a shared decision layer that lowers downstream maintenance as enterprises ramp up iteration on decision automation and AI-driven automation,” he said.

Stephanie Walter, practice leader of AI Stack at HyperFrame Research, doesn’t expect IT teams’ data modelling workload to disappear with the introduction of Fabric IQ’s ontology, she does see it shifting towards controlling security, and approving the changes made by business users.

Other analysts have reservations, fearing complex, time-intensive deployments and vendor lock-in.

While Fabric IQ’s ontology will provide a clear basis for communication between employees and autonomous agents it will also, according to Moor Insights and Strategy principal analyst Robert Kramer, tie the enterprise to it.

“The more an enterprise builds on this semantic layer, the harder it becomes to move that logic elsewhere.,” Kramer said.

Fabric costs

Suhas, too, pointed to the heavy switching costs enterprises would face if they wanted to move to another platform that didn’t support the Fabric IQ ontology.

And if, after spending on the creation and governance of the ontology, and all the attendant Fabric IQ services, an enterprise was unable to drive meaningful agent adoption, then all that investment would be for nothing.

Predicting or measuring that investment will be a challenge in itself. Fabric IQ is treated as a workload in Microsoft Fabric, just like Data Factory, Analytics, Databases, Real-Time Intelligence, and Power BI, the company said.

“It uses the same unified Fabric licensing model and runs on Fabric capacity. There is no separate SKU or add-on fee,” said Yitzhak Kesselman, Microsoft CVP for Messaging and Real-Time Analytics Platform.

Those costs are tracked via a bewildering array of Fabric capacity invoice meters for underlying infrastructure usage.

Microsoft hasn’t yet published the billing meters for the Ontology item, but plans to do so later this week, with billing beginning in the first half of 2026, he said. Billing for other Fabric items will remain unchanged.

More Microsoft Ignite 2025 news:

• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft touts scalability of its new PostgreSQL-compatible managed database
• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft bets on agentic AI for cloud ops, but analysts doubt the pitch

Microsoft is previewing a third PostgreSQL-compatible managed database for its cloud, Azure HorizonDB, that it hopes will prove attractive for modern workloads and for legacy application modernization.

The company already offers two databases compatible with PostgreSQL, the database interface proving popular with developers of AI applications: Azure Cosmos DB for PostgreSQL and Azure Database for PostgreSQL.

Azure HorizonDB differs from both the existing offerings in that it’s a shared-storage, scale-out compute architecture explicitly engineered for AI-era application patterns, said Stephanie Walter, practice lead of the AI stack at HyperFrame Research.

“In contrast, Azure Database and Cosmos DB for PostgreSQL remains the general-purpose managed Postgres for traditional apps and the distributed, sharded option for horizontally scaled multi-tenant workloads respectively,” she said.

“HorizonDB is the AI-era Postgres tier, where transactional modernization and vector-driven applications finally land in the same engine. It’s meant to be the place where you both modernize legacy transactional systems and bolt on RAG, agents, and embeddings-heavy features without stitching together separate databases and ML endpoints,” said Walter.

One of the things that has made PostgreSQL so popular with AI developers is its support for vector indexes, said Microsoft, adding that in Azure HorizonDB it is extending that support with advanced filtering capabilities in the DiskANN vector index that “enable query predicate pushdowns directly into the vector similarity search”. This common optimization technique filters data as early as possible in the pipeline to avoid unnecessary data processing and transmission.

“That early pruning reduces engine work and can improve long-tail latency on vector-plus-metadata queries,” said IDC research director Devin Pratt.

Microsoft also said HorizonDB will make it easier for developers to integrate and manage generative, embedding, and reranking models from Microsoft Foundry with zero configuration.

That, said Pratt, will help reduce glue code, simplify audits, and shorten the path from prototype to production by keeping the data and the models close under one governance plane.

PostgreSQL elsewhere

Microsoft is not the only cloud provider offering PostgreSQL-compatible database services, but it is seeking to differentiate itself.

“Similar approaches exist in offerings such as AlloyDB AI, Snowflake Cortex, Aurora PostgreSQL with Bedrock/SageMaker, but HorizonDB emphasizes model management and vector search together inside the Postgres service,” Pratt said.

Another key differentiator for Microsoft, said Walter, is that Azure HorizonDB’s model layer is plugged into AI Foundry and the broader Azure AI ecosystem, so the same models and governance primitives can be reused across apps, agents, and data services.

Microsoft plans to add mirroring for Azure HorizonDB to its unified data and analytics platform, Fabric.

This will provide Fabric with a more solid, operational database foundation, according to Bradley Shimmin, practice leader of data, analytics, and infrastructure at The Futurum Group.

Fabric already supports mirroring of Azure Database for PostgreSQL.

It looks like you’re migrating to HorizonDB. Would you like help with that?

Although a big part of Microsoft’s story for Azure HorizonDB is that it’s ideal for serving up data to modern AI applications, it’s also pitching it as a way to modernize legacy workloads currently running on Oracle.

To help with that, it’s integrating GitHub Copilot into the PostgreSQL Extension for Visual Studio Code.

“Teams of engineers can work with GitHub Copilot to automate the end-to-end conversion of complex database code using rich code editing, version control, text,” Microsoft wrote in the blog post announcing Azure HorizonDB.

This feature, said Futurum’s Shimmin, “can help Microsoft displace established rivals, most notably Oracle, giving those customers another reason to make the move to Microsoft’s platform.”

More Microsoft Ignite 2025 news:

• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft unveils Agent 365 to help IT manage AI ‘agent sprawl’
• Microsoft bets on agentic AI for cloud ops, but analysts doubt the pitch

Google has launched Gemini 3 and integrated the new AI model into its search engine immediately, aiming to push advanced AI features into consumer and enterprise products faster as competition in the AI market intensifies.

The release brings new agentic capabilities for coding, workflow automation, and search, raising questions about how quickly businesses can adopt these tools and what impact they may have on existing IT operations.

Google also introduced new agent features, including Gemini Agent and the Antigravity development platform, designed to automate multi-step tasks and support software teams.

Gemini 3 comes in a Deep Think mode as well, which “outperforms Gemini 3 Pro’s already impressive performance on Humanity’s Last Exam (41.0% without the use of tools) and GPQA Diamond (93.8%). It also achieves an unprecedented 45.1% on ARC-AGI-2 (with code execution, ARC Prize Verified), demonstrating its ability to solve novel challenges.”

The update introduces a generative UI that can build custom visual layouts in response to prompts, allowing Gemini to present answers in interactive, application-like formats.

Gemini 3 also brings long-context reasoning and improved multimodal support, enabling the model to handle larger documents, richer datasets, and complex multimedia inputs, the company said.

Immediate integration

For enterprise IT leaders, the key question is how quickly Gemini 3’s capabilities will be integrated into real-world workplace applications and whether agentic features like Deep Think and Antigravity can deliver measurable productivity gains without introducing new operational risks.

According to Sanchit Vir Gogia, chief analyst at Greyhound Research, Google’s decision to embed Gemini 3 directly into Search from day one is one of the most consequential shifts in the enterprise AI market this year.

“This is not an AI feature layered on top of Search,” Gogia said. “It is a fundamental rewrite of the global information distribution engine that billions rely on every day. For enterprises, this marks a decisive moment where AI is no longer a separate capability but the default interpreter of user intent, workflow context, and knowledge retrieval.”

By tightly coupling Gemini 3 with Search, Google is converting its most powerful distribution surface into a permanent AI gateway, which reshapes how organizations consume intelligence and structure their digital workplace experience, Gogia said.

Others suggested that the integration could also reshape how enterprises rely on Google’s ecosystem.

“For enterprises, Google Search might become a one-stop shop for all secondary information, whether it is normal search or for generating content,” said Sharath Srinivasamurthy, research vice president at IDC.  “Also, the ad business for Google will go through a change as it will consider AI-driven search and prompts to push relevant ads. The search and prompts (now) will start feeding into Google training models, which will eventually make the search and Gemini’s responses better.”

Charlie Dai, VP and principal analyst at Forrester, said that Google’s integration decisions reflect its confidence in the model’s performance and its native multimodal capabilities. It also shows Google’s intent to monetize AI through core products rather than standalone offerings.

“As enterprise search becomes an AI gateway, enterprise CIOs must have a holistic view on the dependencies in the AI stack for long-term observability and governance,” Dai added.

Automating multi-step workflows

While Google is positioning Gemini 3’s agentic capabilities as a step toward hands-free automation, analysts caution that most enterprises are still far from running fully autonomous workflows. Srinivasamurthy said the complexity of real-world processes remains a major barrier.

“Workflows that cut across multiple systems, involve human exceptions, compliance reviews, or high-risk decision points still require careful orchestration and typically human-in-the-loop supervision,” Srinivasamurthy added. “Enterprise adoption is in its early stages, and scaling from pilot or siloed implementations to organization-wide workflows continues to be a significant challenge.”

Dai agreed that while agentic tools like Gemini Agent and Antigravity with increasingly powerful reasoning capabilities will continue to move enterprises closer to workflow automation, safety hinges on robust guardrails and AI readiness of enterprise data.

“CIOs need governance frameworks for identity, data lineage, and action approval, plus continuous monitoring for non-deterministic behavior,” Dai said.

Gogia said that Gemini Agent and Antigravity will unlock meaningful productivity gains, but only once enterprises build the frameworks required to manage autonomous systems responsibly. “The technology may be ready for demonstration, but enterprise governance is still catching up,” Gogia said. “Organizations that scale agentic automation prematurely may expose themselves to operational, regulatory, and reputational risks that outweigh the short-term benefits.”

When I was tasked with modernizing our enterprise document management system, I knew the stakes were high. We were managing millions of documents, and our legacy architecture was buckling under the load. Query times were unpredictable, scaling was a constant battle and costs were spiraling out of control.

The breakthrough came when I stopped thinking about documents as monolithic entities and started viewing them as two distinct workloads: high-frequency metadata queries and low-frequency content operations. This architectural shift transformed our system from a performance bottleneck into a horizontally scalable, cost-efficient platform that consistently delivers sub-300ms query times even under heavy load.

The core insight: Not all data is created equal

The fundamental problem with traditional document management systems is that they treat metadata and content as a single unit. When a user searches for “all employment contracts for customer X,” the system must wade through both the searchable attributes and the heavyweight file content, even though the search only needs the metadata.

I realized that these two types of data have completely different performance characteristics. Metadata operations are classic Online Transaction Processing (OLTP) workloads: frequent, small, latency-sensitive transactions. Content operations are the opposite: infrequent, large, bandwidth-intensive transfers that can tolerate higher latency.

By separating these workloads, I could optimize each independently. Metadata went into a high-performance NoSQL database — choosing from options like Amazon DynamoDB, Google Cloud Firestore or Azure Cosmos DB based on your cloud provider — configured in on-demand mode for automatic scaling. Document content lives in commodity cloud object storage such as Amazon S3, Google Cloud Storage or Azure Blob Storage. Each document gets a globally unique identifier (unique document ID) that serves as the link between its metadata record and its file in object storage.

The performance impact was immediate. Our metadata queries dropped from seconds to ~200 milliseconds at the median, with 95th percentile latency under 300ms. More importantly, these numbers stayed consistent even as we scaled to handle over 4,000 requests per minute with zero errors.

Making the API layer do the heavy lifting

The separation of metadata and content only works if you enforce it architecturally, which is where an API-first design becomes critical. I created distinct REST endpoints for metadata operations versus content operations. When a client queries “show me all documents for member 12345,” that request hits the metadata API, retrieves the results from the fast NoSQL database and returns them without ever touching object storage.

Here’s how I structured the API:

Metadata APIs:

• GET /api/v1/members/{member-id}/document-metadata: Retrieve all document metadata for a specific member
• GET /api/v1/members/{member-id}/document-metadata/{unique-document-id}: Retrieve metadata for a single document
• PATCH /api/v1/members/{member-id}/document-metadata/{unique-document-id}: Update metadata for a single document

Document APIs:

• POST /api/v1/members/{member-id}/documents: Upload a new document
• GET /api/v1/members/{member-id}/documents/{unique-document-id}: Retrieve a document
• DELETE /api/v1/members/{member-id}/documents/{unique-document-id}: Delete a document

The content is only fetched when explicitly requested by a unique document ID. This explicit separation prevents the system from accidentally coupling the two workloads. It also creates a stable contract that allows the frontend and backend to evolve independently.

Beyond performance, the API layer became our enforcement point for security, rate limiting and request validation. We implemented OpenID Connect Authorization Code Flow with Proof Key for Code Exchange (PKCE) for user facing single-page application (SPA) and OAuth 2.0 Client Credentials Flow for machine-to-machine (M2M) communication, keeping the architecture cloud-agnostic by relying on standards rather than proprietary identity services. Authorization is enforced using Role-Based Access Control (RBAC), with the API layer serving as the policy enforcement point that validates a user’s roles and permissions before granting access to the underlying data stores.

All communication uses TLS 1.2 or higher. Both the metadata datastore and object store have server-side encryption enabled. By relying on standardized protocols and universally available features rather than provider-specific key management services, the architecture remains portable across cloud platforms.

The data modeling decisions that matter

Getting the NoSQL data model right was crucial. Instead of storing verbose strings like “Legal” or “Employment Contract” in every metadata record, I used numeric identifiers (e.g., 101 for “Legal,” 10110 for “Employment Contract”) that reference a separate, cached category table. This normalization reduced storage costs and made updates trivial. Want to rename a category or add multi-language support? Update the reference table once instead of millions of document records.

Here’s what a typical metadata record looks like:

{
  "unique_document_id": "aGVsbG93b3JsZA==",
  "member_id": "123456",
  "file_name": "employment_contract.pdf",
  "document_category_id": 101,
  "document_subcategory_id": 10110,
  "document_extension": ".pdf",
  "document_size_in_bytes": 245678,
  "date_added": "2025-09-20T12:11:01Z",
  "date_updated": "2025-09-21T15:22:00Z",
  "created_by_user_id": "u-01",
  "updated_by_user_id": "u-02",
  "notes": "Signed by both parties"
}

For query patterns, I leveraged secondary indexes aggressively. While the primary table uses the unique document ID as its key, a secondary index organized by member ID and document category enables efficient queries like “retrieve all documents of a certain category for a given member” without expensive table scans.

The schema-on-read model of NoSQL proved invaluable for evolution. When we needed to add a new optional metadata field, there was no risky ALTER TABLE statement or downtime. New documents simply started including the attribute, while existing documents continued working without it. This agility allowed us to respond to new requirements in hours instead of weeks.

Building in disaster recovery and data resiliency

A comprehensive disaster recovery strategy was essential for business continuity. I incorporated resiliency at both the metadata and content layers.

For the metadata store, I enabled Point-in-Time Recovery (PITR), a feature available across major managed NoSQL services. PITR continuously backs up data, allowing the database to be restored to any specific second within a retention window (typically 7 to 35 days). This protects against logical data corruption from accidental writes or deletions.

For document content, I implemented object versioning and cross-region replication. Versioning preserves previous versions of files, protecting against accidental overwrites or deletions. Cross-region replication automatically copies objects to a storage in a different geographical region, ensuring data availability even during a regional outage.

This multi-layered approach to disaster recovery — combining PITR for metadata with versioning and replication for content — provides robust protection against a wide range of failure scenarios.

Managing the long-term lifecycle

One critical design decision was how to handle deletions. Rather than flagging records as deleted in the active table, I implemented an “archive-on-delete” pattern. When a document is deleted, its metadata record moves entirely to a separate archive table, while the file transitions to low-cost archival storage tiers like Amazon S3 Glacier, Azure Blob Storage Archive or Google Cloud Storage Archive.

This approach keeps the active metadata table lean and fast by containing only active records. It also drives significant cost savings — archival storage costs a fraction of standard storage, and we’re not paying for hot database capacity to store cold data. All major cloud providers support these archival tiers with similar pricing models, so the pattern remains cloud-agnostic.

The trade-offs worth making

No architecture is perfect, and this one embraces eventual consistency as a deliberate trade-off for horizontal scalability. In practice, this means there’s occasionally a sub-second window where a newly written document might not immediately appear in a query if it hits a different database replica.

For our use case — a document management system where humans are the primary users — this delay is imperceptible. For the rare programmatic workflows requiring immediate read-after-write consistency, NoSQL services typically offer strongly consistent reads on demand, though at slightly higher latency and cost.

This architecture isn’t ideal for every scenario. If you need complex, ad-hoc transactional queries across many metadata attributes, a traditional relational database might be better. But for high-volume content repositories, digital asset management and customer-facing applications with read-heavy workloads, the scalability and cost benefits are transformative.

The results: Performance and economics

The performance testing validated the architectural decisions. Under sustained load exceeding 4,000 requests per minute, our metadata retrieval API (returning 214 documents per member) maintained excellent performance:

Table 1. Performance metrics under sustained load

The cost model was equally compelling. For a system managing 10 million documents with an average file size of 100KB (1TB total storage), handling 20 million metadata reads and 1 million uploads per month, the estimated costs are remarkably similar across major cloud providers:

Table 2: Estimated monthly cost comparison (10M documents, 1TB storage) as on October 4^th, 2025

The pay-per-request serverless model means costs scale directly with usage, avoiding payment for idle capacity. This represents a dramatic reduction compared to traditional approaches requiring provisioned database compute resources for peak load.

Conclusion: A reusable pattern for modern document management

The separation of metadata and content workloads, enforced through an API-first architecture, proved to be a transformative approach for building a scalable, performant and cost-efficient document management system. By treating metadata as an OLTP workload optimized for a NoSQL database and content as bandwidth-intensive operations suited for object storage, we achieved true horizontal scalability with predictable low-latency performance.

The architecture’s cloud-agnostic design — relying on open standards for security and universally available managed services — ensures portability and resilience. The comprehensive disaster recovery strategy, combining PITR for metadata with versioning and replication for content, provides robust protection without vendor lock-in.

The empirical results validate the approach: sub-300ms query latency under heavy load, zero errors and monthly operational costs under $40 for a system managing 10 million documents. The deliberate trade-off of eventual consistency for scalability proved acceptable for our use case, with strongly consistent reads available when needed.

This architectural pattern represents a reusable blueprint that organizations can adopt to modernize their document management systems. By packaging these design principles, implementation patterns and infrastructure-as-code into a standardized template, teams can accelerate their adoption of cloud-native architectures and focus immediately on business logic rather than infrastructure complexity. The result is a foundation for next-generation document management systems capable of enterprise-scale performance and efficiency.

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

Clojure is one of the most fascinating branches of the programming family tree. It unites the high-design heritage of Lisp with practical, modern capabilities. For Java developers, Clojure can be an excellent expansion of their worldview. It offers an entirely different way of understanding and solving problems, while still running on the JVM and interoperating with Java.

The four key concepts of Clojure

The following four concepts are vital for understanding Clojure:

• Code as data
• Functional programming
• Immutability
• Concurrency

Let’s look at each of these in turn.

Code as data

The most remarkable thing you might notice when coming to Clojure from Java is that it is homoiconic, which means the code is written in the form of the language’s data structures. This practice, also known as code as data, results in very consistent syntax with a limited number of keywords and constructs. It also creates a meta-programming model using “syntax-aware” code templates (called macros).

The idea is that any snippet of Clojure code is also an instance of Clojure data. You will see this most frequently in the list syntax, because most of Clojure is written as lists. Here is a simple “Hello, InfoWorld” function in Clojure:

(defn hello-infoworld [] 
  (println "Hello, InfoWorld"))

The parentheses indicate a list in Clojure. So, the definition of this function is essentially just the definition of a list with a keyword (defn), a function name (hello-infoworld), an empty argument vector ([]), and the function body. The function body is also a list containing a function call (println) and the argument to that function (“Hello, InfoWorld”).

A list literal (defined with ()) is also how we define functions in Clojure. The [] vector is used specifically for data, rather than code execution, and is similar to the Java ArrayList.

Functional programming

Java has gradually become more versatile as a functional programming language, but Clojure was built from the ground up with functional programming principles in mind. In Java, the core concept is the object, whereas in Clojure it’s the function. In functional programming languages, the function is the most fundamental block of reusable functionality, and functions are first-class citizens that can be referenced with variables, returned as values, and passed as arguments (also known as higher-order functions).

In object-oriented programming, you combine state and behavior into objects. This is a very natural and intuitive model, and easy to understand. But as a software system becomes more complex, it can produce unexpected difficulties. These “programming-in-the-large” drawbacks have made functional programming more popular over time. It can be more challenging, initially, to grasp functional programming concepts, because you don’t have the object model to conceptualize with, but they are well worth learning.

Clojure is a great language for learning functional programming. For example, here is a (contrived) example of a function that takes another function as an argument:

(defn formal-greeting [name]
  (str "Greetings, " name "."))

(defn informal-greeting [name]
  (str "Hey, " name "!"))

;; A "higher-order" function:
argument
(defn greet [greeting-fn name]
  (greeting-fn name))

;; --- Using it ---

(greet formal-greeting "Dr. Smith")
;=> "Greetings, Dr. Smith."

(greet informal-greeting "Alex")
;=> "Hey, Alex!"

In Clojure, anything after a semicolon is not parsed, but used for comments. So, the ;=> is just a conventional way of noting the return of the function call. It’s also important to know that at the end of a function, the final expression is evaluated as the return value (so no “return” keyword is used). With these two points in mind, the above code is relatively easy to understand.

Read next: The top 4 JVM languages and why developers love them.

Immutability

The Clojure documents reflect a programming philosophy that has been deeply thought out. Here is what the documents have to say about immutability, or the separation of identity and state:

We need to move away from a notion of state as “the content of this memory block” to one of “the value currently associated with this identity”. Thus an identity can be in different states at different times, but the state itself doesn’t change. That is, an identity is not a state, an identity has a state.

A later statement in the document makes the point more concretely: “In Clojure’s model, value calculation is purely functional. Values never change. New values are functions of old, not mutations.” What this tells you is that functions are designed to accept and return values, not identities. That is different from object-oriented languages like Java, where objects are often passed in by reference, meaning the function can operate on the state of the object, creating side-effects, or effects on something outside of the function’s return value.

In Java, running the same function with the same input (the object reference argument) can produce different results, because the object’s state can be different. In Clojure, we avoid this possibility because functions only take or return values or other functions.

Clojure also uses immutable operations where data structures are commonly recreated to produce changes, instead of inline mutations like Java often uses. (This may sound inefficient, but Clojure is designed to handle this by sharing structures.)

Here is an example of adding to a collection:

;; `original-numbers` is an identity with the value `[1 2]`
(def original-numbers [1 2])

;; The `conj` function returns a NEW vector.
(def new-numbers (conj original-numbers 3))


original-numbers
;=> [1 2]  -- Unchanged original collection

new-numbers
;=> [1 2 3] -- A new collection with the joined values

The new part here is the conj function, which is Clojure’s universal mechanism for adding elements to a collection. It works for lists, sets, and maps. Here, we’ve just added 3 to the existing [1,2].

Because of Clojure’s immutability principle, this code creates a new Vector. This is because the original-numbers variable is an identity, which does not ever change. You can use the identity to produce new identities with new values based on it, but you can’t change it.

In Clojure, there is no direct reassignment of variables like there are in Java. Variables are created with an initial value, or they are produced by function results.

Concurrency

Concurrency is one of Clojure’s main goals. Immutability helps to make it simpler, but eventually we still need to deal with shared state, where many threads may access the same memory concurrently. Clojure includes several powerful concepts for managing shared state:

• Atoms: A simple mechanism for allowing a single value to be accessed safely by multiple threads. The developer just defines a normal function, and Clojure handles all the locking under the hood (though technically, it’s not locking, but “compare-and-swap” or CAS).
• Refs: A sophisticated “software transactional memory” system that allows for transactions on shared values, with commit and rollback operations similar to those in databases.
• Futures: A simple mechanism for offloading a chunk of work to another thread and retrieving the value at a later time.
• Promises: A way to wait for the completion of an asynchronous task executing on another thread.

Clojure is suited for all kinds of concurrent programming, from very simple to highly advanced. Here’s a simple example of how we might use an Atom to handle a multithreaded counter value:

;; Create an atom to hold the counter (initially 0)
(def counter (atom 0))

;; Define a function for one thread's worth of work
;; `swap!` atomically applies the `inc` function to the atom's value.
(defn do-work []
  (dotimes [_ 1000]
    (swap! counter inc)))

;; Use `future` to run our work on two separate threads
(def thread-1 (future (do-work)))
(def thread-2 (future (do-work)))

;; Dereferencing them with @
@thread-1
@thread-2

;; Read the final value of the atom
(println "Final count:" @counter)
;=> Final count: 2000

In this snippet, the @ character is syntax for “dereferencing” the threads, which in essence means to block on them, waiting for their completion (the completion of the futures).

The built-in swap! function and atom variable work together to safely allow mutating the state of the counter across threads. swap! and its related reset! function are special (as denoted by the exclamation mark), tasked with handling thread-safe access to the atom container.

The future function lets us run the work on a worker thread. The overall effect is easy to follow, and an effective use of multithreading with a single shared variable.

Conclusion

Clojure is a different way of thinking about programming, but it is a fully realized platform that offers a powerful conceptual and practical approach to modern software. This article touched on only the most fundamental aspects of Clojure. There is much more to discover, including the REPL interactive development command line and excellent, higher-level Clojure libraries used for common needs like web and enterprise development.

Text editors and IDEs tend to inspire devotion from their users. Vim and Emacs have long-standing power-user bases. Visual Studio Code, despite being far newer, has exploded in popularity thanks to its cross-platform support and overall flexibility. Any new editor, like any new programming language, faces a lot of incumbent competition.

Zed, a new editor built using Rust, is being pitched by its creators as “a next-generation code editor designed for high-performance collaboration with humans and AI.” Originally only available for Mac and Linux systems, it’s recently been released for Microsoft Windows, allowing a much broader base of users to try it out.

Zed should still be considered a pre-release offering; the release I looked at for this review was version 0.212.4. But enough features are in place to give a sense of what working with Zed is like, and how its approach differs from VS Code and other editors in the same class.

Setup and configuration

If you’re an existing VS Code user, when you run Zed for the first time, you can elect to import your VS Code or Cursor settings into Zed. This covers things like the projects you’ve recently worked on, but it doesn’t extend to Zed-specific settings like extensions, which are handled differently (more on this later).

Multiple themes are available out of the box, each with light and dark modes, and you can set Zed to use a base keymap derived from other popular editors—not just VS Code, but JetBrains products like IntelliJ IDEA and PyCharm, as well as Sublime Text, Atom, Emacs, and Cursor. Vim users can also activate a “Vim mode” and use modal command-based editing. It’s a nice touch that you can go back to this setup pane anytime and re-apply the settings.

Look and feel

A widely touted advantage of Zed is that it’s a platform-native application. Unlike VS Code, Zed doesn’t use Electron or another web-view wrapper; instead, it uses native GPU-accelerated code to render the UI. Everything resizes and reformats without jank, including multi-megabyte text files.

Foundry

Zed’s layout echoes most other modern editors. Files open in tabbed panes with panels on the sides, and the panels can be toggled on and off. By default, panels include a file browser for the directory currently in context as a project, real-time collaboration, outlining, version control, terminals, debugging/breakpoints, editor-wide notifications, and an interface for Zed’s agent. All can be redocked at the sides, although only some (such as the terminal panel) can be docked at bottom.

The top border of the editor doesn’t have an application context menu visible by default; instead, it shows the current project’s info. Click it and you get a neat quick-switch menu to bring any other instances of Zed into focus. To expose the menus, you click a hamburger icon at top left or hit F10.

If you’ve imported settings from another editor, you may find some of them don’t map directly to Zed. For instance, toggling word wrap in a file in VS Code is done with Alt-Z. In Zed, even with VS Code settings migrated, it’s Ctrl-K, Z.

AI integration

Zed has its own large language model for making edit predictions with code, called Zeta. It’s on by default, so I let it prompt me with suggestions while writing a sample Python application in Zed (a simple wiki that renders Markdown to HTML with templates).

Like most such tools currently, Zeta’s predictions are hit-or-miss. When writing the more boilerplate parts of the program, it offered some surprisingly accurate and useful code snippets. But anything outside of that only got in the way, so I toggled it off after writing the most predictable parts of the program. The model also tended to mangle the levels of indentation in inserted code, which is a big problem in Python.

Foundry

Zeta will collect training data from your codebase, but only if it identifies a compatible open source license file. Otherwise, collection is off by default. You can also toggle which kinds of files get edit predictions, or how aggressive they are—for example, you can instruct Zeta to only offer hints if the LSP for the language you are writing in doesn’t offer anything.

Also see: How AI is transforming IDEs into intelligent development assistants.

Two thousand predictions can be served on the free tier, with use-billed predictions available on the $10-a-month Pro plan. You can also connect Zed to most any other external agent (e.g., Claude Code) and use that. A handy kick-out panel lists all the major agents and services you can connect with.

Finally, you can disable all of Zed’s AI features by throwing a single switch.

Collaboration

Zed’s collaborative features are also baked into the product, not added by way of a plugin. Sign in with your GitHub credentials, and you can create or join a hierarchical set of “channels,” or virtual workspaces.

Channels have a default document, which can be edited in a shared manner by anyone with channel permissions. Projects you’re working on can be shared through a channel, which becomes shared-editable with people you choose. Channels also function as group voice-chat systems like what you might use on Discord or Slack.

Zed’s creators have noted that “Collaboration as it stands today is considered alpha, and for the time being, is free for all to use!” That, of course, leaves open the possibility that collaboration will become a paid feature in the future. It may also be possible in the future to self-host collaboration, but there is currently no officially supported path to doing so.

Extensions

Zed resembles VS Code, and many other modern editors, in that the user can expand its functionality with third-party extensions. Even at this early stage of its development, Zed has a surprising number of extensions available, even for relatively niche uses. For instance, there’s an extension for syntax highlighting for code used by Python’s Cython package.

Some functionality one might expect by way of extensions is baked directly into Zed, such as Python support. One downside of this setup is that any upgrades are tied to updates to Zed itself. But even in this early version, Zed is updated quite frequently.

Another possible issue with the way Zed handles extensions is, there’s no mechanism for toggling them on or off on a per-project basis. To disable an extension, you have to uninstall it completely. (There is an open feature request to change this.)

Conclusion

There’s no question Zed provides a comfortable and performant experience for the developer, delivered in a more economical, platform-native package than web-UI projects like VS Code. It’s also clear the core of Zed—the editor itself, and most of its extensions—will remain free.

What’s still up in the air is how much of the rest of Zed’s feature set will eventually become a paid option (the language model and collaborative editing in particular), and how that will in time compete with the existing ecosystem of similar tools, both free and for-pay. For now, though, Zed is well worth taking for a test drive.

Software development is fraught with peril. For any development task, there are a million ways to do it wrong, and the one correct way is a small, narrow trail that winds quietly through the forest. It takes experience to know the path and to avoid the dangerous pitfalls along the way.

The following is a list of seven hard-won lessons from many trips into the dark forest. It is an opinionated look at what to do and what not do when navigating the treacherous trail of coding an application.  It’s far too easy to stray from the correct path, and these notions will help you stay on course and arrive safely at your destination with a minimum of snags, missteps, and misadventures.

Follow this advice and avoid the brambles.

Look both ways before crossing a one-way street

In the United Kingdom, they drive on the “wrong” side of the road. The Brits realize that visitors are not always aware of that, because on the crosswalks in London, there is text painted on the ground as you step off the curb that says “Look right.” Being American, my habit is to look left, so I appreciated the advice.

PxHere

But I couldn’t shake the habit, so I ended up looking both ways. 

And I realized that looking both ways was a good metaphor for coding: Protect against the impossible, because it just might happen. Code has a way of surprising you, and it definitely changes. Right now you might think there is no way that a given integer variable would be less than zero, but you have no idea what some crazed future developer might do. 

Go ahead and guard against the impossible, and you’ll never have to worry about it becoming possible.

Never make one thing do two things

Oh man, this is my personal pet peeve. There is no end to the trouble caused by having one thing do more than one thing. 

If you’re ever tempted to reuse a variable within a routine for something completely different, don’t do it. Just declare another variable. If you’re ever tempted to have a function do two things depending on a “flag” that you passed in as a parameter, write two different functions. If you have a switch statement that is going to pick from five different queries for a class to execute, write a class for each query and use a factory to produce the right class for the job.

It might take a bit more coding, but please know that the complexity created by giving one thing more than one responsibility (as Uncle Bob Martin would put it) is just begging for trouble down the road. 

Code against interfaces, not implementations

It’s all too easy—and all to common—to couple your code to specific implementations. You start out with an application that does all its logging to a text file. That works great in the early stages, but pretty soon your application is running on multiple machines, and now those text files are everywhere and hard to track and manage. You decide to log to a central database and soon realize that it is a very large job to change from writing to a text file to writing to a database.

If only you had coded your logging system against an interface. Then, when presented with the problem above, you could just write a new implementation of the logging interface, plug that in, and voilà! Problem solved!

It’s always easier to plug a new implementation into an interface than it is to pull out a deeply coupled implementation, the tentacles of which are entangled deeply within your application.

Fear not the explaining variable

Consider the following code.

if (
  (user.age > 18 && user.hasValidID) &&
  (!user.isBanned || user.hasAppealPending) &&
  (currentDate >= event.start && currentDate 

This code is complex and really hard for my brain to parse. It requires you have to mentally unpack each boolean expression, keeping track of what is going on in the parentheses. It’s quite a bother and really hard to figure out.

This code is much easier to understand: 

const isAdultWithID = user.age > 18 && user.hasValidID;

const isAllowedDespiteBanStatus = !user.isBanned || user.hasAppealPending;

const isEventOngoing = currentDate >= event.start && currentDate 

Each of the complex Boolean variables is given a good, explanatory name so that the notion of whether a given user qualifies for entry or not can be easily understood. Don’t be afraid to do that.

Ruthlessly root out the smallest of mistakes

I follow this rule religiously when I code. I don’t allow typos in comments. I don’t allow myself even the smallest of formatting inconsistencies. I remove any unused variables. I don’t allow commented code to remain in the code base. If your language of choice is case-insensitive, refuse to allow inconsistent casing in your code.

Take care of these kinds of small things and the bigger problems will take care of themselves. 

Implicitness is evil

This is something that I have never understood—why some developers view implicitness as a virtue. I find it amazing that anyone would choose to be less clear rather than more clear.

Implicitness increases cognitive load. When code does things implicitly, the developer has to stop and guess what the compiler is going to do. Default variables, hidden conversions, and hidden side effects all make code hard to reason about. 

Because one can’t always guess right, eliminating the need to guess by making things explicit makes for better code.

Limit scope as much as possible

Everyone knows — or everyone should know at least — that global variables are to be strictly avoided.  They can too easily get out of control, be changed in places you least expect, and mysteriously have strange values. 

Or, put another way, their scope is too large.  Thus, the principle of limiting scope says that global variables are a no-no.

But that principle can apply more broadly. Limit the visibility of fields in your class as much as possible.  Use private if you can.  Declare all your variables at the last minute if your language supports the notion of inline variables.  Don’t let those pesky variables get out of hand by exposing them to places they have no business being available. 

So there are a few ways to make sure that your code stays under control.  These lessons are hard won through both experience of doing it wrong, and even more prevalent, from having to maintain code that was written by folks who hadn’t learned these lessons.

Follow these habits, and that bramble-filled trail gets a lot easier to walk.

Google has introduced the Gemini 3 AI model, an update of Gemini with improved visual reasoning, and Google Antigravity, an agentic development platform for AI-assisted software development.

Both were announced on November 18. Gemini 3 is positioned as offering reasoning capabilities with robust function calling and instruction adherence to build sophisticated agents. Agentic capabilities in Gemini 3 Pro are integrated into agent experiences in tools such as Google AI Studio, Gemini CLI, Android Studio, and third-party tools. Reasoning and multimodal generation enable developers to go from concept to a working app, making Gemini 3 Pro suitable for developers at any experience level, Google said. Gemini 3 surpasses Gemini 2.5 Pro at coding, mastering both agentic workflows and complex zero-shot tasks, according to the company. Gemini 3 is available in preview at $2 per million input tokens and $12 per million output tokens for prompts of 200K tokens or less through the Gemini API in Google AI Studio and Vertex AI for enterprises.

Google Antigravity, meanwhile, shifts from agents embedded within tools to an AI agent as the primary interface. It manages surfaces such as the browser, editor, and the terminal to complete development tasks. While the core is a familiar AI-powered IDE experience, Antigravity is evolving the IDE toward an agent-first future with browser control capabilities, asynchronous interaction patterns, and an agent-first product form factor, according to Google. Together, these enable agents to autonomously plan and execute complex, end-to-end software tasks. Available in public preview, Antigravity is compatible with Windows, Linux, and macOS.

With Antigravity, developers act as the architect, collaborating with agents that can execute processes from end-to-end coding tasks to complex research, Google said. Antigravity provides progress reports and verification. Google said the agent improves over time based on user feedback on code, plans, and designs. Built-in memory enables the agent to get smarter on each project.

Although the C# 14 language was formally launched along with the .NET 10  framework a week ago, Microsoft has put the language update in view again. C# 14 features extension members, a new syntax for declaring extension properties and extension methods. Overall, C# 14’s enhancements improve developer productivity and performance, the company said.

In a November 17 blog post, Microsoft introduced introduced C# 14, the latest update to the company’s popular object-oriented language for .NET, and described extension members as the headline feature. Extension methods allow developers not only to declare extension properties and extension methods, but also to declare extension members that extend the type, rather than an instance of the type. These new extension members can appear as static members of the type extended. Extensions can include user-defined operators implemented as static extension methods.

Also in C# 14 is a set of capabilities designated as offering more productivity by reducing friction for everyday tasks. These capabilities eliminate boilerplate, remove common conditional blocks, simplify lambda declarations, enhance partial types for source generators, and make nameof more expressive in generic scenarios, according to Microsoft. Typing is reduced and developers get cleaner code, fewer trivial identifiers, and code that communicates intent more cleanly. These capabilities include the following:

• The field keyword, previewed in .NET 9, maintains auto‑property terseness and injects minimal logic only where needed.
• nameof accepts an unbound generic type. This eliminates the need to choose an arbitrary type just to retrieve the generic type’s name.
• The null-conditional member access operators, ?. and ?[], now can be used on the left-hand side of an assignment or compound assignment.
• Large generated or source‑generated partial types now can spread event and constructor logic across files. This enables generators or different files to contribute cleanly.

For performance, C# 14 adds implicit conversions among arrays, spans, and read-only spans. This means less ceremony has to be written and the JIT (just-in-time) compiler sees simpler call graphs. That results in fewer temporary variables, fewer bounds checks, and more aggressive inlining in the framework, Microsoft said. Also, C# 14 lets developers declare a compound assignment operator explicitly so that the compiler dispatches directly to the developer’s implementation.

Users of the Go language can expect improved support for AI coding agents in the coming year, according to the Go team. Also in the works is an overhauled go fix command that promises greater developer productivity.

In a November 14 blog post marking the 16th anniversary of Google’s open source release of Go as an experimental language, the Go team noted development plans for the year head. Deeper support for AI coding agents was among the items mentioned. The team said it has been working to provide “well-lit paths” for building with Go and AI, evolving the language platform with care for the evolving needs of today’s developers, and building tools and capabilities that help both human developers and AI assistants and systems alike.

The upcoming Go 1.26 release, meanwhile, will include a total overhaul of the go fix command, a tool that uses static code analyzers to find old idioms and suggests modern replacements. With Go 1.26, expected to be released in February 2026, go fix — currently a dormant command with obsolete analyzers — will feature a suite of new analyzers that will suggest fixes that use newer features of the Go language and library. Also planned for Go are ongoing improvements to the gopls language server and the VS Code Go extension.

Other goals for Go include:

• General availability of the Green Tea garbage collector, which promises to reduce workload times. It was featured in an experimental status in Go 1.25.
• Native support for Single Instruction Multiple Data (SIMD) hardware features.
• Runtime and standard library support for writing code that scales better to massive multicore hardware.
• An upgrade to encoding/json, featuring a new API.
• Goroutine leak detection via garbage collection.

For years, the narrative around artificial intelligence has centered on GPUs (graphics processing units) and their compute power. Companies have readily embraced the idea that expensive, state-of-the-art GPUs are essential for training and running AI models. Public cloud providers and hardware manufacturers have promoted this belief, marketing newer, more powerful chips as crucial for remaining competitive in the race for AI innovation.

The surprising truth? GPUs were never as critical to enterprise AI success as we were led to believe. Many of the AI workloads enterprises depend on today, such as recommendation engines, predictive analytics, and chatbots, don’t require access to the most advanced hardware. Older GPUs or even commodity CPUs can often suffice at a fraction of the cost.

As pressure mounts to cut costs and boost efficiency, companies are questioning the hype around GPUs and finding a more pragmatic way forward, changing how they approach AI infrastructure and investments.

A dramatic drop in GPU prices

Recent reports reveal that the prices of cloud-delivered, high-demand GPUs have plummeted. For example, the cost of an AWS H100 GPU Spot Instance dropped by as much as 88% in some regions, down from $105.20 in early 2024 to $12.16 by late 2025. Similar price declines have been seen across all major cloud providers.

This decline may seem positive. Businesses save money, and cloud providers adjust supply. However, there’s a critical shift in business decision-making behind these numbers. The price cuts did not result from an oversupply; they reflect changing priorities. Demand for top-tier GPUs is falling as enterprises question why they should pay for expensive GPUs when more affordable alternatives offer nearly identical results for most AI workloads.

Not all AI requires high-end GPUs

The idea that bigger and better GPUs are essential for AI’s success has always been flawed. Sure, training large models like GPT-4 or MidJourney needs a lot of computing power, including top-tier GPUs or TPUs. But these cases account for a tiny share of AI workloads in the business world. Most businesses focus on AI inference tasks that use pretrained models for real-world applications: sorting emails, making purchase recommendations, detecting anomalies, and generating customer support responses. These tasks do not require cutting-edge GPUs. In fact, many inference jobs run perfectly on slightly older GPUs such as Nvidia’s A100 or H100 series, which are now available at a much lower cost.

Even more surprising? Some companies find they don’t need GPUs at all for many AI-related operations. Standard commodity CPUs can handle smaller, less complex models without issue. A chatbot for internal HR inquiries or a system designed to forecast energy consumption doesn’t require the same hardware as a groundbreaking AI research project. Many companies are realizing that sticking to expensive GPUs is more about prestige than necessity.

When AI became the next big thing, it came with skyrocketing hardware requirements. Companies rushed to get the latest GPUs to stay competitive, and cloud providers were happy to help. The problem? Many of these decisions were driven by hype and fear of missing out (FOMO) rather than thoughtful planning. Laurent Gil, cofounder and president of Cast AI, noted how customer behavior is driven by FOMO when buying new GPUs.

As economic pressures rise, many enterprises are realizing that they’ve been overprovisioning their AI infrastructure for years. ChatGPT was built on older Nvidia GPUs and performed well enough to set AI benchmarks. If major innovations could succeed without the latest hardware, why should enterprises insist on it for far simpler tasks? It’s time to reassess hardware choices and determine whether they align with actual workloads. Increasingly, the answer is no.

Public cloud providers adapt

This shift is evident in cloud providers’ inventories. High-end GPUs like Nvidia’s GB200 Blackwell processors remain in extremely short supply, and that’s not going to change anytime soon. Meanwhile, older models such as the A100 sit idle in data centers as companies pull back from buying the next big thing.

Many providers likely overestimated demand, assuming enterprises would always want newer, faster chips. In reality, companies now focus more on cost efficiency than innovation. Spot pricing has further aggravated these market dynamics, as enterprises use AI-driven workload automation to hunt for the cheapest available options.

Gil also explained that enterprises willing to shift workloads dynamically can save up to 80% compared to those locked into static pricing agreements. This level of agility wasn’t plausible for many companies in the past, but with self-adjusting systems increasingly available, it’s now becoming the standard.

A paradigm of common sense

Expensive, cutting-edge GPUs may remain a critical tool for AI innovation at the bleeding edge, but for most businesses, the path to AI success is paved with older GPUs or even commodity CPUs. The decline in cloud GPU prices shows that more companies realize AI doesn’t require top-tier hardware for most applications. The market correction from overhyped, overprovisioned conditions now emphasizes ROI. This is a healthy and necessary correction to the AI industry’s unsustainable trajectory of overpromising and overprovisioning.

If there’s one takeaway, it’s that enterprises should invest where it matters: pragmatic solutions that deliver business value without breaking the bank. At its core, AI has never been about hardware. Companies should focus on delivering insights, generating efficiencies, and improving decision-making. Success lies in how enterprises use AI, not in the hardware that fuels it. For enterprises hoping to thrive in the AI-driven future, it’s time to ditch outdated assumptions and embrace a smarter approach to infrastructure investments.

What is A2A?

A2A, short for agent-to-agent, is an open, vendor-neutral protocol that allows autonomous AI agents to communicate, coordinate, and delegate work to one another. Most agents today are built as isolated systems, each with its own framework, API conventions, and assumptions.

A2A defines a shared language and handshake process so they can interoperate. The goal isn’t to reinvent what existing standards do, but to fill the gap between how agents perform tasks and how they collaborate on them.

Matt Hasan, CEO of aiRESULTS, calls A2A a game-changer. “It moves the AI conversation from ‘Can a single agent do this task?’ to ‘How can a team of specialized agents collaborate on a complex business workflow?’,” he says.

The initiative originated at Google, which introduced the open-source specification in April 2025 to promote interoperability across the growing ecosystem of autonomous agents and connect agents built on diverse platforms. The goal was to help developers avoid the brittle integrations that made it difficult for early versions of AI agents to interact.

“In theory, A2A is a universal standard of communication and etiquette for AI agents,” Hasan says. “In practice, it’s the architectural blueprint that finally makes complex, vendor-agnostic multi-agent systems feasible for the enterprise.”

By creating a shared foundation for discovery, messaging, and task delegation, A2A enables agents from different vendors and developers to work together on multi-step workflows without custom middleware. That interoperability is what gives the protocol its significance: rather than building one monolithic super-agent, organizations can assemble a network of specialized ones that understand each other out of the box—and can communicate with external agents as well.

How does A2A work?

A2A defines how agents talk to each other and share standardized information about their capabilities. “The technology’s most critical aspect is the task object, which formalizes the delegation of work,” says aiRESULTS’s Hasan. “When we adapt an existing AI agent to use A2A, we essentially wrap its specialized capability in an agent card — a public metadata file that describes what it can do. This allows a client agent to discover, send a structured task request, and securely monitor the status of that work from a remote agent, regardless of whether the remote agent was built with LangChain, a custom Python framework, or a vendor-specific SDK.”

This is deliberate. A2A is designed as a protocol layer for interoperability, not a runtime, model, or orchestration framework. It defines a clear handshake and message structure that any compliant system can use. But each communicating agent remains a black box (Google uses the term “opaque”) to the other: neither needs to know the internal logic or model architecture that produces results.

In fact, there’s nothing in the spec requiring that an “agent” even be an AI system — any process or human participant can function as one, so long as it can send and receive properly formatted messages. A human operator completing a workflow like the original Mechanical Turk could, in theory, be an A2A agent if they follow the protocol’s structure.

This adaptability is what allows A2A to scale beyond simple demo agents into robust enterprise environments. It provides a predictable surface for discovery and execution without prescribing how the work is done. In that sense, A2A resembles the web itself: a shared protocol layer that lets heterogeneous systems cooperate through standardized requests and responses.

“This structured delegation drastically simplifies building long-running, multi-step workflows — like a complex financial compliance check or a multi-modal recruiting pipeline — by solving the problem of interoperability,” Hasan says.

The four core A2A data shapes

A2A organizes communication around four primary object types, each representing a distinct phase in the workflow:

1. Agent card. A small JSON file (agent.json) that publicly describes an agent’s identity, capabilities, authentication methods, and optional digital signature. Other agents read these cards to discover potential collaborators and verify trust.
2. Task.  A structured work request that includes a unique task_id, an input payload, and metadata about priority, expiration, or required modalities. The task defines what needs to be done and serves as the anchor for all subsequent communication.
3. Message. A stream of status updates and intermediate information about the task. Messages carry progress indicators, requests for additional input, or contextual notes, and are typically transmitted over SSE or gRPC streams.
4. Artifact. The result of the completed task. Artifacts can contain text, files, or structured data. They finalize the transaction and can be stored, validated, or chained into another Task for further processing.

In a typical exchange, the requesting agent first retrieves an agent card to confirm another agent’s capabilities and supported protocols. The requesting agent is referred to as a client, and the agent that it’s interrogating about services is called a server, but these aren’t permanent states: an agent may act as a client in one context and a server in another, and in fact the two might switch roles in the course of a single interaction.

At any rate, the client agent issues a createTask request, which the server agent acknowledges by returning a task_id. As the task runs, the provider streams Message objects that indicate status or request clarification. When the work is finished — or if it fails — the provider emits one or more Artifact objects, along with a completion code.

Because every step adheres to the same schema, any compliant agent can participate in this conversation without custom adapters. An LLM-based planning agent might delegate a data-collection task to a Python microservice; that service could, in turn, trigger a human-in-the-loop agent to review the output — all communicating through A2A messages.

A2A design principles

The A2A protocol borrows lessons from decades of internet engineering, applying principles familiar from standards like HTTP, REST, and OAuth to the emerging world of autonomous systems.

• Interoperability. A2A is explicitly framework-agnostic. Agents written in any language or framework — whether built with LangChain, OpenDevin, or a custom SDK — can communicate through the same standardized message schema. This decoupling of implementation from interaction is what makes multi-agent ecosystems possible.
• Transparency. Each agent exposes its functions and limits through a structured Agent card that acts like a capabilities statement. This transparency allows other agents to discover and evaluate potential collaborators without requiring source code access or vendor integration.
• Security. Authentication, authorization, and message integrity are core parts of the specification. A2A supports multiple authentication methods and signed Agent cards so that trust decisions can be made automatically. Every task and message is traceable, creating an auditable record of agent activity.
• Modularity and composability. The protocol treats each agent as an opaque service with well-defined inputs and outputs. Agents can reuse each other’s functions, chaining them together into longer workflows without manual wiring. This modularity mirrors the composable design of APIs and microservices.
• Scalability and resilience. A2A was built for asynchronous, distributed environments. Agents can spawn long-running tasks, stream partial results, and recover from transient network failures. Because the protocol doesn’t dictate runtime behavior, it scales naturally from a pair of local agents to hundreds of cloud-based ones coordinating across domains.

Together, these principles make A2A a common language for distributed intelligence that can evolve as agents, frameworks, and communication technologies change.

Is A2A secure?

Security in A2A operates on two levels: protocol integrity and trust between agents. The specification builds in the same safeguards that protect web-scale APIs — authentication, authorization, and encryption — while adding features to manage how autonomous systems evaluate and respond to one another’s reliability.

Remember, an Agent card describes an agent’s identity, capabilities, and supported authentication methods. Those cards can include digital signatures, allowing client agents to verify the organization that created the server agent before establishing a connection. Once communication begins, tasks and messages are exchanged over secure channels — typically HTTPS, gRPC, or WebSockets — so all payloads are encrypted in transit. The protocol also defines clear response codes and event logs, creating an auditable trail that can be integrated with enterprise observability tools.

The A2A protocol has mechanisms for error handling. “The failing agent sends an error code or failure notification back to the requester,” Hasan says. “This allows the requester to immediately switch to a different, more reliable agent to get the job done.”

This plumbing can lay the groundwork for more advanced behavior, he notes. “Individual agents (or networks of them) can implement their own tracking, keeping score of who’s reliable, sharing that info, or even publishing trust ratings so others can make smarter choices. Repeated failures cause that score to drop. Eventually, other agents will simply stop asking the unreliable agent for help.”

That self-regulating behavior is essential for large-scale multi-agent systems, where no central controller can vet every participant. A2A’s trust model allows poor-performing or malicious agents to be automatically isolated, while reliable ones gain credibility through successful interactions.

Still, A2A’s open design raises questions familiar to anyone familiar with the dilemmas of cybersecurity. How should organizations authenticate third-party agents that claim certain capabilities? What happens if two agents interpret a schema differently, or if one leaks sensitive data through a malformed message? Identity spoofing, model hallucinations, and version mismatches all pose potential risks that enterprises will need governance frameworks to manage.

For most deployments, A2A security will depend on layering protocol-level controls with operational ones: requiring signed Agent cards, managing API keys or OAuth tokens through a centralized broker, and maintaining reputation databases to record agent reliability across the environment. Over time, these practices could evolve into standardized trust registries—much like certificate authorities on the web — forming the basis for secure, auditable agent ecosystems.

Real-world A2A examples

When Google launched the A2A protocol, the company announced support from more than 50 partners, including Atlassian, Box, PayPal, SAP, and many major consultancies. Likewise, Microsoft publicly announced support for A2A in its Azure AI Foundry and Copilot Studio platforms.

Google has also touted real-world rollouts. For instance, Box AI Agents now coordinate with other agents across dozens of platforms via A2A-compliant endpoints. Another example: Twilio uses A2A extensions to broadcast latency information, enabling intelligent routing among agents and graceful degradation when only slower agents are available. While these examples don’t yet reflect fully documented, large-scale production deployments, they demonstrate meaningful adoption beyond the pilot phase into enterprise ecosystems.

The hope is that A2A isn’t just another AI hype protocol, but that it will become a foundational communication layer for multi-agent ecosystems. Organizations that experiment now with publishing agent cards, defining tasks, and streaming results could gain a head start if vendor-agnostic agents become a core part of automation pipelines. Adoption is still early, but the roadmap is there for a world where agents that were once isolated can now speak a common language.

Testing APIs and applications was challenging in the early devops days. As teams sought to advance their CI/CD pipelines and support continuous deployment, test automation platforms gained popularity, and many devops organizations developed continuous testing strategies.

While shifting left on QA, implementing security testing, and increasing observability are now devsecops non-negotiables for many organizations, these practices are not equally deployed across all applications. Legacy applications are lagging due to underlying technical debt, and test automation is still an emerging capability when developing AI agents.

Developing an LLM testing strategy is challenging because the model’s inputs are open-ended and responses are non-deterministic. AI agents couple language models with the ability to take human-in-the-middle and automated actions, so testing decision accuracy, performance, and security is vital for developing trust and growing employee adoption.

As more companies evaluate AI agent development tools and consider the risks of rapidly deploying AI agents, more devops teams will need to consider how to automate the testing of AI agents. IT and security leaders will seek testing plans to determine release-readiness and avoid the risks of deploying rogue AI agents.

Developing end-to-end testing strategies

Experts view testing AI agents as a strategic risk management function that encompasses architecture, development, offline testing, and observability for online production agents. The approach enables continuous improvement as AI models evolve, and the agent responds to a wider range of human and agent-to-agent inputs in production.

“Testing agentic AI is no longer QA, it is enterprise risk management, and leaders are building digital twins to stress test agents against messy realities: bad data, adversarial inputs, and edge cases,” says Srikumar Ramanathan, chief solutions officer at MPhasis. “Validation must be layered, encompassing accuracy and compliance checks, bias and ethics audits, and drift detection using golden datasets.”

One best practice is to model AI agents’ role, workflows, and the user goals they are intended to achieve. Developing end-user personas and evaluating whether AI agents meet their objectives can inform the testing of human-AI collaborative workflows and decision-making scenarios.

“AI agents are stochastic systems, and traditional testing methods based on well-defined test plans and tools that verify fixed outputs are not effective,” says Nirmal Mukhi, VP and head of engineering at ASAPP. “Realistic simulation involves modeling various customer profiles, each with a distinct personality, knowledge they may possess, and a set of goals around what they actually want to achieve during the conversation with the agent. Evaluation at scale involves then examining thousands of such simulated conversations to evaluate them based on desired behavior, policies, and checking if the customer’s goals were achieved.”

Ramanathan of Mphasis adds, “The real differentiator is resilience, testing how agents fail, escalate, or recover. Winners will not chase perfection at launch; they will build trust as a living system through sandboxing, monitoring, and continuous adaptation.”

Testing AI agents requires shifts in QA strategy

Testing tools and methodologies are built on the simple premise that a test case is deterministic and is properly developed with criteria that either pass or fail. QA engineers will need to consider broader expressions, such as whether an AI agent’s actions are appropriate and whether it provides similar responses to comparable inputs.

“The biggest misconception about testing AI agents is treating them like traditional applications with predictable outputs,” says Esko Hannula, SVP of robotics at Copado. “AI agents learn and adapt continuously, meaning your testing strategy must evolve from validating exact responses to ensuring response appropriateness and business alignment.”

Traditional API and application testing often utilizes automation testing platforms that run in development and test environments, but separate monitoring tools are used for production errors. So, a second change for testing AI agents is that testing scenarios must be automated to run in development, test environments, and continuously in production. Organizations will want to release new versions of AI agents frequently as LLM platforms release new versions and the agents are improved based on end-user feedback.

“Agentic systems are non-deterministic and can’t be trusted with traditional QA alone; enterprises need tools that trace reasoning, evaluate judgment, test resilience, and ensure adaptability over time,” says Nikolaos Vasiloglou, VP of research ML at RelationalAI. “Agents may quickly be replaced by newer LLMs, so leaders must continually benchmark their custom solutions against frontier models and avoid the sunk-cost fallacy.”

Validating the response accuracy of AI agents

How should QA engineers validate an AI agent’s response when inputs and outputs are not deterministic?

Jerry Ting, head of agentic AI at Workday, shares two recommendations for testing AI agents across the enterprise. “Use AI to create synthetic training data that simulates the messiness of real-life prompts and embedded data. Then, have the same prompt go into different large language models, and orchestrate a tournament of prompts and responses with AI as judges.”

Part of the implementation strategy will require integrating feedback from production back into development and test environments. Although testing AI agents should be automated, QA engineers will need to develop workflows that include reviews from subject matter experts and feedback from other end users.

“Hierarchical scenario-based testing, sandboxed environments, and integrated regression suites—built with cross-team collaboration—form the core approach for test strategy,” says Chris Li, SVP of products at Xactly. “To ensure valid and accurate responses, sandboxed replays, automated and human reviews, and rich audit trails are reliable approaches for full workflow validation. As agentic AI systems scale in complexity, balancing precision, safety, fairness, and performance becomes essential to delivering robust, trustworthy agents capable of operating successfully in real-world environments.”

QA engineers will also need to automate the calculation of an accuracy metric that can be compared across deployments and AI model upgrades. Without these metrics, it will be challenging to know whether a deployment improved the AI agent’s decision-making and recommendation capabilities.

“The real challenge isn’t whether the agent gives the ‘right’ answer—it’s whether it consistently makes decisions that advance your business objectives while respecting security boundaries,” adds Hannula of Copado. “This requires a fundamental shift from deterministic testing to contextual validation that accounts for the agent’s learning trajectory.”

Ensuring AI agents take the correct actions

More organizations will look to automate workflows with AI agents. Testing must consider that an agent may have several plausible actions, and its responses should help justify its recommendations.

“Testing must validate not only the agent’s thinking (its responses), but also its actions (the operations it executes),” says Zhijie Chen, co-founder and CEO of Verdent. “For high-risk, complex, or ambiguous decision-making scenarios, fully automated testing may not guarantee safety and reliability; in such cases, a human-in-the-loop approach provides a strategic layer of assurance.”

How should QA develop and automate testing around the AI agent’s actions? Consider how challenging it can be to evaluate people’s decisions, especially in real time, before actions are undertaken. We look for non-verbal clues and seek opinions from outside experts. Testing an AI agent’s recommended and automated actions may require a similar approach.

Mike Finley, co-founder of StellarIQ, says, “One key way to automate testing of agentic AI is to use verifiers, which are AI supervisor agents whose job is to watch the work of others and ensure that they fall in line. Beyond accuracy, they’re also looking for subtle things like tone and other cues. If we want these agents to do human work, we have to watch them like we would human workers.”

Establishing release-readiness practices

AI agents encompass the complexities of applications, automations, and AI models when evaluating their security and operational readiness for production. Many organizations are just getting started with AI agents, and fewer than 5% have reached production. Experts weighed in on security and operational recommendations.

Rishi Bhargava, co-founder of Descope, recommends pressure-testing AI agents against all the OWASP top 10 for LLM applications during automated testing. These include:

• Test that AI agent connections with third-party tools and enterprise systems follow recommended implementations of standard protocols such as MCP and OAuth.
• Test for AI agent permissions and ensure the agent’s permissions are a subset of the bound user’s permissions at all times.

Andrew Filev, CEO and founder of Zencoder, shares how security considerations for AI agents extend beyond deterministic systems, such as applications and automations. Andrew says, “You’ve got prompt injection attacks, model manipulation, context poisoning, adversarial inputs, and data extraction attempts—basically a whole new category of vulnerabilities that most security teams may not yet have on their radar.”

Filev also says that performance testing is tricky because devops teams must do more than evaluate response times, and must consider the following questions:

• Can the agent maintain quality and consistency when it’s being hammered with requests?
• Does the underlying AI model start hallucinating under load?
• How should teams architect performance testing without overspending on API costs?

A good place to start is with practices that should already be in place for validating the release-readiness of applications and AI models. Ian Beaver, chief data scientist at Verint, shared thes following recommendations:

• Collect detailed AI agent audit logs and record every interaction and action, allowing for inspection and correction if needed.
• Follow a policy of least privilege for all APIs and MCP tools to minimize risk.
• Evaluate LLMs for bias and reliability.

“Comprehensive logging, robust monitoring, and user feedback interfaces are even more critical for agents,” adds Beaver.

Automating testing for agentic AI

As challenging as it is to automate AI agent testing, devops teams must also consider how to future-proof their implementations for agentic AI, an objective that’s not fully realized in most organizations. Devops teams will need to use testing frameworks that enable running validations in production and support agent-to-agent communication.

“Perhaps more important than automating the testing of agents is how to best organize and orchestrate agent interactions in a way that both minimizes the possibility of error while also enabling them to recover gracefully in the event of one,” says Sohrob Kazerounian, distinguished AI researcher at Vectra AI. “By decomposing problems into a set of well-specified tasks, you can not only design agents that are more likely to succeed, but importantly, you can create agents that can evaluate and error-correct at each step of the way.”

Probably the most important lesson here is one that most devops teams have learned from developing applications and automations: There’s no free lunch when it comes to testing, and less than half the work is done when the functional code is completed. For teams looking to deploy AI agents, it is essential to consider test-driven approaches to evaluate quality and establish release readiness.

Enterprises have spent the past two years determining which large language model they should use. GPT or Claude? Gemini or an open-source alternative? But as these models begin to converge in terms of quality and capabilities, the question of which model to use becomes less important than how to actually use them.

Ultimately, the real competitive advantage for enterprises won’t come from choosing the right model. It will come from building the right context, including the proprietary data, documents, workflows, and domain knowledge that shape how AI systems reason and act.

We are entering a new discipline known as context engineering: the practice of designing, integrating, and orchestrating the information environment in which AI systems operate. If prompt engineering was about asking better questions, context engineering is about giving AI the foundation to answer them well.

A huge leap beyond prompt engineering

Prompt engineering was the early bridge between human intent and machine intelligence. It taught us a new skill: phrasing instructions in a way that can significantly impact output quality. But prompts alone are shallow, similar to asking for directions without showing a map.

As AI systems evolve into agentic systems capable of reasoning, planning, and executing tasks, they require more than clever phrasing. They need a deeper understanding of where they are, what they know, and the constraints that apply. 

That understanding comes from context.

Context includes everything that shapes intelligent behavior: documents, structured data, memory of previous interactions, workflows, policies, and even unstructured sources such as audio or video. Stitching together all the relevant context and feeding it to AI is what enables AI to make relevant, consistent, and responsible decisions.

In short, we’re moving from a prompted world to a contextual one, and from instructing AI to equipping it.

The challenge of data variety and scale

Building this context layer isn’t simple. For decades, enterprises have struggled to manage structured data from systems such as ERPs, CRMs, and various analytics platforms. Today, the picture is even more complex because context comes from everywhere: chat transcripts, support tickets, sensor feeds, video, contracts, PDFs, and more.

This explosion of data variety has outpaced traditional data engineering methods. AI doesn’t consume static tables; it does much better with live, dynamic information flows. That means organizations must design composable systems that can retrieve, transform, and deliver the right context to the right process, all in real time and at scale.

The scale problem isn’t just about computing power, which has become abundant. It’s about orchestration. When you stitch together dozens of data products, run them across distributed systems, and feed them into AI models, reliability and observability are paramount. Engineers used to spend days restarting failed pipelines or trying to trace lineage across systems. Now, that level of manual intervention simply doesn’t scale.

The next wave of data infrastructure must handle these orchestration challenges automatically by understanding dependencies, monitoring flows, and ensuring that the context being fed to AI is always complete, consistent, and compliant.

Going from data engineering to context engineering

In many ways, context engineering is the natural evolution of data engineering. Where data engineers build systems to collect, clean, and deliver information, context engineers design living data environments, complete with semantics, lineage, and rules.

They don’t just move data; they make it ready for AI consumption. That means packaging data into data products that are secure, well-documented, and embedded with metadata about how they can be used.

Take a financial institution that wants to feed its underwriting models with historical claims data. It needs to mask sensitive information, maintain lineage, and ensure compliance with regulations. Or take a healthcare provider integrating on-premises patient data with cloud-based AI models. It must ensure privacy while still delivering relevant context to the AI system. These are quintessential context engineering problems.

I’ve seen this evolution firsthand, and I’ve found that the goal should be to make data easier to consume, regardless of format or source. The idea is to enable even non-engineers to build and share governed data products, mask personally identifiable information (PII), and document lineage without writing code. This is what context engineering can look like in practice: lowering the technical bar while raising the quality and trust of the data ecosystem.

Teaching AI to operate in complex environments

Context matters for AI as much as it does for human workers. For example, imagine training a human for a complex role at a new company, such as managing procurement for a global manufacturer. It could take months for a new hire to become fully up to speed and understand the specific systems, policies, and nuances the company uses to make decisions. 

AI faces a similar learning curve.

In the same vein, AI agents need the same organizational context that humans rely on to reason effectively, including prior decisions, policies, and examples of exceptions. The better the context, the better the AI will perform.

This doesn’t mean giving AI control of critical systems, such as a general ledger. It means allowing AI to handle the connective tissue—think summarizing reports, flagging anomalies, drafting communications, or optimizing workflows. And it should all be guided by the same context humans would use to make these judgments.

The point isn’t full automation; it’s contextual augmentation. It’s about enabling AI to operate with awareness and reliability in complex, real-world settings.

A shift in methodology

This transition involves more than adding a new toolset; it’s about changing methodology. Traditionally, software and analytics relied on humans to decide what questions to ask, what data to gather, and how to visualize the results. The process was linear and prescriptive.

In the AI-driven world, that model has flipped. We can feed large amounts of contextual data into an intelligent system and let it infer which information is relevant to the outcome we want. Instead of programming every rule, we define boundaries, supply context, and let AI reason within those boundaries.

That’s a fundamentally different way of building software, blending data engineering, governance, machine learning operations, and domain expertise into a single, continuous system. It’s the foundation for truly agentic AI: systems that act with awareness rather than just react to instructions.

Success means lowering the bar for intelligent systems

The real promise of context engineering is access. It opens the door for people beyond data scientists or machine learning experts to work productively with AI. When the underlying systems handle complexity, domain experts such as analysts, product managers, and marketers can focus on applying insight rather than dealing with the complexity of pipelines.

Modern, composable tools make it possible for almost anyone to shape and improve the context behind intelligent systems. They can monitor flows, adjust rules, and refine the data that guides decisions. That’s how enterprises will responsibly scale AI: by making participation broader, not narrower.

The shift we’re seeing isn’t only about building smarter models. It’s about creating smarter ecosystems. Companies that learn to engineer context, connecting knowledge, data, and process into a living system, will be the ones that set the pace for enterprise innovation in the years ahead.

—

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.

Java Development Kit (JDK) 26, a planned update to standard Java due March 17, 2026, has gathered 10 features so far. The following features are officially targeted to JDK 26: a fourth preview of primitive types in patterns, instanceof, and switch, ahead-of-time object caching, an eleventh incubation of the Vector API, second previews of lazy constants and PEM (privacy-enhanced mail) encodings of cryptographic objects, a sixth preview of structured concurrency, warnings about uses of deep reflection to mutate final fields, improving throughput by reducing synchronization in the G1 garbage collector (GC), HTTP/3 for the Client API, and removal of the Java Applet API.

A short-term release of Java backed by six months of Premier-level support, JDK 26 follows the September 16 release of JDK 25, which is a Long-Term Support (LTS) release backed by several years of Premier-level support.

The latest feature to be added, primitive types in patterns, instanceof, and switch, is intended to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. Now in a fourth preview, this feature was previously previewed in JDK 23, JDK 24, and JDK 25. The goals include enabling uniform data exploration by allowing type patterns for all types, aligning type patterns with instanceof and aligning instanceof with safe casting, and allowing pattern matching to use primitive types in both nested and top-level pattern contexts. Changes in this fourth preview include enhancing the definition of unconditional exactness and applying tighter dominance checks in switch constructs. The changes enable the compiler to identify a wider range of coding errors.

With ahead-of-time object caching, the HotSpot JVM would gain improved startup and warmup times, so it can be used with any garbage collector including the low-latency Z Garbage Collector (ZGC). This would be done by making it possible to load cached Java objects sequentially into memory from a neutral, GC-agnostic format, rather than mapping them directly into memory in a GC-specific format. Goals of this feature include allowing all garbage collectors to work smoothly with the AOT (ahead of time) cache introduced by Project Leyden, separating AOT cache from GC implementation details, and ensuring that use of the AOT cache does not materially impact startup time, relative to previous releases.

The eleventh incubation of the Vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs. This achieves performance superior to equivalent scalar computations. The incubating Vector API dates back to JDK 16, which arrived in March 2021. The API is intended to be clear and concise, to be platform-agnostic, to have reliable compilation and performance on x64 and AArch64 CPUs, and to offer graceful degradation. The long-term goal of the Vector API is to leverage Project Valhalla enhancements to the Java object model.

Also on the docket for JDK 26 is another preview of an API for lazy constants, which had been previewed in JDK 25 via a stable values capability. Lazy constants are objects that hold unmodifiable data and are treated as true constants by the JVM, enabling the same performance optimizations enabled by declaring a field final. Lazy constants offer greater flexibility as to the timing of initialization.

The second preview of PEM (privacy-enhanced mail) encodings calls for an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the  PEM transport format, and for decoding from that format back into objects. The PEM API was proposed as a preview feature in JDK 25. The second preview features a number of changes, such as the PEMRecord class is now named PEM and now includes a decode()method that returns the decoded Base64 content. Also, the encryptKey methods of the EncryptedPrivateKeyInfo class now are named encrypt and now accept DEREncodable  objects rather than PrivateKey objects, enabling the encryption of KeyPair and PKCS8EncodedKeySpec objects.

The structured concurrency API simplifies concurrent programming by treating groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. Goals include promoting a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays, and improving the observability of concurrent code.

New warnings about uses of deep reflection to mutate final fields are intended to prepare developers for a future release that ensures integrity by default by restricting final field mutation, in other words making final mean final, which will make Java programs safer and potentially faster. Application developers can avoid both current warnings and future restrictions by selectively enabling the ability to mutate final fields where essential.

The G1 GC proposal is intended to improve application throughput and latency when using the G1 garbage collector by reducing the amount of synchronization required between application threads and GC threads. Goals include reducing the G1 garbage collector’s synchronization overhead, reducing the size of the injected code for G1’s write barriers, and maintaining the overall architecture of G1, with no changes to user interaction.

The G1 GC proposal notes that although G1, which is the default garbage collector of the HotSpot JVM, is designed to balance latency and throughput, achieving this balance sometimes impacts application performance adversely compared to throughput-oriented garbage collectors such as the Parallel and Serial collectors:

Relative to Parallel, G1 performs more of its work concurrently with the application, reducing the duration of GC pauses and thus improving latency. Unavoidably, this means that application threads must share the CPU with GC threads, and coordinate with them. This synchronization both lowers throughput and increases latency.

The HTTP/3 proposal calls for allowing Java libraries and applications to interact with HTTP/3 servers with minimal code changes. Goals include updating the HTTP Client API to send and receive HTTP/3 requests and responses; requiring only minor changes to the HTTP Client API and Java application code; and allowing developers to opt in to HTTP/3 as opposed to changing the default protocol version from HTTP/2 to HTTP/3.

HTTP/3 is considered a major version of the HTTP (Hypertext Transfer Protocol) data communications protocol for the web. Version 3 was built on the IETF QUIC (Quick UDP Internet Connections) transport protocol, which emphasizes flow-controlled streams, low-latency connection establishment, network path migration, and security among its capabilities.

Removal of the Java Applet API, now considered obsolete, is also targeted for JDK 26. The Applet API was deprecated for removal in JDK 17 in 2021. The API is obsolete because neither recent JDK releases nor current web browsers support applets, according to the proposal. There is no reason to keep the unused and unusable API, the proposal states.

Other possible features for JDK 26 include JDK Flight Recorder CPU-time profiling, which would capture more accurate CPU-time profiling information on Linux, and post-mortem crash analysis with jcmd, which would extend the jcmd tool so that it could be used to diagnose a JVM that has crashed.

Microsoft has released Aspire 13, the latest version of the company’s tool kit for building distributed, cloud-native applications. With Aspire 13, Python and JavaScript become “first-class citizens” of the development platform, Microsoft said, with comprehensive support for running, debugging, and deploying applications written in these languages.

Aspire 13 was announced November 11 and is downloadable from aspire.dev.

A full polyglot application platform, Aspire 13 also introduces the aspire do command, which breaks builds and deployments down into parallelizable steps, as well as a Model Context Protocol (MCP) server for AI assistance. For Python, release notes stress support for Python modules, deployment with the Python-based uvicorn web server, flexible package management (uv, pip, or venv), and generation of production Dockerfiles automatically. Improved JavaScript support, meanwhile, centers on Vite and npm-based apps with package manager auto-detection, debugging support, and container-based build pipelines.

The aspire do command, now in an early preview stage, is billed as a complete reimagination of building, publishing, and deploying pipelines. Instead of a monolithic “hit deploy and pray” experience, aspire do breaks everything down into discrete, parallelizable steps with dependency tracking, Microsoft said. Independent operations are automatically parallelized, making for fast deployments. Also, the Aspire dashboard now includes a preview of an MCP server that lets AI assistants directly query a running application. The MCP server enables AI coding assistants to list all resources with their state and endpoints, access console logs in real time, retrieve structured logs and traces, and execute commands on resources.

Previously called .NET Aspire, Aspire provides tools, packages, and templates for building observable, production-ready distributed apps. Aspire provides a unified toolchain for launching and debugging an application locally with one command, then deploying to Kubernetes, the cloud, or a user’s own servers via the same composition, according to Microsoft. Aspire 13 requires the .NET 10 SDK or later.

Microsoft noted a few other new features and improvements in Aspire 13. Database resources now automatically expose multiple connection string formats, including the URI format for Python apps and JDBC format for Java apps. Aspire 13 automatically configures certificate trust for Python (SSL_CERT_FILE), Node.js (NODE_EXTRA_CA_CERTS), and containers. And Aspire now generates optimized multi-stage Dockerfiles that detect a Node version from .nvmrc, .node-version, or package.json.