1. Retrieving a decision because it is relevant doesn’t mean the decision applies to the artifact being changed.
2. A decision that does apply isn’t automatically suitable for deterministic enforcement.

The first distinction is between relevance and authority; the second is between guidance and enforcement.

Here’s the story of how one controlled repository made this distinction clear. The project used local JSON-backed persistence for its current phase, and an active architecture decision ruled out PostgreSQL, ORMs, and database migrations for the command-line application. The task asked the coding agent to change that application’s storage module, so the decision was not merely related to persistence in general; it had authority over the part of the repository being changed. The record was retrieved successfully and placed in the agent’s context before work began.

The agent still proposed PostgreSQL, together with an ORM and a migration path. Under my original four-capability model, that looked at first like a retrieval failure. It wasn’t. The decision was found and was current, and it arrived at the right moment. What was missing was an applicability signal that told the system that this decision governed the storage module being edited rather than serving as one more relevant document for the model to weigh against nearby code and other context.

Retrieval finds; applicability governs

Retrieval helps us determine which architectural decisions might be relevant to a task. That’s a search problem, and teams have increasingly capable ways to solve it: indexed repositories, connected documentation, exposed decision records and service catalogs, semantic search, and project memory. These techniques help an agent see useful material before it writes code. They don’t, by themselves, answer a different question: Which of those decisions has authority over the change in front of the agent?

Suppose a repository contains two persistence decisions. One requires PostgreSQL for an analytics service; the other requires local file storage for a command-line tool. If the agent is editing the command-line tool’s storage module, both decisions may rank highly for a query about persistence, but only the local-storage decision applies to that artifact. Determining which decision governs the change requires scope, lifecycle, precedence, and a clear record of which decisions replace earlier ones. I argued for precedence and lifecycle in the previous article; scope deserves equal attention because scope is what tells the system where a decision has authority.

A related problem is that architectural information is usually scattered across several kinds of documents. Humans know that an old design note, a README, an accepted architecture decision record, and a current platform standard don’t necessarily carry the same authority, even when all four discuss the same topic. Models don’t know that unless the system preserves the distinction. When those sources are flattened into one context window, the hierarchy among them can disappear. I think of this as authority flattening: Information remains available, but the signal about which information is binding becomes weaker. That’s useful when a design question is genuinely open; it’s risky when the team has already answered the question.

Research on architectural decision violations points to a similar boundary. A 2026 study by Su and colleagues examined 980 ADRs across 109 open source repositories. The models were strong when decisions were explicit and inferable from code but less accurate when compliance depended on deployment configuration or organizational knowledge. The study evaluated violations after code was written rather than guidance before generation, but the underlying limitation is similar: A model can retrieve the right document and still make the wrong architectural choice when applicability or authority remains implicit.

What scope changed

I tested this distinction in a small controlled experiment using seven coding tasks, repeated under two conditions with the same coding agent and model configuration. In one condition the agent worked without the relevant architectural guidance; in the other, architectural decisions were supplied before it began changing code. Independent reviewers assessed the first attempts for both architectural compliance and whether the requested work was actually completed. The guidance changed behavior: First-attempt compliance on the architecture-sensitive tasks improved from 6 of 15 runs to 10 of 15, while successful task completion was essentially unchanged.

The more interesting result was a failure inside the guided condition. In several authentication tasks, the agent received a storage-related architectural decision that was genuinely relevant to the surrounding problem and then implemented additional persistence work that the task had never asked for. Nothing was wrong with the decision, and retrieval had done its job. Relevance had simply been presented without enough information about authority. The experiment made two limits explicit: A decision can be relevant without governing the artifact being changed, and even a governing decision doesn’t authorize the agent to widen the task. Applicability tells the system where a decision may constrain work; it isn’t permission to invent more work.

Blocking is easier than guiding

The second distinction forced me to revise another part of the original model. The previous article emphasized deterministic enforcement: when a team has made an explicit decision and a violation can be identified from observable evidence, a blocking verdict should come from a reproducible rule rather than a model’s judgment. I still think that’s the right standard for blocking. The important qualification is that only a subset of architectural decisions can meet it without pretending that judgment has become deterministic.

“Do not introduce SQLAlchemy into this component” is comparatively easy to express as a rule, easy to check, and easy to block. “Use the existing persistence abstraction correctly” is different. Most of its meaning is architectural rather than syntactic: The right implementation depends on which abstraction is intended, how it’s used in this part of the system, and what surrounding constraints are already in force. The first statement describes a prohibition that can plausibly become a deterministic control. The second describes a sanctioned path and is better treated as guidance unless the team can make the relevant evidence and boundary precise.

Earlier experiments with pregeneration guidance pointed in the same direction. Adding more architecture-related context didn’t reliably improve behavior because what was missing was often not another prohibition; it was a clearer description of the accepted implementation path. A guardrail layer built entirely around blocking will become very good at saying no. Useful architectural governance has to do both jobs: block the known violations when the evidence is precise enough and carry positive architectural direction for the much larger set of decisions that still require interpretation.

When judgment becomes authority

This doesn’t reduce the role of models; it puts probabilistic reasoning where it’s useful. Models are good at interpretation: reading ambiguous guidance, surfacing decisions that might bear on a change, explaining the consequences of a boundary violation, and proposing how to bring a change back into line with the intended design. Deterministic logic is better suited to decisions the team has already settled and can state in terms that a check can reproduce. The mistake is asking either mechanism to do both jobs.

Once a system says that a proposed change violates an architectural rule, the standard changes. An engineer should be able to ask which decision applied, why it applied to this part of the codebase, what evidence triggered the result, and whether another developer running the same check would get the same answer. That doesn’t require every part of architecture to become formal policy. It requires a clear boundary around where uncertainty is allowed: Models may help find and explain architectural context, but a blocking decision shouldn’t ultimately reduce to “the model thought this looked wrong.”

Humans routinely work with architectural ambiguity. We weigh incomplete evidence, local context, and competing trade-offs, often using heuristics rather than formal rules. Models can help with that interpretive work too, but the result remains probabilistic. The problem begins when an ambiguous judgment is treated as a blocking rule. Deterministic enforcement requires a boundary precise enough that the same evidence produces the same verdict.

The distinction matters even more when a team uses several coding tools at once. One developer may use Claude Code, another Codex, another Cursor, while automated agents perform background maintenance. The models and retrieval mechanisms can differ, but the team’s architecture shouldn’t change with the tool. A shared set of decisions can sit underneath those environments as the source of authority, while each tool consumes guidance in its own way and the enforceable subset is checked consistently.

What I would add to the original model

I would now amend the original four-capability model in two places.

Retrieval should surface candidate decisions, while applicability determines which of those decisions actually govern the current artifact or action, using scope together with lifecycle and precedence. Then guidance and enforcement should remain separate outcomes: Some applicable decisions are precise enough to support deterministic controls, while others should influence the implementation without becoming binary rules.

That separation leaves the agent free to reason where the architecture is genuinely open while preserving authority where the team has already made a decision. It also avoids a common overcorrection. Once teams see that some architecture can be enforced automatically, the temptation is to formalize everything. A great deal of architecture is still judgment. “Keep domain boundaries narrow” or “prefer asynchronous integration when immediate consistency is unnecessary” can be valuable guidance without being safe material for an automatic block. The level of authority a system exercises should follow the precision of the decision and the evidence available to evaluate it.

For years architectural governance ran largely on human process: Someone wrote the decision record, an architect reviewed the important changes, experienced engineers carried part of the history in their heads, and code review caught some of what slipped through. AI coding agents change the economics of that process because implementation can now move faster than architectural intent can be reexplained and rereviewed by hand. Giving agents more context is necessary, but it’s not sufficient. The harder job is preserving the difference between information that may be useful, a decision that actually applies, guidance that should shape an implementation, and a constraint that is precise enough to stop one.

The goal isn’t to constrain every choice an agent makes. It’s to stop decisions the team has already made from quietly turning back into suggestions. That requires more than retrieving the right document. The system has to know whether the decision is current, where it has authority, and what kind of authority the team intended it to have.

In the final episode of Zero to Agent in 30 Minutes, AI engineer Sajal Sharma showed how to build a personal assistant on OpenClaw that tracks your tasks and notes and handles scheduled work on its own.

A useful personal assistant has to be reachable when you’re away from your computer and keep running when it has scheduled work to do. OpenClaw supports both, and you decide where the agent runs, which models it uses, and how it accesses your data.

How to go from a fresh install to scheduled automations, step-by-step

1. Install your OpenClaw instance. Sajal recommends starting locally while you learn how it works, then moving to an always-on machine or hosted environment if you need continuous availability.
2. Connect the channels you use. Add a messaging channel such as Telegram, WhatsApp, or Slack so you can reach the assistant away from your desk. Sajal used Telegram in his demo to send requests and receive notifications from the same assistant.
3. Set up the assistant’s workspace. Give the agent a place to keep tasks, notes, skills, and memory, along with guidance files that define how it behaves and how it should work with the files in that workspace.
4. Use it in your daily workflows. Sajal asked the assistant for an overview of current projects and checked progress toward a reading goal. He also had it search the web for a book series and add the books it found to his reading list.
5. Add proactive automations. Schedule work the assistant should handle on its own. Sajal added a Telegram reminder and a morning briefing designed to pull from tasks, a calendar, and recent email. Recurring checks and webhooks can also trigger the agent when something changes in another system.

Thanks for following Zero to Agent

This episode closes out Zero to Agent in 30 Minutes. Thanks for watching and building along with our presenters throughout the series.

If you’d like to keep following how agents can take on more complex work, tune in to The Monday Morning Agent, which debuts Monday, October 12, at 8am PT/11am ET. The eight-episode series follows the development of an increasingly autonomous data agent working with real play-by-play data. Learn more and save your seat or follow along here on Radar.

The following article originally appeared on the Agentic AI Foundation blog and is being reposted here with the author’s permission.

Websites are designed for people. We can look at a page and quickly understand where to enter information or which control will complete an action.

AI agents don’t see or use the web the same way we do. An agent may have to process a screenshot or inspect the page’s underlying structure, then reason about which control matches the request.

The additional context increases token use, and each interpretation step creates another chance for error.

WebMCP (not to be confused with MCP) gives web developers a standard way to publish structured tools to access the capabilities of their website enabling agents to call those functions with structured inputs.

A developer can register a tool through document.modelContext and give it a name and description. The tool also defines an input schema and the function that runs when an agent calls it.

For example, an article site could publish a search tool that calls the same application code as its visible search form.

const searchToolController = new AbortController();

await document.modelContext.registerTool(
  {
    name: "search-articles",
    title: "Search articles",
    description: "Search published articles by topic.",
    inputSchema: {
      type: "object",
      properties: {
        query: {
          type: "string",
          description: "The topic or phrase to search for."
        }
      },
      required: ["query"],
      additionalProperties: false
    },
    async execute({ query }) {
      const articles = await searchArticles(query);
      renderSearchResults(articles);
      return { articles };
    }
  },
  { signal: searchToolController.signal }
);

// Call this when the search tool should no longer be available.
// searchToolController.abort();

The name and description tell the agent when to use the tool. The input schema defines the arguments it can send. The execute function calls the site’s existing search logic and updates the page with the results.

The browser makes the registered tool available to a supported agent while the page is active. When the agent calls it, the browser passes the structured arguments to execute and returns the result.

When the search tool should no longer be available, the page can unregister it by calling searchToolController.abort().

A page registers tools that match its current state. A content view may provide a search tool, while an editor can provide tools for changing the selected content. The agent then discovers the tools available for the page’s current state.

WebMCP also proposes a declarative path for existing HTML forms. The article search could be exposed through attributes on the form itself.

<form
  action="/articles"
  method="get"
  toolname="search-articles"
  tooldescription="Search published articles by topic."
>
  <label for="article-query">Topic</label>
  <input
    id="article-query"
    name="query"
    type="search"
    toolparamdescription="The topic or phrase to search for."
    required
  >
  <button type="submit">Search</button>
</form>

The browser uses the form attributes and controls to create the tool definition. Because the form omits toolautosubmit, the browser populates the field but leaves the final click to the person. The person can review the search query and click the Search button.

Keep the person and agent in the same interface

A WebMCP tool uses the state already visible in the application and the person’s active session. The shared page gives the person a place to review the agent’s work. When the agent completes an action, the person can see the updated state and make changes through the normal interface.

Web developers can also reuse application logic that already handles the visible interface. OpenAI’s Runme example is a browser application that registers tools for reading instructions and updating notebook content. Runme can offer those functions through the page without adding a separate server only to expose an MCP endpoint.

Pair WebMCP with MCP

WebMCP and MCP both expose tools to agents, but they operate in different parts of an application. Understanding the difference helps developers decide where each one fits and how they can work together.

An MCP server can provide tools when no related page is open. A WebMCP tool is attached to the current document and can use the page’s current state.

WebMCP standardizes how a page registers tools with the browser. The browser can present those tools to its agent through MCP or another function calling mechanism.

