Amazon Web Services has unveiled a new class of AI agents, called frontier agents, which the company said can work for hours or days without intervention. The first three agents are focused on software development tasks.

The three agents announced December 2 include the Kiro autonomous agent, AWS Security Agent, and AWS Devops Agent, each focused on a different aspect of the software development life cycle. AWS said these agents represent a step-function change in what can be done with agents, moving from assisting with individual tasks to completing complex projects autonomously like a member of the user’s team. The Kiro autonomous agent is a virtual developer that maintains context and learns over time while working independently, so users can focus on their biggest priorities. The AWS Security Agent serves as virtual security engineer that helps build secure applications by being a security consultant for app design, code reviews, and penetration testing. And the AWS DevOps Agent is a virtual operations team member that helps resolve and proactively prevent incidents while continuously improving an applications’ reliability and performance, AWS said.

All three agents are available in preview. The Kiro agent is a shared resource working alongside the entire team, building a collective understanding of the user’s codebase, products, and standards. It connects to a team’s repos, pipelines, and tools such as Jira and GitHub to maintain context as work progresses. Kiro previously was positioned as an agentic AI-driven IDE. The AWS Security Agent, meanwhile, helps build applications that are secure from the start across AWS, multi-cloud, and hybrid environments. AWS Devops Agent is on call when incidents happen, instantly responding to issues and usings its knowledge of an application and relationship between components to find the root cause of a problem with an application going down, according to AWS.

AWS said the Frontier agents were the result of examining its own development teams building services at Amazon scale and uncovering three critical insights to increase value. First, by learning what agents were and were not good at, the team could switch from babysitting every small task to directing agents toward broad, goal-driven outcomes. Second, the velocity of teams was tied to how many agentic tasks could be run at the same time. Third, the longer agents could operate on their own, the better. The AWS team realized it needed the same capabilities across very aspect of the software development life cycle, such as security and operations, or risk creating new bottlenecks.

Imagine it’s 3 a.m. and your pager goes off. A downstream service is failing, and after an hour of debugging you trace the issue to a tiny, undocumented schema change made by an upstream team. The fix is simple, but it comes with a high cost in lost sleep and operational downtime.

This is the nature of many modern data pipelines. We’ve mastered the art of building distributed systems, but we’ve neglected a critical part of the system: the agreement on the data itself. This is where data contracts come in, and how they fail without the right tools to enforce them.

The importance of data contracts

Data pipelines are a popular tool for sharing data from different producers (databases, applications, logs, microservices, etc.) to consumers to drive event-driven applications or enable further processing and analytics. These pipelines have often been developed in an ad hoc manner, without a formal specification for the data being produced and without direct input from the consumer on what data they expect. As a result, it’s not uncommon for upstream producers to introduce ad hoc changes consumers don’t expect and can’t process. The result? Operational downtime and expensive, time-consuming debugging to find the root cause.

Data contracts were developed to prevent this.

Data contract design requires data producers and consumers to collaborate early in the software design life cycle to define and refine requirements. Explicitly defining and documenting requirements early on simplifies pipeline design and reduces or removes errors in consumers caused by data changes not defined in the contract.

Data contracts are an agreement between data producers and consumers that define schemas, data types, and data quality constraints for data shared between them. Data pipelines leverage distributed software to map the flow of data and its transformation from producers to consumers. Data contracts are foundational to properly designed and well behaved data pipelines.

Why we need data contracts

Why should data contracts matter to developers and the business? First, data contracts reduce operational costs by eliminating unexpected upstream data changes that cause operational downtime.

Second, they reduce developer time spent on debugging and break-fixing errors. These errors are caused downstream from changes the developer introduced without understanding their effects on consumers. Data contracts provide this understanding.

Third, formal data contracts aid the development of well-defined, reusable data products that multiple consumers can leverage for analytics and applications.

The consumer and producer can leverage the data contract to define schema and other changes before the producer implements them. The data contract should specify a cutover process, so consumers can migrate to the new schema and its associated contract without disruption.

Three important data contract requirements

Data contracts have garnered much interest recently, as enterprises realize the benefits of shifting their focus upstream to where data is produced when building operational products that are data-driven. This process is often called “shift left.”

Confluent

In a shift-left data pipeline design, downstream consumers can share their data product requirements with upstream data producers. These requirements can then be distilled and codified into the data contract.

Data contract adoption requires three key capabilities:

• Specification — define the data contract
• Implementation — implement the data contract in the data pipeline
• Enforcement — enforce the data contract in real-time

There are a variety of technologies that can support these capabilities. However, Apache Kafka and Apache Flink are among the best technologies for this purpose.

Apache Kafka and Apache Flink for data contracts

Apache Kafka and Apache Flink are popular technologies for building data pipelines and data contracts due to their scalability, wide availability, and low latency. They provide shared storage infrastructure between producers and consumers. In addition, Kafka allows producers to communicate the schemas, data types, and (implicitly) the serialization format to consumers. This shared information also allows Flink to transform data as it travels between the producer and consumer.

Apache Kafka is a distributed event streaming platform that provides high-throughput, fault-tolerance, and scalability for shared data pipelines. It functions as a distributed log enabling producers to publish data to topics that consumers can asynchronously subscribe to. In Kafka, topics have schemas, defined data types, and data quality rules. Kafka can store and process streams of records (events) in a reliable and distributed manner. Kafka is widely used for building data pipelines, streaming analytics, and event-driven architectures.

Apache Flink is a distributed stream processing framework designed for high-performance, scalable, and fault-tolerant processing of real-time and batch data. Flink excels at handling large-scale data streams with low latency and high throughput, making it a popular choice for real-time analytics, event-driven applications, and data processing pipelines.

Flink often integrates with Kafka, using Kafka as a source or sink for streaming data. Kafka handles the ingestion and storage of event streams, while Flink processes those streams for analytics or transformations. For example, a Flink job might read events from a Kafka topic, perform aggregations, and write results back to another Kafka topic or a database.

Kafka supports schema versioning and can support multiple different versions of the same data contract as it evolves over time. Kafka can keep the old version running with the new version, so new clients can leverage the new schema while existing clients are using the old schema. Mechanisms like Flink’s support for materialized views help accomplish this.

How Kafka and Flink help implement data contracts

Kafka and Flink are a great way to build data contracts that meet the three requirements outlined earlier—specification, implementation, and enforcement. As open-source technologies, they play well with other data pipeline components that are often built using open source software or standards. This creates a common language and infrastructure around which data contracts can be specified, implemented, and enforced.

Flink can help enforce data contracts and evolve them as needed by producers and consumers, in some cases without modifying producer code. Kafka provides a common, ubiquitous language that supports specification while making implementation practical.

Kafka and Flink encourage reuse of the carefully crafted data products specified by data contracts. Kafka is a data storage and sharing technology that makes it easy to enable additional consumers and their pipelines to use the same data product. This is a powerful form of software reuse. Kafka and Flink can transform and shape data from one contract into a form that meets the requirements of another contract, all within the same shared infrastructure.

You can deploy and manage Kafka yourself, or leverage a Kafka cloud service and let others manage it for you. Any data producer or consumer can be supported by Kafka, unlike strictly commercial products that have limits on the supported producers and consumers.

You could get enforcement via a single database if all the data managed by your contracts sits in that database. But applications today are often built using data from many sources. For example, data streaming applications often have multiple data producers streaming data to multiple consumers. Data contracts must be enforced across these different databases, APIs, and applications.

You can specify a data contract at the producer end, collaborating with the producer to get the data in the form you need. But enforcement at the producer end is intrusive and complex. Each data producer has its own authentication and security mechanisms. The data contract architecture would need to be adapted to each producer. Every new producer added to the architecture would have to be accommodated. In addition, small changes to schema, metadata, and security happen continuously. With Kafka, these changes can be managed in one place.

Kafka sits between producers and consumers. With Kafka Schema Registry, producers and consumers have a way of communicating what is expected by their data contract. Because topics are re-usable, the data contract may be re-usable directly or it could be incrementally modified and then re-used.

Confluent

Kafka also provides shared, standardized security and data infrastructure for all data producers. Schemas can be designed, managed, and enforced at Kafka’s edge, in cooperation with the data producer. Disruptive changes to the data contract can be detected and enforced there.

Data contract implementation needs to be simple and built into existing tools, including continuous integration and continuous delivery (CI/CD). Kafka’s ubiquity, open source nature, scalability, and data re-usability make it the de facto standard for providing re-usable data products with data contracts.

Best practices for developers building data contracts

As a data engineer or developer, data contracts can help you deliver better software and user experiences at a lower cost. Here are a few guidelines for best practices as you start leveraging data contracts for your pipelines and data products.

1. Standardize schema formats: Use Avro or Protobuf for Kafka due to their strong typing and compatibility features. JSON Schema is a suitable alternative but less efficient.
2. Automate validation: Use CI/CD pipelines to validate schema changes against compatibility rules before deployment. Make sure your code for configuring, initializing, and changing Kafka topic schemas is part of your CI/CD workflows and check-ins.
3. Version incrementally: Use semantic versioning (e.g., v1.0.0, v1.1.0) for schemas and document changes. This should be part of your CI/CD workflows and run-time checks for compatibility.
4. Monitor and alert: Set up alerts for schema and type violations or data quality issues in Kafka topics or Flink jobs.
5. Collaborate across teams: Ensure producers and consumers (e.g., different teams’ Flink jobs) agree on the contract up front to avoid mismatches. Leverage collaboration tools (preferably graphical) that allow developers, business analysts, and data engineers to jointly define, refine, and evolve the contract specifications.
6. Test schema evolution: Simulate schema changes in a staging environment to verify compatibility with Kafka topics and Flink jobs.

You can find out more on how to develop data contracts with Kafka here.

Key capabilities for data contracts

Kafka and Flink provide a common language to define schemas, data types, and data quality rules. This common language is shared and understood by developers. It can be independent of the particular data producer or consumer.

Kafka and Flink have critical capabilities to make data contracts practical and widespread in your organization:

• Broad support for potential data producers and consumers
• Widespread adoption, usage, and understanding, partly due to their open source origins
• Many implementations available, including on-prem, cloud-native, and BYOC (Bring Your Own Cloud)
• The ability to operate at both small and large scales
• Mechanisms to modify data contracts and their schemas as they evolve
• Sophisticated mechanisms for evolving schemas and reusing data contracts when joining multiple streams, each with its own data contract.

Data contracts require a new culture and mindset that encourage data producers to collaborate with data consumers. Consumers need to design and describe their schema and other data pipeline requirements in collaboration with producers, and guided by developers and data architects.

Kafka and Flink make it much easier to specify, implement, and enforce the data contracts your collaborative producers and consumers develop. Use them to get your data pipelines up and running faster, operating more efficiently, without downtime, while delivering more value to the business.

—

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.

Michigan and Wisconsin are considering proposals that would ban the use of virtual private networks (VPNs) by requiring internet providers to block these encrypted connections. The stated rationale is to control how users access certain online materials, but such a ban would upend the technical foundation of modern work, learning, and communication far beyond any single issue.

VPNs are not simply niche tools or workarounds. They’re the invisible infrastructure that underpins the security, productivity, and connectivity of countless institutions and individuals worldwide. If states implement a broad VPN ban, the day-to-day operations of businesses, schools, and residents would be severely affected.

The wide reliance on VPNs

Nearly every organization, from large multinational tech companies to small accounting firms, relies on VPNs to protect sensitive operations. In a world of distributed teams, cloud-based applications, and bring-your-own-device workplaces, the only way to keep sensitive company data secure as it moves across public networks is through encrypted VPN connections.

Cloud computing forms the foundation of most business activities. Whether employees are accessing files, databases, or proprietary applications, they often do so through the cloud. Remote workers, traveling employees, or anyone logging in from outside the office requires a VPN to establish a secure connection and protect their activity and the company’s sensitive assets from cyberthreats. Removing VPNs cuts the essential link between remote users and their digital workspace.

The consequences would be immediate and serious: Companies would need to recall staff to physical offices, risking the loss of talent and drops in productivity, or shifting entire operations to more tech-friendly locations. For smaller businesses without the resources to handle these sudden challenges, the impact could be existential.

