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.

This article first appeared on Computerworld.

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.

This article first appeared on CIO.

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.

All about Hades, the supply-chain malware that hides in Python packages
It hides in Python packages. It replicates itself across systems. It fools LLM-based code analysis tools into ignoring it. And there may be a lot more like it to come.

More good reads and Python updates elsewhere

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.”