MCP Apps address another part of the interaction. An MCP server can provide an interactive interface that a compatible host displays to a person. WebMCP lets an agent use functions from an existing website.

WebMCP and MCP Apps can work together. For example, a shopping website could publish a compare_products tool through WebMCP. An MCP server could provide an MCP App for the comparison, so the person can adjust the options while the agent handles the supporting work.

The comparison interface could also be described with A2UI, which lets an agent describe an interface in a declarative format. The client renders the description with components from its own design system, so the client controls which components are available and how they behave.

People and agents can use the same interface at the same time. Developers need to decide which functions the agent can call and what the person should see while those functions run.

Design the page for agent use

Agent use begins before the first click. An agent may need to discover the website and determine how to authenticate. It may choose an API or structured documentation before opening a browser.

Web teams should study how agents use their site before deciding which interface to add. Check the server logs to see whether agents are crawling HTML or requesting machine readable content. Tool activity can reveal which WebMCP functions agents discover and which calls they abandon.

Keep existing controls in the execution path

WebMCP reduces the amount of interface interpretation an agent has to do, but a structured tool is still an entry point into the application. The website should apply its existing access controls and input validation whenever the tool runs.

For example, an update_cart tool can accept a product identifier and quantity. The server should confirm that the product exists and that the current user can modify the cart. Structured input doesn’t automatically make the request trusted, so the server should run the same checks it uses for updates made through the website.

The browser also has a responsibility. OpenAI reviews each site tool call before it runs and asks the person to confirm sensitive actions. The WebMCP draft requires origin isolation, and its tools permissions policy allows same origin use by default.

Clients need to handle tool changes during a task. A page can change a tool’s identity or schema after the agent begins working, so the client should review the tool again before using the new definition.

Researchers are already testing those boundaries. A June preprint on WebMCP tool surface poisoning found that changes to tool registration and metadata could redirect agents in its test environment. The researchers used a polyfill and a headless agent, so a native browser implementation may behave differently. But these reported attacks can serve as great test cases as you’re adding WebMCP to your site.

Test WebMCP while the design is open

WebMCP already has several experimental implementations. Chrome offers an implementation through a flag and an origin trial. Sarah Drasner created an interactive WebMCP demo of this implementation that you can try in your browser.

Cloudflare released a developer preview that can add a WebMCP bridge to a website, and Brave has tested WebMCP with its Leo assistant.

Testing WebMCP against varied applications can reveal assumptions in the current draft. For example, a form may need a declarative feature that has not been specified yet. Also, look for lifecycle problems when a website changes its tools during a task.

Bring your findings back to the WebMCP issue tracker.

AI systems are gaining more autonomy while governments, companies, and researchers are still working out how much oversight they need. On the latest episode of This Week in AI, we covered the US debate over AI governance, new frontier models, persistent agents, world models, and practical uses for AI in healthcare and disaster response.

AI oversight is moving beyond company promises

The Trump administration announced a voluntary agreement with major AI companies that calls for internal safety monitoring, external audits, and independent board reviews. Because the agreement carries no legal enforcement, it raises a familiar question about how far self-regulation can go when companies are developing increasingly powerful systems.

Government agencies are also testing what existing law can do. The Federal Trade Commission launched an investigation into OpenAI, Anthropic, and other AI companies focused on potential consumer risks. Cases like these could help establish whether current consumer protection laws are enough or whether AI will require a more specialized regulatory framework.

For technical leaders, regulation can influence how organizations evaluate models, document risks, manage access, and choose vendors. As AI moves deeper into business processes, teams will need governance practices that can withstand outside review.

AI systems are taking on longer, more autonomous work

OpenAI just released Dots, its “proactive assistant” designed to retain context, work across applications, pursue multiple goals, and act independently. To do that work without waiting for a prompt, Dots needs standing access to the apps and data it works across. That also increases the amount of personal data an agent can reach and raises the cost of mistakes or misuse.

Google is also extending how long a model can work on a task. The company says Gemini 4 Argon can generate up to a million output tokens in a single response, far beyond the typical output limits of current frontier models. The goal is to let a model stay with long multistep work such as extensive coding or financial and legal analysis. Longer-running models and persistent agents aren’t the same thing, but both let AI finish more work without handing control back to a person.

As agents act more on their own, they need to anticipate the consequences of their actions. That becomes even more important when AI moves beyond software and begins acting in the physical world. World models aim to teach AI how these environments work, including cause and effect, which is why many researchers see them as building blocks for robotics and physical AI. World Labs (recently acquired by AMD) is developing spatial intelligence models for interactive 3D environments, while British startup Worldmodeldata has licensed nearly 1 million hours of video game data paired with player actions. Researchers from NVIDIA, MIT, and Oxford also introduced Physis-Lang, which uses descriptions of physical causes and effects to help video models learn why events happen. Researchers still don’t know which training approach will work best, so they’re testing several kinds of data and model design.

AI support experts in high-stakes work

Anthropic’s Claude is helping teams responding to an Ebola outbreak in the Democratic Republic of the Congo organize daily reports, compare forecasting models, analyze genomic information, and support vaccine research. Researchers have also developed a Spanish-language speech model that may eventually help identify accelerated biological aging and early signs of dementia. Mayo Clinic researchers built a model that identifies patterns associated with elevated pancreatic cancer risk years before diagnosis. Following severe flooding in Nepal, local teams used AI to match reports of missing people with victim lists and map damaged buildings using satellite imagery.

Together, these examples show how AI can be used for good by helping people work through complex information faster and, ultimately, save lives, while keeping qualified experts responsible for the final decisions.

What’s next

As AI takes on more work and enters higher-stakes settings, organizations will need clearer answers about access and accountability. They’ll also need to decide where human judgment remains necessary as systems become more capable.

Join us again next Monday for another episode of This Week in AI, when we’ll dive into more of the news, issues, and key developments shaping the AI era. And check back each Friday for the latest episode, or watch on YouTube, Spotify, Apple, or wherever you get your podcasts.

Today, because the agent is interacting on behalf of a human through a genuine browser with standard extensions, its technical fingerprint looks identical to a normal human user’s device. Agents call tools, observe results, and revise. A person browses, hands off to an agent, and takes the session back. All the activity appears to be coming from the same user.

Signed agents help the identity problem, and they’re arriving. Web Bot Auth is a thin layer over RFC 9421 HTTP Message Signatures where an agent declares its identity and purpose. But they only help with the identity problem: The signature proves who is making the request, not the intent behind it. Prompt injection and other techniques can be used to steer a verified, well-behaved agent into acting against your interest without its operator ever knowing.

The organizations getting this right are treating agent policy as a commercial question with a security implementation. The following questions need to be answered:

• Which agents do we allow to use our service?
• What endpoints do we need to protect? 
• How will agent management security policies impact revenue?

Here are the techniques successful companies are using to secure in the agentic era. A phased strategic roadmap implementing continuous execution-time verification. These are the steps:

1. Establish execution-time machine identity and scoped delegation. Replace static, long-lived API keys with machine single sign-on mechanisms that issue short-lived, context-bound credentials at the time of tool execution. Enforce strict delegation policies so that autonomous agents operate within verified “green zones” without inheriting broad human privileges.
2. Deploy cryptographic ingress verification. Upgrade edge infrastructure to inspect Web Bot Auth HTTP Message Signatures, in order to separate cryptographically verified crawlers from anonymous traffic.
3. Upgrade edge defenses to browser-layer intent classification. Transition legacy network-layer antibot web application firewall (WAF) to client-side browser-layer detection platforms. 
4. Harden agent execution pipelines against prompt injection. Instrument robust input sanitization, instruction hierarchy enforcement, and design-level safeguards around all LLM ingestion channels to neutralize indirect prompt injection attacks before external web content reaches execution tools.
5. Adopt standardization for agentic commerce and admission. Integrate emerging trust frameworks such as the Framework for Agentic Commerce Trust (FACT), a neutral real-time trust layer for AI-driven transactions in addition to verification protocols like CAPTCHA to validate agentic capability vectors before delegating sensitive interagent tasks.

The rapid transition from human-directed software to autonomous AI agents breaks traditional enterprise security paradigms. AI agents operate with broad operational scope but nondeterministic, probabilistic reasoning. This is causing static perimeter defenses to fail. The teams that come through this well will be the ones that stopped asking “Who’s on the other end of the connection?” and started asking “What’s this request for, and what happens if it succeeds?”

Imagine an AI-assisted decision that must be examined six months after it was made. Rerunning the system may produce a different answer, but an investigator may still need to determine which model endpoint, policy, retrieved data, tool contract, and runtime configuration were used at the time. That is the problem addressed here.

The AI industry remains much better at evaluating capability than at preserving the knowledge required to understand past executions. Evaluation pipelines track benchmark scores, task success rates, retrieval precision and recall, tool-call success rates, latency, and cost, and they grow more elaborate with every release. In practice, this machinery often reduces to one acceptance question: What can this system do? That question captures capability, but not whether a past execution will remain understandable after the system changes.

That missing property is historical reconstructability: the ability to establish which dependencies were used and under which conditions a particular execution occurred. It is related to, but distinct from, reproducibility. Reproducibility asks whether a result can be produced again under equivalent conditions. Reconstructability asks whether the conditions of the original execution can still be identified, even when repeating that execution would not produce an identical result.

This distinction matters when a consequential AI execution completes successfully today and is challenged six months later. The model may still exist in a registry. The application revision may still exist in Git. The trace may still identify the request and the services it crossed. Yet none of these records necessarily reveals which model endpoint served the request, which input transformation and runtime configuration were applied, which data, feature state, or retrieved context entered the computation, or which policy state governed it. In an agentic system, the missing history may also include memory, tool contracts, delegation, and external effects. Even when a dependency identifier was recorded, the historical state to which it referred may no longer be available or resolvable.

The problem is that an AI runtime may use dependencies whose historical identities and relationships are not preserved. This is an architectural problem, not merely a logging problem. The gap lies between what the runtime uses and what the surrounding infrastructure is required to preserve. I call this the preservation gap. The AI stack preserves models, code, deployments, and observations, but it does not require the effective historical configuration of a particular execution to remain available. The components may remain while the relations that made them one execution disappear. An AI runtime must assemble today’s execution; it is not necessarily required to remember exactly what it assembled yesterday. Reconstructability must therefore be established during execution, before later mutation erases the bindings that gave the execution its effective configuration.

Hermetic builds illustrate the opposite design pattern. They close the dependency graph before execution begins by pinning inputs, versions, and external dependencies. AI runtimes face the reverse situation: Part of the dependency graph remains open until execution, as model endpoints may resolve through mutable aliases, data and feature state evolve, runtime configuration and policy change, and retrieved context is selected only when a request is processed. Agentic systems extend the graph further through memory, tools, delegation, and external effects. In a hermetic build, dependency closure is an input. In a modern AI runtime, part of it may be an output of the run.

Version control records source evolution, transaction logs record state transitions, and distributed tracing records execution relationships. These mechanisms preserve different views of a run but not its materially relevant execution-specific configuration. A trace may retain execution flow, a deployment manifest the declared application state, and a model registry the model revision. What is often missing is the record of which artifacts and states were bound together in a particular execution.

The dependency graph no longer closes at deployment

A deployment records the configuration known before execution begins. AI systems are harder to reconstruct because materially relevant dependencies are selected during execution rather than fixed at deployment. At inference time, the system may resolve a model endpoint, input transformation, data or feature state, retrieved context, runtime configuration, safety controls, and policy. Agentic systems extend this composition through memory, tools, delegation, and external effects. These execution-specific selections are runtime bindings: facts about what the execution actually used.

The following example makes this distinction concrete. Consider a hypothetical agentic execution identified as E891. During this execution, the system retrieves two documents, evaluates a policy, invokes a tool, and produces an external effect. The deployment may identify application revision 8f31c2 and model v17, while the execution itself binds prompt h31, retrieval index r42, entities d182@17 and d761@4, tool contract h42, policy v8, and ultimately effect e3. The deployment system could not have known this entire set in advance, because some of these dependencies were selected only as the execution proceeded.

The difference between what a deployment declared and what an execution actually used becomes consequential when dependencies change. A model alias may resolve differently, a feature or data source may change, preprocessing and runtime configuration may evolve, and policy v8 may become v9. In agentic systems, retrieved context, memory, and tool contracts introduce further independent mutation. Deployment identity describes what was declared, but the historical record of an execution must describe what was actually used. Unless those binding relations are captured when they occur, the effective configuration of E891 cannot be recovered reliably from later system state.

Current state is a lossy projection

Once runtime bindings are treated as part of the execution, the limitation of current-state records becomes clear. The execution-scoped dependency closure is the combination of the declared state and the runtime bindings that formed the effective configuration of a particular execution.

As dependencies mutate, different historical executions can leave behind the same observable evidence. The current state may show which artifacts still exist without revealing which combination a particular execution used. Once the distinguishing bindings are gone, the history cannot be reconstructed from what remains. A system can retain its artifacts while losing reconstructability: An identifier proves neither that a dependency was used nor that the historical state it denotes remains available. Reconstructability therefore requires durable binding relations and continued access to the historical states they identify.