VPNs are as essential to educational institutions as they are to businesses. Universities, colleges, and even K-12 districts use VPNs to allow students and faculty to access research databases, library archives, and administrative systems from anywhere in the world. The University of Michigan’s own VPN is a crucial tool that enables students and staff to connect securely even when using non-university internet providers.

A ban would prevent students from doing coursework remotely, block faculty from accessing grading portals or academic data anywhere off campus, and make it extremely difficult for school IT teams to maintain security. Academic collaboration—both with colleagues at other institutions within the state and with international peers—would be hindered, isolating campuses at a time when global connectivity has never been more important.

Losing critical privacy and access

For regular internet users, VPNs are a fundamental privacy and security tool similar to having a phone number or locking your mailbox. They prevent third parties from tracking your activity, profiling your location, or creating a detailed record of your browsing history. Public Wi-Fi at coffee shops, airports, or hotels remains a top target for attackers. VPNs mitigate many of these risks, providing users with an important layer of protection.

Users traveling across states or countries rely on VPNs to securely access their home services, bank accounts, and private communications. Freelancers, consultants, medical professionals, and legal experts—anyone who frequently moves between client sites—would be unable to securely connect to their own files or confidential portals.

From a purely technical perspective, attempts to restrict VPNs create problems that are much bigger than the ones they claim to fix. Websites cannot reliably tell whether a VPN connection is coming from a particular state or even another country. If just a few states ban VPNs, sites that face legal risks are likely to block all VPN access globally to avoid accidental violations. This means VPN users everywhere could lose access to vital sites and services simply because of a law in one state. Such broad effects show how a technical policy, made without understanding operational realities, can cause widespread disruption across the internet.

Productivity and security at risk

The unintended consequences of a VPN ban reach well beyond state borders and far beyond the original lawmaking intentions. Without VPNs:

• Businesses lose the option of remote work—and with it, the flexibility and efficiency today’s economy requires.
• Educational institutions and students are cut off from essential resources and collaboration tools.
• Everyday users are exposed to cyberthreats, tracking, and data breaches when using public networks.
• Vulnerable populations, such as journalists, advocates, and individuals relying on privacy for their safety, are deprived of vital digital protections.

Additionally, VPNs are the foundation of many compliance systems, including those overseeing financial data, health records, and legal documents. A ban could lead to legal and regulatory issues for companies trying to stay in good standing.

Informed policy and practical solutions

The debates in Michigan and Wisconsin over VPN access aren’t just about a single technology. They grapple with how societies balance security, productivity, privacy, and economic competitiveness in the digital age. Instead of limiting key security tools, states should focus on promoting cybersecurity education, strengthening tech infrastructure, and implementing smart digital policies that acknowledge the vital role VPNs play in modern life.

The digital world requires thoughtful legislation that helps people and organizations thrive online rather than broad bans that make the internet less useful, secure, and productive for everyone. If Wisconsin and Michigan truly aim to attract business, research, and innovation, maintaining secure, private, and open access to essential technologies like VPNs is a key step.

Many organizations are experimenting with AI agents to determine which job roles to focus on, when to automate actions, and what steps require a human in the middle. AI agents connect the power of large language models with APIs, enabling them to take action and integrate seamlessly into employee workflows and customer experiences in a variety of domains:

• Field operations AI agents can help outline the steps to address a service call.
• HR agents partner with job recruiters to schedule interviews for top applicants.
• Finance AI agents help respond to daily challenges in managing supply chain, procurement, and accounts receivable.
• Coding agents are integrated into AI-assisted development platforms that facilitate vibe coding and accelerate application development.
• AI agents are integrating into the workplace, where they participate in meetings, summarize discussions, create follow-up tasks, and schedule the next meetings.

World-class IT organizations are adapting their strategies and practices to develop AI agents while mitigating the risks associated with rapid deployments. “Building a world-class IT team means leading the conversation on risk,” says Rani Johnson, CIO of Workday. “We work closely with our legal, privacy, and security teams to set a clear adoption risk tolerance that aligns with our overall strategy.”

A key question for every technology, data, and business leader is whether the underlying data that AI agents tap into is “AI-ready.” According to Ocient’s Beyond Big Data report, 97% of leaders report notable increases in data processing due to AI, but only 33% have fully prepared for the escalating scale and complexity of the AI-driven workplace. Establishing data’s AI readiness is critical, as most AI agents leverage enterprise data to provide business, industry, and role-specific responses and recommendations.

I asked business and technology leaders how they were evaluating AI agents for data readiness in domains such as sales, HR, finance, and IT operations. Seven critical practices emerged.

Centralize data and intelligence

IT departments have invested significantly in centralizing data into data warehouses and data lakes, and in connecting resources with data fabrics. However, data is not equivalent to intelligence, as much of the data science and computational work occurs downstream in a sprawl of SaaS tools, data analytics platforms, and other citizen data science tools. Worse, numerous spreadsheets, presentations, and other unstructured documents are often poorly categorized and lack unified search capabilities.

“Instead of endlessly moving and transforming data, we need to bring intelligence directly to where the data lives, creating a journey to enterprise-ready data with context, trust, and quality built in at the source,” says Sushant Tripathi, VP and North America transformation lead at TCS. “This connected organizational intelligence weaves into the fabric of an enterprise, transforming fragmented information into trusted and unified assets so that AI agents can act with the speed and context of your best people, at enterprise scale.”

Even as IT looks to centralize data and intelligence, a backlog of data debt creates risks when using it in AI agents.

“AI-ready data must go beyond volume and accuracy and be unified, trusted, and governed to foster reliable AI,” says Dan Yu, CMO of SAP data and analytics. “With the right business data fabric architecture, organizations can preserve context, mitigate bias, and embed accountability into every layer of AI. This foundation ensures accurate, auditable decisions and enables AI to scale and adapt on semantically rich, governed data products, delivering durable business value.”

Recommendation: Most organizations will have a continuous backlog of dataops and data debt to address. Product-based IT organizations should manage data resources as products and develop roadmaps aligned with their AI priorities.

Ensure compliance with regulations and security standards

When it comes to data security, Jack Berkowitz, chief data officer at Securiti, advises starting by answering who should have access to any given piece of information flowing in or out of the genAI application, whether sensitive information is included in the content, and how this data and information are being processed or queried. He says, “As we move to agentic AI, which is actively able to do processing and take decisions, putting static or flat guardrails in place will fail.”

Guardrails are needed to help prevent rogue AI agents and to use data in areas where the risks outweigh the benefits.

“Most enterprises have a respectable security base with a secure SDLC, encryption at rest and in transit, role-based access control, data loss prevention, and adherence to regulations such as GDPR, HIPAA, and CCPA,” says Joanne Friedman, CEO of ReilAI. “That’s sufficient for traditional IT, but insufficient for AI, where data mutates quickly, usage patterns are emergent, and model behavior must be governed—not guessed.”

Recommendation: Joanne recommends establishing the following four pillars of AI risk-ready data:

• Define an AI bill of materials.
• Use a risk management framework such as NIST AI RMF or ISO 42001.
• Treat genAI prompts as data and protect against prompt injection, data leakage, and related abuses.
• Document AI with model cards and datasheets for datasets, including intended use, limitations, and other qualifications.

Define contextual metadata and annotations

AI language models can be fed multiple documents and data sources with conflicting information. When an employee’s prompt results in an erroneous response or hallucinations, they can respond with clarifications to close the gap.

However, with AI agents integrated into employee workflows and customer journeys, the stakes of poor recommendations and incorrect actions are significantly higher. An AI agent’s accuracy improves when documents and data sources include rich metadata and annotations, signaling how to use the underlying information responsively.

“The AI needs to be able to understand the meaning behind the data by adding a semantic layer, which is like a universal dictionary for your data,” says Andreas Blumauer, SVP growth and marketing at Graphwise. “This layer uses consistent labels, metadata, and annotations to tell the AI what each piece of data represents, linking it directly to your business concepts and questions. This is also where you include specific industry knowledge, or domain knowledge models, so the AI understands the context of your business.”

Recommendation: Leverage industry-specific taxonomies and categorization standards, then apply a metadata standard such as Dublin Core, Schema.org, PROV-O, or XMP.

Review the statistical significance of unbiased data

Surveys are a primary tool of market research. Researchers determine the questions and answers of the survey according to best practices that minimize the exposure of biases to the respondent. For example, asking employees who use the service desk, “How satisfied are you with our excellent help desk team’s quick response times?” is biased because the words excellent and quick in the question imply a subjective standard.

Another challenge for researchers is ensuring a significant sample size for all respondent segments. For example, it would be misleading to report on executive response to the service desk survey if only a handful of people in this segment responded to it.

When reviewing data for use in AI, it is even more important to consider statistical significance and data biases, especially when the data in question underpins an AI agent’s decision-making.

“AI-ready data requires more than conventional quality frameworks, demanding statistical rigor that encompasses comprehensive bias audits with equalized odds, distributional stability testing, and causal identifiability frameworks that enable counterfactual reasoning,” says Shanti Greene, head of data science at AnswerRocket and adjunct professor at Washington University.

“Organizations pursuing transformational outcomes through sophisticated generative models paradoxically remain constrained by data infrastructures exhibiting insufficient volume for edge-case coverage. AI systems remain bounded by statistical foundations, proving that models trained on deficient data can generate confident hallucinations that masquerade as authoritative intelligence.”

Recommendation: Understanding and documenting data biases should be a data governance non-negotiable. Applicable common fairness metrics include demographic parity and equalized odds, while p-value testing is used for statistical significance testing.

Benchmark and review data quality metrics

Data quality metrics focus on a dataset’s accuracy, completeness, consistency, timeliness, uniqueness, and validity. JG Chirapurath, president of DataPelago, recommends tracking the following:

• Data completeness: Fewer than 5% of entries for any critical field may be blank or missing to be considered complete.
• Statistical drift: If any key statistic changes by more than 2% compared to expected values, the data is flagged for human review.
• Bias ratios: If a group or segment experiences outcomes that are more than 20% different from those of another group or segment, the data is flagged for human review.
• Golden data sets: AI outputs must achieve greater than 90% agreement with human-verified ground truth on sample subsets.

Rajeev Butani, chairman and CEO of MediaMint, adds, “Organizations can measure readiness with metrics like null and duplicate rates, schema and taxonomy consistency, freshness against SLAs, and reconciliation variance between booked, delivered, and invoiced records. Bias and risk can be tested through consent coverage, PII exposure scores, and retention or deletion checks.”

Recommendation: Selecting data quality metrics and calculating a composite data health score is a common feature of data catalogs that helps build trust in using datasets for AI and decision-making. Data governance leaders should communicate target benchmarks and establish a review process for datasets that fall below data quality standards.

Establish data classification, lineage, and provenance

Looking beyond data quality, key data governance practices include classifying data for IP and privacy, and establishing data’s lineage and provenance.

“The future is about governing AI agents as non-human identities that are registered, accountable, and subject to the same discipline as people in an identity system,” says Matt Carroll, founder and CEO of Immuta. “This requires classifying information into risk tiers, building in checkpoints for when human oversight is essential, and allowing low-risk interactions to flow freely.”

Geoff Webb, VP of product and portfolio marketing at Conga, shares two key metrics that must be carefully evaluated before trusting the results of any agentic workflows.

• Data provenance refers to the origin of the data. Can the source be trusted, and how did that data become part of the dataset you are using?
• The chronology of the data refers to how old it is. Prevent training models using data that is no longer relevant to the objectives, or that may reflect outdated working practices, non-compliant processes, or simply poor business practices from the past.

Recommendation: Regulated industries have a long history of maturing data governance practices. For companies lagging in these disciplines, data classification is an essential starting point.

Create human-in-the-middle feedback loops

As organizations use more datasets in AI, it is essential to have ongoing validation of the AI language model and agent’s accuracy by subject matter experts and other end-users. Dataops should extend feedback on AI to the underlying data sources to help prioritize improvements and identify areas to be enriched with new datasets.

“In our call centers, we’re not just listening to customer interactions, we’re also feeding that qualitative data back into engineering teams to reshape how experiences are designed,” says Ryan Downing, VP and CIO of enterprise business solutions at Principal Financial Group. “We measure how people interact with AI-infused solutions and how those interactions correlate with downstream behaviors, for example, whether someone still needed to call us after using the mobile app.”

