Enterprises implementing agentic AI face a challenge: Which tools should they allow their agents to use, where can they be found, and how can they be used safely? A new protocol, Agentic Resource Discovery, or ARD, aims to let agents answer those questions for themselves. Behind it are Google, Microsoft, Cisco, Nvidia, Salesforce and others.
ARD aims to standardize the way that tools and services are shared across systems within a corporate domain. For example, when investigating a production problem, an agent may want to query engineering documentation and open support tickets, deployment history and observability systems, all of which could be managed by different registries and across different silos. There is no common layer that pulls them together. ARD has been designed to be that layer.
It operates across two levels. Catalogs and Registries. In the first, an organization publishes a catalog setting out its available capabilities. The Registries layer act as a form of search engine, crawling those published catalogs.
The ARD specification is available now. Organizations are invited to publish their own catalogs using the quickstart guide. After this, they are able to join the community and participate in the evolution of ARD.
An IT executive changing jobs usually attracts little attention outside a narrow group of people, but Noam Shazeer’s move from Google to OpenAI is as momentous as any high-value soccer transfer.
He announced the news in a post on X: “I’m excited to share that I’ll be joining OpenAI and look forward to working with the exceptional team there.”
Shazeer initially achieved fame as one of the eight co-authors of the influential AI paper Attention Is All You Need, published when he was working at Google Brain. He is also one of the creators of the transformer technology that lies at the heart of modern AI models.
He left Google when the company failed to back his chatbot Meena and was tempted back when Google subsequently bought the company he founded, Character.AI, for $2.7 billion. That company achieved notoriety when it was sued by a grieving mother, who alleged that a Character.AI chatbot had contributed to her son’s death by suicide. The company subsequently settling out of court.
Shazeer has since been working as the co-lead on Google’s Gemini project. It’s not clear what role he will play at OpenAI, but hiring someone with his background shortly before the company’s IPO could be an attractive move for investors.
It is tempting to date cloud computing from the launch of Amazon S3 in 2006 and the rise of infrastructure as a service (IaaS) that followed. That was certainly the moment the market changed in a visible, irreversible way. But the truth is that cloud began earlier, in the 1990s, when software as a service (SaaS), application hosting, managed services providers, and various forms of remote subscription computing started to reshape how enterprises thought about owning and operating technology. Even then, the core value proposition was familiar: Let someone else run the infrastructure, abstract the complexity, deliver capability as a service, and allow the business to consume only what it needs.
What AWS changed was the scale, accessibility, and precision of the execution. Amazon turned infrastructure into a programmable utility. It made compute and storage available in ways that were elastic, self-service, API-driven, and globally reachable. That was the breakthrough. Enterprises had outsourced pieces of technology before, but now they could rent raw infrastructure with unprecedented speed and flexibility. The launch of Amazon S3 was especially important because it provided a durable, scalable storage foundation that became one of the building blocks for modern digital business.
AWS changed everything
Technology markets are rarely transformed by the first company to think of an idea. They are transformed by the first company to make that idea operationally real, economically viable, and broadly consumable. AWS did exactly that. It built a model for infrastructure as a service that allowed enterprises, startups, and eventually governments to rethink the entire life cycle of IT delivery.
Looking back from 2026, it is difficult to remember how radical this concept once seemed. At the time, many enterprise leaders considered public cloud too risky, too immature, too uncontrolled, or simply too foreign for conventional IT governance. There were concerns about security, compliance, vendor dependency, performance, data residency, and reliability. Many of those concerns were valid. Early cloud adoption often ran ahead of cloud maturity, and many organizations discovered that moving quickly did not always mean moving wisely.
Still, the economics of agility overwhelmed the inertia of the old model. Provisioning that once took months could be done in minutes. Capital expenditure gave way, at least in part, to operating expenditure. Experimental workloads became easier to justify. Digital businesses could scale without building data centers first. AWS led that transition, and the rest of the industry followed, including competitors that helped mature the market.
Cloud’s strengths and liabilities
If the first decade of cloud was about acceleration, the second decade was about correction. Enterprises learned that cloud was not automatically cheaper, not automatically simpler, and not automatically better. It was better when used with discipline. It was more cost-effective when architected intelligently. It was more resilient when governance, operations, and security were designed into the system rather than added later.
This is when the industry grew up. We learned about cloud financial management because too many organizations assumed elasticity would control cost, only to discover that unused resources, poor workload placement, and fragmented accountability could drive spending far beyond expectations. We learned that public cloud could provide extraordinary innovation and reach, but also that not every workload belongs there. Latency, sovereignty, compliance constraints, legacy integration challenges, and predictable high-volume workloads all forced a more nuanced view.
We also learned about concentration risk. As enterprises standardized on a small number of hyperscalers, questions emerged around resilience, lock-in, and strategic dependency. The answer was never simplistic multicloud posturing for its own sake. It was architectural realism. Use the public cloud where it creates a clear advantage. Keep options open where business risk requires it. Understand portability, but do not romanticize it. In other words, cloud became less ideological and more practical.
Cloud is now an assumption
Perhaps the most important shift of all is that we no longer debate whether cloud is real or whether enterprises should use it. That argument is over. Cloud is baked into the cake. It is part of enterprise operating reality. The modern enterprise assumes on-demand infrastructure, platform services, automation pipelines, managed databases, identity fabrics, observability stacks, and globally distributed application delivery. Even when workloads remain on-premises or at the edge, they are often built, governed, or operated with cloud-native thinking.
This is maturity. Cloud is not a project or a trend. It is not even a strategy by itself. It is an enabling model that now underpins enterprise strategy. Businesses no longer ask whether to adopt cloud in the abstract. They ask how much cloud, which cloud services, under what governance model, at what cost profile, and in support of which business outcomes.
That may sound less exciting than the early days of disruption, but it is actually the mark of success. The most powerful technologies eventually disappear into standard practice. Electricity, networking, virtualization, and mobile platforms all went through this process. Cloud has done the same.
How cloud supports the AI race
As enterprises move aggressively into AI, cloud has entered another pivotal phase. AI is not replacing cloud. It is intensifying the importance of cloud while also changing how value is measured. Training, tuning, deploying, and governing AI systems require immense computational scale, specialized infrastructure, distributed data access, and operational consistency. Public cloud providers are well positioned to offer those capabilities, particularly with GPUs, AI platforms, managed model services, and data integration tools.
But this is not a repeat of the early cloud era. Enterprises are more sober now. They know the importance of cost, latency, and data gravity. They know that governance and accountability matter more in AI than perhaps anywhere else in modern IT. The role of cloud in the AI race is therefore foundational, but not absolute. Some AI workloads will run in public cloud. Some will be distributed across edge computing environments. Some will remain in private environments for reasons of sovereignty, economics, or control. The key is not to force a universal answer. The key is to create an architecture that aligns AI ambitions with operational reality.
Cloud should play the role it has gradually earned: not as a religion, but as a strategic utility. For AI, the cloud is where many enterprises will source scale, experimentation speed, global reach, and managed innovation. The winning organizations understand where cloud creates leverage and where other operating models make more sense.
Changing how enterprises think
The real story of the past 20 years is not just that AWS launched S3 and helped popularize infrastructure as a service. It is that cloud changed enterprise behavior. It normalized service consumption over asset ownership. It moved architecture toward abstraction, automation, and modularity. It forced IT organizations to broker capability rather than build everything from scratch. It redefined speed as a core competitive requirement.
And now, as AI becomes the next forcing function, cloud stands less as a novelty and more as the platform on which the next era will be built. That is a remarkable outcome for something that, in many ways, started with the old idea that computing could be delivered remotely on a subscription basis. We have been heading here for longer than many people realize. In the past two decades, led in large measure by AWS and the broader hyperscale movement it accelerated, cloud has evolved from a gamble to an indispensable foundation.
Hard to believe? Yes. But also inevitable in retrospect.
Google, Microsoft, OpenAI, and others want to help enterprises demonstrate that their AI applications are behaving themselves through the creation of a new foundation.
The Appia Foundation will, it explained rather impenetrably, “establish modular specifications that provide a connecting layer to bridge foundational global standards with practical, trusted assessments across the global AI value chain.”
Those specifications will help AI users ascertain whether the systems they are using meet all the obligations that apply to them in the form of standards and regulations, it said. It’s a challenging task with so much regional variation in requirements, and where the EU, for example, is more tightly controlled than the US.
The Foundation has established a set of criteria to demonstrate conformity with what is expected. There are two layers: the Requirements and Guidance layers will help users determine what is actually required, while the Assessment Enablement layer will look at how those requirements are evaluated.
Appia stressed that what it is offering are not standards — which are set by recognized international bodies such as ISO/IEC — but a means of assessing what those standards mean and how they can be used by organizations. However, the Foundation said that some of the criteria that it is introducing may become standards themselves after a period of time.
The Appia Foundation is hosted by the Linux Foundation’s Joint Development Foundation, and its other members include Arm, Ericsson, Mastercard, Mitsubishi Electric, Omron, Schneider Electric, and Siemens. It is also looking to bring academics and government into the fold, so that it can establish an advisory board.
For many developers, the hard part of building an AI application isn’t the model anymore. It’s keeping the application’s knowledge current.
Retrieval-augmented generation (RAG) has become a popular technique for grounding AI applications in enterprise data, but it also introduces a steady stream of operational work, including tasks such as updating embeddings and indexes, synchronizing data sources, and tuning retrieval performance.
AWS is seeking to remove much of that burden with Bedrock Managed Knowledge Base, a new managed service that automates the retrieval layer behind enterprise AI applications.
“By default, the service automatically selects and manages a default embeddings model, re-ranker model, and foundational model on your behalf, so you can get up to speed quickly without needing to pick or maintain one yourself,” Daniel Abib, senior solutions architect at AWS, wrote in a blog post.
In order to help maintain data pipelines without building and managing custom integrations, the service also comes with six native connectors for enterprise data sources, including Amazon S3, SharePoint, Confluence, Google Drive, OneDrive, and web content, Abib wrote.
Managed RAG could boost developer productivity
For developer teams, the ability to automatically manage infrastructure could provide an immediate boost in productivity, according to Pareekh Jain, principal analyst at Pareekh Consulting.
“Enterprises spend significant time building data connectors, managing document ingestion and indexing, tuning retrieval quality, enforcing access controls, and maintaining vector databases, often making the RAG infrastructure more complex than the AI application itself. With this, developers can now focus on building the application,” Jain said.
“That should accelerate deployment timelines and reduce maintenance costs while enabling teams to focus on business outcomes,” Jain added.
Beyond reducing infrastructure management overhead, Managed Knowledge Base also targets retrieval accuracy. The service, according to Abib, also comes with features, such as Smart Parsing and Agentic Retriever, which are aimed at helping improve accuracy across different content types and sources, which is often an issue with RAG pipelines and queries spanning multiple repositories.
Improved retrieval quality could prove particularly important for organizations looking to move AI projects from experimentation to production, according to Jain.
“This is a common challenge across enterprises because business data is scattered across multiple systems. As organizations move from AI pilots to production, retrieval quality becomes critical for user trust, making RAG infrastructure a major bottleneck that often delays deployments,” Jain said.
AWS is also positioning Managed Knowledge Base as a building block for agentic applications, which, Jain said, can place even greater demands on enterprise knowledge and retrieval systems.
The service, according to the hyperscaler, integrates with Bedrock AgentCore, reducing the amount of code and configuration required to connect enterprise knowledge sources to AI agents while providing built-in monitoring, evaluation, and access management capabilities.
Taking aim at RAG stacks?
That integrated approach could also have implications for the broader RAG tooling ecosystem, Jain said.
“Managed services such as Bedrock Managed Knowledge Base could reduce demand for standalone RAG orchestration and retrieval frameworks, including tools such as LangChain and LlamaIndex, as well as some custom combinations of vector databases, ingestion pipelines, and retrieval services,” Jain noted.
However, Jain cautioned that the convenience of an integrated approach comes with tradeoffs, potentially increasing customer dependence on a single cloud provider and limiting flexibility in how AI infrastructure is assembled and managed.
Amazon Bedrock Managed Knowledge Base is currently available across North Virginia, Oregon, Sydney, Tokyo, Dublin, Frankfurt, London, and AWS GovCloud (US-West) Regions.
The service follows a usage-based pricing model, with charges tied to the volume of indexed data stored and retrieval requests processed.
Meta’s long-awaited Pyrefly linter is out in a 1.0 version, and the forthcoming Python 3.15 has a super-efficient sampling profiler. Plus we have a comprehensive rundown of Python’s indispensable virtual environments — and a warning about a novel breed of malware that exploits Python’s package ecosystem.
Top picks for Python readers on InfoWorld
How to use virtual environments in Python Isolate and protect your Python projects from each other, and empower them to do more, with virtual environments and their native-to-Python tooling.
Pyrefly 1.0: A fast, forward-looking Python linter The first full release of Meta’s long-awaited linting and type checking tool for Python delivers speed and offers advanced features for type-checking PyTorch and Django projects.
Hands-on with the new sampling profiler in Python 3.15 Among Python 3.15’s best new features is a sampling profiler, for instrumenting your code and finding its bottlenecks with a minimum of performance impact or fuss. See up-close how it works.
Python Steering Council calls for temporary pause on JIT project The requested pause stays in place until a proper Standards Track PEP lands for the experimental JIT (just-in-time) compiler, the better to describe how the JIT will be a formal and supported part of Python.
Pyodide 314.0: Pyodide packages on PyPI Thanks to PEP 783, Python packages built with Pyodide (Python ported to WebAssembly) can be installed straight from PyPI instead of through Pyodide — another step closer to Py-on-Wasm becoming an everyday thing.
All about that Python 3.14 garbage collection rigmarole A new garbage collector introduced in Python 3.14 was yanked at the last minute due to reports of higher memory usage. Here’s a deep dive into what changed for the worse and why.
Are you really expected to run five type checkers now? No, but you should keep your options open. This blog post from a Pyrefly contributor recommends choosing one of the major offerings (Mypy, Pyrefly, Pyright, ty, Zuban, etc.), but also getting to know the others too.
AI coding agents are becoming critical to software development, but the configuration files that guide them, such as Agents.md or Claude.md, can be “smelly.”
That means they can contain structural flaws, redundancies, or counterproductive workflows that bloat context, waste tokens, and make coding agents less reliable.
Researchers from the Department of Computer Science at Brazil’s Federal University of Minas Gerais hope to shed light on this problem, presenting what they call the “first catalog of smells” for coding agent configuration files. The most odorous? Lint and skill leakage, context bloat, and conflicting instructions.
“Our results show that these smells are widespread in practice,” the researchers wrote. Consequently, they “may directly influence how coding agents interpret project conventions, prioritize instructions, and perform development tasks.”
Smelly configs in the harness make models misbehave
Agents like Claude Code, Codex, Cursor, and Gemini are increasingly taking over software engineering tasks like code generation and review, test creation, bug fixing, software migration, and documentation writing.
Essentially, they are a combination of a large language model (LLM) and a harness; the model is the brain, the harness provides a loop that executes actions and allows agents to call the tools they need to fulfill a task. These might include web search engines, issue-tracking platforms, and test runners.
Agents’ behavior is guided by config files such as Agents.md and Claude.md, which provide instructions around project workflows, testing requirements, and domain-specific knowledge. This helps maintain consistency across separate tasks and sessions. Typically, these config files are loaded at the start of a session as part of a prompt and are maintained throughout the task.
But the researchers found that these configurations are riddled with smells; 91 of 100 popular open-source repositories containing Agent.md or Claude.md files had at least one smell.
The six strongest odors:
Lint leakage (appearing in 62% of files)
Context bloat (42%)
Skill leakage (35%)
Conflicting instructions (28%)
Init fossilization (24%)
Blind reference (16%)
The scent of waste
Lint leakage occurs when instructions in config files needlessly include rules that are already enforced by analysis tools like code formatters or linters (which filter out bugs, security vulnerabilities, inconsistencies, and programmatic errors, by, for example, restating generic style guide recommendations, formatting rules, line length, naming conventions, or import ordering).
This repetition increases a model’s context size and wastes tokens, the researchers pointed out. It “can divert the model from focusing on more important project-specific concerns, such as architectural constraints, domain rules, or safety policies.”
Context bloat means that configurations are excessively large and overloaded with rules, examples, or details that are unnecessary or low priority. This drives up token usage, ultimately raising costs and distracting the model from higher priority instructions.
With skill leakage, rarely-used or task-specific instructions are unnecessarily included in the configuration, rather than in separate dedicated skill or task files. This specialized knowledge is dragged into every session, even when the model doesn’t need it to perform its task. Thus, the context window becomes larger, more expensive, and difficult to maintain, the researchers noted.
“Furthermore, such rules may compete for attention with the rules that are actually critical for the project,” they wrote.
Just as it sounds, conflicting instructions means that file rules contradict one another, leading to ambiguity; the model essentially gets “confused” and has to choose arbitrarily. This can lead to inconsistency and unstable results.
Init fossilization occurs when files are generated once but never reviewed or edited again, so they include stale or irrelevant rules because they don’t reflect changes in the codebase. “As a result, the configuration tends to accumulate noise, increase context consumption, and reduce the overall effectiveness of the agent over time,” the researchers explained.
Finally, blind references point to files or docs without explaining what they’re for. Consequently, the agent might simply ignore them, leading to problems if they’re critical to a task, load unnecessary materials to gather context, taking up tokens and space, or fail to prioritize important information.
Additionally, the researchers discovered that smells often co-occur in the same file and trigger the appearance of others; for instance, skill leaking and conflicting instructions can increase the likelihood of context bloat by 83% because they add extemporaneous or irrelevant information.
How to air out smells
While these smells are “widespread in practice,” there are ways to air them out.
For example, to reduce lint leakage, stylistic constraints such as formatting, and import ordering should be removed from prompts. Let programmatic tools handle them; spending budget on style rules is a waste, the researchers noted.
To cut down on context bloat, Claude.md and Agents.md files should remain concise and provide project-specific guidance. For instance, Anthropic recommends a target of fewer than 200 lines per Claude.md file.
To limit skill leakage, developers should provide specific instructions in config files about the project build, test running, code conventions, and other important context. Task-specific instructions should be kept in separate markdown files with descriptive names, the researchers advise.
Additionally, to avoid conflicting instructions, builders should periodically review config files to remove instructions that are contradictory or outdated. Similarly, reducing init fossilization requires continuous updating of files, the researchers explained. This is particularly important in cases where an agent makes the same mistake twice in a row, a code review reveals a detail the agent should have already known, or when developers find themselves prompting corrections and clarifications already addressed in a previous session.
Finally, to minimize blind references, developers should tell agents when and why to read files, and include references with concise explanations of the document’s role, the information it contains, and scenarios where it should be used. For instance, text may reference an external dependency, include a link to its GitHub repository, and provide a brief explanation of its purpose. “Then the agent is able to understand the role of the dependency without needing to load or inspect the external repository directly,” the researchers explained.
Ultimately, they concluded, configuration files are “key artifacts” in agentic software development, and when they get smelly, there’s a problem. Therefore, “their quality deserves effort and attention.”
Understanding a reactivity model in the abstract is useful, but it is ultimately incomplete without seeing how it shapes real application code. Concepts such as state, derivation, and explicit dependencies only become meaningful when they influence how forms are built, validated, and maintained in practice.
This article focuses on a concrete example: a modest but realistic registration form. Rather than introducing new concepts, the goal here is to make earlier ideas tangible. We will see how a signal-backed model reshapes validation, interaction state, and submission logic, and how much coordination logic simply disappears when form behavior is expressed declaratively.
The focus here is not on novelty or completeness, but on making the underlying ideas easier to reason about. By walking through a signal-first form from model definition to submission, we can evaluate whether this approach truly reduces complexity and where it introduces new trade-offs that teams should understand before adopting it more broadly.
With the conceptual groundwork in place, we can now turn theory into a concrete implementation. In this section, we will build a fully working registration form using Angular’s Signal Forms API. This example is deliberately modest in scope, but it is designed to serve as the foundation for the rest of the series. Each subsequent article will extend this same example rather than introducing a new one.
The form collects an email address, a password, a confirmation password, and explicit acceptance of terms. While simple on the surface, this structure allows us to explore field-level validation, cross-field constraints, interaction state, and submission behavior, all without reverting to event-driven form logic.
Project setup and structure
The example assumes a standard Angular application created with the Angular CLI and configured to use Signals (Angular 17+). The Signal Forms APIs (Angular 21+) live under @angular/forms/signals, which must be explicitly imported.
Separating the model from the component keeps form state independent of presentation. This becomes increasingly valuable as the form grows or is reused across multiple components.
Defining the form model
We begin by defining the shape of the data that the form collects. This is a plain TypeScript interface with no Angular dependencies. Treating the form model as a simple data structure reinforces the idea that the form’s values are just state.
This interface mirrors what would typically be sent to a back-end API. There is no duplication of state, no separate “form value” object, and no mapping required at submission time.
Creating the signal-backed form
The form itself is created in the component using a writable signal as the source of truth. The form() function attaches form semantics validation, field state, and submission to that signal.
// registration.component.ts
import { CommonModule } from "@angular/common";
import { Component, signal } from "@angular/core";
import {
email,
form,
FormField,
required,
submit,
} from "@angular/forms/signals";
import { RegistrationData } from "./registration.model";
@Component({
selector: "app-registration",
imports: [FormField, CommonModule],
templateUrl: "./registration.html",
styleUrl: "./registration.css",
})
export class Registration {
readonly model = signal({
email: "",
password: "",
confirmPassword: "",
acceptedTerms: false,
});
readonly registrationForm = form(this.model, (schema) => {
required(schema.email, { message: "Email is required" });
email(schema.email, { message: "Enter a valid email address" });
required(schema.password, { message: "Password is required" });
required(schema.confirmPassword, {
message: "Please confirm your password",
});
required(schema.acceptedTerms, {
message: "You must accept the terms to continue",
});
});
async onSubmit(event?: Event) {
event?.preventDefault();
await submit(this.registrationForm, (value) => {
console.log(value());
// Mock Server Call
return Promise.resolve([
{
kind: "EmailAlreadyExists",
field: this.registrationForm.email,
error: { kind: "server", message: "Email already taken" },
},
]);
});
}
}
Several design decisions are worth noting.
First, the model signal is defined as read-only. All mutations to the model occur through form bindings, not ad hoc assignments in the component. This keeps the component declarative and avoids the temptation to manipulate form state imperatively.
Second, validation is declared in one place. The schema function describes constraints on the model without introducing control trees, validator arrays, or observable pipelines. Angular takes responsibility for re-running validation whenever the model changes.
Finally, submission logic is explicit. The submit() helper ensures that the form is valid before invoking the callback, and it passes the current model value directly. There is no need to check flags or manually extract values.
Binding the form to the template
With the form defined, the next step is to bind it to the template. Signal Forms provide the [formField] directive, which connects an input element directly to a field in the form schema.
@if (registrationForm().errors().length > 0) {
@for (error of registrationForm().errors(); track error.message) {
What stands out here is the absence of indirection. Each input binds directly to a field. Validation state is accessed through signals such as invalid() and touched(). Error messages are read from a structured error object, not reconstructed manually.
This template contains no subscriptions, no async pipes, and no event handlers for value changes. The UI simply reflects the current form state.
Interaction state and user experience
One of the common criticisms of declarative form models is that they obscure user interaction logic. Signal Forms address this directly by exposing interaction metadata as signals.
The touched() signal determines whether a field has been interacted with. By combining it with invalid(), we control when validation messages appear. This logic remains purely declarative: the template describes when errors should be visible, and Angular ensures the signals stay up-to-date.
The disabled state of the submit button is derived from registrationForm.invalid(). There is no need to manually enable or disable it in response to events. If the form becomes valid, the button is enabled automatically.
Why this scales
Even at this early stage, several advantages of a signal-first form model are apparent. The form’s behavior is expressed in terms of state and derivation, not events. The model, validation rules, and UI bindings are clearly separated. There is no duplication of logic between the component and the template.
As the form grows, this structure holds. Additional fields introduce additional schema entries and template bindings, not new subscription logic. Cross-field validation can be added declaratively. Asynchronous validation and persistence can be layered on without rewriting the core model.
Most importantly, the form remains inspectable. At any point during execution, the model signal reflects the current state of the form. Derived state validity, errors, and UI flags can be understood by reading the code, not by tracing runtime behavior.
What we did not solve yet (and why)
At this stage, it would be easy to walk away with the impression that Signal Forms eliminates most of the hard problems associated with form handling. That impression would be misleading. What we have built so far is intentionally incomplete, not because the approach falls short, but because introducing too much too early obscures the value of the underlying model.
One area we have deliberately postponed is cross-field validation that expresses richer business rules. Many real-world forms depend on relationships between fields rather than isolated constraints. Password confirmation is a familiar example, but more complex scenarios quickly arise in enterprise applications. While Signal Forms support these patterns, introducing them before establishing a clear understanding of derived state risks turns validation back into an imperative exercise rather than a declarative one.
We have also avoided asynchronous validation. Server-backed checks introduce latency, partial failure, cancellation, and race conditions. These are not trivial concerns, and treating them casually often leads to subtle bugs and confusing user experiences. Although Signal Forms provide the necessary hooks to model asynchronous behavior, doing so responsibly requires a careful discussion of pending state, effects, and life-cycle boundaries. That discussion belongs in its own article.
Another omission is persistence and synchronization. Many forms need to autosave drafts, synchronize state with local storage, or react to changes by triggering external side effects. These behaviors are not part of the form state itself; they are consequences of state changes. Treating them as such is essential to keeping the architecture comprehensible. Introducing persistence too early would blur the distinction between state and reaction that this article has worked to establish.
Finally, this article has not addressed migration and interoperability. Few teams are starting from a blank slate. Most will adopt Signal Forms incrementally within applications that already rely on reactive forms or template-driven forms. Hybrid approaches, bridging strategies, and gradual refactors are all critical topics, but they presuppose familiarity with both paradigms. Addressing migration before establishing a solid signal-first mental model would undermine that foundation.
These omissions are intentional. A form architecture that tries to do everything at once often ends up doing nothing clearly. By focusing on the core ideas of state, derivation, and declarative validation, we create a base that can absorb additional complexity without collapsing under it.
Signal Forms in the context of Angular’s evolution
To fully appreciate Signal Forms, it helps to step back and view them not as an isolated feature, but as part of a broader shift in Angular’s design philosophy.
For much of its history, Angular emphasized declarative templates paired with imperative coordination in component classes. RxJS became the backbone of that coordination, providing a powerful abstraction for handling asynchronous workflows, user input, and external events. This model scaled well, but it also encouraged developers to express state indirectly through streams and subscriptions.
Signals represent a deliberate recalibration. They re-center Angular’s reactivity model around state and derivation, rather than events and emissions. This shift is visible across the framework: in component inputs, change detection, and now forms. Signal Forms are not an attempt to replace everything that came before; they are an attempt to make the most common use case, modeling and deriving state, simpler and more explicit.
Framed this way, the design of Signal Forms aligns more closely with state-driven form behavior. The requirement to start with a model signal reflects the idea that the state should have a single, inspectable source of truth. Schema-based validation aligns with the notion that constraints are properties of state, not behaviors triggered by events. Field state exposed as signals reinforces the idea that validity, errors, and interaction metadata are derived values that should be read, not managed.
It is also worth noting that Signal Forms do not attempt to abstract away form behavior. They do not hide form state behind opaque classes or life-cycle hooks. They do not require developers to think in terms of control hierarchies or subscription graphs. Instead, they expose form behavior directly, making it easier to reason about how values, validation, and UI feedback relate to one another.
This approach aligns closely with other recent changes in Angular, including the introduction of modern template control flow and a stronger emphasis on explicit data dependencies. Together, these features point toward a framework that favors clarity over indirection and composition over orchestration.
Importantly, Signal Forms are still evolving. Their APIs may change, and their surface area will almost certainly expand. That is precisely why grounding them in first principles matters. Developers who understand why Signal Forms work the way they do will be far better equipped to adapt as the APIs mature.
This article has intentionally avoided duplicating documentation or enumerating every available feature. Instead, it has focused on establishing a conceptual framework that makes the official APIs feel intuitive rather than surprising. When viewed this way, Signal Forms are not a new way to write forms; they are a clearer expression of what forms have always been.
A new way to think about forms
Building the registration form in this article reveals a quiet but important shift. The reduction in complexity does not come from fewer features or simpler requirements. It comes from expressing form behavior in terms of state and derivation rather than orchestration and reaction.
By treating the data model as the single source of truth, validation rules as declarative constraints, and UI behavior as derived from current conditions, much of the coordination logic that typically surrounds forms becomes unnecessary. There are fewer subscriptions to manage, fewer flags to synchronize, and fewer life-cycle concerns to reason about. Form behavior becomes easier to inspect because it is visible directly in the relationships between values.
This approach does not eliminate the hard problems associated with forms. Asynchronous validation, persistence, and interoperability with existing Angular Forms APIs still require careful design. What changes is where that complexity lives. Instead of being interwoven with state representation, those concerns are layered explicitly on top of a clear foundation.
Signal-first forms are not a universal replacement for existing patterns, nor are they a shortcut to simpler applications. They are, however, a strong example of how aligning APIs with first principles can reduce cognitive overhead and improve maintainability over time. For teams building large, state-heavy forms, this alignment can make the difference between code that merely works and code that continues to evolve without friction.
Databricks is pitching a fix for what it sees as the growing operations mess in enterprise AI. With the launch of Genie ZeroOps, unveiled at its Data + AI Summit, the company is targeting a problem many data teams know too well: it’s no longer building pipelines and models that hurts, it’s keeping them running.
As data estates sprawl and AI workloads multiply, engineering time is increasingly eaten up by maintenance. Meanwhile, AI coding tools are accelerating development, churning out even more assets that need oversight, widening the gap between how fast teams can build and how much they have to manage.
Databricks Genie ZeroOps is a new agentic operations capability that is designed to automate the monitoring, investigation, and remediation of issues across data and AI workloads.
Currently in private preview, ZeroOps uses an AI agent to identify anomalies, trace root causes using metadata and lineage information via Unity Catalog, generate proposed fixes, and then test those fixes in an isolated environment before pushing them out for human review to be applied in production.
Targeting real operational complexity?
Genie ZeroOps addresses a legitimate enterprise challenge around operational complexity, particularly the growing burden of maintaining data and AI workloads in production, analysts say.
“Most data teams spend more time keeping pipelines and models alive than building new ones,” said Amit Chandak, chief analytics officer at IT consulting firm Kanerika.
Echoing Chandak, independent consultant David Linthicum said enterprises continue to grapple with deployment drift, incident response, compliance checks, and root-cause analysis across increasingly fragmented data and AI estates.
Those challenges, echoed Victor Coimbra, CTO of IT consulting firm Artefact, are compounded by the emergence of agentic coding tools that accelerate the development of assets, such as machine learning pipelines and models that need “babysitting.”
That maintenance burden carries a significant productivity cost, said Robert Kramer, managing partner at KramerERP, noting that activities such as managing infrastructure, deployment environments, support processes, and operational workflows consume time without directly creating business value.
Those productivity drains, according to Coimbra, have proven difficult to eliminate despite the emergence and widespread adoption of automated observability and governance tools.
“What is different here is the agentic piece. Databricks is trying to move from tools that alert humans to systems that diagnose issues, propose fixes, and validate them in a governed environment without breaking anything in production,” echoed Stephanie Walter, practice leader of AI stack at HyperFRAME Research.
Shifting the role of platform teams
That shift, according to analysts, could change the way most enterprise platforms and development teams work currently.
“Skilled engineers spend the majority of their time on toil. If the ZeroOps agent, in the background, handles monitoring, investigation, and fix-proposal, engineers shift from doing the operational work to reviewing it. The traditional split between ‘people who build’ and ‘people who keep things running’ starts to blur,” said Ashish Chaturvedi, leader of executive research at HFS Research.
“Additionally, this would also mean that platform teams (engineers responsible for maintenance) can focus on genuinely novel failures rather than the repetitive ones,” Chaturvedi added.
The shift, according to Coimbra, could also affect how enterprises scale platform teams: “They can stop hiring operations staff in lockstep with every new pipeline. The same team can cover a lot more.”
Given that the capability is still in preview, Kanerika’s Chandak pointed out that the headcount reduction claims may be overstated.
ZeroOps could instead pose the risk of “skill atrophy,” Chandak said.
“If engineers stop debugging because the agent does it, the team’s ability to handle the cases the agent cannot handle becomes a real exposure,” Coimbra added.
What ZeroOps could mean for CIOs
Genie ZeroOps could be attractive to CIOs because it links innovation capacity with operational discipline rather than forcing a tradeoff between the two, Linthicum said.
“The appeal is straightforward: reduce operational drag, shorten deployment cycles, improve service resilience, and enforce governance without scaling headcount at the same rate as workloads,” Linthicum said.
That combination of efficiency and reliability could help CIOs rein in one of the biggest costs associated with operating data and AI environments, Chaturvedi said. “ZeroOps attacks time spent on maintenance. CIOs have watched their data engineering budgets balloon while the proportion of that spend going to net-new value shrinks.”
Linthicum warned that CIOs should consider the new offering with calculated skepticism and seek metrics to validate Databricks’ claims.
“The headline metrics are mean time to detect and mean time to resolve, plus the share of incidents the agent closes without a human stepping in. Those tell you whether it is actually removing the operational complexities that it promises,” Kanerika’s Chandak echoed.
“Underneath these metrics, CIOs should track the accuracy of their root cause calls, the false positive rate on proposed fixes, and the proportion of fixes engineers approve without editing, because that last number is the real trust signal. On cost, they should measure cost per incident handled against the human baseline, net of agent compute,” Chandak added.
That scrutiny, Chandak further added, is even more important for CIOs because Databricks is entering an emerging category.
“Most vendor agent announcements target the build and use layers, helping people write code or ask questions of their data. ZeroOps targets the operate layer, which is less crowded,” Chandak said.
France’s OVHcloud is moving beyond cloud infrastructure into frontier AI model development, a shift that could test whether Europe can produce another serious alternative to US and Chinese AI systems.
The company, one of Europe’s leading homegrown cloud providers, plans to train a family of models from scratch and aims to open-source them once they meet its performance targets, CEO Octave Klaba told Reuters.
The move would put OVHcloud in closer comparison with Mistral AI, the Paris-based model developer that has become Europe’s most visible challenger to US AI labs.
Klaba said the economics of building advanced AI models have changed, with improvements in chips, training methods, and synthetic data reducing the cost of a project that may once have required about $1.15 billion (€1 billion) to now cost less than $230 million (€200 million).
Reuters reported that OVHcloud said one of its models has completed pre-training on Jupiter, the Germany-based EuroHPC supercomputer described as Europe’s fastest and its first exascale system, though the company has not yet disclosed detailed performance benchmarks.
This comes as European governments and enterprises are increasingly having to assess AI infrastructure through the lens of data governance and continuity of access, rather than performance alone.
Those concerns were sharpened this month after Anthropic said a US government export-control directive required it to suspend access to its Fable 5 and Mythos 5 models by foreign nationals inside and outside the US.
Training is only the opening cost
OVHcloud’s lower cost estimate does not capture the full cost of becoming a frontier AI model provider, said Neil Shah, vice president for research and partner at Counterpoint Research.
The $230 million (€200 million) figure likely refers mainly to the initial training run, Shah said. Once trained, however, models require continued investment because they can become depreciating assets if they are not improved with fresh data.
OVHcloud would also need to spend on fine-tuning, post-training, sovereign infrastructure, storage, security, distribution, and enterprise support. It would also need enough scale to make model serving economically viable against established AI providers such as Google and Anthropic.
“Model is seen as a depreciating asset if it is not consistently trained and kept fresh with the data,” Shah said.
That makes OVHcloud’s plan a test not only of technical capability, but also of policy support and economic viability. If the company falls short, enterprises may be reluctant to shift workloads away from more established models.
The lower training cost could still give OVHcloud a credible starting point, said Charlie Dai, principal analyst at Forrester.
The budget range can be enough to produce a credible frontier model as efficiency gains reduce the cost of entry, Dai said. But enterprise competitiveness will depend on sustained capabilities beyond training, including inference efficiency, data pipelines, evaluation frameworks, and ecosystem reach.
Buyers need proof
OVHcloud’s plan remains an expression of intent rather than demonstrated capability, said Sanchit Vir Gogia, chief analyst at Greyhound Research, pointing to the absence of published benchmarks and other details.
“$200 million now buys a serious training run,” Gogia said. “It does not buy a serious enterprise AI franchise.”
Gogia said questions around sovereignty also extend to the infrastructure used to train the model, noting that pre-training was run on Jupiter rather than on infrastructure owned or controlled by OVHcloud.
The system is a publicly owned European supercomputer in Germany that runs on American silicon, Gogia said, adding that this shows how partial European AI sovereignty remains.
CIOs will need evidence that the models can be supported in production, governed effectively, audited when needed, and exited without major disruption.
Gogia said a European-owned model could reduce some dependence on US and Chinese providers, but would not remove jurisdictional risk. “Sovereignty does not abolish the off switch,” he said. “It changes whose hand rests upon it.”
OVHcloud’s move into model development could also alter the lock-in risks enterprises need to assess, Gogia said. Customers may be able to move cloud infrastructure later, but find it harder to shift AI workloads once applications and processes are built around a provider’s models and governance tools.
In hardware, when you ship something broken, the consequences are severe and often irreversible. That’s the world I worked in for years, in verification roles at Mellanox and later at Alibaba. The stakes forced the industry to build a rigorous verification culture. You proved designs worked before they left the building.
In software, verification disciplines look like CI/CD pipelines, static analysis, canary deployments, and observability. But those systems were built around code written at human speed, with human comprehension baked into the process. AI code generation has broken that assumption. The writing process can no longer be trusted to carry institutional knowledge and judgment into the codebase. The industry is being pushed toward the kind of rigorous verification culture that hardware engineers have practiced for decades.
Enterprises are generating code faster than at any point in history. Google recently disclosed that 75% of the company’s new code is now AI-generated. Meta has set internal targets requiring most of its engineers to generate the majority of their committed code with AI tools by mid-2026. The velocity gains are significant. But a growing body of evidence suggests the industry is accumulating a new form of technical debt, one that is less visible than the traditional kind and harder to unwind. It’s also preventable, and the organizations that get ahead of it will have a meaningful advantage over those that don’t.
Understand what makes this debt different
The standard narrative frames this as AI writing bad code. That’s not quite right. The more precise problem is cognitive debt: the loss of understanding of how and why software was built the way it was.
When a human writes code, something else happens alongside the typing. They simulate edge cases, reason through dependencies, and make judgment calls grounded in organizational context, including the business requirements behind a feature, the best practices the team has established, and the reasoning behind past architectural choices. That cognitive loop is how institutional knowledge gets built. When AI writes the code, you can get output that is syntactically correct, passes CI, ships cleanly, and leaves no one holding the mental model. The code works until something changes or breaks, and then the team is excavating a black box.
This is distinct from traditional technical debt, which is messy code. Cognitive debt is invisible code that functions but that nobody truly owns. And it compounds faster, because the same velocity that makes AI generation attractive is what prevents anyone from stopping to build the understanding that maintainability requires.
GitClear’s analysis of 211 million changed lines of code across major repositories found that during 2024, duplicate code blocks of five or more lines increased eightfold, while refactoring dropped from 25% to under 10% of all code changes. Refactoring is the slow, unglamorous work that keeps codebases healthy, and developers are doing far less of it. Google’s 2024 DORA report found that a 25% increase in AI adoption correlates with a 7.2% decrease in delivery stability. DORA analysts note that the root cause isn’t flawed code per se; AI inflates batch sizes, and larger changesets have always been riskier to ship.
These findings aren’t indictments of AI-assisted development. They’re diagnostics, and they point toward a specific set of fixes.
Close the context gap first
In a survey of 609 developers we conducted last year, 65% said AI misses relevant context during critical tasks like refactoring, writing tests, or reviewing code. Context is the primary driver of AI code quality, and it’s where most enterprise organizations are underinvesting.
When an AI tool generates code without access to your organization’s architectural decisions, historical pull requests, security policies, or existing module patterns, you get solutions that are locally correct but globally incoherent. Closing that gap requires context engineering: ensuring the tools and agents you use have access, at the right moment, to the right organizational knowledge, and the judgment to determine what is actually relevant for a given task. A retrieval system that surfaces too much irrelevant context can degrade output quality as readily as one that surfaces too little. The specific tooling matters less than the discipline. Context infrastructure needs to be actively maintained, not indexed once and forgotten.
Build this infrastructure before you scale AI generation. Retrofitting is significantly harder. Treat it the way you treat your CI pipeline, as a prerequisite for safe production deployment.
Consider what happens when a team has built this context infrastructure well. Their code review tooling knows about a deprecated internal API, because that deprecation decision lives in months of past pull request discussions that have been indexed and surfaced. When generated code references the old API, the review flags it. Without that context layer, the same mistake gets waved through every time. That’s the kind of institutional knowledge that evaporates when humans stop writing every line of code, and that you have to actively work to preserve.
Build a verification layer that matches your generation velocity
Almost all of the investment in AI-assisted development has gone into generation. Very little has gone into verification. That imbalance is where the tech debt accumulates.
I think of these as the blue team and the red team. The blue team covers code generation, autocomplete, and agentic coding. It’s getting the headlines, the budgets, and the product launches. The red team covers integrity checks, behavior coverage, and alignment with organizational standards. In most organizations, it’s an afterthought. A CI pipeline catches obvious failures. A code review might happen, but reviewers are overwhelmed by the volume of AI-generated output and cannot meaningfully evaluate all of it. The result is code with a veneer of having been reviewed without anyone having actually understood it.
The Crowdstrike outage of 2024 is worth keeping in mind here. AI didn’t generate the problematic code, but the incident illustrated what happens when a single software error propagates through production systems without sufficient verification. That exposure multiplies when code is being generated faster than humans can understand it.
A real verification layer means automated analysis that evaluates whether generated code aligns with your organization’s best practices, architectural standards, and compliance requirements. It means test coverage that reflects intended behavior, not only the happy path the AI chose to generate tests for. And it means traceability: a connection between the requirement and the implementation, so that six months from now, someone can understand what the code does and why it exists.
The numbers support investment here. In the same developer survey, teams that integrated AI into their code review workflow saw quality improvements in 81% of cases, compared to 55% for comparable teams without it.
Make ownership non-negotiable
Every piece of AI-generated code in production needs an accountable human who understands it well enough to maintain it. This is harder than it sounds, and it’s where most organizations are falling short.
The same velocity that makes AI generation attractive also creates pressure to skip the slow work of genuine comprehension. A developer reviews a 500-line pull request that an AI generated in three minutes and faces a real choice: spend two hours actually understanding it, or approve it because it looks right, passes the test, and “LGTM” (looks good to me).
Real ownership means slowing down generation velocity enough to allow for meaningful review, and being explicit with your team that this is the right trade-off. When that doesn’t happen, you’ve started building your next legacy system.
What to do this quarter
The good news is that none of this requires a multi-year transformation. The structural problems are real, but they have concrete solutions, and engineering leaders can make meaningful progress on all three fronts without waiting for the next budget cycle.
Audit your context infrastructure. If your AI tools are generating code without access to your organization’s architectural decisions, deprecated APIs, and security policies, fix that before expanding generation velocity further. The quality of context determines the quality of output.
Invest in the red team. Establish an automated code quality and governance layer that evaluates generated code against your specific organizational standards, beyond functional correctness. This is a distinct investment from your code generation tooling and needs to be treated as such.
Establish ownership explicitly. Every AI-generated feature in production should have a human owner who genuinely understands it. Make that a formal requirement.
The organizations that get this right will find that AI generation becomes far more reliable once it has a verification layer underneath it. The ones that don’t will keep shipping faster while understanding their systems less, until the accumulated debt forces a reckoning. That’s a solvable problem. The question is whether you solve it now or later.
—
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.
Understanding a reactivity model in the abstract is useful, but it is ultimately incomplete without seeing how it shapes real application code. Concepts such as state, derivation, and explicit dependencies only become meaningful when they influence how forms are built, validated, and maintained in practice.
This article focuses on a concrete example: a modest but realistic registration form. Rather than introducing new concepts, the goal here is to make earlier ideas tangible. We will see how a signal-backed model reshapes validation, interaction state, and submission logic, and how much coordination logic simply disappears when form behavior is expressed declaratively.
The focus here is not on novelty or completeness, but on making the underlying ideas easier to reason about. By walking through a signal-first form from model definition to submission, we can evaluate whether this approach truly reduces complexity and where it introduces new trade-offs that teams should understand before adopting it more broadly.
Implementing a signal-first registration form
With the conceptual groundwork in place, we can now turn theory into a concrete implementation. In this section, we will build a fully working registration form using Angular’s Signal Forms API. This example is deliberately modest in scope, but it is designed to serve as the foundation for the rest of the series. Each subsequent article will extend this same example rather than introducing a new one.
The form collects an email address, a password, a confirmation password, and explicit acceptance of terms. While simple on the surface, this structure allows us to explore field-level validation, cross-field constraints, interaction state, and submission behavior, all without reverting to event-driven form logic.
Project setup and structure
The example assumes a standard Angular application created with the Angular CLI and configured to use Signals (Angular 17+). The Signal Forms APIs (Angular 21+) live under @angular/forms/signals, which must be explicitly imported.
Separating the model from the component keeps form state independent of presentation. This becomes increasingly valuable as the form grows or is reused across multiple components.
Defining the form model
We begin by defining the shape of the data that the form collects. This is a plain TypeScript interface with no Angular dependencies. Treating the form model as a simple data structure reinforces the idea that the form’s values are just state.
This interface mirrors what would typically be sent to a back-end API. There is no duplication of state, no separate “form value” object, and no mapping required at submission time.
Creating the signal-backed form
The form itself is created in the component using a writable signal as the source of truth. The form() function attaches form semantics validation, field state, and submission to that signal.
// registration.component.ts
import { CommonModule } from "@angular/common";
import { Component, signal } from "@angular/core";
import {
email,
form,
FormField,
required,
submit,
} from "@angular/forms/signals";
import { RegistrationData } from "./registration.model";
@Component({
selector: "app-registration",
imports: [FormField, CommonModule],
templateUrl: "./registration.html",
styleUrl: "./registration.css",
})
export class Registration {
readonly model = signal({
email: "",
password: "",
confirmPassword: "",
acceptedTerms: false,
});
readonly registrationForm = form(this.model, (schema) => {
required(schema.email, { message: "Email is required" });
email(schema.email, { message: "Enter a valid email address" });
required(schema.password, { message: "Password is required" });
required(schema.confirmPassword, {
message: "Please confirm your password",
});
required(schema.acceptedTerms, {
message: "You must accept the terms to continue",
});
});
async onSubmit(event?: Event) {
event?.preventDefault();
await submit(this.registrationForm, (value) => {
console.log(value());
// Mock Server Call
return Promise.resolve([
{
kind: "EmailAlreadyExists",
field: this.registrationForm.email,
error: { kind: "server", message: "Email already taken" },
},
]);
});
}
}
Several design decisions are worth noting.
First, the model signal is defined as read-only. All mutations to the model occur through form bindings, not ad hoc assignments in the component. This keeps the component declarative and avoids the temptation to manipulate form state imperatively.
Second, validation is declared in one place. The schema function describes constraints on the model without introducing control trees, validator arrays, or observable pipelines. Angular takes responsibility for re-running validation whenever the model changes.
Finally, submission logic is explicit. The submit() helper ensures that the form is valid before invoking the callback, and it passes the current model value directly. There is no need to check flags or manually extract values.
Binding the form to the template
With the form defined, the next step is to bind it to the template. Signal Forms provide the [formField] directive, which connects an input element directly to a field in the form schema.
@if (registrationForm().errors().length > 0) {
@for (error of registrationForm().errors(); track error.message) {
What stands out here is the absence of indirection. Each input binds directly to a field. Validation state is accessed through signals such as invalid() and touched(). Error messages are read from a structured error object, not reconstructed manually.
This template contains no subscriptions, no async pipes, and no event handlers for value changes. The UI simply reflects the current form state.
Interaction state and user experience
One of the common criticisms of declarative form models is that they obscure user interaction logic. Signal Forms address this directly by exposing interaction metadata as signals.
The touched() signal determines whether a field has been interacted with. By combining it with invalid(), we control when validation messages appear. This logic remains purely declarative: the template describes when errors should be visible, and Angular ensures the signals stay up-to-date.
The disabled state of the submit button is derived from registrationForm.invalid(). There is no need to manually enable or disable it in response to events. If the form becomes valid, the button is enabled automatically.
Why this scales
Even at this early stage, several advantages of a signal-first form model are apparent. The form’s behavior is expressed in terms of state and derivation, not events. The model, validation rules, and UI bindings are clearly separated. There is no duplication of logic between the component and the template.
As the form grows, this structure holds. Additional fields introduce additional schema entries and template bindings, not new subscription logic. Cross-field validation can be added declaratively. Asynchronous validation and persistence can be layered on without rewriting the core model.
Most importantly, the form remains inspectable. At any point during execution, the model signal reflects the current state of the form. Derived state validity, errors, and UI flags can be understood by reading the code, not by tracing runtime behavior.
What we did not solve yet (and why)
At this stage, it would be easy to walk away with the impression that Signal Forms eliminates most of the hard problems associated with form handling. That impression would be misleading. What we have built so far is intentionally incomplete, not because the approach falls short, but because introducing too much too early obscures the value of the underlying model.
One area we have deliberately postponed is cross-field validation that expresses richer business rules. Many real-world forms depend on relationships between fields rather than isolated constraints. Password confirmation is a familiar example, but more complex scenarios quickly arise in enterprise applications. While Signal Forms support these patterns, introducing them before establishing a clear understanding of derived state risks turns validation back into an imperative exercise rather than a declarative one.
We have also avoided asynchronous validation. Server-backed checks introduce latency, partial failure, cancellation, and race conditions. These are not trivial concerns, and treating them casually often leads to subtle bugs and confusing user experiences. Although Signal Forms provide the necessary hooks to model asynchronous behavior, doing so responsibly requires a careful discussion of pending state, effects, and life-cycle boundaries. That discussion belongs in its own article.
Another omission is persistence and synchronization. Many forms need to autosave drafts, synchronize state with local storage, or react to changes by triggering external side effects. These behaviors are not part of the form state itself; they are consequences of state changes. Treating them as such is essential to keeping the architecture comprehensible. Introducing persistence too early would blur the distinction between state and reaction that this article has worked to establish.
Finally, this article has not addressed migration and interoperability. Few teams are starting from a blank slate. Most will adopt Signal Forms incrementally within applications that already rely on reactive forms or template-driven forms. Hybrid approaches, bridging strategies, and gradual refactors are all critical topics, but they presuppose familiarity with both paradigms. Addressing migration before establishing a solid signal-first mental model would undermine that foundation.
These omissions are intentional. A form architecture that tries to do everything at once often ends up doing nothing clearly. By focusing on the core ideas of state, derivation, and declarative validation, we create a base that can absorb additional complexity without collapsing under it.
Signal Forms in the context of Angular’s evolution
To fully appreciate Signal Forms, it helps to step back and view them not as an isolated feature, but as part of a broader shift in Angular’s design philosophy.
For much of its history, Angular emphasized declarative templates paired with imperative coordination in component classes. RxJS became the backbone of that coordination, providing a powerful abstraction for handling asynchronous workflows, user input, and external events. This model scaled well, but it also encouraged developers to express state indirectly through streams and subscriptions.
Signals represent a deliberate recalibration. They re-center Angular’s reactivity model around state and derivation, rather than events and emissions. This shift is visible across the framework: in component inputs, change detection, and now forms. Signal Forms are not an attempt to replace everything that came before; they are an attempt to make the most common use case, modeling and deriving state, simpler and more explicit.
Framed this way, the design of Signal Forms aligns more closely with state-driven form behavior. The requirement to start with a model signal reflects the idea that the state should have a single, inspectable source of truth. Schema-based validation aligns with the notion that constraints are properties of state, not behaviors triggered by events. Field state exposed as signals reinforces the idea that validity, errors, and interaction metadata are derived values that should be read, not managed.
It is also worth noting that Signal Forms do not attempt to abstract away form behavior. They do not hide form state behind opaque classes or life-cycle hooks. They do not require developers to think in terms of control hierarchies or subscription graphs. Instead, they expose form behavior directly, making it easier to reason about how values, validation, and UI feedback relate to one another.
This approach aligns closely with other recent changes in Angular, including the introduction of modern template control flow and a stronger emphasis on explicit data dependencies. Together, these features point toward a framework that favors clarity over indirection and composition over orchestration.
Importantly, Signal Forms are still evolving. Their APIs may change, and their surface area will almost certainly expand. That is precisely why grounding them in first principles matters. Developers who understand why Signal Forms work the way they do will be far better equipped to adapt as the APIs mature.
This article has intentionally avoided duplicating documentation or enumerating every available feature. Instead, it has focused on establishing a conceptual framework that makes the official APIs feel intuitive rather than surprising. When viewed this way, Signal Forms are not a new way to write forms; they are a clearer expression of what forms have always been.
A new way to think about forms
Building the registration form in this article reveals a quiet but important shift. The reduction in complexity does not come from fewer features or simpler requirements. It comes from expressing form behavior in terms of state and derivation rather than orchestration and reaction.
By treating the data model as the single source of truth, validation rules as declarative constraints, and UI behavior as derived from current conditions, much of the coordination logic that typically surrounds forms becomes unnecessary. There are fewer subscriptions to manage, fewer flags to synchronize, and fewer life-cycle concerns to reason about. Form behavior becomes easier to inspect because it is visible directly in the relationships between values.
This approach does not eliminate the hard problems associated with forms. Asynchronous validation, persistence, and interoperability with existing Angular Forms APIs still require careful design. What changes is where that complexity lives. Instead of being interwoven with state representation, those concerns are layered explicitly on top of a clear foundation.
Signal-first forms are not a universal replacement for existing patterns, nor are they a shortcut to simpler applications. They are, however, a strong example of how aligning APIs with first principles can reduce cognitive overhead and improve maintainability over time. For teams building large, state-heavy forms, this alignment can make the difference between code that merely works and code that continues to evolve without friction.
The problem with software development today may no longer be writing code. With AI coding assistants generating code faster than ever, the bigger challenge is reviewing, testing, and safely releasing it.
AWS is betting that software teams need help with that part of the process, adding release management features to its DevOps Agent.
The new features, currently in preview, automatically assess code changes against organizational standards, identify potential release risks, and generate tests tailored to individual changes before they reach production.
The release readiness feature, in particular, runs the code in an AWS-managed isolated environment, executing lightweight user journey tests to verify the software builds, runs, and passes basic functional checks before the change enters the pipeline, the company wrote in a blog post.
The findings of these tests can be viewed through the DevOps Agent console, as comments on pull requests in GitHub or GitLab, or can be invoked directly through IDEs via Kiro or the Claude Code plugin, it added.
Targeting AI-era software delivery bottlenecks
Running code in isolated environments and delivering the results directly through developer tools helps address two longstanding challenges in software delivery, said Pareekh Jain, principal analyst at Pareekh Consulting.
It enables teams to validate how code changes behave before deployment, catching issues that static analysis may overlook, while reducing context switching by embedding findings into existing workflows, in turn accelerating fixes, Jain said.
The analyst pointed out that the release readiness capability addresses a key bottleneck in AI-driven software development: “While AI coding agents can generate code quickly, reviews, compliance checks, dependency validation, and release approvals still slow deployment.”
“By automatically checking code changes against internal standards, security policies, and dependency impacts, AWS helps developers, DevOps teams, and SREs identify issues earlier, reduce manual review effort, and improve release confidence,” Jain added.
These gains in productivity for developers could also translate into tangible business benefits for CIOs, according to Jain.
“Release readiness as a feature could help enterprises capture more value from AI-generated code while reducing operational overhead by eliminating the need for additional QA and DevOps resources. This means that they can accelerate software delivery without sacrificing reliability,” the analyst noted.
Autonomous testing before merging code
While release readiness reviews focus on assessing whether a code change is safe to move through the delivery pipeline, AWS is also adding a separate feature aimed at validating how those changes behave in production-like environments.
Named autonomous release testing, the new capability generates and runs change-specific test plans for web and API-based applications in customer-provisioned, production-like environments before the change actually merges, the company wrote in the blog post.
For Jain, autonomous release testing is “even more” important for developers and SREs as it “automates one of the most time-consuming parts of software delivery.”
“Developers spend less time creating and maintaining tests, while SREs benefit from fewer rollbacks and improved system reliability,” Jain said.
These benefits stem from the feature’s ability to automatically generate tests tailored to individual code changes, covering functional correctness, behavioral regressions, and integration scenarios that might otherwise require significant manual effort, Jain added.
However, AWS is not alone in trying to bring AI deeper into the software delivery lifecycle.
Microsoft-owned GitHub has been expanding Copilot’s code review capabilities, allowing the service to automatically review pull requests, suggest fixes, and provide feedback directly within developer workflows.
Google, meanwhile, has been steadily broadening the scope of Gemini Code Assist beyond code generation to support software development tasks such as code review and developer assistance.
AWS’s differentiation, though, according to Jain, lies in tying those capabilities to release management and operational workflows that span development and production environments.
Availability and pricing
For development teams interested in evaluating DevOps Agent’s new capabilities, AWS said both features are available in preview at no additional cost in the US East (N. Virginia) region.
AWS DevOps Agent, billed per agent-second, is included in the AWS Free Tier for new customers.
Additionally, new AWS DevOps Agent customers receive a 2-month free trial starting with their first operational task after general availability.
Each trial month includes up to 10 agent spaces, 20 hours of investigations (incident response), 15 hours of evaluations (incident prevention), and 20 hours of on-demand SRE tasks (chat), the company said.
Once those limits are exhausted, customers are charged based on consumption, with investigations, evaluations, and on-demand SRE tasks each priced at $0.0083 per agent-second, AWS added.
A prerequisite for using the new release management features includes connecting at least one GitHub or GitLab repository to an AWS DevOps Agent Space.
First came vector databases, then RAG. Now, the next frontier in enterprise AI is taking shape: context layers that give autonomous agents a shared understanding of the business, a vision Databricks is advancing with Genie Ontology.
Currently in preview, Genie Ontology automatically extracts business context from enterprise data, dashboards, queries, pipelines, documents, and applications and organizes it into a living graph that AI agents can use to understand how an organization operates.
Showcased at the company’s Data + AI Summit, Genie Ontology uses a ranking system inspired by Google’s PageRank to identify the most authoritative business definitions within an organization.
Rather than treating all sources equally, it weighs factors including who created the information, how widely it is used, its links to certified datasets and assets, and how recently it was updated before determining which answer an AI agent should rely on, Databricks CEO Ali Ghodsi said during his keynote late on Tuesday while explaining the new offering.
Organizations can also upload their own business definitions or ontologies to Genie Ontology via Databricks’ existing Unity Catalog Semantics platform, Ghodsi added.
Ontology promises consistency, but readiness remains a hurdle
For CIOs, a unified context layer, such as Genie Ontology, will materially improve consistency, trust, and governance for enterprise AI deployments, according to analysts.
“One definition feeding every agent means you stop getting three different answers to the same question,” said Michael Leone, principal analyst at Moor Insights and Strategy.
“Older approaches, such as RAG and vector search, just pull back whatever looks similar to your question, and they don’t actually understand your business. An ontology gives the agent the meaning a catalog can’t, what your terms mean, and which source to trust,” Leone added.
That improvement in consistency, according to Ashish Chaturvedi, leader of executive research at HFS Research, could also improve trust, which remains one of the most critical barriers to AI adoption.
“The single biggest barrier to enterprise AI adoption is that decision-makers don’t trust AI outputs enough to act on them without checking. An ontology that grounds answers in governed business definitions, with lineage back to source, directly attacks that trust deficit,” Chaturvedi said.
Alternatively, Leone was more cautious about the trust argument: “It’s a promising idea, but it still has to prove itself before I’d lean on it for anything that matters.”
Echoing Leone, HyperFRAME Research’s practice leader of AI stack Stephanie Walter pointed out that ontologies have a missing link, and that is verification: “Ontologies can improve context, but they do not guarantee the answer is correct. An agent can still pull incomplete data, apply the wrong logic, skip rows, misunderstand a workflow, or take the wrong action.”
That verification gap becomes even more critical, according to Leone, because most enterprises don’t have the data and governance readiness required to implement an ontology layer for AI deployments: “If your data and governance aren’t already in order, this just speeds up your existing mess.”
Seconding Leone, Walter pointed out that an ontology cannot fix messy definitions, poor lineage, weak ownership, or fragmented permissions on its own.
Additionally, the analyst pointed out that the hard part for CIOs is not creating an ontology once but keeping it accurate as the business changes: “Enterprises will need clear data ownership, metric ownership, domain expertise, governance processes, and a way to resolve conflicting definitions.”
“Otherwise, the ontology becomes another stale metadata project with a more sophisticated name,” Walter added.
A growing risk of CIO confusion
Beyond data and governance readiness, CIOs also face a growing risk of confusion in the wake of several technology vendors pursuing approaches, similar to Genie Ontology, to ground enterprise AI in a business context, according to analysts.
Over the past year, Snowflake, Microsoft, and others have introduced some form of ontology, semantic, and context-layer offerings, but the problem is in how these offerings are named, Leone said.
“Everyone slapped a different name on basically the same idea. It slows people down as it creates confusion,” Leone noted.
That confusion could also backfire on Databricks and other vendors, according to Bhupendra Chopra, cofounder and CRO of IT consulting firm Kanerika: “While the marketing has converged around context-building offerings, most enterprises will choose the platform where their data already resides.”
HFS Research’s Chaturvedi doubled down on that view, saying CIOs should resist evaluating ontology offerings in isolation and asked them to stick to the mantra of context layer follows data gravity: “If your data lives in Databricks, Genie Ontology is your path. If it’s in Snowflake, Horizon Context is. If you’re a Microsoft shop, the IQ family is.”
Additionally, Chaturvedi urged CIOs to look beyond functionality and assess how open and portable these offerings are, particularly in multi-platform environments where business definitions may need to move across data lakehouses, analytics tools, and AI platforms.
This is where Chaturvedi sees Snowflake differentiating itself from rivals, with its focus on open semantic interoperability aimed at reducing the risk of semantic lock-in as enterprises evolve their data and analytics stacks.
The battle for the AI control plane
Snowflake’s efforts to differentiate itself, though, analysts pointed out, at least for CIOs, draw attention to a larger race among vendors, including Databricks, to become the control plane for enterprise AI.
While Snowflake is attempting to position itself as an AI control layer through a combination of Snowflake Intelligence, Horizon Catalog, and its push for open semantic interoperability, Microsoft is embedding business context and governance across its Copilot, Fabric, and broader AI stack through offerings such as Work IQ, Fabric IQ, and Foundry IQ, Chaturvedi said.
Databricks’ Genie Ontology, too, is part of a similar strategy, Chaturvedi pointed out, urging CIOs to view the offering in the context of the company’s wider effort to position its lakehouse platform as the foundation on which enterprise AI agents are built, governed, and eventually deployed.
“It’s absolutely a control-plane play. When you connect the dots across everything Databricks has announced at this summit, including LTAP, OpenSharing, and Genie Ontology, you see a single place where enterprise data, governance, business semantics, and agent execution all converge,” Chaturvedi added.
Further, the analyst noted that the control-plane strategy reflects Ghodsi’s broader vision that data platforms could evolve into what the CEO describes as an “agentic system of record” — an authoritative source that AI agents read from, reason over, and act through.
The concept mirrors earlier platform shifts, Chaturvedi said, where ERP systems became the system of record for business transactions and data warehouses became the system of record for analytics.
The next battle, the analyst said, is over which platform becomes the system of record for enterprise AI agents.
Moor Insights and Strategy’s Leone agreed that data platforms are well-positioned to compete for that role because they already own the data, governance controls, lineage, and permissions that agents require to operate safely at scale.
Still, analysts cautioned that context alone will not determine which vendor comes out on top.
“The next enterprise AI battleground is not just context. It is verifiable execution,” Walter said.
Z.ai has released GLM-5.2, an MIT-licensed open-source AI model designed for long-running software engineering tasks, as the Chinese company seeks to challenge proprietary coding models on cost and performance.
The company said GLM-5.2 ranked just behind Anthropic’s Claude Opus 4.8 on FrontierSWE, a long-horizon coding benchmark, trailing it by 1%. Z.ai said the model also edged out OpenAI’s GPT-5.5 by 1%.
Z.ai said GLM-5.2 supports a one million-token context window with up to 131,072 output tokens, positioning it for agentic coding workflows that require reasoning across large codebases.
The company is also making an efficiency argument. It said GLM-5.2 uses a technique called IndexShare, which reduces per-token compute by 2.9 times at a one million-token context length. It also said changes to the model’s multi-token prediction layer increased the acceptance length for speculative decoding by up to 20%.
The changes are aimed at a practical problem for developers: long-context coding agents can be expensive to run when they are asked to work across large repositories.
Enterprise appeal
GLM-5.2’s clearest appeal is that it pairs stronger coding capabilities with the cost advantages of an open-source model. But capability alone will not be enough to make it a credible alternative.
“Western enterprises will want independent benchmark validation, successful deployments at global enterprises, strong security and governance controls, and long-term support commitments,” said Pareekh Jain, CEO of Pareekh Consulting.
Jain said the fastest route to enterprise credibility would be hosting by a major cloud provider like AWS. That would allow customers to use the model under standard enterprise terms, with service-level commitments and compliance certifications.
Tulika Sheel, senior VP at Kadence International, said GLM-5.2 would also need to prove it can operate as a stable enterprise product.
“Demonstrated success in real-world deployments and transparent governance will be just as important as benchmark scores,” Sheel said.
The performance and cost claims will also need to hold up against established models.
“Enterprise leaders generally consider two major factors when evaluating new models,” said Lian Jye Su, chief analyst at Omdia. “First, they look at overall performance against competitors, where GLM-5.2 performs well in long-horizon agentic coding and software engineering. Second, they look at the cost of adoption. As an open-source model, GLM-5.2 has clear cost advantages.”
Su said the model could appeal to engineering teams under pressure to control AI costs. It may also attract open-source advocates and companies with significant operations in Asia-Pacific.
But the claims still need wider validation, particularly around hallucination control and coherence during extended tasks. These are critical issues for enterprises considering AI coding agents, which may need to work across large codebases and multi-step software engineering workflows.
Jain said the one million-token context window could be useful for large codebase analysis. It could also help with legacy modernization projects and complex engineering documentation.
He said long-context capability may also help with audit logs or legal contracts, where splitting material into smaller chunks can create errors across document boundaries. But for everyday coding tasks, effective retrieval systems may matter more than very large context windows, making some of the benefits more limited in practice.
Governance risks
The governance question depends largely on where the model runs.
Sheel said enterprises should evaluate GLM-5.2 as they would any strategic technology partner, rather than as a standalone model. That means looking at where data is stored and whether the model can be used in environments customers control.
That deployment choice is central to the risk calculation, according to Jain. Because GLM-5.2 is available under an MIT license, companies can download the weights and run them on their own infrastructure, reducing the need to send sensitive data to Z.ai.
“The risk flips completely if you use Z.ai’s hosted API instead,” Jain said.
He said Chinese national security rules could require domestic companies to cooperate with government requests, making hosted use difficult for regulated industries or workloads involving sensitive data.
Su said the issue is not limited to Chinese vendors. Recent restrictions affecting access to some Anthropic models have also highlighted the risk that enterprises may have limited control over the availability of AI services from foreign providers.
“Selecting solutions from American and Chinese AI vendors does expose non-US Western enterprises to additional risk of having zero control over the availability and uptime of these models,” Su said.
Most generative AI tools know less about R than languages like JavaScript and Python, thanks to how much training data is available for each. However, with a little extra setup, you can give a large language model (LLM) the knowledge it needs to improve its R skills.
Here are 10 ways to help generative AI write R code like a pro.
Use a coding agent
AI coding agents have more power, flexibility, and coding-focused tools than general-purpose chatbots.
Anthropic’s Claude Code and OpenAI’s Codex agents have versions that run in a terminal, IDE extensions, desktop and mobile apps, and other integrations.
R users may also be interested in Posit’s Posit Assistant, which is designed for data analysis in both R and Python. It needs less setup for R than general-purpose coding agents, and it has more built-in knowledge about data science, R package development, and Shiny apps. Plus, it can read objects in your R and Python environments by default, which can be useful in some situations (although perhaps not if you’re working with sensitive data). There are versions of Posit Assistant for RStudio, the Positron IDE, and the terminal. Setup info is here.
Note: Posit Assistant is not the same as the older Positron Assistant that was demo’d at last year’s posit::conf(). The older assistant will eventually be superceded by Posit Assistant. Posit Assistant comes pre-installed with RStudio but not pre-activated, so you don’t need to use it unless you want to.
Google’s original entry in this space, Gemini CLI, is being retired in favor of a new “Antigravity CLI” starting June 18.
There are other IDE platforms with built-in agents, including Cursor and Windsurf, and terminal + subscription coding agents such as Warp, which was open-sourced in April. However, I won’t be covering those here.
You may be limited at work by what your employer allows you to use, but you can still experiment on your own with public data — and then lobby for a new agent if a different one better meets your needs. Whatever you choose, though, moving to one of these from a web-based chatbot should produce better code.
“The shift from chatbot to agent is the most important change in how people use AI since ChatGPT launched,” says Ethan Mollick, co-director of the Wharton School’s Generative AI Labs at the University of Pennsylvania.
Set up CLAUDE.md, AGENTS.md, or GEMINI.md knowledge files
All the major coding agents look for knowledge files to load each time you start a session, and you can easily edit those files. The files can include things like your proficiency in various languages and how you like to document projects. For example, I tell my LLMs that I’d like a README.md in every project with info on how to use the project and technical info on how the project was coded.
Most coding tools let you have both an overarching main file that’s loaded into every session, and an additional file per project.
If you’re adding Claude or Codex to an existing code base, the /init slash command will create one of those .md project files after scanning and analyzing the code. You can also ask an LLM to interview you to create or add to one of those files.
Claude Code looks for a user-level main CLAUDE.md file at ~/.claude/CLAUDE.md and then a project-level file at ./CLAUDE.md or ./.claude/CLAUDE.md. The /memory slash command shows where those files are located. Codex uses AGENTS.md files. Antigravity docs say it looks for a main GEMINI.md file plus GEMINI.md and/or AGENTS.md files in your working directory.
Positron Assistant is set up to read AGENT.md, AGENTS.md, POSITRON.md, CLAUDE.md, GEMINI.md, and LLMS.txt in a workspace root directory, according to the docs. See the Positron docs for more on custom instructions.
Use agent skills
Agent skills can turn an LLM with questionable R knowledge into an expert that understand how you want it to write code. You can develop your own skills, work with your LLM to create skills, or download skills written by others. Claude even has a skill to help you build skills. This is one of the best ways to stop having to repeat the same instructions over and over. Instead, the LLM will “remember” what’s in your skills files by loading them when they’re needed.
What’s the difference between the knowledge .md files mentioned above and a skill? I like to think of CLAUDE.md or AGENTS.md files as important background info that’s always available, while skills are more specific instructions that are useful at certain times. Or, as Claude Opus 4.7 put it: “Skills are for triggered workflows (‘when user asks X, do Y’). A standing rule that applies to every project isn’t trigger-based; it’s a directive I should always follow.” Standing rules should go in CLAUDE.md.
“Create a skill when you keep pasting the same instructions, checklist, or multi-step procedure into chat, or when a section of CLAUDE.md has grown into a procedure rather than a fact,” according to Anthropic’s Claude Code docs. “Unlike CLAUDE.md content, a skill’s body loads only when it’s used, so long reference material costs almost nothing until you need it.” Only skill descriptions are loaded at the start of each session, so the LLM knows what skills are available.
Anthropic originally created skills for Claude in October 2025 and then published the concept as an open standard a couple of months later. Most coding agents now use them.
Anthropic has an easy-to-folllow guide to creating custom skills here if you want to try your hand at building your own.
Posit Assistant comes with several R-related skills built in and allows users to add more. You’ll find them here.
If you’re not using Posit Assistant, you can add Posit-developed skills to another coding agent. Posit published a GitHub repository with skills for creating R packages, Shiny apps, and Quarto documents; for creating and resolving GitHub pull requests; for open-source R and Python package releases; for code reviews (R, Python, JavaScript/TypeScript, SQL); and for creating architectural documentation for a codebase. Browse them all here.
Read and edit the skills you download
Skills are just a folder with one or more markdown text files that have a structured YAML header. That folder can include optional resources and scripts, too. Skill instruction files are easy to read and edit, so you can make sure they do what you want. Tweak them as desired.
For example, Claude helped me write my own customized R skill. Claude leans toward tidyverse packages, but there are other packages I like a lot, too, such data.table. I made sure the R skill knows my package preferences, and under what circumstances I prefer each.
If one of your preferred procedures changes, remember to update the associated skills. Or, ask an LLM to update it for you. Keeping skills up to date will make your coding agent more useful.
Keep your CLAUDE.md or AGENTS.md files updated, too. Maybe you started off with a CLAUDE.md file that said you’re an experienced Python programmer who is just learning R. Three months from now, you might want to update your R skill level. Or, perhaps you told an AGENTS.md file that you like thoroughly documented code, but now you’d prefer a lighter touch. You may want to have your coding agent go over those files with you from time to time and ask you about the main points and whether they need updating.
Use the btw R package and its MCP server
It’s frustrating when an LLM writes code based on an ancient R package version in its training data, or when it doesn’t know about a relatively recent package at all. btw solves this problem by letting your coding agent access info about all the R packages installed on your system. That means it can write code based on your specific R environment. Plus, btw lets an LLM access variables in your current R environment via a Model Context Protocol (MCP) server.
MCP servers are a standardized way for LLMs to access external data — in this case, your running R session (external doesn’t have to mean cloud). Like skills, MCP was created by Anthropic as an open standard and has since been adopted by most major AI platforms. The btw R package includes an MCP server, which you can install for Claude Code by running the following code in a terminal window (not R console).
claude mcp add -s "user" r-btw -- Rscript -e "btw::btw_mcp_server()"
btw comes with a lot of tools. It’s not a great idea to overload your LLM with tools it may never use. If you just want to register btw tools for accessing your R session and looking up package documentation, you can run a command like this instead:
To connect Claude Code to your open R session, you also need to run btw::btw_mcp_session()in every new R session. (I sometimes forget this part until I’m puzzled why Claude can’t read my R variables or even see what packages I have installed.)
You can see a demo of btw in this Posit video that compares Claude Code and Posit Assistant.
The btw R package lets Claude Code and other agents read objects in your R session.
Foundry
You don’t need to do this setup for Posit Assistant, since tools for accessing your R session and variables are built in.
Use plan mode for your projects
I cannot stress this enough. Just as humans benefit from having a plan before starting to implement a project, LLMs benefit from working through a plan before beginning to generate code. Plus, it can be useful at times to “brainstorm” with an LLM about structures and features, ask it for alternatives, or even have another LLM review a plan before implementing it.
Anthropic advises starting with plan mode. “Letting Claude jump straight to coding can produce code that solves the wrong problem. Use plan mode to separate exploration from execution,” they wrote in a best practices doc.
Claude, Codex, Gemini, and Posit Assistant all have a plan mode in their CLI versions that can be activated with the /plan slash command.
Foundry
When in plan mode activated with /plan, Claude will often ask questions before coming up with its plan.
Foundry
Make sure your coding agent learns from its mistakes
This is one of the best tips I read first from Joe Amditis, associate director of operations at the Center for Cooperative Media at Montclair State University: If your coding agent makes a mistake and you work together to fix it, make sure to save that memory so it doesn’t make the same error again.
Your agent may have an auto memory system that’s supposed to do some of this (I’ve used Claude Code’s), but you can instruct any coding agent to keep a separate lessons learned file for each project, too, or ask it what’s the best way to ensure it doesn’t make the same error again. This isn’t a guarantee, any more than you can be assured an LLM will follow all the rules in a CLAUDE.md or AGENTS.md file or all the steps in a skill. But it has definitely cut down on my agents making the same errors over and over.
Have your agent write tests and do code reviews
Tests and code reviews done by a coding agent aren’t a substitute for a human checking that software works. Review an LLM’s results yourself any time a task is important! However, agent-generated tests are still a good way to head off some problems and cut down the time you spend as your LLM’s debugging partner. If you don’t know where to start to help your agent know how to test and review code, see Posit’s testing-r-packages and critical-code-reviewer skills. Your agent may also have built-in code review skills, such as Claude Code’s /code-review slash command.
Code review skills are available from many sources. For example, Sentry has a code review skill in its repository. Aimed specifically at its project’s needs, it can be a useful sample for similar skills. And superpowers is a popular set of general-purpose programming skills that’s billed as “a complete software development methodology for your coding agents, built on top of a set of composable skills and some initial instructions that make sure your agent uses them.” I don’t use superpowers, but a lot of other people clearly do given its more than 227,000 GitHub stars and 20,000 forks.
Another tip: Several experts suggest using a different LLM — maybe even from a different provider — to conduct a code review, since each model has its own strengths and weaknesses.
Don’t forget general prompting good habits
Whatever programming language you’re using, being clear will improve your outputs. Keep your requests targeted, and don’t expect the LLM to read your mind.
“Codex handles complex work better when you break it into smaller, focused steps,” OpenAI says in its developer docs. “Smaller tasks are easier for Codex to test and for you to review. If you’re not sure how to split a task up, ask Codex to propose a plan.”
“Take time to make your prompts as relevant as possible, just as you would when helping a new teammate scope a task,” Google advises in its Five Best Practices for Using AI Coding Assistants. “Consider what details you need to share for a person to succeed, and provide all those details to your AI tool.”
And, don’t load up your context window to the LLM’s published limit. Performance often degrades as you get close to the maximum token limit.
Take advantage of open LLMs, particularly if you have budget and token limits
Open-weight models — especially ones small enough to run on a desktop computer — may never rival frontier LLMs like Claude, GPT, or Gemini. But for a lot of R coding, they don’t need to.
To see how well an LLM can write R code, it should have the same kind of harness that Claude Code, Codex, or Posit Assistant gives larger LLMs. “The harness is the product,” argues Mallory Mejias at Sidecar, an AI education company. “The model is the engine inside it — important, but increasingly interchangeable.” I wouldn’t go that far, since I still find the LLM to be a critical piece of this equation, and models differ. But the same LLM will perform differently depending on the tools and context it has.
Posit recently added Google’s open-source Gemma 4 26B to Assistant’s existing options of larger, closed-source LLMs. “Up until this point, models of this size — small enough to run comfortably on high-end consumer laptops — were on our radar but not yet capable enough to drive an agent harness like Posit Assistant,” Posit senior software engineer Simon Couch wrote on the Posit blog. “This has changed in the last few months with releases like Gemma 4.” However, to use it in Posit Assistant in RStudio, you still need to run it through a Posit AI subscription, not locally. It uses 1/10 the budget that the same session with Claude Sonnet would consume.
Several projects can use Claude Code to run local LLMs. Ollama, open-source software for running LLMs locally, does this with the terminal command ollama launch claude --model , such as:
ollama launch claude --model gemma4:26b
The makers of Unsloth, an open-source framework for running and training models, say running local LLMs inside Claude Code can be very slow due to a cache invalidation issue. They say this can be fixed by adding "CLAUDE_CODE_ATTRIBUTION_HEADER" : "0" to ~/.claude/settings.json under “env”.
Unsloth can also use Claude Code to run local models, but it’s somewhat more involved to install and set up than Ollama. See this Unsloth tutorial.
Open-source coding agent Open Code runs LLMs from OpenAI, Anthropic, Google, Kimi, Alibaba’s Qwen, and others. I haven’t warmed up to it yet compared with commercially backed CLI tools I’ve tried, but it has 174,000 GitHub stars so clearly a lot of fans.
AI consultant Thomas Wiegold, who switched from Claude to Open Code, said “OpenCode covers everything I need for my daily workflow. It’s fast, the provider flexibility is genuinely useful rather than theoretical, and the TUI is better for extended sessions…. That said, I’m not going to pretend it’s all smooth sailing.” He noted some stability issues and a remote code execution vulnerability earlier this year.
Large language models remain imperfect and unpredictable tools, but they’re improving rapidly — as are the harnesses around them. Even frontier LLMs in commercial coding agents can ignore instructions at times and otherwise behave in unpleasantly surprising ways. However, you’ll vastly improve your chances of generating quality code if you use coding agents, take time to set them up with quality instructions, and remember good prompting techniques. Good luck!
—
Coding agent info
Claude Code – Anthropic’s coding agent is available in the terminal and as an IDE extension, a desktop app, mobile apps, Slack app, and a cloud version that can work directly in your repos on GitHub. Arguably the first breakthrough coding agent, it now includes an elegant remote-control option where you can start a session on your desktop and then continue it on a phone or tablet. While designed for Claude LLMs, you can use it to run local LLMs via tools like Ollama or Unsloth Studio. When using Claude models, it tends to offer less usage than other vendors’ options. Anthropic has posted the terminal version’s code on GitHub, with usage governed by Anthropic’s commercial terms of service. You can use Claude Code via API pay per use or as part of a Claude subscription.
Codex – OpenAI’s answer to Claude Code is available via terminal, app, IDE extension, or cloud, with integrations for GitHub, Slack, and Linear. The CLI tool is open source under an Apache license, available on GitHub, and works via API pay per use or as part of a ChatGPT subscription.
Posit Assistant – The Posit (formerly RStudio) coding agent is designed for data work in R and Python, although Posit senior software engineer Simon Couch told me it would do fine for programming work for other uses and in other languages. It is available for the RStudio IDE (via a Posit AI subscription in RStudio), Positron IDE, and as a stand-alone CLI terminal app, although the CLI tool currently doesn’t feel as full-featured as the IDE integrations (that may change). As of this writing, you can also use API keys from Anthropic, OpenAI, and Snowflake Cortex and a GitHub Copilot account in Positron. Posit Assistant is being updated quite frequenty, Couch told me. If you tested it a month or two ago, it has more capabilities now.
Antigravity CLI – Google’s terminal-based tool will be replacing the Gemini CLI for unpaid and Google One users this month. There’s also an Antigravity IDE, SDK, and platform for orchestrating multiple agents. One advantage of Antigravity: Google offers a free plan with access to Gemini 3.5 Flash, Gemini 3.1 Pro, Gemini 3 Flash, Claude Sonnet 4.6, Claude Opus 4.6, and gpt-oss-120b, and what it describes as “generous” but undefined weekly rate limits based on “the degree we have capacity.”
Frontend reliability is often discussed in terms of outages. Teams prepare for failed API calls, downtime and visible crashes because those failures are easy to recognize and measure. However, in many modern applications, the bigger challenge is not complete failure but latency. Systems rarely go fully offline. Instead, they become slow enough that users lose confidence in the interface long before anything technically breaks.
Most frontend engineers have experienced this in production. A page eventually loads, but only after several seconds of waiting. A save action succeeds in the backend, yet the interface remains unchanged long enough that the user clicks the button again. A dashboard renders immediately, but the critical data appears so late that the application feels unstable. In practice, users rarely distinguish between “slow” and “broken.” If an interaction feels uncertain or delayed, trust drops quickly.
As frontend systems become increasingly dependent on distributed cloud infrastructure, latency becomes a normal operating condition rather than an occasional exception. APIs may depend on multiple downstream services, serverless systems may introduce startup delays and state updates may propagate asynchronously across regions or caches. Frontend reliability therefore can no longer be defined only by uptime. It also depends on how clearly the interface behaves while waiting on slow cloud dependencies.
In many production systems, the application remains technically available while still feeling unreliable to users. An API request that takes ten seconds may still return successfully. A delayed state update may eventually synchronize correctly. A dashboard may fully render after several refresh cycles. From a monitoring perspective, these systems appear healthy. From a user perspective, however, the experience feels inconsistent and unpredictable.
What makes this difficult is that many frontend applications are still designed around ideal conditions. Interfaces often assume fast responses, immediate consistency and stable network behavior. Cloud environments rarely behave with that level of predictability. Distributed systems naturally introduce latency, asynchronous updates and intermittent delays, even when everything is technically functioning correctly.
This changes how frontend engineers need to think about resilience. Modern interfaces are no longer designed only for success and failure. They also need to handle slow success, delayed feedback and partial availability in ways that remain understandable to users.
Slow APIs and the user experience problem
One of the most common latency issues frontend teams encounter is the slow API response. Technically, the request succeeds, but the delay changes how users interpret the application. A user waiting several seconds for a response rarely thinks about infrastructure behavior or distributed systems. They assume the interface is frozen, unresponsive or broken.
This becomes especially noticeable in cloud-connected systems where response times vary depending on caching layers, regional routing, serverless initialization or downstream dependencies. Frontend applications designed around consistently fast responses often struggle in these conditions because they treat latency as exceptional instead of expected.
Many applications still rely on generic loading spinners that provide little context beyond “something is happening.” While spinners technically indicate activity, they also communicate uncertainty. Users do not know whether the system is progressing, stalled or close to failure. As waiting time increases, frustration grows quickly.
More effective interfaces treat loading as part of the user experience rather than a temporary placeholder. Skeleton screens, layout-preserving placeholders and contextual loading feedback provide users with a clearer understanding of what is happening. Even relatively small decisions can make a noticeable difference. For example, users generally tolerate a dashboard chart loading later far more than they tolerate waiting several seconds before the navigation menu appears. Similarly, an e-commerce page that progressively loads recommendations often feels faster than one that blocks the entire interface until every service responds.
These patterns do not reduce actual latency, but they significantly improve perceived responsiveness. When users understand that the system is actively processing their request, they are far more tolerant of delays.
Delayed state updates and perceived instability
Another common issue in cloud-based systems is delayed state synchronization. A user submits an action successfully, but the interface does not immediately reflect the result. Even if the backend processes the request correctly, the delay creates uncertainty around whether the action worked at all.
This behavior is increasingly common in distributed architectures where writes may propagate asynchronously across services, regions or caches. Frontend applications that assume immediate consistency often expose these delays directly to users, leading to repeated clicks, duplicate submissions and confusion around application state.
In many cases, the real problem is not the delay itself but the absence of clear feedback. Users are generally willing to wait if the interface acknowledges that progress is occurring. Without feedback, even short delays begin to feel unreliable.
Frontend systems can reduce this uncertainty by designing around transitional states more intentionally. Pending confirmations, temporary UI updates and clearer progress indicators help maintain confidence while backend systems synchronize. Users care less about exact infrastructure timing than about whether the interface feels responsive and understandable throughout the interaction.
Progressive rendering and partial availability
Traditional frontend rendering strategies often wait for all required data before displaying meaningful content. While this simplifies state management, it also magnifies perceived latency by forcing users to stare at incomplete or empty screens.
Modern cloud systems rarely deliver all information simultaneously. Some requests complete quickly while others depend on slower downstream services. Treating the entire interface as blocked until every dependency responds unnecessarily increases the feeling of slowness.
Progressive rendering offers a more resilient alternative. Instead of waiting for the entire page, the application renders available content immediately while secondary information loads incrementally. A profile page may display account details before loading recommendations. A dashboard may render navigation and layout structure first while analytics populate later. This creates a sense of continuous progress rather than complete inactivity.
What makes this approach effective is that users tolerate delayed secondary content far better than delayed primary interaction. Even when total loading time remains unchanged, the interface feels significantly more stable because progress is visible.
Progressive rendering also changes how frontend teams think about dependency importance. Not every cloud service needs to block the entire user experience. Separating critical interaction paths from secondary content creates systems that remain usable even under imperfect network conditions.
Designing recovery, not just error messages
Latency-related problems are often made worse by weak recovery patterns. Many applications either wait indefinitely or fail abruptly with vague messaging such as “Something went wrong.” Neither approach creates confidence for users who are already uncertain about system behavior.
Frontend resilience improves significantly when interfaces guide users through delays and recovery intentionally. Instead of displaying generic failures immediately, applications can acknowledge that an operation is taking longer than expected while still preserving user progress. Retry actions, recoverable workflows and state preservation help users continue without restarting tasks entirely.
This becomes especially important in forms and transactional flows. Losing user input because of a temporary timeout often damages trust more than the delay itself. In practice, people are usually willing to retry an action. They are far less willing to repeat work they already completed once.
These recovery patterns are not simply UX enhancements. They are architectural decisions that recognize cloud latency as a normal operating condition rather than an edge case.
Designing for latency is designing for reality
As frontend systems become more dependent on distributed cloud infrastructure, latency becomes unavoidable. The most reliable interfaces are not necessarily the ones with the fastest response times. They are the ones that communicate clearly, preserve user confidence and remain usable during delays.
Frontend teams spend enormous effort optimizing rendering performance while often underestimating the impact of latency behavior on user trust. In many applications, the difference between a reliable experience and a frustrating one is not milliseconds of rendering speed but how clearly the interface handles waiting.
Frontend engineers do not need to become cloud infrastructure specialists to design for these realities. However, understanding that cloud latency is a normal part of modern application behavior fundamentally changes how interfaces should be built. Designing for latency is ultimately not about preparing for rare outages. It is about designing for the way modern systems behave every day.
This article is published as part of the Foundry Expert Contributor Network. Want to join?
I was blessed with a terrific high school English teacher. Ms. Jewel was funny, kind, interesting, and tough on us. I can still spell “ecstasy” on the first try because of her. One of the more memorable lessons she taught was a “Hemingway and Fitzgerald” module.
I loved the short stories of both, but Hemingway’s work always stuck out for me. It’s cliché to say that Hemingway was terse, but we only say it because it is true. He could pack more into a page than most writers. He didn’t waste a syllable.
Software developers are soon going to have to take a lesson from Hemingway.
It’s not hard to be concise in code. You have to be, by design. The compiler won’t put up with any throat-clearing and jibber-jabber. You can’t meander. You have to use a very strict set of words and symbols, and you have to use them in a defined way.
Let me explain. Claude Code, Codex, Copilot, and the rest all love to be “spoken” to in Markdown. We used to define our code with unit tests and specifications written for humans. Now, it’s all about the spec. And the spec needs to be both complete and concise.
It needs to be complete in the sense that if you leave something out or forget to define something, the agent will very likely fill in the gaps for you. Forget a feature or requirement, and the agent will go off confidently and almost certainly in the wrong direction.
At the same time, you need to be concise. Because if you are too effusive, you may give the agent ideas that you don’t want it to have. If you write like Fitzgerald — lush and expansive — the agent will be off and running in a direction you can’t be sure about.
Our compilers will stop cold if we aren’t precise and concise. Our agents? They will proceed with confidence, diligently producing a result that looks great but isn’t what we want.
So we need to learn to write like Hemingway and pack as much meaning into as few words as possible. Or, as Paul Graham said:
Foundry
Let’s be clear
For years, we’ve been writing semi-vague Jira tickets and expecting our fellow humans to fill in the gaps and “get the gist” of what we were trying to do. We don’t have that luxury anymore. Developers who aren’t able to move on from “Jira-speak” to “Agent-speak” are going to struggle. If we don’t follow Graham’s advice in writing those specs, who knows what we’ll get.
Maybe someday agents will know the ins and outs of our business well enough to “know what we mean,” but they can’t today. The time we used to spend coding now needs to be spent perfecting our new craft of writing precise specifications for our agents to execute.
Every listicle ever written on “How to be a Great Developer” says you need to be a great communicator — but that was communication with other humans.
Ms. Jewel always taught us that our writing is only as clear as our thinking. Our compilers forced us to write clearly. Our coding agents won’t do that. I’m sure there are many developers out there now who wish they had listened more closely to their high school English teacher.
When SpaceX on Tuesday officially announced its plan to purchase AI coding startup Cursor for $60 billion in stock, as it had predicted it would do in April, it presented CIOs and developers with a little good news, a little bad news and a massive pile of uncertainty.
The details of the proposed acquisition were virtually identical to the terms announced in April, even retaining the $10 billion consolation prize for Cursor should SpaceX back out of the deal.
But for CIOs and developers, the increasing probability of the deal happening is forcing them to make long-term decisions without many long-term answers about what is likely to happen to Cursor, which says its coding agents are used by 64% of Fortune 500 companies.
But whether the deal is good news for Cursor’s customers, or even those of its rivals, is an open question.
Arnal Dayaratna, research VP for software development at IDC, is firmly in the good news camp. He argued that the main element holding back the company, which he estimated brings in about $2 billion in annual revenue, was access to GPUs. And, he said, SpaceX’s xAI has the ability to resolve that problem.
It’s all about the GPUs
“The implication is that Cursor can get better because it will get better access to more compute, in the form of GPUs. That was what Cursor was struggling to obtain,” Dayaratna said, adding that Cursor joins both Anthropic and Google in aligning with xAI.
“It is bad news for Anthropic,” he said, pointing out, “[Elon] Musk figured out that GPUs were the limiters, the bottleneck. Not human talent: compute. And it’s not only about GPUs. It’s about the data centers,” as well as the mechanisms needed to support data centers, including electricity access, cooling apparatus, and zoning rights.
“Zoning rights are very difficult to obtain in the United States, and Elon has been able to leverage his political capital” to obtain those rights, Dayaratna said.
Dayaratna also commented on the highly unusual tactic of a company pre-announcing an acquisition and then announcing it “officially” two months later. The reason, he suggested, is that Musk didn’t want the acquisition to delay the SpaceX IPO, but he did want potential investors to know about it. “It gave the IPO more legs, even though it was not formally a part of the IPO. He wanted to socialize it before it happened,” he said.
Jason Andersen, principal analyst at Moor Insights & Strategy, took a far more cautious approach and predicted, “enterprise customers will be very concerned.”
Time for CIO due diligence
“xAI’s models and treatment of guardrails are very different than what Cursor has stood for,” Andersen said, and the key issue involves model choice. “Will Cursor be able to point at models other than Grok? If that is the case, it could go towards helping customers be OK with things for a while,” he said.
But Andersen stressed the words “for a while.” He argued that Cursor rivals have gotten more sophisticated, which could give enterprise CIOs more alternatives.
“The tooling options from the classic enterprise vendors have gotten really good, and also have a number of features that enable better governance and teaming. For example, Kiro from AWS is already a worthy competitor to Cursor, but there have also been major improvements from Google and Microsoft this year,” Andersen said. “I’d venture to say that Cursor was already facing a substantial competitive challenge in the enterprise, especially as the vibe coding movement lost some steam towards agents that enable so much more developer capability.”
Andersen added, “A lot of SpaceX’s valuation is pinned to xAI and there wasn’t enough IP there for it to be long-term competitive with Anthropic or OpenAI without rapidly injecting new technology.”
Shashi Bellamkonda, principal research director at Info-Tech Research Group, said the current period of due diligence gives CIOs opportunities to ask difficult questions.
“I do believe that enterprise customers will start to ask harder questions now, especially if more of the processing starts moving through Grok or xAI infrastructure,” Bellamkonda said, but he stressed that he does see a SpaceX deal helping Cursor.
“Cursor is already carrying a lot of LLM cost and if SpaceX and xAI can give it access to more compute and a faster, improved Grok model, customers could eventually get better performance at a lower cost. Grok is getting faster and more accurate, and under SpaceX there may be more enterprise appetite for xAI than xAI had on its own,” Bellamkonda said.
Questions about data privacy
But Bellamkonda also pointed to the trust issue, specifically asking whether Cursor would be allowed to continue its zero-data-retention policy under the new ownership.
“Enterprise users with sensitive codebases will want to understand exactly where their data is going, who has access to it, and whether any prompts, code, metadata, or embeddings are touching SpaceX or xAI systems,” Bellamkonda said. “Zero data retention is only valuable if customers believe the controls still apply across the new infrastructure. If they can preserve Cursor’s privacy posture while using xAI and SpaceX compute to improve the product, this could be a very strong outcome for customers. If the data governance is unclear, enterprise buyers will hesitate.”
Justin Greis, CEO of consulting firm Acceligence, echoed Bellamkonda’s concerns.
“For many enterprise customers, Cursor’s zero-data-retention policy was not simply a security feature. It was a foundational part of the procurement and approval process,” Greis said, pointing out that security teams, legal departments, compliance officers, and executive leadership all became more comfortable adopting AI-assisted development because they believed their source code, prompts, and proprietary intellectual property would not be retained, stored, or repurposed.
“Whenever ownership changes, customers naturally revisit those assumptions,” he said. “I would expect enterprise customers to immediately seek clarity on whether existing zero-data-retention commitments remain unchanged, whether those commitments continue to be contractually enforceable, and whether any future modifications could be introduced through changes to terms of service or product strategy.”
Reassessing platform risk
Another concern is whether the move will create greater vendor concentration, and whether that will increase risk exposure.
“Many organizations are already concerned about becoming overly dependent on a small number of AI providers. If Cursor becomes more tightly integrated into a broader SpaceX technology ecosystem, some enterprises may worry about reduced flexibility and fewer alternatives. I suspect this will be a continued question with SpaceX’s recent IPO and growth plans,” Greis said.
Additionally, he pointed out, “AI coding platforms are rapidly becoming part of critical software delivery infrastructure. When organizations standardize on these tools, they are making a long-term platform decision that influences developer productivity, software quality, security processes, and engineering workflows. A change in ownership naturally prompts a reassessment of platform risk, roadmap alignment, and long-term strategic direction.”
As well, Sanchit Vir Gogia, chief analyst at Greyhound Research, noted, “zero data retention survives only where it stays contractual, auditable, enforceable and fenced from affiliate use. The deeper point is what Cursor has become. It is no longer a developer convenience. It sits inside the act of software creation, close to the intellectual-property bloodstream of the enterprise. That is a control plane, and control planes change hands rarely and consequentially.”
Gogia added that even before an acquisition, Cursor was already weakening its data guarantee. “Even now the promise is layered. Cursor’s own disclosures show that standard Privacy Mode still permits some code data to be stored for product features, while only the stricter legacy setting retains nothing. Zero is the exception, not the default.”
As enterprises rush to build AI agents that can reason over business data and take action, Databricks argues that the long-standing practice of separating operational and analytical data systems is turning into a liability.
That separation, the cloud-based data warehouse provider says, is becoming increasingly strained as AI agents require simultaneous access to live operational data and historical context to make decisions and take actions in real time, unlike humans, who traditionally can work with data that is minutes or hours old.
At its annual Data + AI Summit, the data warehouse provider introduced Lake Transactional and Analytical Processing (LTAP), a new architecture designed to unify transactional and analytical data on a single storage layer.
Traditionally, OLTP databases are optimized for running day-to-day business operations such as order processing, payments, and inventory updates, while OLAP systems are designed for large-scale analytical queries and reporting.
As a result, enterprises often need to rely on ETL pipelines, data replication, and separate infrastructure to move information between the two environments.
LTAP, Databricks said, seeks to eliminate the reliance on ETL pipelines, replicated databases or separate data copies by storing data once in a shared lakehouse layer while allowing dedicated compute engines to handle transactional and analytical workloads independently.
This approach, the company argued, provides AI-driven agents and applications access to both live operational data and historical analytical context without requiring data movement or duplicate copies.
Developer simplicity in the agentic era
Analysts, too, agree with Databricks’ contention that AI agents place new demands on enterprise data architectures.
“Agents don’t behave like people, or even like the apps we built for people. They read for context, loop, try things, then write something back, thousands of times over in ways you can’t fully predict. At that volume, the constant bouncing between production and analytics systems starts becoming the bottleneck. The pressure to collapse that gap is real, and LTAP is one way to approach it,” said Michael Leone, principal analyst at Moor Insights and Strategy.
Bhupendra Chopra, cofounder and CRO at IT consulting firm Kanerika, pointed out that an autonomous agent’s data access pattern makes the traditional architectures brittle: “We’re seeing this directly with clients deploying multi-agent systems, the pipeline layer becomes the ceiling almost immediately as an agent runs hundreds of times per task.”
The analysts also pointed out that the ability to collapse the gap between OLAP and OLTP is likely to help developers design more robust AI agents or applications that enterprises are currently targeting to deploy.
“The most interesting workflow or application patterns are real-time, context-aware applications that combine transactions, analytics, and AI in one flow,” said Stephanie Walter, practice leader of AI stack at HyperFRAME Research.
“Examples include AI agents that update customer workflows while seeing historical account context and fraud systems that act on live transactions and long-term behavioral patterns,” Walter added.
Designing such applications today, however, according to Leone, would require developers to pull together data from transactional systems, data warehouses, vector databases, and other sources through custom integrations, creating significant engineering complexity and maintenance overhead.
Operational simplicity and governance gains for CIOs
For CIOs, LTAP’s ability to reduce that engineering complexity, according to Ashish Chaturvedi, leader of executive research at HFS Research, will result in operational simplicity as well as cost savings.
“Most prominent advantage would be fewer data pipelines and everything that cascades from eliminating them. Most enterprises don’t realize how much of their data engineering budget is pure plumbing maintenance,” Chaturvedi said.
Kanerika’s Chopra pointed out that a substantial portion of data engineering capacity in mid-to-large enterprises today is consumed by maintaining synchronization between transactional and analytical systems.
The implications, however, Chaturvedi noted, are not limited to developer productivity, architectural simplicity, or cost savings: “The strategic prize is simplified governance. When you have one copy of data under one governance model instead of the same data scattered across operational stores, replicas, warehouses, and vector databases, you’ve solved the governance fragmentation problem.”
That simplification, according to Chopra, will matter operationally for enterprises deploying multiple AI agents, as these workflows can amplify governance gaps at a speed and scale that no human workflow ever did.
LTAP versus HTAP
Despite all its benefits, though, LTAP isn’t the first effort to unify operational and analytical workloads under a single architecture and for years.
The industry has pursued a similar goal through Hybrid Transactional and Analytical Processing (HTAP) architecture, which sought to combine operational and analytical workloads on tightly coupled infrastructure to serve both workload types from the same system.
LTAP, in contrast, separates storage from compute, allowing different engines to access a common data layer while remaining independently scalable, Databricks said.
That separation of compute engines is why analysts think that LTAP might be a better bet than HTAP.
“HTAP never took off because asking one tightly bound system to be great at transactions and great at analytics usually left it mediocre at both, so customers ended up paying a premium for that compromise,” Leone said.
“I think separating storage from compute is the right instinct, and it’s the same move that made the modern cloud data world work in the first place. It matters because the thing that sank HTAP was one workload starving the other, and giving each side its own dedicated engine is exactly how you keep that from happening,” Leone added.
Another reason for HTAP’s failure, according to David Menninger, executive director of software research at ISG, was its requirement for enterprises to replace existing data platforms with a new architecture.
LTAP, by contrast, builds on the now-common practice of separating compute and storage, making the addition of an operational layer less of an architectural transformation and potentially lowering the barrier to adoption, Menninger added.
Not yet the default architecture for AI agents
However, despite the enthusiasm around LTAP, analysts warned CIOs against viewing this as the inevitable successor to existing data architectures.
“CIOs will still need to choose their data architecture based on latency, reliability, ecosystem fit, cost, compliance, and developer experience,” Walter said.
Echoing Walter, Chaturvedi pointed out that for LTAP to become the de facto standard for the industry, Databricks will need more than architectural elegance: “The architecture looks sound on paper. The proof will be in the commit-to-query latency numbers under real load.”
LTAP, Databricks said, is expected to be released soon as part of Lakebase, without providing any specific timelines.
Login