Existence is not usage

The existence of an artifact and its use in a particular execution are different facts. Concurrent versions, caches, retries, and asynchronous changes make it unreliable to infer whether an execution used an artifact merely because that artifact existed at the relevant time.

W3C PROV already provides the relevant semantic distinction: An activity can use an entity. The missing primitive is therefore not a new provenance vocabulary, but a runtime requirement to record which dependency a particular execution used and to preserve an identity that can be resolved later.

This requirement also exposes the limit of observability. OpenTelemetry can transport dependency identifiers through attributes, links, context, and baggage, but encoding an identifier does not preserve its historical meaning. A trace may retain execution topology while the identities that explain it disappear. Instrumentation can carry preservation metadata, but it cannot guarantee durable storage or continued resolution of the referenced states.

Historical reconstructability therefore requires more than retained artifacts. For a defined class of executions and a specified retention period, the system must preserve two properties: binding integrity, which records which dependency versions and states an execution actually used, and resolution integrity, which keeps those recorded identities resolvable to the historical states they denote.

Preservation requires failure semantics

Once reconstructability is treated as a system property, the architecture must define what happens when the records required to reconstruct an execution fail to reach durable storage. Suppose policy v8 authorizes execution E891 to invoke tool contract h42, and the tool commits effect e3. If the usage record fails to reach durable storage, the action succeeds while the historical links among the effect, its policy, the tool contract, and the execution context are lost. The external effect remains, but the historical record no longer reliably explains which policy and tool contract authorized it. The external world and the historical record have diverged.

Figure 2 shows why this condition cannot be treated as ordinary telemetry loss. When an external effect has been committed but the corresponding usage record is missing, the architecture does not guarantee historical reconstructability. It provides only best-effort historical evidence.

Reconstructability becomes an engineering guarantee only when the architecture defines when preservation records become durable and what the system does if they cannot be stored.

A system may require a durable usage record before committing the effect, atomically persist the effect intent and preservation record through a transactional outbox, quarantine the execution for reconciliation, or trigger a compensating action. The implementation is application-specific, but preservation failure must have explicit semantics rather than disappear into telemetry.

Existing technologies provide the building blocks for this layer. Provenance and lineage models represent relations, tracing propagates execution context, registries identify versions, and content-addressed stores preserve artifacts. None, however, creates a runtime obligation to preserve the execution-scoped dependency closure required for reconstruction.

This layer is a preservation plane: the contract and machinery that keep an execution’s dependency closure identifiable as its surrounding systems change. It defines what to record, how records become durable, and how referenced states remain resolvable. Orrery applies this principle as a reference architecture in which materially relevant runtime bindings are captured when they occur and retained together with resolvable identities for the historical states they reference.

AIGov Core: reconstructability as a tested property

AIGov Core provides a limited implementation of this principle. Its evidence ledger stores hash-chained events, while its replay engine reconstructs a governance verdict from a stored export without querying live state. A companion check labels the export Ready, Partial, or NotReady according to unresolved lineage, missing policy artifacts, version drift, or replay failure. This demonstrates that reconstructability can be tested, but it does not solve the complete preservation problem. The system can replay only what was recorded; it cannot recover a runtime binding that was never captured.

The preservation gap is the mismatch between what an execution depends on and what the system persists. Closing it requires a runtime obligation: Whenever an execution binds materially relevant state, the system must record that binding, preserve a durable identity for the dependency, and retain access to the historical state it denotes for the defined retention period. Reconstructability is therefore not a by-product of capability or observability. It is an architectural property that must be designed, tested, and enforced during execution.

This is the final post in a four-part series about post-training. If you missed them, check out part 1, part 2, and part 3.

Time to get your hands dirty! I’ll take you through implementing the key pieces of the classic ChatGPT pipeline: SFT, then reward model training, then PPO. The goal isn’t to reproduce InstructGPT, because that took a large team and thousands of GPU-hours. But getting hands-on will help make the concepts from this series concrete, so that when you look at each stage’s code, you understand what it’s doing to the model and why.

We’ll use Qwen2.5-1.5B as the base model. It’s small enough to train on a single node with a few GPUs but large enough that you can observe real behavioral changes from post-training.

For SFT, you’ll use torchtune, Meta’s PyTorch-native fine-tuning library. For RL, you’ll use verl (from ByteDance’s team), a production-grade RL post-training framework built on Ray. verl was designed from the ground up for distributed RL training with proper rollout orchestration, and it’s what you’d actually reach for if you were doing this at scale.

You’ll need a machine with at least 2 GPUs (4 or 8 is better) and around 80 GB of total GPU memory.

You’ll likely use an LLM to flesh out the boilerplate and get this running end to end. I used LLMs pointed to the recent docs to generate these. What matters as you read the code in this section is that you understand the config choices and data formats well enough to direct that process and debug when something goes wrong.

Stage 1: SFT on demonstrations

SFT is the easiest stage to implement. You’re taking the pretrained model and training it on {prompt, response} pairs using the same next-token prediction loss from pretraining, except you only compute loss on the response tokens.

Your SFT data should be in a conversational format. Here’s what a single example looks like:

{
    "messages": [
        {"role": "user", "content": "Why do people like golden retrievers?"},
        {"role": "assistant", "content": "Golden retrievers are one of the most 
popular dog breeds for good reason. They have a gentle, friendly temperament 
that makes them great family dogs. They're patient with kids and tend to get 
along well with other animals. They're also highly trainable and eager 
to please, which is why they're commonly used as service dogs and therapy dogs. 
And honestly, the goofy enthusiasm doesn't hurt either. They never really grow 
out of that puppy energy."}
    ]
}

Remember what a pretrained model does with “Why do people like golden retrievers?” It might spit out “Why do people like labrador retrievers?” because it’s just completing patterns. Your SFT data is what teaches it to actually answer the question instead.

In practice, you’d have thousands of these examples covering a range of tasks: question answering, summarization, creative writing, coding help, multiturn dialogue, and refusals for harmful requests. For this walkthrough, assume you have a JSONL file of these conversations.

torchtune uses YAML configs and built-in recipes. Here’s what a config might look like:

# sft_config.yaml

# Model
model:
  _component_: torchtune.models.qwen2_5.lora_qwen2_5_1_5b
  lora_attn_modules: ['q_proj', 'k_proj', 'v_proj', 
'output_proj']
  lora_rank: 64
  lora_alpha: 128

# Tokenizer
tokenizer:
  _component_: torchtune.models.qwen2_5.qwen2_5_tokenizer
  path: /path/to/Qwen2.5-1.5B/vocab.json
  merges_file: /path/to/Qwen2.5-1.5B/merges.txt
  max_seq_len: 2048

# Checkpointer — loads the pretrained weights
checkpointer:
  _component_: torchtune.training.FullModelHFCheckpointer
  checkpoint_dir: /path/to/Qwen2.5-1.5B
  output_dir: ./sft_checkpoint
  model_type: QWEN2

# Dataset
dataset:
  _component_: torchtune.datasets.chat_dataset
  source: sft_data.jsonl
  conversation_style: sharegpt
  max_seq_len: 2048
  train_on_input: false           # only compute loss on the 
                                    assistant's response tokens

# Training
seed: 42
epochs: 3
batch_size: 4
gradient_accumulation_steps: 4    # effective batch 
                                    size of 16
optimizer:
  _component_: torch.optim.AdamW
  lr: 2e-5
  weight_decay: 0.01
lr_scheduler:
  _component_: torchtune.training.lr_schedulers.get_cosine_schedule_with_warmup
  num_warmup_steps: 50

dtype: bf16
compile: false

Then launch it:

tune run lora_finetune_distributed --config 
sft_config.yaml

What actually matters in this config:

• train_on_input: false masks the loss on prompt tokens so the model only learns to generate good responses, not to mimic user messages. If you accidentally set this to true, the model wastes capacity learning to produce prompts.
• A learning rate of 2e-5 is the standard starting point for SFT. That’s aggressive enough to shift behavior in a few epochs but not so large that you destroy the pretrained weights.
• Use LoRA instead of full fine-tuning. For a 1.5B model you could do either, but LoRA is the practical default because it’s faster, uses a lot less GPU memory, and at this model size the quality gap is negligible. At larger model sizes, LoRA becomes even more useful in saving compute.
• 3 epochs because the dataset is small. InstructGPT trained for 16 epochs on ~13K examples. Smaller datasets need more passes, but watch validation loss for overfitting. This is something you should tune to see different results across different-sized datasets.

After this stage, try chatting with the model and try a bunch of different comparisons to the base model. Ask it “Why do people like golden retrievers?” and you should get a real answer now, not a list of related questions. The model should be able to hold a conversation and follow basic instructions. It’s already dramatically more useful than the base model, even if the responses aren’t always great.

Realistically, you should set up a good evaluation (“evals”) to assess the quality of the model, hyperparameter tune, and determine your data mix. In this section, you’ll just focus on looking at the code.

Stage 2: Training the reward model

For your reward model, start with your data of preference pairs, which will look like this:

{
    "prompt": "What's the capital of that country that celebrates with a lot 
of colored powders?",
    "chosen": "You're probably thinking of Holi, the festival where people 
throw bright colored powders. That celebration is most famously associated 
with India. The capital of India is New Delhi.",
    "rejected": "The capital of that country that celebrates with a lot of 
colored flowers is Amsterdam, the Netherlands, known for its tulip festivals."
}

The “rejected” response isn’t just wrong about the festival. It also misread “powders” as “flowers” and jumped to an incorrect answer.

For reward model training, you’ll use TRL’s RewardTrainer. Reward model training is a straightforward classification task.

from transformers import AutoModelForSequenceClassification, 
AutoTokenizer
from trl import RewardTrainer, RewardConfig
from datasets import load_dataset

# Start from the SFT checkpoint — it already understands 
the response distribution
model = AutoModelForSequenceClassification.from_pretrained(
    "./sft_checkpoint",
    num_labels=1,
    torch_dtype="bfloat16",
)
tokenizer = AutoTokenizer.from_pretrained("./sft_checkpoint")
tokenizer.pad_token = tokenizer.eos_token

dataset = load_dataset("json", 
data_files="preference_data.jsonl", split="train")

training_args = RewardConfig(
    output_dir="./reward_model",
    per_device_train_batch_size=8,
    num_train_epochs=1,    # just 1 epoch — reward models overfit fast
    learning_rate=1e-5,    # lower than SFT, be gentle
    bf16=True,
    max_length=2048,
    logging_steps=10,
    save_strategy="epoch",
)

trainer = RewardTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset,
    tokenizer=tokenizer,
)

trainer.train()
trainer.save_model("./reward_model/final")

As you skim the code, take note of these three things:

• Start from an SFT checkpoint, not a base model. The reward model needs to understand the distribution of responses it’ll be scoring, and the SFT model is closer to that distribution.
• 1 epoch only. Reward models overfit quickly. The InstructGPT team found only 1 epoch was needed.
• Learning rate of 1e-5, lower than SFT. Smaller updates.

After training, check the reward model by scoring a few responses manually. Give it a clearly good response and a clearly bad one for the same prompt and make sure the good one gets a higher score. If this basic test fails, something is wrong with your data or training. Don’t skip this step: It’s better to catch problems sooner than many GPU hours later!

Stage 3: PPO with verl

Now you can take the SFT model and optimize it against the reward model using PPO. verl handles the hard parts: coordinating rollout generation across workers, managing the four models that need to be in memory simultaneously (policy, reference, reward, critic), and orchestrating the update loop.

First, prepare your prompts. verl expects parquet format. Each row needs a prompt field containing the tokenized and chat-template-formatted prompt. Here’s an example of preparing it:

import pandas as pd
from transformers import AutoTokenizer
from datasets import load_dataset

tokenizer = AutoTokenizer.from_pretrained("./sft_checkpoint")

raw_prompts = load_dataset("json", data_files="rl_prompts.jsonl", split="train")

def format_prompt(example):
    messages = [{"role": "user", "content": example["prompt"]}]
    formatted = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    return {"prompt": formatted}

formatted = raw_prompts.map(format_prompt)
df = pd.DataFrame(formatted)
df.to_parquet("data/rl_prompts.parquet")

The prompts for RL don’t need labels. The reward model provides the signal. You just need a diverse set of prompts that covers the types of requests your model expects to see when you deploy it.

Next, define the reward function. verl lets you wrap your reward model in a function that takes a batch of prompts and responses and returns rewards:

# reward_fn.py — verl will call this during training
import torch
from transformers import AutoModelForSequenceClassification, AutoTokenizer