Recommendation: Unstructured datasets and those capturing people’s opinions and sentiments are most prone to variance that statistical methods may not easily validate. When people report odd responses from AI models built on this data, it’s essential to trace back to the root causes in the data, especially since many AI models are not fully explainable.

Automate a data readiness checklist

Guy Adams, CTO of DataOps.live, says “AI-ready data isn’t just good data; it’s good data that’s been productized, governed, and delivered with the correct context so it can be trusted by AI systems today—and reused for the AI use cases we haven’t even imagined yet.”

Organizations that heavily invest in AI agents and other AI capabilities will first ensure their data is ready and then automate a checklist for ongoing validation. The bar should be raised for any dataset’s AI readiness when that data is used for more mission-critical workflows and revenue-impacting customer experiences at greater scales.

Qdrant has released Qdrant 1.16, an update of the Qdrant open source vector database that introduces tiered multitenancy, a capability intended to help isolate heavy-traffic tenants, boost performance, and scale search workloads more efficiently.

Announced November 19, Qdrant 1.16 also offers ACORN, a search algorithm that improves the quality of filtered vector search in cases of multiple filters with weak selectivity, Qdrant said. To upgrade, users can go to Qdrant Cloud, then go to the Cluster Details screen and select Qdrant 1.16 from the dropdown menu.

With tiered multitenancy, users get an improved approach to multitenancy that enables the combining of small and large tenants in a single collection, with the ability to promote growing tenants to dedicated shards, Qdrant said. Multitenancy is a common requirement for SaaS applications, where multiple customers, or tenants, share a database instance. When an instance is shared between multiple users in Qdrant, vectors may need to be partitioned by the user. The main principles behind tiered multitenancy are user-defined sharding, fallback shards, and tenant promotion, Qdrant said. User-defined sharding enables users to create named shards within a collection, allowing large tenants to be isolated in their own shards. Fallback shards are a routing mechanism that allows Qdrant to route a request to a dedicated shard or shared fallback shard. Tenant promotion is a mechanism that allows tenants to be changed from a shared fallback shard to their own dedicated shard when they have grown large enough.

ACORN stands for ANN (Approximate Nearest Neighbor) Constraint-Optimized Retrieval Network. This capability offers improved vector search in cases of multiple filters with weak selectivity, according to Qdrant. With ACORN enabled, Qdrant not only traverses direct neighbors in Qdrant’s HNSW (Hierarchical Navigable Small World) graph-based infrastructure but also examines neighbors of neighbors if direct neighbors have been filtered out. This improves search accuracy but at the expense of performance, especially when multiple low-selectivity filters are applied. Because ACORN is slower (approximately 2x to 10x slower in typical scenarios) but improves recall (i.e. accuracy) for restrictive filters, tuning this parameter is about deciding when the accuracy improvement justifies the performance cost, the company said. Qdrant has published a decision matrix on when to use ACORN.

Qdrant 1.16 also features a revamped UI intended to offer a fresh new look and an improved user experience. The new design incudes a welcome page that offers quick access to tutorials and reference documentation as well as redesigned Point, Visualize, and Graph views in the Collections Manager. This redesign makes it easier to work with data by presenting it in a more-compact format. In the tutorials, code snippets now are executed inline, thus freeing up screen space for better usability, Qdrant said.

Also featured in Qdrant 1.16 is a new HNSW index storage mode, which enables more efficient disk-based vector search; a conditional update API, which facilitates easier migration of embedding models to a new version; and improved full-text search capabilities, with a new text_any condition and ASCII folding support.

Researchers at Socket have uncovered more details of a sophisticated software supply-chain operation linked to the Contagious Interview campaign attacking developers who rely on packages from NPM.

They report finding a “full stack” operation behind the attacks, where code hosting, package distribution, staging servers and command-and control (C2) infrastructure are orchestrated much like a legitimate software development and delivery pipeline — and offer honest developers fresh advice on protecting themselves against the attacks.

In the latest wave, threat actors uploaded almost 200 new malicious NPM packages, with more than 31,000 recorded downloads. The campaign lures victims with fake job interviews and coding assignments related to Web3 and blockchain projects, asking them to pull dependencies for a “test project”. But the NPM packages they install are Trojan horses.

The latest packages identified by Socket ultimately deliver a new payload with upgraded credential theft, system monitoring and remote access capabilities, enabling them to take over developers’ accounts and machines.

Point defense

Based on its latest analysis, Socket advised developers to focus on the weak points this campaign exploits, and to treat every “npm install” as potential remote code execution, restrict what continuous-integration runners can access, enforce network egress controls, and review the code of any new templates or utilities pulled from GitHub. Teams should also scrutinize unfamiliar helper packages, pin known-good versions, and use lockfiles instead of auto-updating dependencies, it advised.

Automated package analysis can further reduce risk, with real-time scans catching threats including import-time loaders, network probing, and bulk data exfiltration before they hit developer machines or CI systems.

With these checks in place, dependency onboarding and code review become effective filters for blocking Contagious Interview-style attacks early, Socket said.

Coding tasks lead to malware delivery

These defensive measures are effective because Contagious Interview’s entry vector relies heavily on social engineering, using fake interview tasks to trick developers into installing compromised dependencies.

The campaign exploits NPM, a widely used package registry for JavaScript and Node.js, by publishing packages that appear benign but carry hidden payloads. The malicious packages including one named “tailwind-magic” mimic legitimate libraries (in this case, a typosquatted version of the genuine “tailwind-merge” utility) to avoid suspicion.

When an unsuspecting developer installs such a package, a post-install script triggers and reaches out to a staging endpoint hosted on Vercel. That endpoint in turn delivers a live payload fetched from a threat-actor controlled GitHub account named “stardev0914”. From there the payload, a variant of OtterCookie that also folds in capabilities from the campaign’s other signature payload, BeaverTail, executes and establishes a remote connection to the attackers’ control server. The malware then silently harvests credentials, crypto-wallet data, browser profiles and more.

“Tracing the malicious npm package tailwind-magic led us to a Vercel-hosted staging endpoint, tetrismic[.]vercel[.]app,and from there to the threat actor controlled GitHub account which contained 18 repositories,” Socket’s senior threat intelligence analyst Kirill Boychenko said in a blog post, crediting related research by Kieran Miyamoto that helped confirm the malicious GitHub account stardev0914.

A ‘full stack’adversary: GitHub, Vercel, and NPM

What makes this campaign stand out is the layered infrastructure behind it. Socket’s analysis traced not just the NPM packages but also how the attackers built a complete delivery pipeline: malware serving repositories on GitHub, staging servers on Vercel, and separate C2 servers for exfiltration and remote command execution.

Through this setup, attackers can rotate payloads, update malware unobtrusively, and tailor deployments per target—all while blending deeply into the legitimate developer ecosystem, according to Boychenko.

Once installed, OtterCookie doesn’t just run and vanish: It remains persistent, capable of logging keystrokes, hijacking the clipboard, scanning the filesystem, capturing screenshots, and grabbing browser and wallet credentials across Windows, macOS and Linux.

The campaign actors’ intensified NPM activity arrives at a worrying moment for the JavaScript and open-source ecosystem. In recent months, the community has seen a flurry of NPM-based attacks — including worm-style campaigns that transformed popular packages into Trojan horses, automated credential theft, and widespread supply chain compromise across both development and CI environments.

Sometimes in tech we misunderstand our history. For example, because Linux eventually commoditized the Unix wars, and because Apache and Kubernetes became the standard plumbing of the web, we assume that “openness” is an inevitable force of nature. The narrative is comforting; it’s also mostly wrong.

At least, it’s not completely correct in the ways advocates sometimes suppose.

When open source wins, it’s not because it’s morally superior or because ”many eyes make all bugs shallow” (Linus’s Law). It dominates when a technology becomes infrastructure that everyone needs but no one wants to compete on.

Look at the server operating system market. Linux won because the operating system became a commodity. There was no competitive advantage in building a better proprietary kernel than your neighbor; the value moved up the stack to the applications. So, companies like Google, Facebook, and Amazon poured resources into Linux, effectively sharing the maintenance cost of the boring stuff so they could compete on the interesting stuff where data and scale matter most (search, social graphs, cloud services).

This brings us to artificial intelligence. Open source advocates point to the explosion of “open weights” models like Meta’s Llama or the impressive efficiency of DeepSeek’s open source movement, and they declare that the closed era of OpenAI and Google is already over. But if you look at the actual money changing hands, the data tells a different, much more interesting story, one with a continued interplay between open and closed source.

Losing $25 billion

A recent, fascinating report by Frank Nagle (Harvard/Linux Foundation) titled “The Latent Role of Open Models in the AI Economy” attempts to quantify this disconnect. Nagle’s team analyzed data from OpenRouter and found a staggering inefficiency in the market. Today’s open models routinely achieve 90% (or more) of the performance of closed models while costing about one-sixth as much to run. In a purely rational economic environment, enterprises should be abandoning GPT-4 for Llama 3 en masse.

Nagle estimates that by sticking with expensive closed models, the global market is leaving roughly $24.8 billion on the table annually. The academic conclusion is that this is a temporary market failure, a result of “information asymmetry” or “brand trust.” The implication is that once CIOs realize they are overpaying, they will switch to open source, and the proprietary giants will topple.

Don’t bet on it.

To understand why companies are happily “wasting” $24 billion, and why AI will likely remain a hybrid of open code and closed services, we have to stop looking at AI through the lens of 1990s software development. As I’ve written, open source isn’t going to save AI because the physics of AI are fundamentally different from the physics of traditional software.

The convenience premium

In the early 2010s, we saw a similar “inefficiency” with the rise of cloud computing. You could download the exact same open source software that AWS was selling—MySQL, Linux, Apache—and run it yourself for free. Yet, as I noted, developers and enterprises flocked to the cloud, paying a massive premium for the privilege of not managing the software themselves.

Convenience trumps code freedom. Every single time.

The $24 billion “loss” Nagle identifies isn’t wasted money; it is the price of convenience, indemnification, and reliability. When an enterprise pays OpenAI or Anthropic, they aren’t just buying token generation. They are buying a service-level agreement (SLA). They are buying safety filters. They are buying the ability to sue someone if the model hallucinates something libelous.

You cannot sue a GitHub repository.

This is where the “openness wins” argument runs into reality. In the AI stack, the model weights are becoming “undifferentiated heavy lifting,” the boring infrastructure that everyone needs but no one wants to manage. The service layer (the reasoning loops, the integration, the legal air cover) is where the value lives. That layer will likely remain closed.

The ‘community’ that wasn’t

There is a deeper structural problem with the “Linux of AI” analogy. Linux won because it harnessed a large, decentralized community of contributors. The barrier to entry for contributing to a large language model (LLM) is much higher. You can fix a bug in the Linux kernel on a laptop. You cannot fix a hallucination in a 70-billion-parameter model without access to the original training data and a compute cluster that costs more than any individual developer can afford, unless you’re Elon Musk or Bill Gates.

There is also a talent inversion at play. In the Linux era, the best developers were scattered, making open source the best way to collaborate. In the AI era, the scarce talent—the researchers who understand the math behind the magic—are being hoarded inside the walled gardens of Google and OpenAI.

This changes the definition of “open.” When Meta releases Llama, the license is almost immaterial because of the barriers to running and testing that code at scale. They are not inviting you to co-create the next version. This is “source available” distribution, not open source development, regardless of the license. The contribution loop for AI models is broken. If the “community” (we invoke that nebulous word far too casually) cannot effectively patch, train, or fork the model without millions of dollars in hardware, then the model is not truly open in the way that matters for long-term sustainability.

So why are Meta, Mistral, and DeepSeek releasing these powerful models for free? As I’ve written for years, open source is selfish. Companies contribute to open source not out of charity, but because it commoditizes a competitor’s product while freeing up resources to pay more for their proprietary products. If the intelligence layer becomes free, the value shifts to the proprietary platforms that use that intelligence (conveniently, Meta owns a few of these, such as Facebook, Instagram, and WhatsApp).

Splitting the market into open and closed