class RewardFunction:
    def __init__(self, reward_model_path="./reward_model/final"):
        self.model = AutoModelForSequenceClassification.from_pretrained(
            reward_model_path, torch_dtype=torch.bfloat16
        ).cuda().eval()
        self.tokenizer = AutoTokenizer.from_pretrained(reward_model_path)
        self.tokenizer.pad_token = self.tokenizer.eos_token

    def __call__(self, prompts, responses):
        """
        prompts: list of prompt strings
        responses: list of response strings
        Returns: list of scalar rewards
        """
        texts = [p + r for p, r in zip(prompts, responses)]
        inputs = self.tokenizer(
            texts, return_tensors="pt", padding=True,
            truncation=True, max_length=2048
        ).to(self.model.device)
        with torch.no_grad():
            rewards = self.model(**inputs).logits.squeeze(-1)
        return rewards.tolist()

Now configure the PPO training run. verl uses YAML configuration files that specify the models, hyperparameters, and infrastructure:

# ppo_config.yaml
data:
  train_files: data/rl_prompts.parquet
  prompt_key: prompt
  max_prompt_length: 1024
  max_response_length: 1024

actor_rollout_ref:
  model:
    path: ./sft_checkpoint
  actor:
    optim:
      lr: 1e-6                    # very low — RL updates should be gentle
      lr_warmup_steps: 10
    ppo_mini_batch_size: 64
    ppo_micro_batch_size: 8       # adjust based on GPU memory
    ppo_epochs: 4                 # number of PPO update passes per batch
    clip_ratio: 0.2               # PPO clipping — standard value
    kl_penalty_coeff: 0.1         # KL penalty to prevent reward hacking
    entropy_coeff: 0.01           # small entropy bonus for exploration
  rollout:
    temperature: 0.7
    top_p: 0.9
    n: 1                          # 1 response per prompt per rollout
    tensor_model_parallel_size: 1
  ref:
    log_prob_micro_batch_size: 8

critic:
  model:
    path: ./reward_model/final    # initialize critic from reward model
  optim:
    lr: 1e-5
  ppo_micro_batch_size: 8

reward_model:
  path: ./reward_model/final
  micro_batch_size: 8

trainer:
  total_training_steps: 500
  save_freq: 100
  test_freq: 50
  project_name: post_training_walkthrough
  logger: wandb

A few important hyperparameters in the config:

• The learning rate is an order of magnitude smaller than SFT, default at 1e-6. (“Actor” refers to the policy model.) RL updates are noisier, and you want to move slowly. If the model starts producing gibberish or repetitive text, your learning rate is probably too high.
• The KL penalty coefficient is 0.1, and recall that it controls how much the model is penalized for drifting from the SFT checkpoint. 0.1 is a reasonable starting point, but you’ll likely need to adjust. If you see reward hacking, turn it up, but if the model doesn’t really change, you need to lower it.
• The clip ratio is default set to 0.2, from the original PPO paper. This likely doesn’t need tuning. It prevents any single update from changing the policy too much.

Launch the training:

python -m verl.trainer.main_ppo \
    --config ppo_config.yaml \
    --n_gpus 4

During training, watch for a few things. The reward should generally trend upward, meaning the model is learning to produce responses the reward model likes. The KL divergence should increase but not explode, in which case the model is drifting too far and you need a higher KL penalty. And periodically generate some responses from the current checkpoint and read them yourself. Metrics can be unreliable on their own, and your own judgment of output quality can be more reliable. Of course, ideally, you have a held out evaluation set that you’re working with that can help you test different tasks you care about.

Putting it together

The full pipeline runs on stage after the next: SFT first, reward model second, PPO third. Each stage depends on the previous one. The SFT model provides the starting point for both RL training and the reward model. The reward model provides the signal for PPO. And PPO produces the final model.

This is, structurally, the same pipeline that produced InstructGPT and the first version of ChatGPT. The scale is obviously different. They used 175B parameter models, 40 labelers, and far more compute, but the mechanics are identical. Your 1.5B model won’t write poetry as well as the latest GPT, but it will go from producing “Why do people like labrador retrievers?” to actually answer “Why do people like golden retrievers?” with a conversational response. That’s post-training doing the heavy lifting.

If you’re doing this for real, what will eat most of your time isn’t the code but the data: curating good SFT demonstrations, collecting reliable preference labels, and building a prompt set for RL that covers the right distribution of tasks. But there are some great open source datasets out there that you can get started with.

The training infrastructure is largely solved: You can point an LLM at the torchtune and verl docs and have it scaffold a working pipeline for you in an afternoon. But no amount of tooling fixes bad data or a reward model that scores the wrong things highly. Understanding what each stage needs and why is what lets you direct that process effectively.

AI Models

Model choice is starting to hinge on price and specialization as much as raw benchmark leadership. Alongside general chat models, there are now decision models that never chat, spatial models built for robot planning and camera control, forecasting models sized for a single task, and cybersecurity-specialized models kept behind an invite-only program. Specialization leads to greater efficiency and lower costs, at least in the short term. In the long term, specialized models may succumb to the “bitter lesson.”

• Anthropic has released Claude Opus 5.5, which it claims has performance similar to Fable 5.1, and hence similar restrictions. It’s faster and requires fewer resources to run. Anthropic has dropped prices 20% for input and output tokens and 60% for cached reads. Not to be outdone, OpenAI released GPT-6 Sol and Luna, with 50% price reductions.
• Anthropic has also announced Fable 5.1 and Mythos 5.1. The most significant change appears to be a 75% price reduction for cache reads, which might translate into significant savings for long-running jobs; Anthropic estimates 25%. Mythos is only available to trusted partners. Simon Willison used Fable 5.1 to animate his pelican-riding-a-bicycle pseudobenchmark.
• Anthropic released Sonnet 5.5 with claims that it’s 30% faster and 30% less expensive for most work. The new model has security limitations similar to those applied to Opus and Fable; it routes to Sonnet 5 if it’s asked to do anything out of bounds.
• And finally, as September closes, Anthropic announces a marketplace for Claude plugins and connectors. At its launch, Claude Marketplace had over 2,000 items.
• OpenAI has released GPT-6 Astra, with claims that the company has achieved AGI (artificial general intelligence). Astra’s excellent benchmark scores appear to depend on the use of an unreleased harness. OpenAI has also released GPT-6.1 Sol, with per-token price reductions and claims that it is close to GPT-6 Astra in capabilities
• OpenAI has solved the Navier-Stokes existence and smoothness problem, a mathematical problem in fluid mechanics. This development raises an ethical question: Did OpenAI train its system on the work of two mathematicians who were close to solving the problem themselves? It also raises practical questions about the future of mathematics. Decorated mathematician Terence Tao asks whether “the collection of good, fruitful open problems is now being mined in a non-renewable fashion.” An advisory group has been formed to help OpenAI make decisions about releasing mathematical results.
• Google has released Gemini 3.8 Flash TTS and Flash-Lite TTS. Voice options aren’t limited to a prebuilt library. These models have APIs that allow developers to describe the voice that they want or upload a sample. These custom voices are then assigned an ID so they can be reused.
• Google has announced Gemini 3.8 Live and Gemini 3.8 Live Extended Thinking. These models are designed for live, near-real-time conversation. They can process video input. Live Extended Thinking can reason and speak at the same time.
• Google has released Gemini 3.8 Flash and Flash Cyber. Flash appears to be similar to frontier models on most benchmarks, with Computer Use being the biggest exception. Flash Cyber is specialized for vulnerability detection and mitigation and is only available to defenders in the Fairwind Program.
• Google has also released TimesFM-3, a small specialized model for multivariate time series forecasting. The model weights are available on Hugging Face with a license that only allows for noncommercial use. (Source code is available under the Apache open source license.)
• Xiaomi released MiMo-V2.6, its latest large language model. It’s fully open sourced, and based on benchmark results, Xiaomi claims that MiMo is the strongest open model to date. What’s more interesting is the claim that MiMo only cost $3.5 million to train.
• TypeSafe’s new decision model, Jev, is unlike anything else we’ve seen. It doesn’t chat; its output is always strictly typed and accompanied by probabilities that estimate correctness. It’s much faster and less expensive than other leading models. It isn’t open source, but there are already many open source clones.
• Ollaya is similar to Ollama, but for running decision open models like Laya (a clone of Jev) locally.
• World Labs has released Atlas, a model for “spatial intelligence.” It uses text, images, video, and 3D data to perform tasks like planning a robot’s movements or changing the camera position in a photograph.
• The rumors that NVIDIA would buy Hugging Face are true. NVIDIA is hoping for a proliferation of models that will run on its hardware, and the company promises that Hugging Face will remain a neutral platform, without favoring one model over another.

Software development

Agents are starting to delegate to, and coordinate with, other agents rather than working solo. Claude Code can break a task apart and hand pieces to other Claude Code instances, Muse Code lets sessions message each other, and Google’s AX orchestrator exists purely to wire up sandboxes and control communications for swarms of agents doing a task together. That shift is pushing developers to rethink what a source repository needs to record, and to start asking how much all this delegation costs.

• Now that Jev has caught everyone’s attention, what can you build with it? Jevmem is a memory manager that hooks into Claude Code and prunes the context at every conversational turn.
• AX is a new agent orchestrator from Google. It isn’t an agent; it’s intended to coordinate many agents to complete a task. It creates sandboxes, wires up Git repos and other resources, and controls outbound communications.
• The latest version of Claude Code can manage Claude projects, breaking a task into subcomponents and delegating the subtasks to other Claude Code instances. Another important change is the ability to read AGENTS.md if CLAUDE.md isn’t available.
• Google’s CC agent is designed for families. Family members can share data with CC, which has its own user account. It could be used for filling out forms, synchronizing calendars, and other common tasks.
• What will replace GitHub? There’s a growing consensus that we need different kinds of source repositories to deal with the agent-assisted software development. In addition to changes to code, it’s important to record the conversations between the developer and the agent, the architectural decisions, and many other artifacts that don’t make it into traditional source control.
• Anthropic is merging its Claude Cowork and chat products. Anything users type in a chat session is seen by Cowork, and vice versa. Some sensitive information (health, politics, and gender) is excluded. The feature is on by default but can be disabled in settings, and memory isn’t shared with Claude Code. The company also released Claude Docs and Slides.
• Claude Money is a new feature that will allow users to connect their bank accounts to Claude for analysis. The product appears to be similar to a product from OpenAI.
• OpenAI’s Agents API is now in public beta. It allows compaction, session orchestration, and tool use, and it can be deployed in OpenAI’s sandbox, a cloud provider’s sandbox, or the developer’s hardware.
• Meta has released Muse, its AI agent. Muse is a “personal agent” designed for tasks like shopping, filling in forms, and dealing with customer service. It has its own secure credential store, so data like passwords and credit card numbers are never sent offsite.
• Some open source projects are shutting down external pull requests, which are largely AI-generated. In some cases, the developer team is using its own agents to create and manage PRs; some are using AI agents to triage external PRs.
• Meta has launched Muse Code, another competitor to Claude Code. One important new feature is the ability to send messages to other Muse Code sessions, allowing agents to coordinate on complex problems.
• AI providers appear to be moving toward outcome-based pricing, at least for major corporate customers. Rather than billing by token, customers are billed for completed tasks. That approach begs the question: When is a task completed?
• Now that organizations are concerned with AI budgets, the question of how to evaluate the cost of different models and agents becomes important. What should platform teams measure?
• ChatGPT Work was designed to compete with Claude Cowork, Microsoft Copilot Cowork, Muse Code, and other agents designed for noncoders. Simon Willison shows how Work goes beyond its competitors. It can perform tasks on the web for users, even logging in to websites without sending usernames and passwords to OpenAI; it can execute code with full internet access; it can build and deploy a web application. Whether these features are also risks is an open question.
• Anthropic has given Claude Desktop access to a Chromium-based browser that’s built into Cowork, eliminating the need for a Chrome plugin when Claude needs to browse the web.
• TimeLord is a short Python program that, given a string up to 1,000 characters long, produces a seed for Python’s pseudo-random number generator so that repeated calls reproduce the text. It’s a surprisingly simple hack, though not a statement about randomness or the quality of Python’s PRNG.

Security

OpenAI’s experiment that attacked Hugging Face is the gift that keeps giving, but the past month has had plenty of news about more conventional attacks, many aided by AI. Security has always been a game of whack-a-mole, in which vulnerabilities are discovered and exploited as fast as defenders can patch them. AI is an important tool for defenders, and it’s constantly improving, but it’s still behind attackers, especially given the limitations placed on frontier models and the unlimited persistence that attacking agents exhibit.

• OpenAI has postponed the release of GPT-6.1 Astra because it failed its safety tests.
• NVIDIA has announced its Open Agent Safety Platform. The reference implementation includes NVIDIA OpenShell, which has been enhanced with a policy prover, and NVIDIA Sentry, a service that runs on NVIDIA DPUs.
• The Felony Bench lists known attacks by agents from the major AI labs against third parties. We don’t know if the Bench will be kept up-to-date, but tens of thousands of security incidents involving OpenAI and Anthropic are now being investigated.
• Following through on Dario Amodei’s call to control the speed of frontier model development, Anthropic, OpenAI, and Google are creating a standards consortium for governing the process of AI development. Meta, xAI, Microsoft, and the Chinese labs are all notably absent.
• Agents need their own identity. Unlike the long-term identities we’re used to, agents need a short-lived identity tied to a revocable certificate and that limits access to resources appropriate for the job. That’s not all of agent security, but it’s a table stakes.
• Anthropic has published a lengthy report on the misuse of its systems by threat actors. Daniel Meissler has published a summary, digesting Anthropic’s report into 117 findings.
• A malicious NPM malware package works by hiding malicious code in the package itself (indexed-btree) rather than simply attacking the install script. This technique makes it significantly harder to detect.
• An attack against the RSA algorithm allows forging of signatures in some situations. The attack was invented in 2007; this is the first public implementation.
• Fake CAPTCHA pages are being used to spread malware. Victims are frequently sent to those pages when they respond to a phish.
• Hugging Face has volunteered to audit AI labs for safety and alignment with human values.
• In an experiment designed to test AI alignment, DeepMind found that, out of 100 agents, 14% were willing to cheat, 25% were “whistleblowers” that reported cheating, and the remainder didn’t notice.
• Threat actors are building frameworks for AI agent-enabled attacks. A human in the loop is no longer needed. Fully automated attackers don’t appear to be using zero-days yet; they’re relying on known vulnerabilities.
• OpenAI autonomous AI agents were found communicating with each other via publicly accessible Wikis, possibly to collaborate on a benchmark.
• OpenAI has stated that its unreleased Astra model has reached the “Critical” cybersecurity threshold, which means that it can find new vulnerabilities and run exploits against well-protected systems. Now that Astra is released, access to its cybersecurity capabilities has been limited.

Infrastructure and Operations

Individuals, corporations, and even nations all face a similar problem: keeping their infrastructure under control. At a minimum, control means keeping data on a laptop, corporate server, or data center; at the other end of the spectrum it means eliminating dependencies on software and services from another nation. Any organization working through an AI transformation has to evaluate its entire stack: What do they need to control, and what can they safely delegate to others?

• DAWO is a community that’s building an open source “workspace” to support digital sovereignty for the Dutch government. The stack will include AI, an operating system based on NixOS, cloud services, and collaboration tools.
• Cohere now offers a confidential computing platform for artificial intelligence. The company claims that customer data is never visible to Cohere itself or any cloud providers that are in use; data is processed on GPUs whose memory is encrypted and isolated.
• Perplexity has announced Hybrid Compute, a feature that allows it to run models and use files and tools directly on a user’s Mac. The company claims that sensitive data will never leave the user’s computer.

Hardware

It’s too easy to view consumer devices as innocuous things that sit around and do their job silently. Recent devices include cameras, microphones, and even EEG sensors that are constantly collecting data. Where is that data sent, how is it used, and who might have access to it? These questions need to be asked more often.

• LG Smart Televisions have been found to record conversations and other audio, even while turned off. The conversations are sent back to LG. If the set is disconnected from the network, it will attempt to find open WiFi access points to deliver its data.
• In part because of backlash against Meta’s camera-enabled glasses and their abuse, its AI glasses now come with or without a camera, and can be used as hearing aids. Well-documented abuse aside, virtual reality will only succeed if there are fashionable, easily wearable products.
• Headphones, earbuds, and other devices equipped with EEG sensors are appearing on the market. They’re advertised for monitoring fatigue, monitoring sleep, and similar applications. It’s time to ask what happens at the interface between neurology and AI.
• Microduck is a small bipedal AI-driven robot. It’s trained in simulation with open source software, and the model that results can be shared on Hugging Face. It’s affordable and is available for preorder now, shipping by Christmas.

Web

• Cloudflare now supports HTTP Vary, which allows servers to serve different kinds of files at the same URL. This is the “ugliest part” of the HTTP standard. It makes caching very difficult, and it probably should be avoided.
• WebMCP is a proposed standard that gives websites a small API to register tools that agents can discover and call. It was developed by Google and Microsoft.
• A new Twitter? Operation Bluebird is relaunching Twitter, the service bought by Elon Musk and renamed X.

Biology

• Anthropic has built a biology lab for experimenting with AI-enabled drug development. Claude assisted in the discovery of an enzyme that might be able to perform CRISPR-like gene editing.
• To improve its training data for biological applications, the OpenAI Foundation (OpenAI’s nonprofit parent organization) is buying data from failed biotech companies.
• Google has released AlphaGenome Atlas, a database of every possible single letter change to human DNA, and what that change will do.

Developers already have useful capabilities exposed through REST APIs. The Model Context Protocol (MCP) lets developers make those capabilities available to AI clients without rebuilding the underlying application.

In this episode of Zero to Agent in 30 Minutes, Bruce Hopkins, an AI developer, author, and longtime software educator, shows how to do that with an MCP server. His demo wraps an existing stock-data API in an MCP server so an MCP client can call it.

From REST API to MCP, step-by-step

1. Start with an existing API. Identify the operations and data you want an AI client to access. The demo uses the Twelve Data API to retrieve current and historical stock prices.
2. Create an MCP server. Use an MCP SDK to create the layer between the AI client and your existing application logic. In Bruce’s Python example, FastMCP handles the MCP interface while the stock-data functions remain separate.
3. Expose capabilities as tools and resources. Register the operations the client should be able to discover and call. The stock-price data is exposed through MCP resources and tools that reuse the same underlying functions.
4. Describe how the client should use them. Define clear names, inputs, descriptions, and prompts so the client understands what each capability does and what information it requires. Bruce’s example includes prompts for current prices, historical prices, and expected symbol and date formats.
5. Connect the server to an MCP client. Run the server over a supported transport so the client can discover and call its tools and resources. 

You don’t need to replace the systems that already handle your application logic to help them work with agents. You can add an MCP interface around existing capabilities to give an AI client a standard way to discover and use them. Be sure to check out Bruce’s GitHub repo for working code you can adapt for your own APIs.

Coming next week

Next week, AI engineer Sajal Sharma returns to Zero to Agent in 30 Minutes to build a personal assistant on OpenClaw. He’ll show how an agent can keep tasks and notes in Markdown, run proactive automations, and deliver scheduled updates such as a regular morning briefing without waiting for a new prompt.

Follow along with Zero to Agent in 30 Minutes on Radar, or watch the latest episode on YouTube, Spotify, Apple, or wherever you get your podcasts. If you’re an O’Reilly member, you can watch live. Save your seat.

The following article was originally published on the Agentic AI Foundation blog site and is being republished here with the author’s permission.

A customer asks your company’s AI agent to update the shipping address on account 123. The agent relies on a support ticket with a typo and updates account 132 instead. The customer relationship management system reports that the update “succeeded.”

The API successfully completed the authorized request, but because it had no way to know which account the customer approved versus what was intended, it saw no error.

Teams often try to improve reliability by tuning the prompt or choosing a stronger model. But the model did exactly what the surrounding system allowed because the system treated the agent’s decision as the final authority. Prompt tuning and stronger models can improve the agent’s responses, but can’t provide guarantees for actions.

Put each decision in a layer that can enforce it

The model should propose an action, while a policy service decides whether the action is allowed. The execution layer can then perform the action within those limits.

Now consider that same agent, but with a policy service in place. The agent would propose updating an account after reading a support ticket. Before the update runs, a policy service can compare the request with the change the user approved. If the request falls outside those limits, the service can reject it even when the agent sounds confident.

After the policy check, the system can save an audit record that connects the request to the result and identifies the policy version used for the decision.

This separation gives each part of the system a job it can handle. The model interprets the request, while deterministic software enforces the conditions that must always hold.

However, policy enforcement depends on the information used to request an action. A policy check can’t correct a decision that was built on context the system should never have trusted.

Treat agent context as untrusted input

Agents receive instructions from more places than the user’s current prompt. A coding agent may read a SKILL.md file or persisted memory from a previous run. Each source can influence what the agent does next.

Stored instructions are useful, but their source may be stale or malicious. Another agent may have written the memory. A downloaded skill may contain instructions that expose credentials.

Therefore, stored context needs provenance. The system should record who wrote the context and when, then verify that linked files still match the versions the writer used. A risk label can also tell the runtime whether a piece of context may guide an answer or authorize a write.

Warnings help, but they don’t remove the risk. In controlled testing described in “Trustworthy Context Is Untrusted By Default,” Shub Argha reports that a trust preamble reduced one class of context contamination from 88.8 percent to 33.3 percent. The remaining failures show why a warning should sit alongside technical checks.

Once a team can tell where context came from, the next decision is what an agent may do with it.

Give the agent only the authority required for the task

OAuth scopes provide a useful boundary, but a broad write scope still leaves a large decision to the agent. The token may allow the agent to update any record even though the user approved one field on one account, as we saw in the opening example.

A narrower capability can represent the exact action the user approved. For example, the runtime could issue a capability that permits one update to the shipping address on account 123. The capability expires after the update, so the agent cannot reuse it for another customer.

Narrow capabilities also apply to local execution. An agent that needs to format one file doesn’t need unrestricted shell access. The runtime can provide a tool with the necessary input and keep other commands unavailable.

As a result, a prompt injection has less authority to work with. The agent may still request the wrong action, but the runtime can reject anything outside the capability it received.

Narrow permissions also make audit records easier to understand because the record contains the authority granted for that specific action. When authority lives in a broad token or a long prompt, an operator has to reconstruct what the agent was supposed to do after the failure.

Even narrow authority doesn’t require an agent to act. A reliable system also needs clear conditions for when the agent should stand down.

Make stopping part of normal operation

An agent can cause damage even without calling a sensitive tool. It can post a wrong answer to a customer or keep replying after a human has taken over.

The runtime should make restraint part of the workflow. If the agent’s confidence falls below a set threshold, the runtime can route the support ticket to a human representative. A reply from the human can then cancel any pending response from the agent.

Confidence checks and rules that stop the agent when a human takes over belong in the routing and execution layers. The model shouldn’t make either decision on its own. Similarly, a kill switch must stop an agent even when the model is in the middle of a plan.

Stopping safely solves one part of reliability, but long-running agents also need a plan for failures that occur after valid work begins.

Preserve state so the system can recover

Consider a browser agent that has filled out most of a form when the page changes. A retry that starts from the beginning could submit an earlier step twice, while a retry that guesses where to continue may skip a required field.

The execution system should record each confirmed step and attach an idempotency key to any action that must happen once. The key is a unique identifier that tells the server a retry belongs to the same action. Then, when the workflow resumes, the system can continue from the last confirmed state without repeating a completed action.

Agent sandboxes create a related problem. Keeping every sandbox running during long idle periods wastes resources and keeps execution environments available longer than needed. Hibernation can reduce both concerns, but only when the wake-up process restores the required state and handles a failed resume.

Recovery becomes much harder when the system can’t explain what happened before the interruption.

Keep evidence that people and agents can inspect

An execution log should connect the context an agent received to the action it requested. It should also show which policy allowed the action and what result came back.

Teams can use that record during an incident, but the agent can also use it during later work. For example, an agent that can read the reason behind a previous code change doesn’t need to infer intent from the final diff alone.

Context graphs offer one way to preserve those relationships across time. A graph can connect a tool call to the policy that governed it. The same record can link the source context to the outcome. Later, a person or agent can query the relationships to understand why the system made a decision.

The record still needs limits. Secrets shouldn’t be copied into an audit trail, for example, and retention rules should match the data involved.

A deliberate record is safer than relying on a conversation transcript and hoping it contains everything an operator will need.

A reliable agent system can explain why an action was allowed and resume safely when that action fails. Enforceable policies and recorded state provide those guarantees around the model.

Keep the controls portable

Many organizations will use more than one model or agent runtime. When each agent carries its permissions inside a prompt, the rules can drift as teams add models and tools.

MCP gives clients and servers a shared way to describe and call tools. Teams can use that common tool surface to enforce authorization at the server or gateway, regardless of which model requested the action.

A shared context format can also preserve provenance when a workflow moves between agents. Open specifications provide consistent interfaces, while each deployment remains responsible for its policies and enforcement.

On the latest episode of This Week in AI, host Vicki Reyzelman, a senior solutions engineer at Akamai, traced a common problem across cybersecurity, energy, model releases, consumer hardware, and regulation. AI agents can now probe networks, coordinate with other agents, make purchases, and interact with real-world systems faster than many organizations can respond. We’re seeing those capabilities move into systems built for slower, more predictable software.

Security has to operate at agent speed

Vicki opened with an incident in which an OpenAI agent reportedly found ways around security controls while researching public information in Australia’s Medicare system. The activity didn’t expose any  personal Medicare records, but OpenAI reportedly took 54 days to identify the incident and another month to notify the government. A response cycle measured in weeks can’t keep pace with systems that can test defenses in seconds.

She also brought up the recent Hugging Face incident involving a swarm of 1,200 agents that exchanged roughly 70,000 messages while coordinating their work. Agents can change tactics faster than traditional security processes play out, so teams can no longer rely on the familiar methods of addressing suspicious behavior. Companies are now experimenting with runtime enforcement, agent sandboxes, enterprise browsers, and other controls that sit closer to execution.