We are heading toward a messy, hybrid future. The binary distinction between open and proprietary is dissolving into a spectrum of open weights, open data (rare), and fully closed services. Here is how I see the stack shaking out.

Base models will be open. The difference between GPT-4 and Llama 3 is already negligible for most business tasks. As Nagle’s data shows, the catch-up speed is accelerating. Just as you don’t pay for a TCP/IP stack, you soon won’t pay for raw token generation. This area will be dominated by players like Meta and DeepSeek that benefit from the ecosystem chaos.

The real money will shift to the data layer, which will continue to be closed. You might have the model, but if you don’t have the proprietary data to fine-tune it for medical diagnostics, legal discovery, or supply chain logistics, the model is a toy. Companies will guard their data sets with far more ferocity than they ever guarded their source code.

The reasoning and agentic layer will also stay closed, and that’s where the high-margin revenue will hide. It’s not about generating text; it’s about doing things. The agents that can autonomously navigate your Salesforce instance, negotiate a contract, or update your ERP system will be proprietary because they require complex, tightly coupled integrations and liability shields.

Enterprises will also pay for the tools that ensure they aren’t accidentally leaking intellectual property or generating hate speech—stuff like observability, safety, and governance. The model might be free, but the guardrails will cost you.

Following the money

Frank Nagle’s report correctly identifies that open models are technically competitive and economically superior in a vacuum. But business doesn’t happen in a vacuum. It happens in a boardroom where risk, convenience, and speed dictate decisions.

The history of open source is not a straight line toward total openness. It is a jagged line where code becomes free and services become expensive. AI will be no different. The future is the same as it ever was: open components powering closed services.

The winners won’t be the ideological purists. The winners will be the pragmatists who take the free, open models, wrap them in proprietary data and safety protocols, and sell them back to the enterprise at a premium. That $24 billion gap is just going to be reallocated to the companies that solve the “last mile” problem of AI: a problem that open source, for all its many virtues, has never been particularly good at solving.

Success as an independent software developer requires a lot of preparation and hard work, as well as some luck. But as baseball executive Branch Rickey once said, luck is the residue of design.

Income for freelance developers varies depending on factors such as location, experience, skills, and project type. Average pay for a contractor is about $111,800 annually, according to ZipRecruiter, with top earners making potentially more than $151,000.

That’s in line with what developers in general can expect to make, based on U.S. Bureau of Labor Statistics figures for median pay in 2024, the most recent figure available as of this writing.

So, what does it take to succeed as a freelancer in the tech industry? I asked five successful independent developers how they did it.

1. Become a business

Creating a formal business can be a good way to attract new clients and retain existing ones.

“One of the most important ways to succeed as an independent developer is to treat yourself like a business,” says Darian Shimy, CEO of FutureFund, a fundraising platform built for K-12 schools, and a software engineer by trade.

“That means setting up an LLC or sole proprietorship, separating your personal and business finances, and using invoicing and tax tools that make it easier to stay compliant,” Shimy says. “For some people, it might feel like an overkill or unnecessary overhead at first. But that type of structure will help give your clients confidence and save you a few headaches down the road.”

Independent developers often underestimate the value of structure, says Sonu Kapoor, who has worked as an independent software engineer for more than two decades, architecting front ends for Citigroup’s global trading platform, leading RFID integration at American Apparel, and modernizing enterprise stacks for Sony Music Publishing and Cisco.

“For individual developers, the difference between staying small and landing enterprise-scale work often comes down to perception,” Kapoor says. “Early on, I treated my freelance work like a company, registering a limited entity, keeping separate finances, and using professional tools like QuickBooks and HubSpot. But what really moved the needle was building relationships with senior leaders inside companies like Citigroup and Sony Music Publishing. Enterprises rarely hire individuals directly; contracts usually flow through vendors.”

Kapoor focused on networking with decision-makers, showcasing credibility through his previous work and thought leadership. “That combination of structure and relationships opened doors that pure technical skill alone never could,” he says. “Running my freelance career as a structured business with processes, relationships, and professional credibility turned those introductions into sustained partnerships. It’s not about pretending to be a big company; it’s about operating with the same reliability as one.”

2. Find your niche

Being a jack of all trades in the development world can be helpful for working on broad projects. But for some, success comes with specialization.

“The biggest leap in my independent career came when I stopped spreading myself thin across frameworks and committed fully to Angular,” Kapoor says. “That focus reshaped my professional identity, leading to an invitation to join a private group of 11 global Angular collaborators who work directly with Google’s core team.”

Soon after, Kapoor was recognized as a Google Developer Expert, which opened doors to speaking, consulting, and global visibility. This included being featured on a Topmate billboard in Times Square, New York City, highlighting his work on Angular and AI.

“That depth also brought new opportunities organically,” Kapoor says. After seeing his work as a technical editor and contributor in the developer publishing space, Apress approached him to author a book on Angular Signals.

“It was a full-circle moment, recognition not just for coding expertise, but for shaping how developers learn emerging technologies,” Kapoor says. “Specialization builds identity. Once your expertise becomes synonymous with progress in a field, opportunities—whether projects, media, or publishing—start coming to you.”

Shimy of FutureFund followed a similar arc. At first, “I really tried to be everything to everyone,” he says. “It’s a similar outlook a lot of agencies have—do we want to specialize in one or two areas or be ‘decent’ at five or six things? A niche helps you stand out, build a reputation, and get referrals more easily.”

3. Build authority through visible contributions

Publishing open source work and becoming known for thought leadership creates leverage and new opportunities for independent developers, Kapoor says. “Early in my career, I launched DotNetSlackers, a technical community that reached over 33 million views and became one of the top destinations for .NET content,” he says. “I didn’t realize it at the time, but that reach was more powerful than any marketing budget.”

CTOs and engineering managers started discovering Kapoor’s work organically, he says. “One of my first major enterprise contracts came from a client who had been reading my posts for months before reaching out,” he says.

That same principle carried forward when Kapoor shifted to Angular. “Using open source, I created over 100 code changes within one year in the Angular repository,” he says. “Contributing to Angular’s Typed Forms, which became the most upvoted feature request in Angular history, put my work in front of the global developer community and directly led to my Microsoft MVP and later Google Developer Expert recognitions.”

Each visible contribution, whether it’s an open source library, conference talk, or published article in CODE Magazine, helps create credibility for independent developers, Kapoor says. “Developers often underestimate how far a single well-documented idea can travel,” he says. “One blog post can bring in client leads years later. In my case, it’s created a steady loop of media visibility, consulting opportunities, and technical recognition that continues to grow long after the initial effort.”

4. Prioritize communication to build relationships

Freelancers in any field need to know how to communicate well, whether it’s through the written word or conversations with clients and colleagues. If a developer communicates poorly, even great talent might not make the difference in landing gigs.

“My main tip, having been an indie developer for several years and now the CEO of a development agency, is to always communicate clearly and thoroughly,” says Lisa Freeman, CEO at 18a, a web design, development, and hosting services provider.

“We work with the same clients for years—some over a decade—and that’s because of how we communicate,” Freeman says. “It’s easier to keep clients you’ve got than constantly [needing] to win new ones, as the competition is fierce nowadays.”

A relationship with a client is as important if not more so than the code produced, Freeman says. “Don’t bamboozle them with complicated things they don’t need, but explain why you’ve done things the way you have,” she says.

One area where Freeman often sees developers falling short is in communicating to clients where they’ve added value. “If a client asks for something and the developer does it in a way that makes things quicker another day, or helps solve another issue…that all needs to be highlighted,” she says. “It often doesn’t seem worth mentioning, but honestly, these little extras just help build a better impression in the mind of the client and keep them coming back to you.”

A key to good communication is to practice translating technical jargon into something more approachable, says Mia Kotalik, who became a full-time freelance developer in 2022.

“You can’t win trust by drowning non-technical clients in tech jargon,” Kotalik says. “It makes people feel talked down to and reluctant to engage with you. Explain concepts in non-technical language first, then introduce key terms with one-line definitions so clients feel informed, not overwhelmed. This skill is a differentiator: Clients understand the plan, feel respected, and still see that you’re technically rigorous. This skill is arguably the most important.”

5. Create a portfolio of your work

A portfolio of work tells the story of what you bring to the table. It’s the main way to showcase your software development skills and experience, and is a key tool in attracting clients and projects. A good portfolio supplements a resume and other materials needed to demonstrate what you are capable of doing.

“You will need customers who are willing to take a risk on an independent developer,” says Brad Weber, founder and president of InspiringApps, a company that designs and builds custom digital products, and previously an independent developer for 12 years.

“Minimize their risk by having similar work you can point to for reference,” Weber says. “If that sounds like a Catch-22 when you are starting, it is. I found it effective to do work for free or greatly reduced price for friends, family, and not-for-profit organizations.”

Independent software developers first starting out don’t even need to wait for a client to build a portfolio, Kotalik says. “Make apps and websites in your free time,” she says. “I built my first sites on my own time for free; by the second hobby project, paid clients started reaching out.”

AWS has launched Flexible Training Plans (FTPs) for inference endpoints in Amazon SageMaker AI, its AI and machine learning service, to offer customers guaranteed GPU capacity for planned evaluations and production peaks.

Typically, enterprises use SageMaker AI inference endpoints, which are managed systems, to deploy trained machine learning models in the cloud and run predictions at scale on new data.

For instance, a global retail enterprise can use SageMaker inference endpoints to power its personalized-recommendation engine: As millions of customers browse products across different regions, the endpoints automatically scale compute and storage to handle traffic spikes without the company needing to manage servers or capacity planning.

However, the auto-scaling nature of these inference endpoints might not be enough for several situations that enterprises may encounter, including workloads that require low latency and consistent high performance, critical testing and pre-production environments where resource availability must be guaranteed, and any situation where a slow scale-up time is not acceptable and could harm the application or business.

According to AWS, FTPs for inferencing workloads aim to address this by enabling enterprises to reserve instance types and required GPUs, since automatic scaling up doesn’t guarantee instant GPU availability due to high demand and limited supply.

FTPs support for SageMaker AI inference is available in US East (N. Virginia), US West (Oregon), and US East (Ohio), AWS said.

Reducing operational load and costs

The guarantee of GPU availability, according to analysts, solves major challenges that enterprises face around scaling AI and machine learning workloads.

“The biggest change is reliability,” said Akshat Tyagi, associate practice leader at HFS Research. “Before this update, enterprises had to deploy Inference Endpoints and hope the required GPU instances were available. When GPUs were scarce, deployments failed or got delayed. Now they can reserve the exact GPU capacity weeks or months in advance. This can be huge for teams running LLMs, vision models, or batch inference jobs where downtime isn’t an option.”

Forrester’s principal analyst Charlie Dai termed the new capability a “meaningful step” toward cost governance that reduces cost unpredictability for AI operationalization: “Customers can align spend with usage patterns and avoid overprovisioning, which will lower idle costs,” Dai said.

Tyagi pointed out that by reserving capacity in advance, AWS customers can pay a lower committed rate compared to on-demand pricing, lock in pricing for a set period, avoid expensive last-minute scrambling or scaling up to more costly instance types, and plan budgets more accurately because the expenditure is fixed upfront.

The ability to reserve instances, Tyagi added, also might stop the trend of enterprises being forced to “run” inference endpoints 24*7 in fear of not being able to secure them when needed, which in itself causes more unavailability.

AWS isn’t the only hyperscaler that is offering the option to reserve instances for inference workloads.

While Microsoft Azure offers reserved capacity for inference via Azure Machine Learning, Google Cloud provides committed use discounts for Vertex AI.

Download the December 2025 issue of the Enterprise Spotlight from the editors of CIO, Computerworld, CSO, InfoWorld, and Network World.

Prepare to be surprised when we compare Python and Kotlin for simple programs, loops, imports, exceptions, and more. You can also get a super early preview of Python’s next-generation (Python 3.15) sampling profiler, get up close with AWS’s new AI-powered Zed editor, and explore your options for AI/ML programming outside of the Python ecosystem. Find these stories and more in this week’s Python Report.

Top picks for Python readers on InfoWorld

Python vs. Kotlin: Side-by-side code comparison
How does the snake stack up against a new-school JVM language? Prepare to be surprised (video).