Policymakers are searching for workable controls too, from California proposals for emergency AI shutdown mechanisms to international discussions about independent model evaluation. Teams can’t govern agent behavior they can’t see, so they need to know what an agent did and when its behavior crossed a boundary.

Power and latency are becoming model decisions

Power is one constraint software teams can’t code their way around. Vicki pointed to a $2 billion US Department of Energy investment across 26 states alongside hundreds of billions of dollars in planned AI spending from Microsoft, Amazon, Alphabet, and Meta. Data centers can add servers quickly, but it won’t make a difference if the grid can’t provide the energy those servers require.

Meanwhile, major model releases are arriving roughly every 17 days, with context windows now exceeding one million tokens. Open weight and edge models are advancing too, particularly around low-latency reasoning. More frequent releases and heavier inference workloads put added pressure on networks, compute, and budgets.

Solving this challenge may mean companies have to run more reasoning at the edge or locally, where systems can reduce latency and avoid sending every request across the network. That gives teams another architectural choice to make alongside model selection. A frontier model may be appropriate for one workload, while a smaller local model may be faster and cheaper for another.

Consumer agents move autonomy into everyday life

Consumer hardware puts those architecture and governance choices directly in users’ hands. AI-enabled glasses, pendants, and other devices stay with users throughout the day and can learn preferences, connect with outside services, and take actions such as shopping or making reservations. Meta’s new Muse agent is one example of that shift.

Meta says the Muse ecosystem already includes roughly 1,500 developer connectors, including integrations with retailers such as Walmart and Best Buy. If more purchases begin with an agent acting for the customer, companies may have to rethink how people discover products and complete transactions. The convenience of Amazon Prime and one-click shopping, for example, looks different when another system is comparing options and buying on a user’s behalf.

Muse already ran into problems, including exposing information it wasn’t supposed to and relying on humans to complete some tasks, such as making dinner reservations. Those failures carry more weight when the software can spend money or act on personal preferences. Users and businesses need clear limits on what an agent can access, what it can do without approval, and how those actions are recorded.

What’s next

Deploying an agent means taking responsibility for the systems around it. Security controls, power and network constraints, local versus remote inference, and permission boundaries all shape what these systems can safely do in production. For practitioners, the job now includes the architecture around the models.

Join us again next Monday for another episode of This Week in AI, when we’ll dive into more of the news and developments shaping the AI era. And check back each Friday for the latest episode, or watch on YouTube, Spotify, Apple, or wherever you get your podcasts. You can also hear more from Vicki on her Substack.

The following article originally appeared on Duncan Davidson’s blog and is being republished here with the author’s permission.

Decision records give coding agents durable project context—as long as they don’t turn every decision into a courtroom transcript.

Architectural Decision Records (ADRs) help human teams establish rules and carry context forward in software projects. They capture significant design choices, their context, and the reasons behind them. Like many tools built for human software teams, ADRs work well for coding agents too.

Agents often arrive with little memory of yesterday and only a narrow view of a codebase. Even systems with persistent memory may preserve context without establishing whether it is accurate, current, or accepted by the human team. Decision records help them understand the intent behind the code rather than having to infer it. Keeping them in a project repository spares agents from having to trawl through issues, search chats, and perform code archaeology. When you record intent explicitly, an agent is less likely to mistake an implementation detail for a foundational rule.

Once a decision enters an agent’s context window, the agent may adhere to it even more rigidly than a human would. In my own work, I’ve seen agents fight tooth and nail to apply an accepted decision even when it is obsolete. In one case, an agent preserved an outdated storage abstraction across a new feature because an ADR still described it as mandatory. Instead of flagging the mismatch, it added another layer to keep the new requirement technically compatible with the old ruling.

The first remedy is to give agents explicit permission to question decisions that no longer fit—and to watch for signs that they’re overfitting. But that solves only half the problem. When you invite an agent to update a decision, a second tendency appears: preserving the deliberation. Every clarification becomes an amendment explaining its own existence at the expense of clarity. Small implementation details become rules, and cross-references acquire their own restatements and justifications. The result is overlitigated prose that is hard for humans to read.

ADRs should absolutely be readable by humans, especially as we lean on agents to generate more and more code. To counter this, I’ve become explicit in my projects’ AGENTS.md files about how agents should apply and maintain ADRs. Here’s an excerpt from one:

Architectural Decision Records (ADRs) are stored as Markdown files in the
docs/decisions directory. Treat accepted ADRs as binding. Proposed ADRs
are non-binding context. Superseded ADRs are historical context and do
not govern current work. If a given task conflicts with an accepted ADR,
stop and discuss whether the task or ADR should change and propose the
change that you think should be made. Propose new ADRs or updates to
existing ones when a change introduces or revises a durable product or
architectural decision.

Keep ADRs succinct. Each ADR carries only its current text; Git history
is its changelog, so do not add or maintain amendment logs in ADR
headers. When substantively changing an accepted ADR, add or update a
single Updated: date line after Date:—its presence signals that history
exists and Git has the details. A superseded ADR records a Superseded-On:
date instead of Updated: , matching the Supersedes: line on the ADR that
replaced it. State each rule once in the ADR that owns it and cross-reference
it from other ADRs instead of restating it.

These instructions are still evolving in my projects, and different projects will need different conventions. Some teams will prefer immutable ADRs that are superseded rather than revised; in my projects, I’m happy to have Git carry that history.

If you do something similar, adapt the guidance to your own needs. The essential principle is that each governing ADR should describe the decision currently in force, with enough rationale to apply it. An agent doesn’t need the transcript of every argument. It needs the ruling that governs today and clear permission to stop when the ruling no longer fits.

The following article originally appeared on Robert Englander’s blog site and is being reposted here with the author’s permission.

The software industry has become deeply focused on autonomous AI systems. Agents that can replace workers. Agents that can write software. Agents that can operate applications on our behalf. Entire startups are now built around the assumption that the natural end state of AI is autonomy.

Some of this work is genuinely useful. AI-assisted coding can improve productivity. Generative systems are already helping people draft documents, summarize information, and accelerate certain kinds of repetitive work. There are clearly domains where more automation makes sense.

Still, I increasingly suspect the industry may be underestimating another opportunity that feels both more practical and potentially more transformative over the long term: natural language interfaces sitting on top of deterministic software systems.

Much of the current AI narrative assumes the model itself should become the authoritative actor. The AI writes the code. The AI performs the workflow. The AI executes the task. The AI makes the decision. The conversation around “agents” often assumes the system itself should gradually absorb more and more of that responsibility until people become optional.

The problem is that large language models are probabilistic systems. They’re incredibly capable. But they’re still statistical machines. They hallucinate, improvise, approximate. In many contexts, that’s perfectly acceptable.

Brainstorming, summarization, drafting, translation, and exploratory work all tolerate a degree of uncertainty. Deterministic systems generally don’t.

Financial systems have to calculate correctly. Scheduling systems have to preserve consistency. Medical systems have to maintain integrity. Accounting systems have to reconcile accurately. Reliability is still the foundation upon which useful software is built.

That’s one reason I think the most important role for LLMs may not be replacing deterministic systems, but reducing the friction between people and those systems.

Historically, software interfaces forced people to adapt to machine discipline. We learned command syntax. We navigated menus and workflows. We memorized procedures. We filled out forms in exactly the way the application expected. Even graphical interfaces, which were a huge leap forward, still largely required users to think in terms of the structure of the software itself. Natural language interfaces potentially invert that relationship.

Instead of forcing users closer to the system, the system moves closer to human expression. That may sound subtle, but I think it represents a significant shift in how software can be experienced. A user no longer needs to think primarily in terms of application structure or workflow design. The interaction begins to center more naturally around intent.

“Show me how delaying Social Security by two years impacts long-term spending.”

“Transfer $500 from checking into savings next Friday.”

“Why did my tax liability increase this year?”

“Find the contracts signed after January that contain auto-renewal

language.”

None of these requests eliminates the need for deterministic systems underneath. In fact, they depend on them. The natural language layer simply acts as an interpreter between human expression and authoritative execution.

That architecture feels considerably more durable to me than the idea that probabilistic systems should become the primary authority layer themselves.

One interesting thing about the current AI wave is that language models are often strongest in areas involving interpretation. They’re remarkably good at extracting meaning from ambiguous human communication, maintaining conversational context, translating between representations, and helping users express intent more naturally. Those are fundamentally interaction problems.

Meanwhile, the areas where language models remain weakest are usually the areas requiring guarantees, consistency, accountability, and deterministic correctness. Those are system-of-record problems. The current industry conversation often blurs the distinction between the two.

I don’t think conversational interfaces reduce the importance of deterministic software. If anything, they increase it. Once users begin interacting through natural language, the validation layer underneath becomes even more critical. Systems have to safely interpret intent, validate operations, preserve constraints, and maintain correctness even when the incoming requests are conversational and ambiguous.

The conversational layer improves accessibility. The deterministic layer preserves trust.

Both matter.

Every major era of computing has involved some kind of interface transition. Mainframes required specialized operators. Personal computers brought graphical interfaces that made computing accessible to nonspecialists. The web normalized hyperlinks, search, and forms. Mobile computing shifted interaction toward touch and gestures. Natural language may become the next major abstraction layer.

Not because computers suddenly became human-like, but because we finally built systems capable of translating between human communication and machine discipline at scale.

I also think this changes how we should think about software’s future. The current AI environment sometimes frames autonomy as the inevitable destination. If an AI can partially perform a task today, many assume the long-term outcome is full replacement of the person performing that task.

I’m not convinced that’s where the most durable value lies.

In many domains, the real friction isn’t execution. It’s interface complexity. People struggle less with the underlying capabilities of software than with the difficulty of expressing what they actually want the software to do.

Enterprise systems are notoriously difficult to navigate. Financial systems expose overwhelming complexity. Creative tools bury users under layers of workflow and terminology. Even relatively simple applications often require substantial onboarding before users become comfortable with them.

Natural language interfaces potentially change that equation in a meaningful way. They allow software to meet users closer to where they already are: ordinary human communication.

That doesn’t mean conversational systems should become undisciplined systems. In fact, I think the opposite is true. As interfaces become more conversational, the underlying architecture has to become even more rigorous about validation and execution semantics. The ambiguity doesn’t disappear. It moves.

Historically, much of the burden of precision sat on the user. The user had to learn the syntax, understand the workflow, and conform to the application’s structure.

Conversational systems shift more of that burden into the interpretation and validation layers of the software itself. That’s not a trivial engineering problem. It requires clarification, normalization, policy enforcement, validation, and authoritative execution underneath the conversational layer. It also requires accepting that probabilistic interpretation and deterministic execution aren’t competing ideas. They’re complementary ones.

This is one reason I increasingly think the future of software may become conversational without necessarily becoming autonomous. The two ideas are related. But they’re not the same thing.

There’s enormous value in reducing the natural friction between human expression and machine discipline. Large language models may ultimately prove most transformative not when they replace deterministic systems, but when they help people interact with those systems more naturally.

For decades, people have adapted to computers. It now seems possible that software may finally start adapting to people instead.

The following article originally appeared on Vanishing Gradients and is being republished here with the authors’ permission

When an AI agent can explore a dataset, choose a modeling approach, run the analysis, and explain its findings, what should the data scientist do?

Traditionally, data scientists chose each step and implemented much of the analysis themselves. Agentic data science changes that division of work: we can delegate an investigation, including methodological choices, while shaping the question, supplying relevant expertise, and challenging the evidence it produces. For AI-native data scientists, choosing the runtime, writing reusable skills, and designing the workflows and feedback that guide the agent are part of the analytical work.

This article provides a playbook for working with data science agents, from setting up an investigation to reviewing its results and carrying lessons into the next assignment. To see why that requires more than a capable model and a business question, consider an experiment we deliberately started with too little guidance. We gave Claude Opus 5.0 a modified version of the public Elliptic dataset and asked, “Build me a model to detect fraudulent nodes.” The dataset is a graph of Bitcoin transactions: each node is a transaction, and an edge represents a flow of bitcoin between transactions. Some transaction nodes carry licit or illicit labels based on the entities that created them; the rest are unlabeled. Each node has a time step indicating when its transaction was broadcast, allowing us to train on earlier time steps and test on later ones. We also wanted separate results for transactions with many connections (high-degree nodes), which mattered most in the intended application. Importantly, we renamed the columns, changed several features, and reindexed the time steps while preserving their order, making the public dataset harder for Claude to recognize.

Claude wrote the code, trained a random forest, and reported an F1 of 0.87 and ROC AUC of 0.99. It had split transactions randomly, mixing earlier and later time steps in both the training and test sets. That test did not measure how the model would perform on transactions from later time steps. Moreover, Claude also used a feature we had planted as a proxy for the fraud label (yes, we tricked it!), giving the model leaked information it would not have when scoring a new transaction. So how do we avoid these situations?

We then supplied the guidance missing from the initial prompt:  We required a temporal holdout, removed the leaking feature, supplied context about how the model would be used in production, and asked for separate reporting on the high-degree nodes that mattered most. Under the corrected evaluation, F1 was 0.70, overall recall was 0.61, and recall on high-degree nodes was 0.21.

The key point is that “Build a fraud detector” left Claude to infer how the model would be used and what would count as success. AI-native data scientists build and direct an analytical process in which agents can investigate, receive feedback, and return evidence for review. The work begins with deciding how much of the investigation to delegate.  Agentic data science is doing data science work with AI agents as teammates. Crucially, the scope of their responsibility can extend well beyond code implementation. An agent can help frame a question, explore data, test a claim, or communicate a result, provided it has the context and tools to do the work, a way to assess its progress and validate its results.

Asking an agent to write a pandas transformation leaves you as the bottleneck, responsible for deciding every next operation. Asking it to investigate a change in customer behavior gives it larger analytical responsibility. It can inspect a result, form another question, choose a method, and continue. The interaction becomes a conversation about the investigation rather than a sequence of requests for code.

The question may be descriptive (what happened?), diagnostic (why did it happen?), predictive (what might happen next?), or prescriptive (what should we do?). The fraud model is predictive; the pricing investigation later in this article is diagnostic and causal. Across these kinds of work, we need to specify the question and intended use, then verify that the evidence supports the answer.

The following five practices are key to agentic data science:

• Frame the investigation.
• Equip the agent for the assignment.
• Organize the work through bounded experiments, competing analyses, or both, according to the question.
• Review the result independently.
• Preserve evidence and turn reviewed lessons into reusable expertise.

The first two practices set up the work. The third determines how the investigation proceeds; the fourth tests its claims. Evidence is captured throughout, and the fifth practice carries reviewed lessons into future assignments.

As in agentic software engineering, the agentic data scientist’s two central responsibilities are specification and verification. Specify the question, intended use, and evidence the agent should produce; then verify that its analysis supports the conclusion. Agents can help with both, while the data scientist remains responsible for judging the question and the evidence.

1. Frame the investigation with the agent

Start by discussing the assignment with the agent. Supply the intended use and organizational context, then let it inspect the data and propose an approach. Method selection can be part of its responsibility. Your intervention matters when a proposal changes the question, rests on a questionable assumption, or needs information the agent cannot obtain. Predicting fraud and deciding which flagged entities to investigate, for example, require different evidence about errors and their consequences. A brainstorming skill such as those in Superpowers can help structure that conversation before you turn it into a task prompt.

A useful specification records that shared understanding. It states the decision, relevant constraints, and evidence the investigation should produce. It need not prescribe every step. In the fraud example, “classify transactions from later time steps using only information available when each is scored” matters more than “use a random forest.” The former defines the analytical task, while the latter selects one possible implementation.

You can specify what the investigation must establish without specifying the answer you want. “Determine whether the data support a recommendation” leaves room for an inconclusive result. “Keep trying until you find an effect” does not.

Turn that discussion into a short analytical brief to give the agent as its task prompt. For an assignment like our fraud example, a starting version could read:

TASK PROMPT:
Question: Can we identify fraudulent nodes as they enter the network?
Use: Support investigation, with separate reporting on high-degree nodes.
Available information: Only inputs known when the node is scored.
Agent discretion: Explore data, propose eligible features, choose models.
Return to me: Unclear feature provenance, changes to the target or
population, or a trade-off that requires an operational decision.
Deliverable: Reproducible analysis, temporal evaluation, subgroup errors,
and a recommendation that states what the evidence cannot establish.

Review it with the agent before the investigation proceeds. If exploration reveals that the evidence cannot answer the question, revise the brief explicitly; do not quietly substitute an easier question.

The deliverable may still be a notebook, model, or report prepared outside a production service. You can begin in the workspace where you already do that work.

2. Equip the agent for the assignment

The task prompt tells the agent what to investigate. It also needs to know how the project works, reach the data, run the analysis, and check the result. The harness is the system around the language model that allows this: its tools, runtime, context, permissions, and feedback from its actions. Its runtime is the environment that executes those actions. A language model alone cannot inspect a warehouse, run a simulation, or recover an interrupted statistical model fit. The environment must make those operations possible and return useful evidence about what happened.

Runtime choices are analytical choices as well as engineering choices. Can the agent execute Python or R with the libraries the task needs? Can a long-running fit continue after an interactive session ends? Which scientific libraries should the agent use? Can the agent inspect plots, or does it only see the code that produced them? Can you reproduce the environment in which it reported a result?

An existing agent runtime may provide most of this. Configuring it means deciding what belongs in Markdown, what needs a tool, and what should be checked by a small script. In an investigation like the fraud example, Markdown can hold the brief and data definitions, while a Python script could check that the appropriate temporal validation split is executed. A CSV data extract may be enough for exploration; if the agent needs data warehouse access, a tool exposed through an MCP server can provide it with appropriately scoped, read-only credentials. A sentence in a prompt cannot enforce that access limit.

Take the same care with outputs. Ask the agent to preserve the data reference, code, environment, assumptions, and diagnostics behind its report. A chat transcript is a poor substitute for a runnable analysis. Review becomes much harder when the only surviving artifact is a confident paragraph about what the agent says it did.

Execution is only part of the problem. An agent may know how to fit a model and still misunderstand what the columns mean. It may find five revenue tables and choose the wrong one. A schema rarely explains which customers were eligible for an offer, when a measurement changed, or why the team stopped using an apparently reasonable metric. This is where agent skills and domain knowledge enter. A skill packages instructions and resources for a type of analytical work. It might contain a modeling approach, example code, required diagnostics, and guidance on when to ask for help. Data documentation supplies the organizational meaning: canonical definitions, table grain, known limitations, and the history needed to interpret a result.

A useful skill is specific enough to change the agent’s behavior. “Be rigorous” gives it little to work with. A fraud-modeling skill can require the agent to establish feature availability, evaluate on later observations, and report performance on operationally important subgroups. For example:

For fraud prediction:

Establish what information is available when a node is scored.

Exclude features derived from subsequent investigations or labels.

Fit preprocessing on training data only.

Evaluate on later-arriving nodes and report the required degree groups.

Flag uncertainty about feature provenance before claiming performance.

These instructions leave room to choose a model. They encode reasons that some apparently successful models should be rejected. Where a requirement can be checked reliably in code, the skill can call a script that performs the check and records its result.

Loading every method and every document into every assignment is unnecessary. Give the agent a way to find relevant expertise, including its scope and exceptions. A forecasting skill should not silently impose its evaluation rules on an unrelated retrospective analysis. Nor should a notebook from last year outrank an updated metric definition merely because it offers convenient code to copy.

To put these pieces together locally, begin with a file-and-code agent in a sandboxed project workspace, such as the following:

fraud-investigation/

  AGENTS.md                # Project instructions, where supported by the runtime

  brief.md                 # Agreed question and delegation boundaries

  data-notes.md            # Sources, column meaning, availability times

  skills/fraud.md          # The methodological guidance above

  environment.lock         # Dependency versions, in your tool’s format

  model/                   # Code the investigating agent may change

  results/                 # Experiment log, diagnostics, saved candidates

  review.md                # Acceptance decision and unresolved questions

Use a project instruction file, such as AGENTS.md in runtimes that support it, to explain which context files the agent should read and how to propose updates to them. In other runtimes, provide those instructions through the supported mechanism. Give the sandbox read access to the approved development data and write access to the model and results directories. Keep the final test data outside of the agent’s accessible workspace. The practitioner can run acceptance checks in a separate environment whose evaluator and data the investigating agent cannot modify. A different folder, or version control alone, is not an access boundary.

Now ask the agent to inspect the inputs, identify unresolved questions, and build a baseline. Before allowing repeated experiments, rerun that baseline and examine its feature-availability record, split dates, and subgroup report. This small rehearsal checks whether the setup works all the way from instructions to evidence. A missing subgroup report points to a different problem than a failed package installation. Resolve those problems before giving the agent a longer run.

3. Organize the investigation

With the question framed and the agent equipped, the next choice is how to organize its work. This depends on the intent of the data science problem. For descriptive work, exploratory data analysis may proceed one question and plot at a time. Building a predictive model may support repeated experiments against a fixed evaluator; a causal question may require comparing analyses built on different assumptions.

In a live exploratory analysis on Show Us Your Agent Skills, Eric Ma (Moderna) uses a marimo notebook as a shared workspace with an agent. He explains the protein mutation data, asks for one plot at a time, corrects a color scale that affects interpretation, and chooses the next question from what he sees. The agent edits the notebook and renders the plots; Eric supplies the domain context, checks the artifacts, and owns the interpretation. The reason Eric needed to be in the loop was that human understanding was part of the objective function here!

Use a bounded experiment loop

For predictive modeling, the autoresearcher pattern organizes the work into a repeatable loop: propose a hypothesis, change the model, evaluate it, and keep or revert the change. The agent records each result and uses it to choose the next attempt. Within the scope you give it, it can explore features and model structure as well as parameter values. This is an inner loop within a broader investigation: the data scientist frames the question and sets the evaluation, the agent searches within those boundaries, and the data scientist reviews the result (potentially using an independent agent) before deciding what to do next.

Define what the agent may change, protect the evaluator from those changes, and set a time or compute budget. This makes iteration a bounded task within the investigation.

A compact experiment contract could say:

Improve the supplied baseline within the agreed compute budget.

You may change model code and propose eligible features.

Keep the target definition, validation split, and evaluator fixed.

Record each hypothesis, change, result, and keep-or-revert decision.

Stop at the budget limit or escalate if the evaluation is unsuitable.

Return the best candidate and the experiment history for review.

In a separate exercise with its own baseline and evaluation, we used this pattern to improve a graph neural network trained on the network data from the opening example. We used lower validation loss as the rule for keeping a change; F1 for fraudulent transactions was a separate measure of the resulting classifier. The agent ran 41 experiments while the team slept and retained seven changes that reduced validation loss. On the validation set, loss fell by about 70%, and F1 for fraudulent transactions rose from about 0.72 to 0.82. The log preserved both successful changes and failed attempts, so we could examine how it reached the result.

One candidate had the highest F1 for fraudulent transactions, but the agent rejected it because its validation loss was higher. That followed the selection rule we had set. The experiment history records that choice for the subsequent review.

The autoresearcher pattern works when an objective gives the agent useful feedback on each attempt. But some investigations turn on which assumptions to make, not which candidate scores best. Those tasks need a different way to organize the agent’s work.

Investigate competing explanations

In causal work, no held-out outcome directly reveals what would have happened without an intervention. The agent needs to examine how different analyses construct and test that counterfactual.

In a demonstration from our Master Agentic Data Science course using simulated subscription-business data, we asked: “What did the price increase cost us?” The outcome is daily conversion rate: paid conversions divided by the pool of potential subscribers. Choices about the observation window, counterfactual, exclusions, and validation produce different analytical paths. A final memo usually shows only one.

Two agent runs estimated conversion roughly 16% below their no-price-increase counterfactuals, yet shipped opposing claims.  Run A attributed its estimated drop to a changing pool of potential subscribers and concluded there was “no real effect,” but did not validate that explanation.  Run B backtested its counterfactual, ran a placebo check, and compared six specifications. It reported a robust relative reduction of 15.6%.

The parallel-analysis pattern has independent agents test different choices in the same investigation: one examines the observation window, another tests seasonal assumptions, and we compare their estimates, uncertainty, and diagnostics. Our Decision Lab work extends this approach across analytical paths, using checks to identify unsuitable analyses and unresolved disagreements.

Both approaches give the agent feedback while it works. The fixed evaluator steers the model experiments; diagnostics help it compare causal analyses. The output is a candidate and experiment history, or a set of analyses with their assumptions and checks. Those are the materials for the next task: verifying the claim.

4. Review the result independently

The agentic data scientist now needs to check what that evidence supports, and a fresh agent can help. Give an independent agent reviewer the original brief, data context, code, diagnostics, and final claim. Ask it to reproduce decisive checks and challenge assumptions. In this adversarial review pattern, the agent raises objections it can substantiate; the data scientist judges whether they change the conclusion.

In the fraud exercise, the agent used the same validation data to guide 41 experiments, so the reported gains may partly reflect what worked on that set. Freeze the selected candidate and assess it on an untouched holdout chosen for the intended use, including errors in the groups that matter.

In the pricing exercise, a fresh reviewer challenged Run A’s conclusion. Run A attributed the estimated decline to a changing pool of potential subscribers but provided no evidence for that explanation. The reviewer found that conversion had been rising before the price increase and that placebo interventions in earlier periods did not reproduce the negative effect. Run B’s analysis, which included these validation checks, was selected in the final comparison.

Netflix’s agentic workflow for causal inference implements this division: an actor performs the analysis and diagnostics, while a critic challenges the reasoning and claims. Humans can inspect and rerun the artifacts.

A fresh agent session is not necessarily an independent review if it can read the investigator’s earlier attempts through the workspace or Git history, though! For a check meant to stand on its own, give the reviewer the original brief, final artifact, and data needed for that check, while limiting access to the prior path. The full experiment trail can be examined separately when auditing how the result was reached.