Hands-on with the new sampling profiler in Python 3.15
The next version of Python is over a year away, but you can try out one of its hottest features right now (video).

Hands-on with Zed: The IDE built for AI
AWS’s Zed IDE was designed from the ground up for machine-native speed, integrates collaborative features, and sports its own custom LLM for code completion.

AI and machine learning outside of Python
Python might be the best, but it’s not your only choice for AI and machine learning. Here’s what you need to know about using Java, Rust, Go, or C#/.Net for AI/ML.

More good reads and Python updates elsewhere

Pyrefly language server is now in beta
Meta’s high-performance type checking and code linting tool for Python is now being offered as a production-ready (if still fast-developing) project.

Phoronix.com’s Python 3.14 benchmark suite
For the most part, Python 3.14’s performance stands up to or exceeds its predecessors. But you’ll want to know about these eyebrow-raising exceptions to the rule.

NiceGui 3.0: Python UIs in HTML made simple (and nice)
We’ve talked before about the NiceGUI library, used for quickly designing Python app UIs with HTML. The latest major version is out, with tons of convenience improvements, Tailwind 4 support, and a new event system.

Slightly off-topic: Microsoft open sources original Zork I-III code
Three classic text adventure games that inspired generations of developers are now available for all to read, run, and tinker with under the MIT license.

It was supposed to be a routine Tuesday. Employees trickled into the office of a mid-sized logistics company; some grabbed coffee, others settled at their desks. As they tried to access their shipment-tracking dashboards, schedule pickups, or even log in to the HR portal, critical systems inexplicably went offline. Chaos ensued.

The IT team scrambled to diagnose the problem, initially confused because their company’s tech infrastructure didn’t rely on the major cloud service that had been hit by a significant outage that morning. Hours later, they learned their software vendors—and their vendors’ vendors—depended on that cloud provider. Like many others, the company unexpectedly fell victim to the complexities of modern cloud systems.

This story echoes across industries every time an infrastructure as a service (IaaS) provider stumbles. It happens more often than most realize. The truth is that we’ve constructed a digital world on a surprisingly fragile foundation, building whole economies, sometimes unknowingly, on just a handful of hyperscaler companies.

The domino effect

Beneath the elegant veneer of mobile apps, dashboards, and connected devices lies a labyrinth of technical dependencies. Cloud computing promised affordable scalability and offloaded complexity. As adoption snowballed, a handful of giants (Amazon Web Services, Microsoft Azure, Google Cloud Platform) and a small circle of others became the backbone for modern digital services. These hyperscalers offer infrastructure so ubiquitous that many technology providers, even ones hesitant to rely on the tech titans directly, still depend on them indirectly through partner services, APIs, or even core infrastructure providers that themselves run on the cloud.

When one of these hyperscalers suffers an outage, the impact is uncontained. It cascades. In late 2025, for example, three major outages at Amazon Web Services, Microsoft Azure, and Cloudflare rippled across industries with astonishing speed. Delta and Alaska airlines couldn’t check in passengers. Gaming and streaming platforms like Roblox and Discord ground to a halt. Even internet-connected “smart beds” and residential video doorbells became unusable.

It’s tempting to write these off as embarrassing but rare moments in the industry’s upward arc, but the frequency is increasing. More importantly, the scope is far broader than what’s visible on outage maps. For every downed social media giant, thousands of enterprises, municipalities, and nonprofits experience the same disruptions in silence, sometimes without even knowing where to place the blame.

Costs are higher than they appear

Whenever an outage disrupts our digital core, the damage extends beyond customer complaints. The adverse effects are immediate and widespread: decreased productivity, delayed or missed financial transactions, and erosion of trust.

Estimating the global economic loss from outages is also tricky. Brief disruptions can cost companies hundreds of millions of dollars in downtime, lost transactions, customer support costs, and reputational damage. The hidden costs for third-party providers, such as compensating customers and re-architecting platforms, push the total losses into the billions.

It’s not just about money. Modern life depends on the invisible infrastructure of the cloud. Outages lead to confusion, missed opportunities, and sometimes serious risks, such as medical services or public utilities going dark due to software failures deep within their systems.

Typical approaches fail

Following these outages, calls for regulation have intensified. Lawmakers and consumer advocates seek to investigate, enforce redundancy, and possibly even break up platforms that are increasingly regarded as “too big to fail.” That’s understandable, but it only addresses the most superficial layer of the issue.

Regulatory guardrails can only do so much; outages often result from minor errors, bugs, or routine changes more than from catastrophic hacks. No legislation can prevent typos, misconfigurations, or software mishaps. If anything, the drumbeat for outside intervention can give businesses a false sense of security, believing that safety is someone else’s job, or that headline-grabbing outages are unavoidable acts of fate.

The urgent need for resilience

The solution is both challenging and empowering. Enterprises must own their architectures, identify direct and indirect dependencies, and plan for failures. Resilience can’t be an afterthought or delegated solely to IT; it must be a core mindset of every digital transformation.

This requires answers to some tough questions: If a core provider or one of our technology partners suffers an outage, what happens? Which systems go offline, which degrade gracefully, and which are truly mission-critical? How can redundancy—real, cross-provider redundancy, not mere failover within a single vendor’s walled garden—be built into every layer of operations? Are we confident in our disaster recovery and business continuity strategies, or do they only exist on paper?

The recent series of outages was a wake-up call, highlighting how few organizations have truly robust plans in place. Too many were caught flat-footed, unsure how to respond or not even sure what had failed and why.

A plan built on awareness and action

We are not powerless in the face of these challenges. The answer isn’t to “uncloud” entirely or freeze innovation, but to build digital ecosystems that acknowledge their real-world fragility. This means deeper due diligence when selecting partners, open conversations about dependencies, and above all, engineering for failure rather than assuming it won’t occur.

The lesson should be clear by now: The interconnected nature of cloud services means the entire economy is only as resilient as its weakest link. Enterprises must look beyond the marketing gloss and prepare for the inevitable, not just the ideal. Only through proactive, ongoing investments in resilience can we stop reliving the same costly surprises week after week.

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1] 

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

• Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
• Automation: Automating away toil is a key goal for any devops team.
• Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
• Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
• Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

• CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
• Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
• AI  and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

 Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

More on devops:

• Devops debt: The hidden tax on innovation
• 10 big devops mistakes and how to avoid them
• Smarter devops: How to avoid deployment horrors

Google’s Antigravity development tool for creating artificial intelligence agents has been out for less than 11 days and already the company has been forced to update the known issues pages after security researchers discovered what they say are vulnerabilities.

According to a blog from Mindgard, one of the first to discover problems with Antigravity, Google isn’t calling the issue it found a security bug. But Mindgard says a threat actor could create a malicious rule by taking advantage of Antigravity’s strict direction that any AI assistant it creates must always follow user-defined rules.

Author Aaron Portnoy, Mindgard’s head of research and innovation, says that after his blog was posted, Google replied on November 25 to say a report has been filed with the responsible product team.

Still, until there is action, “the existence of this vulnerability means that users are at risk to backdoor attacks via compromised workspaces when using Antigravity, which can be leveraged by attackers to execute arbitrary code on their systems. At present there is no setting that we could identify to safeguard against this vulnerability,” Portnoy wrote in his blog.

Even in the most restrictive mode of operation, “exploitation proceeds unabated and without confirmation from the user,” he wrote.

Asked for comment, a Google spokesperson said the company is aware of the issue reported by Mindguard, and is working to address it. 

In an email, Mindgard’s Portnoy told CSOonline that the nature of the flaw makes it difficult to mitigate. “Strong identity would not help mitigate this issue, because the actions undertaken by Antigravity are occurring with the identity of the user running the application,” he said. “As far as the operating system can tell, they are indistinguishable. Access management control could possibly do so, but only if you were able to restrict access to the global configuration directory, and it may have downstream impact on Antigravity’s functionality.” For example, he said, this could cause Model Context Protocol (MCP), a framework for standardizing the way AI systems share data, to malfunction.

“The attack vector is through the source code repository that is opened by the developer,” he explained, “and doesn’t need to be triggered through a prompt.”

Other researchers also have found problems with Antigravity:

• Adam Swanda says he discovered and disclosed to Google an indirect prompt injection vulnerability. He said Google told him the particular problem is a known issue and is expected behavior of the tool.
• another researcher who goes by the name Wunderwuzzi blogged about discovering five holes, including data exfiltration and remote command execution via indirect prompt injection vulnerabilities. 
  This blog notes that, according to Google’s Antigravity Known Issues page, the company is working on fixes for several issues.   

Asked for comment about the issues reported in the three blogs, a Google spokesperson said, “We take security issues very seriously and encourage reporting of all vulnerabilities so we can identify and address them quickly. We will continue to post known issues publicly as we work to address them.”

What is Antigravity?

Antigravity is an integrated application development environment (IDE), released on November 18, that leverages the Google Gemini 3 Pro chatbot. “Antigravity isn’t just an editor,” Google says. “It’s a development platform that combines a familiar, AI-powered coding experience with a new agent-first interface. This allows you to deploy agents that autonomously plan, execute, and verify complex tasks across your editor, terminal, and browser.”

Individuals — including threat actors — can use it for free.

Google Antigravity streamlines workflows by offering tools for parallelization, customization, and efficient knowledge management, the company says, to help eliminate common development obstacles and repetitive tasks. Agents can be spun up to tackle routine tasks such as codebase research, bug fixes, and backlog tasks.

Agent installs the malware

The problem Mindgard discovered involves Antigravity’s rule that the developer has to work within a trusted workspace or the tool won’t function. The threat manifests through an attacker creating a malicious source code repository, Portnoy says. “Then, if a target opens it (through finding it on Github, being social engineered, or tricked into opening it) then that user’s system becomes compromised persistently.” 

The malicious actor doesn’t have to create an agent, he explained. The agent is part of Antigravity and is backed by the Google Gemini LLM. The agent is the component that is tricked into installing the backdoor by following instructions in the malicious source code repository that was opened by the user.

“In Antigravity,” Mindgard argues, “’trust’ is effectively the entry point to the product rather than a conferral of privileges.” The problem, it pointed out, is that a compromised workspace becomes a long-term backdoor into every new session. “Even after a complete uninstall and re-install of Antigravity,” says Mindgard, “the backdoor remains in effect. Because Antigravity’s core intended design requires trusted workspace access, the vulnerability translates into cross-workspace risk, meaning one tainted workspace can impact all subsequent usage of Antigravity regardless of trust settings.”

For anyone responsible for AI cybersecurity, says Mindguard, this highlights the need to treat AI development environments as sensitive infrastructure, and to closely control what content, files, and configurations are allowed into them.

Process ‘perplexing’

In his email, Portnoy acknowledged that Google is now taking some action. “Google is moving through their established process, although it was a bit perplexing on the stop-and-start nature. First [the reported vulnerability] was flagged as not an issue. Then it was re-opened. Then the Known Issues page was altered in stealth to be more all encompassing. It’s good that the vulnerability will be reviewed by their security team to ascertain its severity, although in the meantime we would recommend all Antigravity users to seriously consider the vulnerability found and means for mitigation.”

Adam Swanda says in his blog that he was able to partially extract an Antigravity agent’s system prompt, enough to identify a design weakness that could lead to indirect prompt injection.

Highlights broader issues

The problem is, the prompt tells the AI to strictly follow special XML-style tags that handle privileged instructions in a conversation between a user and the chatbot, so there would be no warning to the user that special, and possibly malicious, instructions were retrieved. When the agent fetches external web content, Swanda says, it doesn’t sanitize these special tags to ensure they are actually from the application itself and not untrusted input. An attacker can embed their own special message in a webpage, or presumably any other content, and the Antigravity agent will treat those commands as trusted system instructions.

This type of vulnerability isn’t new, he adds, but the finding highlights broader issues in large language models and agent systems:

• LLMs cannot distinguish between trusted and untrusted sources;
• untrusted sources can contain malicious instructions to execute tools and/or modify responses returned to the user/application;
• system prompts should not be considered secret or used as a security control.

Advice to developers

Swanda recommends that app development teams building AI agents with tool-calling:

• assume all external content is adversarial. Use strong input and output guardrails, including tool calling; Strip any special syntax before processing;
• implement tool execution safeguards. Require explicit user approval for high-risk operations, especially those triggered after handling untrusted content or other dangerous tool combinations;
• not rely on prompts for security. System prompts, for example, can be extracted and used by an attacker to influence their attack strategy.

In addition, Portnoy recommends that developers work with their security teams to ensure that they sufficiently vet and assess the AI-assisted tools that they are introducing to their organization. “There are numerous examples of using AI-assisted tools to accelerate development pipelines to enhance operational efficiency,” he said. “However, from experience, security in bleeding-edge (recently dropped) tools is somewhat of an afterthought. Thinking seriously about the intended use case of the AI tool, what data sources it can access, and what it is connected to are fundamental to ensuring you remain secure.” 

This article originally appeared on CSOonline.

OpenAI has suffered a significant data breach after hackers broke into the systems of its analytics partner Mixpanel and successfully stole customer profile information for its API portal, the companies have said in coordinated statements.

According to a post by Mixpanel CEO Jen Taylor, the incident took place on November 8 when the company “detected a smishing campaign and promptly executed our incident response processes.”

Smishing is a form of phishing-by-SMS against targeted employees, popular with hackers because text messages bypass normal enterprise controls. This gave the attackers access to Mixpanel’s system, allowing them to steal a range of metadata relating to platform.openai.com account profiles:

• Name provided to OpenAI on the API account 
• Email address associated with the API account
• Approximate location based on API user browser (city, state, country)
• Operating system and browser used to access the API account
• Referring websites
• Organization or User IDs associated with the API account

“We proactively communicated with all impacted customers. If you have not heard from us directly, you were not impacted,” said Taylor.

According to a separate OpenAI post, Mixpanel shared the affected customer dataset with it on November 25. After review, OpenAI had terminated its use of Mixpanel, it said, implying that this might be permanent.

The incident affects some customers with platform.openai.com accounts, but not users of ChatGPT or other OpenAI products, OpenAI said.

“We are in the process of notifying impacted organizations, admins, and users directly. While we have found no evidence of any effect on systems or data outside Mixpanel’s environment, we continue to monitor closely for any signs of misuse,” OpenAI said.

“This was not a breach of OpenAI’s systems. No chat, API requests, API usage data, passwords, credentials, API keys, payment details, or government IDs were compromised or exposed.”

How should customers react?

There are three levels of concern here: which OpenAI API customers are affected, how attackers might use stolen data if they are, and the possibility, however hypothetical, that more valuable data such as API keys or account credentials could be at risk.

On the first issue, as noted above, both companies have said they have contacted customers caught up in the breach without specifying how many users are affected. OpenAI has set up an email address customers can use if they have further questions: mixpanelincident@openai.com. Mixpanel has set up an equivalent contact address: support@mixpanel.com⁠.

Nevertheless, if decades of data breaches have taught the world anything it’s that companies don’t always know the full extent of a data breach even when they say they do. For that reason, it would be wise for OpenAI customers who have not been contacted to conduct the same security review as those that have.

OpenAI said that customers should be on their guard for phishing attacks targeting breached email addresses and to check that messages that appear to be sent from OpenAI’s domain are genuine. They should also turn on multi-factor authentication (MFA).

If phishing sounds generic, in the context of an API connection the dangers are more specific and include more nuanced fake alerts for things like billing, quota messages, and suspicious logins.

According to OpenAI, there is no need for customers to rotate or reset account credentials or API keys, which attackers could use to steal data or consume services. Despite this, cautious developers are likely to ignore this and rotate and reset credentials because this removes the risk. 

Several organizations involved in API and AI security have offered more detailed breakdowns of recommendations in the light of the OpenAI-Mixpanel incident, including Ox Security, and Dev Community.

Downstream attack surface

OpenAI uses external analytics platforms such as Mixpanel to track how customers interact with models through the API. This includes which models a customer selects plus basic metadata such as location and email ID listed above. It does not track the user ‘payload’, that is chatbot queries and responses being sent to the model from a browser, which are encrypted.  

The latest incident underlines that the security of the primary platform is only one part of the risk: secondary platforms and partners are a backdoor that can expose even careful organizations, as some Salesforce customers have seen with data breaches at its partner Salesloft.

The attack surface exposed by AI platforms is bigger than it looks, a security and governance challenge enterprises should assess before jumping in with both feet.

Microsoft unveiled its awkwardly named Copilot in Azure back in 2024. That was followed by the Azure Model Context Protocol Server, called from the GitHub Copilot agent in Visual Studio Code. Now, Microsoft is putting the band back together, with a new Azure Copilot that builds on both earlier projects to deliver a set of useful tools for all parts of the cloud application life cycle: for infrastructure as a service and platform as a service.

Announced at Ignite 2025, the new Azure Copilot is a collection of specialized agents that can help you with a wide selection of different cloud management tasks, either on their own or working together. The original Copilot in Azure was an assistive chatbot, useful but unable to execute actions. You had to copy and paste responses into the Azure CLI or follow instructions in the portal.

Introducing agentic cloud ops

The revamped Azure Copilot is much more sophisticated, providing an orchestration layer for its component agents, an approach that Microsoft is calling “agentic cloud ops.” There’s a certain logic to this, considering how complex the Azure management surface has become. Under the portal or through the CLI, you interact with dozens of different services daily, often more.

Azure is complex and ever-changing. New services launch almost daily, and APIs update and change on a rapid cadence. Under the hood, tools and technologies like the TypeSpec language allow Microsoft to automate the process of documenting and publishing Azure’s APIs, delivering them as OpenAPI format documents. By standardizing the structure of its APIs, Microsoft has made it relatively simple for the latest generation of generative AI tools to parse and use them, generating the requisite calls and fielding responses, providing a natural language interface to the heart of Azure.

One key feature of the new Azure Copilot is that it works wherever you work, so you can access it in the portal, with a new agent dashboard, in a chat interface, or via the Azure CLI. This approach fits well with Microsoft’s long history of delivering tools that surface where they’re needed, making them part of your workflow instead of you having to be part of theirs.

Six new agents make up the Azure Copilot stack: Migration Agent, Deployment Agent, Observability Agent, Optimization Agent, Resiliency Agent, and Troubleshooting Agent. The intent is to support key pieces of the Azure operations platform, leaving the Azure MCP server in Visual Studio Code to support cloud development. The agents themselves have access to Azure tools and APIs, as well as knowledge bases like Learn. They can also use your deployed resources in the Azure Resource Manager and the associated Azure Resource Graph.

Let’s take a look at the new Azure Copilot agents and their capabilities.

Migration Agent

The Migration Agent is intended to help bring on-premises applications into the cloud and is based on the existing Azure Migrate tools and processes. It includes agentless discovery tools to map your existing infrastructure, with support for offline operations. As well as mapping your infrastructure, the tool is application-aware and can help update and modernize systems, building the necessary infrastructure as code scripts in either Bicep or Terraform. These can be evaluated and tested before being run to ensure that the agent is building the correct infrastructure for you.

At the same time, the tool isn’t focused on a big-bang approach; you can work with it to define how to move applications instead of simply creating a network and deploying VMs. It provides security reports and risk analysis and provides advice and guidance on application modernization. This takes advantage of the tools in GitHub Copilot to update both .NET and Java code, fitting in with an application-focused migration. Along with new GitHub Copilot tools for migrating on-premises Oracle databases to cloud Azure databases, you can use this process to change platform elements.

Deployment Agent

Like other hyperscale cloud platforms, Azure has a set of best practices for deploying infrastructure and applications. The Azure Well-Architected Framework forms the basis of the Azure Copilot Deployment Agent and builds deployment plans from your goals, constructing the right infrastructure as code to build out a virtual infrastructure. The resulting Terraform plans can be added to GitHub and used in actions as part of a CI/CD pipeline.

One key point shows links to the spec-driven development model used in GitHub’s Spec Kit. You’re encouraged to write long prompts to describe the application or service you want to build. This isn’t like searching documentation; it’s providing a complete description of the application, the Azure services you want to use, and how you want them to function. Like SpecKit, the process of building out your infrastructure is interactive, with the agent requesting more information as needed.

There are links to other Azure services, so when the Deployment Agent generates a set of Terraform scripts, it offers additional analysis from the Azure pricing calculator so you can get a feel for how expensive it will be to deliver and run your infrastructure.

Observability Agent

Much of what is in the Azure Copilot extends existing tools, which makes sense and reduces the risks associated with generative AI. This approach allows the Observability Agent to build on Azure Monitor, using its investigation tools to help explore issues in your applications and infrastructure. A new Investigate button has been added to Azure Monitor alerts and produces a set of agent-generated probable causes for the underlying issue, mixing anomaly detection machine learning tools with generative AI natural language interfaces. The ML engine handles fault finding, and the agent’s generative AI component summarizes results and produces next steps.

The agent can access signals from across Azure’s services, allowing it to analyze logs from Azure Kubernetes Service and use context to link possibly related alerts. With modern cloud-native applications built on top of distributed systems, this last feature is surprisingly important as it can help connect what might at first glance be unrelated events that lead to failure.

Optimization Agent

Running on top of Azure is as much about managing costs as running applications and virtual infrastructures. The Azure Copilot Optimization Agent is targeted at finops practitioners, giving them tools to choose between actions that are ranked by how much they cost, their environmental impact, and how easy they are to implement. Options can include changing the underlying VM SKUs. The agent generates the scripts to move workloads to more efficient, lower cost virtual infrastructure.

The aim is to prevent finops teams from being surprised by costs, keeping bills aligned to usage and avoiding inefficient hardware choices. You’re less likely to need this tool if you’re using other Azure Copilot tools to deploy applications, but if you’re running existing implementations—especially lift-and-shift ones from on-premises data centers—it should help you get your Azure infrastructure under control.

Resiliency Agent

Azure offers a wide selection of features to make your infrastructure more resilient, but the complexity of many virtual infrastructures means that in many cases, you don’t often have all the relevant options enabled. The Resiliency Agent checks your resources to ensure that they are in more than one availability zone so data center outages don’t affect your operations. The agent can help build your failover and recovery plans, and even test processes by simulating failures. Here the agent uses information in the Azure Resource Graph to build reports and run necessary automations in case of infrastructure failures.

Troubleshooting Agent

The Troubleshooting Agent in Azure Copilot is designed to run diagnostics on your infrastructure and then provide a fix, either as a series of steps for you to walk through or, in some cases, a one-click automation. It’s available for all Azure services, but works best with AKS, Cosmos DB, and Azure-hosted VMs.

Not all failures get a one-click fix. In some cases, the best the agent can do is document the issue and generate a support ticket. However, that’s still useful as the agent has access to your logs and resources and can help diagnose issues and suggest fixes based on Microsoft’s internal data.

Finding a role for AI operations

The role of the new Azure Copilot is to orchestrate these agents, parsing your requests and then calling agent functions as needed. The result is an interesting combination of features that address common pain points across Azure operations. Initially, you’ll likely get the most use out of the Troubleshooting Agent, and your finops team (and your bottom line) will benefit from the Optimization Agent.

With a handful of agents in this first preview, Microsoft is clearly easing its Azure users into accepting AI-assisted operations. That’s a sensible move, as users need to trust Copilot, much like any human colleague, and Copilot needs to prove itself in action. Keeping Azure Copilot to a limited set of operations scenarios will allow Microsoft to see how it performs and help tune it before a wider release.

Context engineering has emerged as one of the most critical skills in working with large language models (LLMs). While much attention has been paid to prompt engineering, the art and science of managing context—i.e., the information the model has access to when generating responses—often determines the difference between mediocre and exceptional AI applications.

After years of building with LLMs, we’ve learned that context isn’t just about stuffing as much information as possible into a prompt. It’s about strategic information architecture that maximizes model performance within technical constraints.

The technical reality of context windows

Modern LLMs operate with context windows ranging from 8K to 200K+ tokens, with some models claiming even larger windows. However, several technical realities shape how we should think about context:

• Lost in the middle effect: Research has consistently shown that LLMs experience attention degradation in the middle portions of long contexts. Models perform best with information placed at the beginning or end of the context window. This isn’t a bug. It’s an artifact of how transformer architectures process sequences.
• Effective vs. theoretical capacity: A model with a 128K context window doesn’t process all 128K tokens with equal fidelity. Beyond certain thresholds (often around 32K to 64K tokens), accuracy degrades measurably. Think of it like human working memory. We can technically hold many things in mind, but we work best with a focused subset.
• Computational costs: Context length impacts latency and cost quadratically in many architectures. A 100K token context doesn’t cost 10x a 10K context, it can cost 100x in compute terms, even if providers don’t pass all costs to users.

What we learned about context engineering  

Our experience building an AI CRM taught us four important lessons about context engineering:

1. Recency and relevance trump volume
2. Structure matters as much as content
3. Context hierarchy creates better retrieval
4. Stateless is a feature, not a bug

I will unpack each of those below, then I’ll share some practical tips, useful patterns, and common antipatterns to avoid.

Lesson 1: Recency and relevance trump volume

The most important insight: more context isn’t better context. In production systems, we’ve seen dramatic improvements by reducing context size and increasing relevance.

Example: When extracting deal details from Gmail, sending every email with a contact performs worse than sending only emails semantically related to the active opportunity. We’ve seen models hallucinate close dates by pulling information from a different, unrelated deal mentioned six months ago because they couldn’t distinguish signal from noise.

Lesson 2: Structure matters as much as content

LLMs respond better to structured context than unstructured dumps. XML tags, markdown headers, and clear delimiters help models parse and attend to the right information.

Poor context structure:

Here’s some info about the user: John Smith, age 35, from New York, likes pizza, works at Acme Corp, signed up in 2020, last login yesterday…

Better context structure:

xml

  
    John Smith
    35
    New York
  
  
    2020-03-15
    2024-10-16
  
  
    Pizza
  

The structured version helps the model quickly locate relevant information without parsing natural language descriptions.

Lesson 3: Context hierarchy creates better retrieval

Organize context by importance and relevance, not chronologically or alphabetically. Place critical information early and late in the context window.

Optimal ordering:

1. System instructions (beginning)
2. Current user query (beginning)
3. Most relevant retrieved information (beginning)
4. Supporting context (middle)
5. Examples and edge cases (middle-end)
6. Final instructions or constraints (end)

Lesson 4: Stateless is a feature, not a bug

Each LLM call is stateless. This isn’t a limitation to overcome, but an architectural choice to embrace. Rather than trying to maintain massive conversation histories, implement smart context management:

• Store full conversation state in your application
• Send only relevant history per request
• Use semantic chunking to identify what matters
• Implement conversation summarization for long interactions

Practical tips for production systems

Tip 1: Implement semantic chunking

Don’t send entire documents. Chunk content semantically (by topic, section, or concept) and use embeddings to retrieve only relevant chunks.

Implementation pattern:

Query → Generate embedding → 
Similarity search → Retrieve top-k chunks → 
Rerank if needed → Construct context → LLM call

Typical improvement: 60% to 80% reduction in context size with 20% to 30% improvement in response quality.

Tip 2: Use progressive context loading

For complex queries, start with minimal context and progressively add more if needed:

1. First attempt: core instructions plus query
2. If uncertain: add relevant documentation
3. If still uncertain: add examples and edge cases

This reduces average latency and cost while maintaining quality for complex queries.

Tip 3: Context compression techniques

Three techniques can compress context without losing information:

1. Entity extraction: Instead of full documents, extract and send key entities, relationships, and facts.
2. Summarization: For historical conversations, summarize older messages rather than sending verbatim text. Use LLMs themselves to create these summaries.
3. Schema enforcement: Use structured formats (JSON, XML) to minimize token usage compared to natural language.

Tip 4: Implement context windows

For conversation systems, maintain sliding windows of different sizes:

• Immediate window (last three to five turns): Full verbatim messages
• Recent window (last 10 to 20 turns): Summarized key points
• Historical window (older): High-level summary of topics discussed

Tip 5: Cache smartly

Many LLM providers now offer prompt caching. Structure your context so stable portions (system instructions, reference documents) appear first and can be cached, while dynamic portions (user queries, retrieved context) come after the cache boundary.

Typical savings: 50% to 90% reduction in input token costs for repeated contexts.

Tip 6: Measure context utilization

Instrument your system to track:

• Average context size per request
• Cache hit rates
• Retrieval relevance scores
• Response quality vs. context size

This data reveals optimization opportunities. We’ve found that many production systems use 2x to 3x more context than optimal.

Tip 7: Handle context overflow gracefully

When context exceeds limits:

• Prioritize user query and critical instructions
• Truncate middle sections first
• Implement automatic summarization
• Return clear errors rather than silently truncating

Advanced patterns

Multi-turn context management

For agentic systems that make multiple LLM calls:

Pattern: Maintain a context accumulator that grows with each turn, but implement smart summarization after N turns to prevent unbounded growth.

Turn 1: Full context
Turn 2: Full context + Turn 1 result
Turn 3: Full context + Summarized(Turns 1-2) + Turn 3

Hierarchical context retrieval

For retrieval-augmented generation (RAG) systems, implement multi-level retrieval:

1. Retrieve relevant documents
2. Within documents, retrieve relevant sections
3. Within sections, retrieve relevant paragraphs

Each level narrows focus and improves relevance.

Context-aware prompt templates

Create templates that adapt based on available context:

if context_size 

Common antipatterns to avoid

• Antipattern 1: Sending entire conversation histories verbatim. This wastes tokens on greetings, acknowledgments, and off-topic banter.
• Antipattern 2: Dumping database records without filtering. Send only fields relevant to the query.
• Antipattern 3: Repeating instructions in every message. Use system prompts or cached prefixes instead.
• Antipattern 4: Ignoring the lost-in-the-middle effect. Don’t bury critical information in long contexts.
• Antipattern 5: Over-relying on maximum context windows. Just because you can use 128K tokens doesn’t mean you should.

Looking forward

Context engineering will remain critical as models evolve. Emerging patterns include:

• Infinite context models: Techniques for handling arbitrarily long contexts through retrieval augmentation
• Context compression models: Specialized models that compress context for primary LLMs
• Learned context selection: Machine learning models that predict optimal context for queries
• Multi-modal context: Integrating images, audio, and structured data seamlessly

Effective context engineering requires understanding both the technical constraints of LLMs and the information architecture of your application. The goal isn’t to maximize context. It’s to provide the right information, in the right format, at the right position.

Start by measuring your current context utilization, implement semantic retrieval, structure your context clearly, and iterate based on quality metrics. The systems that win aren’t those that send the most context. They’re those that send the most relevant context.

The future of LLM applications is less about bigger context windows and more about smarter context engineering.

—

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.

Google has updated its Gemini API in support of its recently introduced Gemini 3 AI model. The Gemini API updates, which include simpler controls over thinking, more granular control over multimodal vision processing, and ‘thought signatures’ to improve function calling and image generation, are designed to support Gemini 3’s reasoning, autonomous coding, multimodal understanding, and agentic capabilities.

The Gemini API improvements were detailed in a November 25 blog post. They are designed to give users more control over how the model reasons and processes media, and how the model interacts with the “outside” world, Google said. Gemini 3 was rolled out November 18.

Among the improvements in the Gemini API are simplified parameters for thinking control, via a parameter called thinking_level. This parameter controls the maximum depth of the model’s internal reasoning before a response is produced. The thinking_level parameter can be set to high for complex tasks such as strategic business analysis, and low for latency and cost-sensitive applications.

The Gemini API also now provides more granular control over multimodal vision processing, with a media_resolution parameter for configuring how many tokens are used for image, video, and document inputs. Developers can balance visual fidelity with token usage. Resolution can be set using media_resolution_low, media_resolution_medium, or media_resolution_high. Higher resolution boosts the model’s ability to read fine text or identify small details, Google said.

Starting with Gemini 3, Gemini API also brings back thought signatures to improve function calling and image generation. Thought signatures are encrypted representations of the model’s internal thought process. By passing these signatures back to the model in subsequent API calls, developers can ensure that Gemini 3 maintains its chain of reasoning across a conversation. This is important for complex, multi-step agentic workflows where preserving the “why” behind a decision is as important as the decision itself, Google said.

Additionally, developers now can combine structured outputs with Gemini-hosted tools, specifically Grounding with Google Search and URL Context. Combining structured outputs is especially powerful for building agents that must fetch live information from the web or specific web pages and extract the data into a JSON format for downstream tasks, Google said, noting that it has updated the pricing of Grounding with Google Search to better support agentic workflows. The pricing model changes from a flat rate of $35 per 1K prompts to a usage-based rate of $14 per 1,000 search queries.

When Miqdad Jaffer, product lead at OpenAI, challenged the illusion of ‘just add AI’ earlier this summer, he drew a line between teams crushed by hype and those who turn artificial intelligence into a lasting advantage. “The most durable and defensible moat in AI is proprietary data,” Jaffer wrote. “If your product generates unique structured data every time it is used, you pull further ahead in ways competitors cannot copy or buy.”

But that future is unevenly distributed across hyperscalers, early stage startups, and mature enterprises. OpenAI can spend billions and field armies of data infrastructure engineers. Startups have a fraction of those resources but enjoy a clean slate, building data pipelines for AI systems without the burden of legacy systems.

It is mature enterprises that have the biggest lift to get their data layer unstuck for AI. They may already own that coveted proprietary data, but they also face decades of legacy architecture and technical debt.

Every major computing wave has rewritten the data layer. Service-oriented architecture standardized system interfaces. Business intelligence and data warehousing structured analytics. Big data platforms handled scale, and streaming moved data in real time. Each shift changed how developers modeled and connected information.

AI is now pushing enterprises to rewrite the data layer again, this time around meaning, trust, and interoperability. So where to focus?

Connect what you already have

For most enterprises, the problem is not scarcity of data but lack of connection. Systems have multiplied faster than they have been integrated, each with its own schema, logic, and history. Relational models freeze early design choices, making it easier to create new applications than evolve old ones. Traditional formats store structure but not meaning. Today’s legacy debt at the data infrastructure layer looks like so many silos that hold information but hide context.

“Most companies are in this state, where you have just built new application after application, each with its own database, typically relational,” says Philip Rathle, CTO at Neo4j. “Relational databases have data models that cannot easily be evolved once they are in place. Over time it becomes simpler to build a new application than to change an existing model, which creates more sprawl.”

Once enterprises shift to graphs, their data starts to look the way the world actually behaves. “Once an enterprise has started using graphs, they see their whole world of knowledge can be represented as a graph,” Rathle said. “The world shows up as networks, hierarchies, and journeys, so why force that into tables?”

The ability to model meaning has moved graphs from niche technology to necessity. “The same organizations that started with graphs for recommendation engines or fraud detection are realizing the greater opportunity is connecting knowledge itself,” Rathle said. “The rise of AI has created broader awareness that graphs are a foundation for AI and for more accurate and transparent reasoning.”

Dave McComb, CEO of Semantic Arts, explains why this shift matters. “An ontology or a semantic database is about what things actually mean, and how things that sound similar are distinct in a way a machine can interpret,” he said. “Ambiguity is genAI’s kryptonite.” Without the clarity a knowledge graph provides, AI hallucinates faster, not smarter.

By layering graph-based connections on top of existing systems, enterprises can modernize incrementally. “If you already have structure across different parts of the business, you can connect them without rewriting everything,” Rathle said. “Over time that connected layer becomes the foundation for a knowledge graph that allows AI to understand the enterprise.”

Reclaim control of proprietary data

Even with better data modeling, enterprises face a deeper question of ownership. The convenience of multitenant software has blurred the boundaries of control. In the AI era the risk is not only exposure. It is the possibility that the competitive value inside proprietary data can be learned from and lost.

“Before AI, somebody else was storing your data, and if they got infiltrated they were a honeypot,” said Grant Miller, CEO at Replicated. “Now the data is not only being stored, it is being learned from. So it becomes part of training sets.” Once that happens, reclaiming your advantage may be impossible.

Miller argues that the answer is to bring AI to the data rather than sending data out into the world. “By removing access from the vendor, instead of sending the data to thousands of different vendors, you bring the applications to where the data already resides,” he said. “You get a major advantage.”