These examples call for different balances of human and agentic verification. In Eric Ma’s EDA, the agent makes plots while Eric checks them and chooses the next question. In the bounded experiment loop, a fixed evaluator checks each candidate before a person reviews the selected model. In the pricing analysis, agentic diagnostics and critique help a data scientist judge what the evidence supports.

The low-low quadrant leaves little basis for trusting a result (in fact, it’s “vibe data science!”). Repeatable checks can move some work toward more agentic verification, while questions that depend on domain understanding or consequential decisions continue to need human judgment.

5. Turn reviewed experience into reusable expertise

The experiment loop and adversarial review both depend on an evidence trail: the saved artifacts that show what the agent did and why a conclusion survived or changed. Preserve that trail throughout each investigation, including data references, code versions, analytical choices, experiment results, diagnostics, and review findings. Keep the failed alternatives and review findings as well as the final report.

This trail has a second use beyond inspecting the current result. Reviewing it with the agent can reveal missing context, recurring mistakes, or methods worth reusing. The next question is which of those lessons should change how the agent approaches a future assignment. Leaving them in a conversation makes that learning difficult to carry forward.

In the fraud example, we deliberately planted a feature that leaked the fraud label. Removing it corrected that analysis. The reusable lesson is to have the agent check proposed features for leakage: where did each feature come from, and would it be available when a new transaction is scored? That requirement can go into a fraud-modeling skill for future investigations.

Before making a lesson into standing guidance, we need to define where it applies. The planted feature was a problem because it carried information unavailable at scoring time, not because it predicted fraud well. The temporal split likewise fits a task involving transactions from later time steps; it is not a rule for every analysis. A skill should capture those conditions so the agent applies the lesson to the right task.

For example:

Lesson: a feature encoded information from the fraud label.

Scope: prospective fraud prediction.

Update: require a documented source and availability time for inputs.

Evaluation: test whether the agent detects outcome-derived inputs

without rejecting legitimate signals merely because they predict well.

This is where evals enter: repeatable tasks with explicit criteria for assessing the data science agent’s behavior. Here, we evaluate how the agent conducts the analysis, not only its model’s predictive performance. The evidence trail supplies concrete failures that can become test cases for proposed changes to its skills or workflow.

Keep the evals, skill versions, and results together. As reviewed assignments reveal new failure modes, expand the cases and rerun them when the agent’s setup changes. The aim is evidence that its analytical behavior improves, rather than a growing collection of instructions that merely sound sensible.

Workflow changes can accumulate in the same way. If a reviewer repeatedly catches a missing diagnostic, move that diagnostic earlier. If a separate reviewer adds cost but never changes the analysis, reconsider its role. If the agent repeatedly asks the same question about a table, improve the data context rather than supplying the answer again in chat.

A completed assignment need not always produce a new skill. A one-off constraint belongs in the project’s notes; a recurring methodological failure may justify standing guidance. That distinction keeps the next investigation from inheriting every exception encountered in the last one.

When other people use the agents you build

When colleagues use an agent without you mediating each request, your local knowledge has to become shared infrastructure. OpenAI’s internal data agent combines institutional context with query evaluations and existing user permissions. Meta’s Analytics Agent draws on prior analytical work and reusable guidance, exposing generated SQL alongside results. Both illustrate why earlier analyses and corrections belong in the system, not only in an analyst’s memory.

In your own work, you can explain an unfamiliar table or catch a misleading conclusion as it appears. When colleagues use the agent directly, that support must be built into the system. Try an assignment with a colleague and note where you need to step in. Missing context belongs in the agent’s guidance; recurring mistakes become evals; questions beyond its remit need a route to a qualified reviewer. Someone must maintain that guidance, and access controls must limit each user’s data access. The analytical principles stay the same, but the agent can no longer depend on you being present for every investigation.

Put the playbook to work

Choose a small investigation you understand well enough to challenge: a model you periodically retrain or a business metric you regularly explain. Give the agent the decision context and ask it to propose an approach. Agree on what it can decide, then let it carry the investigation far enough to produce evidence you can inspect.

At review, pay attention to where your intervention changes the work. Did the agent need a definition only your team knows? Did a diagnostic overturn its conclusion? If that intervention would help on another assignment, make the relevant context or check available there, and test whether it helps.

AI-native data scientists use their expertise to build and direct analytical agents. They turn lessons from reviewing an analysis into skills and checks, then test whether those changes help the agent on future tasks.

The next cohort of our Master Agentic Data Science course starts Oct 6.

Frontend code is often judged too quickly. If the build passes and the screen looks close to the design, it is tempting to treat the generated code as mostly done. But a user interface is not just a collection of components on a page. It is a path someone has to move through. It has to handle input, state, errors, loading, navigation, focus, responsiveness, and accessibility. Some of the most important failures are not visible in a screenshot.

This is why teams need better ways to evaluate AI-generated frontend code. They need evidence that the UI is ready for people to use.

Build and render are only the starting line

The easiest checks are usually the first ones teams run. Does the code compile? Does the page render? Are there obvious console errors? Does the component appear in the browser? Those checks matter, but they are only the starting line. A page can render while the form is difficult to complete. A modal can appear while focus remains behind it. A generated test can pass while the actual user flow is broken.

This is especially important with AI-generated code because the output often has a polished surface. The code may be formatted well, the component names may sound reasonable, and the test file may make the change look more complete than it is. That polish can make reviewers less likely to slow down and ask whether the interface actually works. A better evaluation process starts with a simple assumption: generated frontend code is a draft until the user behavior has been checked.

Start with the structure of the page

Before looking at more complex behavior, it is worth checking whether the generated UI has a sound structure. Frontend evaluation should include the basic semantics of the page, not just the visual layout.

That means checking whether the code uses native HTML where possible. A button should usually be a button, not a clickable div. A link should be used for navigation, not for actions that behave like buttons. A form field should have a label that is connected to it. These details are easy to overlook because the UI may look fine without them, but they affect how people navigate, how assistive technologies interpret the page, and how maintainable the code will be later.

AI tools sometimes choose generic containers where native elements would be better. They may also add ARIA without using it correctly. ARIA stands for Accessible Rich Internet Applications, a set of attributes defined by the W3C to help make web interfaces more accessible when native HTML is not enough. The W3C’s WAI-ARIA overview is a useful reference. ARIA can be important, but it should not be used as a substitute for the right HTML element. The first evaluation question should be: Did the generated code use the right building blocks?

Check the keyboard path

A useful frontend evaluation should include the keyboard path through the interface. Many users rely on keyboards or keyboard-like navigation, and keyboard testing also exposes problems in the interaction model.

The simplest test is often the most revealing: put the mouse aside and try to complete the task. If the flow becomes confusing, the generated code is not ready. Can you reach the important controls? Is the focus order logical? Can you open and close a dialog without a mouse? When the dialog closes, does focus return to a sensible place?

These checks are especially important for generated UI because AI can produce interactions that work for the most obvious mouse path but fail in less visible ways. A custom dropdown, for example, may open on click and look finished in a demo, but it may not respond correctly to keyboard input. That is not a small edge case. It is part of whether the interface is usable.

Test focus, not just clicks

Click-based tests are useful, but they can hide important problems. A test that clicks a button and waits for a success message may pass even when the same flow is frustrating for someone who is navigating by keyboard.

Focus behavior deserves its own attention, especially when the UI changes after the user takes an action. For example, when a form submission fails, the user should not be left guessing what happened. The error should be visible, connected to the relevant field when appropriate, and reachable in a way that makes recovery clear. In many cases, focus should move to the first error or to a summary that explains what needs attention.

The same idea applies to modals. When a modal opens, focus should move into it. When it closes, focus should return to the element that opened it. These are small details in code, but they make a large difference in whether the UI feels predictable.

Evaluate what happens when things go wrong

Generated frontend code often looks best in the happy path. The user fills everything in correctly, the network responds quickly, the data shape is exactly as expected, and nothing fails. Real interfaces spend a lot of time outside that path.

A practical evaluation should check what happens when data is missing, delayed, empty, invalid, or returned in an unexpected state. This is what I mean by loading, error, and empty states. They are the parts of the interface that explain what is happening when the ideal path breaks down. A loading state should help the user understand that something is in progress. An error state should explain what went wrong and what the user can do next. An empty state should make it clear whether there is nothing to show, whether the user needs to take action, or whether something failed quietly.

These cases are easy to leave for later because the happy path is usually enough to make the screen look finished. But users will eventually hit the less perfect paths. A generated component may include a spinner because the prompt asked for one, but that does not mean the loading experience is useful. An error message may say “Something went wrong,” but offer no recovery. Evaluation should include these cases because this is where many real user experiences break.

Test the full user flow

Component-level checks are helpful, but they do not always tell the full story. A component can work by itself and still fail when it is placed inside a larger flow.

That is why AI-generated frontend code should be evaluated through user tasks. Can someone start the flow, understand what is expected, recover from a mistake, submit successfully, and see what changed afterward? Does the interface still work on a smaller screen? Does the state remain consistent if the user goes back, edits something, or retries after a failure?

This is where Playwright-style tests or other end-to-end tests can be useful. The goal is not to automate every possible interaction. The goal is to protect the flows that matter most. A good test should determine whether the user can complete the task the component is supposed to support.

Use accessibility checks, but do not stop there

Automated accessibility checks are useful and should be part of the evaluation process. They can catch missing labels, invalid ARIA usage, some contrast issues, landmark problems, and other common mistakes. They are especially helpful when AI-generated code is moving quickly because they catch issues before they become repeated patterns.

But automated checks are not a complete accessibility review. They cannot fully judge whether a flow is understandable, whether focus movement feels natural, or whether instructions are clear. Passing an automated accessibility scan does not mean the UI is accessible. It means some common problems were not detected.

The best approach is to combine automated checks with behavior-based review. Run the tools, but also use the interface. Navigate by keyboard. Trigger an error. Try the empty state. Look at the generated code and ask whether native HTML could do more of the work. Accessibility evaluation is strongest when it is part of normal frontend quality, not a separate pass at the end.

Review the generated tests too

When AI generates code, it may also generate tests. That sounds helpful, but those tests need to be reviewed with the same care as the code.

Generated tests often reflect what the implementation already does. They may check that text appears, that a function was called, or that a component was rendered. Those checks are not useless, but they can create false confidence if they do not test meaningful behavior. A better review asks what the tests would catch if the UI broke. Would they fail if a validation error was unclear? Would they fail if the retry button did not work? Would they fail if keyboard navigation was broken?

If the answer is no, the tests may be documenting the implementation more than protecting the user experience. Teams can use AI to help write better tests, but the prompt matters. “Write tests for this component” is too vague. A better request explains the behavior that matters, such as validation recovery, loading behavior, successful submission, and focus movement. Even then, the generated tests still need human review.

Decide what evidence is enough

Not every UI change needs the same level of evaluation. A small copy update does not require the same review as a new checkout flow, onboarding flow, or account settings page. Teams need judgment.

A useful approach is to match the evaluation to the risk of the change. If the generated code affects a critical user flow, collects user input, changes navigation, introduces a custom interaction, or handles important status messages, it deserves deeper testing. If it reuses stable components in a familiar pattern, the review may be lighter.

There is no need to create a checklist for every pull request; clarity on what evidence is enough suffices. For some changes, a quick review and component test may be fine. For others, the team should expect keyboard testing, accessibility checks, error-state review, and a user-flow test. The point is to avoid treating all generated code as equally trustworthy just because it looks polished.

Human review still matters

AI can generate code and suggest tests, but it cannot fully understand the product, the users, or the trade-offs behind a frontend decision. It does not know which flows are most important, which interaction patterns users already rely on, or where inconsistency will cause confusion.

That is why human review remains central. The reviewer’s role is to ask whether the generated solution fits the system and supports the user’s task. Sometimes that means accepting the generated code. Sometimes it means asking for a simpler native element, reusing an existing component, improving the error recovery, or adding a test that reflects real behavior.

The more code AI generates, the more important this judgment becomes.

What should we actually test?

When AI writes frontend code, teams should test the parts of the interface that users depend on. That includes structure, keyboard access, focus behavior, loading and error states, form validation, responsive behavior, accessibility checks, and full user-flow completion. It also includes reviewing the generated tests themselves to make sure they protect behavior rather than merely confirming the current implementation.

The goal is not to slow down AI-assisted development. The goal is to make it safer to use. If AI reduces the time spent producing a first draft, teams have an opportunity to spend more time asking whether the software actually works properly.

That may be the real shift. In frontend development, the value of AI is not just faster code. It is the chance to move more engineering attention toward evaluation, user behavior, and quality.

AI-generated UI should not be trusted because it looks complete. It should be trusted because the team has checked the right things.

AI use acknowledgment

AI assistance was used lightly for phrasing, editing, and tightening parts of this draft. The article’s ideas, structure, examples, and final review are my own.

Author’s note

The views expressed are my own and do not represent those of my employer.