From his vantage point, Miller sees enterprises moving toward a four-tier model that aligns deployment with data sensitivity. “Fully managed software for low risk use, VPC-based deployments for more control, self hosted environments for sensitive systems, and air gapped setups for the highest levels of sovereignty… That is the pattern we see enterprises follow,” Miller says. “It is about aligning architecture to data sensitivity, not convenience.”

Miller believes we’re seeing a cultural turn. Enterprises that once prized cloud abstraction are reevaluating what control means when data itself has become intellectual property. “If you hand it over to a vendor, you have no idea how it is used,” Miller said. “Not your weights, not your AI.”

Build trust through shared operations

Even when data remains under enterprise control, trust breaks down if operations are fragmented. AI only works when the people who manage data, run systems, and interpret results share the same picture. Shared visibility creates explainability, accountability, and real governance.

Brian Gruttadauria, CTO of hybrid cloud at HPE, said his teams are seeing disciplines converge after years of separation. “There has to be a union between the database operations teams who understand how data is consumed, the data engineers who manage the pipeline, and the subject matter experts who are asking the abstract AI questions,” Gruttadauria said. “They all need to work together to deliver the outcome.”

Across the industry, this shift is reshaping automation. What once involved simple AIOps scripts is evolving into coordinated action between agents that communicate through protocols like the Model Context Protocol (MCP) and Agent2Agent (A2A). “In the past you opened ten tickets and involved 10 teams,” Gruttadauria said. “Now the networking agent, storage agent, and orchestration agent can communicate and make those calls directly.”

For Gruttadauria, this is the operating model for trustworthy AI: shared visibility, shared reasoning, and shared responsibility.

Stabilize APIs and evolve the stack

The final hurdle lies in the stack itself. The AI ecosystem is still a patchwork of models, frameworks, and protocols, and no enterprise can afford a full rebuild.

Anthony Annunziata, director of AI and open innovation at IBM, said the goal is not a universal stack but stability at the interaction points. “I do not think a one stack solution is what we need or can produce,” he said. “But we can standardize the APIs used to build applications and the protocols that let them communicate.”

These communication layers are moving fastest. Protocols like MCP and A2A are giving tools and agents a consistent way to exchange context and coordinate actions. They are becoming the connective tissue that allows heterogeneous systems to behave coherently.

At the data layer, standards are also maturing. Cypher, the graph query language from Neo4j, has now been formalized into ISO’s new GQL standard, the first new database language standard since SQL nearly forty years ago. “Access to the graph is done through GQL,” Rathle said. “That is the interoperability layer enterprises can rely on.”

Both Rathle and Annunziata point to how graph, relational, and vector systems can share context in a way that integrates with different models, orchestration frameworks, and systems. The aim is not unification, but dependable, open connection.

Dave McComb warns that this decision will shape the next decade. “If you build around open standards you have freedom,” he said. “If you build around proprietary APIs, you have already chosen your next migration.”

Transforming data into meaning and knowledge

Every major data evolution has battled the same problems: too many systems, too many silos, too many versions of truth. But AI raises the stakes. The challenge now is not only integrating data, but integrating meaning. When context is missing, AI does not merely degrade. It hallucinates. And when proprietary data is learned from without control, the competitive advantage inside that data can disappear for good.

“The real Holy Grail of an AI enterprise is not having functionality restricted to the knowledge inside a given silo, but the knowledge of the entire enterprise,” said Philip Rathle. Achieving that requires shared understanding across systems, not only shared access.

Dave McComb is blunt about what happens if enterprises get this wrong. “The legacy systems of tomorrow are being written today,” he said.

The cost of fragmentation is no longer inefficiency, but misaligned models, lost advantage, and AI systems that cannot be trusted. The future will belong to companies that understand the value of connected data and that structure their data to enable AI to derive meaning and knowledge.

Not to be confused with Next.js, Nest.js is a server-side framework that offers a complete solution for building web applications. Nest is very popular, with over 73,000 stars on GitHub as of this writing. It is an excellent choice if you need to build a server-side application using TypeScript or JavaScript, and if you want a well-thought-out solution with all the architectural components in one place.

Nest out of the box

Nest’s design is philosophically inspired by Angular. At its heart is a dependency injection (DI) engine that wires together all the components using a common mechanism. If you are familiar with Spring Web, you will probably be right at home with Nest.

On top of its DI engine, Nest hosts a variety of useful built-in capabilities, including controllers, providers and modules:

• Controllers define HTTP routes and their handlers.
• Providers contain the middleware logic used by controllers (often called services in other frameworks).
• Modules group together controllers and providers.

Nest also incorporates several additional features worth noting:

• Pipes are used for data validation and transformation.
• Guards are for authentication and authorization.
• Interceptors are a type of AOP support, used for other cross-cutting concerns.

Next, we’ll look at using Nest’s core components in a server-side application.

Nest controllers: Define routes and endpoints

To define a controller class in Nest, you use the @Controller decorator:

import { Controller } from '@nestjs/common';

@Controller('birds') export class BirdsController {
// ...
} }

This controller exists at the /birds route and lets us define routes inside that route, where each endpoint is defined with a decorator corresponding to the HTTP method it handles.

For example, if we wanted a GET endpoint inside the /birds route that accepted a type parameter, we could do this:

@Get(':type')
findBirdsByType(@Param('type') type: string): Bird[] {
  const birds = birdDatabase[type];
  if (!birds) { 
    throw new NotFoundException(`No birds found for type '${type}'.);
  }
 return birds;
}

Nest is TypeScript-native, so our birdDatabase might look like this:

interface Bird {
  id: number;
  name: string;
  species: string;
}

const birdDatabase: Record = {
  songbird: [
    { id: 1, name: 'Song Sparrow', species: 'Melospiza melodia' },
    { id: 2, name: 'American Robin', species: 'Turdus migratorius' },
    { id: 3, name: 'Eastern Towhee', species: 'Pipilo erythrophthalmus' },
  ],
  raptor: [
    { id: 4, name: 'Red-tailed Hawk', species: 'Buteo jamaicensis' },
    { id: 5, name: 'Peregrine Falcon', species: 'Falco peregrinus' },
    { id: 6, name: 'Bald Eagle', species: 'Haliaeetus leucocephalus' },
  ],
  corvid: [
    { id: 7, name: 'California Scrub-Jay', species: 'Aphelocoma californica' },
    { id: 8, name: 'American Crow', species: 'Corvus brachyrhynchos' },
    { id: 9, name: 'Common Raven', species: 'Corvus corax' },
  ],
};

Nest automatically converts that code to appropriate JSON, which you then fine-tune as needed.

Nest providers: Separate business logic from HTTP handling

One of the most important principles in organizing web applications as they grow in complexity is to separate concerns into layers. As much as possible, we want to separate the HTTP handling logic from the business logic. To do this, we can extract the latter into a provider (or service) class that is injected into the controller.

Below is an example of a bird provider. The @Injectable decorator instructs Nest to make this class available in the dependency injection engine:

@Injectable()
export class BirdsService {
  private readonly birdDatabase: Record = { 
    // ... same bird data as before 
  };
  findByType(type: string): Bird[] {
    const birds = this.birdDatabase[type];
    if (!birds) {
      throw new NotFoundException(`No birds found for type '${type}'.`);
    }
    return birds;
  }
}

Now, in the controller, we can consume the provider and its findByType method like so:

import { BirdsService } from './birds.service';

@Controller('birds')
export class BirdsController {
  // Injected provider:
  constructor(private readonly birdsService: BirdsService) {}

  @Get(':type')
  findBirdsByType(@Param('type') type: string) {
    // Delegate to the provider:
    return this.birdsService.findByType(type);
  }
}

Notice that we need to import the BirdsService from the file where it is defined.

Now we have a very simple controller, which deals only with the details of the HTTP request itself. The business logic is all concentrated in the service layer.

Nest modules: Organize your work

To register our controllers and providers with the Nest engine, we need to define a module that contains them:

import { Module } from '@nestjs/common';
import { BirdsController } from './birds.controller';
import { BirdsService } from './birds.service';

@Module({
  controllers: [BirdsController],
  providers: [BirdsService],
})
export class BirdsModule {}

The classes listed in the providers array will be made available to all other providers and controllers in this module, while the controllers will be made active as handlers.

Although the module definition adds an extra step of work, it is an excellent mechanism for organizing your application. It lets you define areas of your application that are related and keeps them focused. It also limits the amount of code Nest has to scan to find dependencies.

The Nest data layer: Built-in data persistence

The data layer is another common layer in an application architecture. It is where services (providers) go to interact with a persistent datastore like a relational or NoSQL database.

Nest’s module system is quite flexible and can support any datastore, but it has built-in modules for TypeORM, Sequelize and Mongoose, which makes using any of those solutions easier.

Among other things (like defining datastore connection information), a datastore like TypeORM lets you define entities (persistent types) that hold the data going to and from the database. For our example, we could have a TypeORM entity for birds:

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Bird {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @Column()
  species: string;

  @Column()
  type: 'songbird' | 'raptor' | 'corvid';
}

This entity can be used to expose a repository class (a data layer class). The repository is created by the typeORM tool when we register it in the module system:

//...
import { TypeOrmModule } from '@nestjs/typeorm';
import { Bird } from './bird.entity';

@Module({
  imports: [TypeOrmModule.forFeature([Bird])], // Added this
  controllers: [BirdsController],
  providers: [BirdsService],
})
export class BirdsModule {}

The TypeORMModule function automatically creates various CRUD functions based on the datastore and entity definition. We can then use those in the service layer:

import { Injectable, NotFoundException } from '@nestjs/common';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { Bird } from './bird.entity';

@Injectable()
export class BirdsService {
  constructor(
    @InjectRepository(Bird) // Bird repository is injected here
    private birdsRepository: Repository,
  ) {}

  // NOTE: DB access is async
  async findByType(type: string): Promise {
    // Actual DB call here instead of in-memory data:
    const birds = await this.birdsRepository.find({ where: { type } });

    if (!birds || birds.length === 0) {
      throw new NotFoundException(`No birds found for type '${type}'.`);
    }
    return birds;
  }
}

Data transfer objects and DTO validation

So far, we have only been reading data. The other side of the coin is accepting data from the user. For this, we use DTOs (data transfer objects). This lets us define the shape of data we take in.

For example, if we wanted to accept a new bird type from the user, it could look something like this:

import { IsString, IsNotEmpty, IsIn } from 'class-validator';

export class CreateBirdDto {
  @IsString()
  @IsNotEmpty()
  name: string;

  @IsString()
  @IsNotEmpty()
  species: string;
  
  // Hardcoding these values for convenience
  @IsIn(['songbird', 'raptor', 'corvid'])
  type: 'songbird' | 'raptor' | 'corvid';
}

The create-bird.dto describes what values are allowed for the bird-creation process. We can then use this in the controller to add a bird-creation endpoint:

import { CreateBirdDto } from './create-bird.dto';
//...
@Post() 
create(@Body() createBirdDto: CreateBirdDto) { 
  return this.birdsService.create(createBirdDto); 
}

We also use it in the bird service provider:

async create(createBirdDto: CreateBirdDto): Promise { 
// Uses TypeORM's .create() to make a new bird entity 
const newBird = this.birdsRepository.create(createBirdDto); 
  // TypeORM’s save() method persists the entity:
  return this.birdsRepository.save(newBird); 
}

Activate the DTO validation with a pipe

Now everything is in place to enforce the rules defined by the DTO. We can make the DTO validator live by telling Nest to use all validators globally:

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);

  // Enable auto-validation for our entire application
  app.useGlobalPipes(new ValidationPipe());

  await app.listen(3000);
}
bootstrap();

The built-in ValidationPipe will enforce all the DTOs defined in the application. Now, Nest itself will reject requests that don’t meet the DTO’s requirements with a 400 Bad Request.

Conclusion

This article was an overview of the core internal architecture of Nest. In addition to its core components, Nest has excellent CLI support like generators for DTOs and controllers, scaffolding, and development mode, as well as multi-platform deployment targets, such as Node or Fastify, and Docker-friendly builds.

Nest is a full-featured and modern server-side framework for TypeScript and JavaScript. It’s a great option to have for substantial projects that require robust server-side support.